Generate DID in ION SIDETREE testnet - blockchain

I have succeeded deploy the ION SIDETREE testnet.
I followed this install instruction. But when I created DID, it returned DID for mainnet.
I don't know where it's wrong.
Here is my configuration:
Step 1: I run bitcoin with this command:
root#ion:~/bitcoin-0.20.1# ./bin/bitcoind -testnet -rpcuser=admin -rpcpassword=admin -fallbackfee=0.0002 -txindex=1 -server
And here is the output log
Step 2: I config ION Sidetree
Here is my configuration:
root#ion:~/ion/json# cat testnet-bitcoin-config.json
{
"bitcoinDataDirectory": "/root/.bitcoin/testnet3",
"bitcoinFeeSpendingCutoffPeriodInBlocks": 1,
"bitcoinFeeSpendingCutoff": 0.001,
"bitcoinPeerUri": "http://localhost:18332",
"bitcoinRpcUsername": "admin",
"bitcoinRpcPassword": "admin",
"bitcoinWalletOrImportString": "cMj4VE3WyJt6RAQVGboDATFQ6YAVKo6fCVXw7oKuSpaAfNJqCuV1",
"databaseName": "ion-testnet-bitcoin",
"genesisBlockNumber": 1900000,
"logRequestError": true,
"mongoDbConnectionString": "mongodb://127.0.0.1:27017/",
"port": 3002,
"sidetreeTransactionFeeMarkupPercentage": 1,
"sidetreeTransactionPrefix": "ion:test",
"transactionPollPeriodInSeconds": 60,
"valueTimeLockUpdateEnabled": false,
"valueTimeLockAmountInBitcoins": 0,
"valueTimeLockPollPeriodInSeconds": 600,
"valueTimeLockTransactionFeesAmountInBitcoins": 0.0001
}
And
root#ion:~/ion/json# cat testnet-core-config.json
{
"batchingIntervalInSeconds": 600,
"blockchainServiceUri": "http://127.0.0.1:3002",
"databaseName": "ion-testnet-core",
"didMethodName": "ion:test",
"ipfsHttpApiEndpointUri": "http://127.0.0.1:5001",
"maxConcurrentDownloads": 20,
"mongoDbConnectionString": "mongodb://127.0.0.1:27017/",
"observingIntervalInSeconds": 60,
"port": 3000
}
Step 3: I run bitcoin
root#ion:~/ion# npm install
root#ion:~/ion/json# npm run build
root#ion:~/ion/json# npm run bitcoin
And here is the output log
Step 4: I run core
root#ion:~/ion# npm run core
And here is the output log
Step 5: I build ION
root#ion:~# cd ion/
root#ion:~/ion# npm install
root#ion:~/ion# npm run build
root#ion:~/ion# npm install -g .
Step 6: I generate DID
root#ion:~/ion# ion operation create
Here is the output log
Here is my problem, I don't know why I am running testnet but it created DID as mainnet. So, when I resolved DID, it proved this error
Thank you.

But when I use command "ion operation create"...
The CLI is completely experimental (as it is using a test library) and on development pause since last year, we did not anticipate anyone would know about it since we didn't advertise it on front page, but I have just opened a PR to make it use the ION SDK instead, it should be merged soon, I am not sure if it was working before my PR (probably was), but it should definitely work now.
That DID belongs to mainet.
The CLI was written with the assumption that it targets mainnet. But it is fine, the request will work perfectly fine against the testnet. The test: prefix in the DID string is purely cosmetic for the most part.
But with my DID (generate by myself), it shows this error
Since you are testing testnet DIDs and your node is setup as such ("didMethodName": "ion:test", seen in your config above), you must therefore prefix your unique DID suffix string with did:ion:test:<unique_suffix>, you didn't in your screenshot, hence the error. I hope this makes sense. The error message you are seeing in the screenshot also says exactly that.
Step 3: I resolve with DID "did:ion:test:EiC3YoSodQ20tJcgKjLXr65BHr2KwnQWsUnm3VOiYUFMeA", but It proved "not found"
ION DID tool should work. Sanity: assuming you've setup the node to be able to write, did you wait for that transaction to be confirmed? You can check by checking the transaction hash that is printed out when batch writer kicks in every 10 minutes (based on your conifg "batchingIntervalInSeconds": 600,). Even though the post request immediately returns a DID Document, that is just for your convenience to know that 1. the node accepted your request and queues it, and 2. shows what your DID Document will look like once it is confirmed, purely for your convenience. But we all know bitcoin transactions takes a while to confirm, especially on testnet, where the confirmation time is less predictable.

Related

HTCondor - Partitionable slot not working

I am following the tutorial on
Center for High Throughput Computing and Introduction to Configuration in the HTCondor website to set up a Partitionable slot. Before any configuration I run
condor_status
and get the following output.
I update the file 00-minicondor in /etc/condor/config.d by adding the following lines at the end of the file.
NUM_SLOTS = 1
NUM_SLOTS_TYPE_1 = 1
SLOT_TYPE_1 = cpus=4
SLOT_TYPE_1_PARTITIONABLE = TRUE
and reconfigure
sudo condor_reconfig
Now with
condor_status
I get this output as expected. Now, I run the following command to check everything is fine
condor_status -af Name Slotype Cpus
and find slot1#ip-172-31-54-214.ec2.internal undefined 1 instead of slot1#ip-172-31-54-214.ec2.internal Partitionable 4 61295 that is what I would expect. Moreover, when I try to summit a job that asks for more than 1 cpu it does not allocate space for it (It stays waiting forever) as it should.
I don't know if I made some mistake during the installation process or what could be happening. I would really appreciate any help!
EXTRA INFO: If it can be of any help have have installed HTCondor with the command
curl -fsSL https://get.htcondor.org | sudo /bin/bash -s – –no-dry-run
on Ubuntu 18.04 running on an old p2.xlarge instance (it has 4 cores).
UPDATE: After rebooting the whole thing it seems to be working. I can now send jobs with different CPUs requests and it will start them properly.
The only issue I would say persists is that Memory allocation is not showing properly, for example:
But in reality it is allocating enough memory for the job (in this case around 12 GB).
If I run again
condor_status -af Name Slotype Cpus
I still get something I am not supposed to
But at least it is showing the correct number of CPUs (even if it just says undefined).
What is the output of condor_q -better when the job is idle?

Cardano-cli query utxo fails

Error message I am trying to create a staking pool for cardano, i got the node up and running but cardano-cli is giving me a hard time. I have it installed as when i type cardano-cli version it returns infocardano-cli version.
However when i enter cardano-cli query utxo --mainnet --address $RECEIVER i get this error:
cardano-cli: Network.Socket.connect: <socket: 11>: does not exist (No such file or directory)root#vmi803461:~#
Could it be because the blockchain isn't fully synched?
I am running windows 10 with vs
node
Yes ivan p is correct however its also important to mention that there have been cardano node example scripts involving stakepools such as creating a shelley blockchain from scratch that had a bug for quite some time essentially causing multiple nodes to point to the same socket. If you're attempting to run multiple nodes - which you should be while running a stakepool, double check the precise path and location of the socket
cardano-cli requires both CARDANO_NODE_SOCKET_PATH variables installed in the shell and node server running to access it with the socket.
export CARDANO_NODE_SOCKET_PATH="/root/db/node.socket"
To query the balance of an address we need a running node and the
environment variable CARDANO_NODE_SOCKET_PATH set to the path of the
node.socket:

Nextjs export timeout configuration

I am building a website with NextJS that takes some time to build. It has to create a big dictionary, so when I run next dev it takes around 2 minutes to build.
The issue is, when I run next export to get a static version of the website there is a timeout problem, because the build takes (as I said before), 2 minutes, whihc exceeds the 60 seconds limit pre-configured in next.
In the NEXT documentation: https://nextjs.org/docs/messages/static-page-generation-timeout it explains that you can increase the timeout limit, whose default is 60 seconds: "Increase the timeout by changing the staticPageGenerationTimeout configuration option (default 60 in seconds)."
However it does not specify WHERE you can set that configuration option. In next.config.json? in package.json?
I could not find this information anywhere, and my blind tries of putting this parameter in some of the files mentioned before did not work out at all. So, Does anybody know how to set the timeout of next export? Thank you in advance.
They were a bit more clear in the basic-features/data-fetching part of the docs that it should be placed in the next.config.js
I added this to mine and it worked (got rid of the Error: Collecting page data for /path/[pk] is still timing out after 2 attempts. See more info here https://nextjs.org/docs/messages/page-data-collection-timeout build error):
// next.config.js
module.exports = {
// time in seconds of no pages generating during static
// generation before timing out
staticPageGenerationTimeout: 1000,
}

Twisted ssh - session execCommand implementation

Good day. I apologize for asking for obvious things because I'm writing in PHP and I know Python at the level "I started learning this yesterday". I've already spent a few days on this - but to no avail.
I downloaded twisted example of the SSH server for version 20.3 from here https://docs.twistedmatrix.com/en/twisted-20.3.0/conch/examples/. Line 162 has an execCommand method that I need to implement to make it work. Then I noticed a comment in this method "We don't support command execution sessions". Therefore, the question: Is this comment apply only to the example, or twisted library entirely. Ie, is it possible to implement this method to make the example server will work as I need?
More information. I don't think that this info is required to answer my questions above.
Why do I need it? I'm trying to compile an environment for writing functional (!) tests (there would be no such problems with the unit tests, I guess). Our API uses the SSH client (phpseclib / SSH2) by 30%+ of endpoints. Whatever I do, I had only 3 options of the results depending on how did I implement this method: (result: success, response: "" - empty; result: success, response: "1"; result: failed, response: "Unable to fulfill channel request at… SSH2.php:3853"). Those were for an SSH2 Client. If the error occurs (3rd case), the server shows logs in the terminal:
[SSHServerTransport, 0,127.0.0.1] Got remote error, code 11 reason: ""
[SSHServerTransport, 0,127.0.0.1] connection lost
I just found this works:
def execCommand(self, protocol, cmd):
protocol.write('Some text to return')
protocol.session.conn.sendEOF(protocol.session)
If I don't send EOF the client throws a timeout error.

Occasional Date or timezone discrepancy in hudson or maven with jodatime

I hope following explanation will make sense because it's a weird problem we're facing and hard to describe.
We have a maven project which gets build in hudson and that contains some unit tests where dates are used and asserted. The hudson server runs on solaris. Now, occasionally (like 30% of the times) the unit tests using dates fail because 3,5 hours are deducted from the specified time in the unit test and hence asserts start failing. The other 70% everything works fine although nothing at all changed in the code and we run the hudson job several times an hour.
I add following code to a unittest to check the time:
#Test
public void testDate() {
System.out.println("new DateMidnight(2011, 1, 5).toDate();");
System.out.println(new DateMidnight(2011, 1, 5).toDate());
System.out.println(new DateMidnight(2011, 1, 5).toDate().getTime());
Calendar cal = Calendar.getInstance();
cal.set(Calendar.YEAR, 2011);
cal.set(Calendar.MONTH, 0);
cal.set(Calendar.DAY_OF_MONTH, 5);
cal.set(Calendar.HOUR, 0);
cal.set(Calendar.MINUTE, 0);
cal.set(Calendar.SECOND, 0);
cal.set(Calendar.MILLISECOND, 0);
System.out.println("cal.getTime();");
System.out.println(cal.getTime());
System.out.println(cal.getTime().getTime());
}
So basically it should print the same thing when using jodatime or plain old Calendar. This is the case in 70% of the runs; for the other 30% I get following printouts:
Running TestSuite
new DateMidnight(2011, 1, 5).toDate();
Tue Jan 04 21:30:00 MET 2011
1294173000000
cal.getTime();
Wed Jan 05 12:00:00 MET 2011
1294225200000
So, Calendar keeps the correct date and time but jodatime deducts 3,5 hours.
Local maven tests never appear the pose this problem and we can't figure out what could be the cause of it. Especially, we can't think of a single reason why the tests sometimes pass and sometimes fail without changing any code nor hudson or server setting.
Also, we run the maven install with cobertura which means that the unit tests are run twice. It happens also that they pass the first time and fail the second time or the other way around or that they fail both times.
Thanks for any solutions or tips to track down the cause,
Stijn
You may also be running into some version of SUREFIRE-533, which should be solvable by setting the TZ environment variable in the environment that is running hudson. Please report back on the issue if this helps.
Perhaps Hudson is running on 3 servers, and 1 has a different version of the time zone data in the JDK from the other 2? (check the JVM version in detail). Remember that Joda-Time also has its own version of the time-zone data, and the two may be different.
The problem seems to be fixed now.
We've upgraded our jodatime version from 5.14.2 to 5.14.6.
Since then I ran the build on auto each half hour so after about a 100 runs we never encountered this problem again.