[ValentinesNet] [14/2/24 Testnet] [Offline]

If you post your address I’ll send you some monopoly money.

2 Likes

No worries at the moment, I seem to have gotten sufficient coin balance from my local faucet server, and now attempting a safe files upload. Not sure if it will proceed further successfully or not (currently chunking the ubuntu iso).

1 Like

What was the input for the faucet? Coin you had earned through storage, a previous hit of the original faucet to an address you have or somehow the original faucet?!

1 Like

As far as I can tell nothing to do with the URL or address of the original faucet.

./faucet claim-genesis
./faucet server &
./safe wallet get-faucet 127.0.0.1:8000

That allowed me to obtain coins, though now I am curious if its actually going to allow me to spend it on the network when uploading… looks like the chunking took place… currently uploading 60 out of 9411 chunks for ubuntu.iso.

Update:

Interesting, it didn’t charge me for the 2 extra chunks:

"ubuntu.iso" 80d88c666263718d9ee271acdf38710065d4cc235837eed7fa7314f0a53d8080
Among 9411 chunks, found 9409 already existed in network, uploaded the leftover 2 chunks in 35 minutes 46 seconds
**************************************
*          Payment Details           *
**************************************
Made payment of 0.000000000 for 2 chunks
Made payment of 0.000000000 for royalties fees
New wallet balance: 200.000000000

Attempted a new random 10 mb file:

safe-node-142:# ./safe files upload .../32bc7c49-a40d-4a2c-bbb8-3a773b33d00a.txt 
Logging to directory: "/.../.local/share/safe/client/logs/log_2024-02-24_18-31-54"
Built with git version: 07afae78 / HEAD / 07afae78
Instantiating a SAFE client...
Connecting to the network with 1 peers
⠄ Connecting to The SAFE Network...                                                                                                                                                                                                         Metrics server on http://0.0.0.0:36475/metrics
🔗 Connected to the Network                                                                                                                                                                                                                 Starting to chunk ".../32bc7c49-a40d-4a2c-bbb8-3a773b33d00a.txt" now.
Chunking 1 files...
Uploading 20 chunks
**************************************
*          Uploaded Files            *
*                                    *
*  These are not public by default.  *
*     Reupload with `-p` option      *
*      to publish the datamaps.      *
**************************************
"32bc7c49-a40d-4a2c-bbb8-3a773b33d00a.txt" 3f0289b641184dc1957a9247d3db938e2227dc4b235b220e0fb84f206a0d18c7
Among 20 chunks, found 0 already existed in network, uploaded the leftover 20 chunks in 2 minutes 17 seconds
**************************************
*          Payment Details           *
**************************************
Made payment of 0.000049976 for 20 chunks
Made payment of 0.000008810 for royalties fees
New wallet balance: 199.999941214

Is this some sort of double spend here or whatever may be the term? Assuming I am not even suppose to have some of the genesis coin supply in a local faucet wallet and then being able to transfer it to my own local wallet and then being able to spend it against the network?

Seems I was also able to retrieve the uploaded 10MB file successfully:

safe-node-142:# ./safe files download dummy.txt 3f0289b641184dc1957a9247d3db938e2227dc4b235b220e0fb84f206a0d18c7
Logging to directory: "/.../.local/share/safe/client/logs/log_2024-02-24_18-54-38"
Built with git version: 07afae78 / HEAD / 07afae78
Instantiating a SAFE client...
Connecting to the network with 1 peers
⠄ Connecting to The SAFE Network...                                                                                                                                                                                                         
Metrics server on http://0.0.0.0:35841/metrics
🔗 Connected to the Network                                                                                                                                                                                                                 
Downloading "dummy.txt" from 3f0289b641184dc1957a9247d3db938e2227dc4b235b220e0fb84f206a0d18c7 with batch-size 16
Saved "dummy.txt" at /.../.local/share/safe/client/dummy.txt

safe-node-142:# cat /.../.local/share/safe/client/dummy.txt | md5sum 
5ead157b00a705094a9df4ae71b44bae  -
safe-node-142:# cat /.../32bc7c49-a40d-4a2c-bbb8-3a773b33d00a.txt | md5sum 
5ead157b00a705094a9df4ae71b44bae  -

Further Updates:

Ran the safe wallet audit command and it threw out the following errors:

safe-node-142:# ./safe wallet audit
Logging to directory: "/.../.local/share/safe/client/logs/log_2024-02-24_18-45-53"
Built with git version: 07afae78 / HEAD / 07afae78
Instantiating a SAFE client...
Connecting to the network with 1 peers
⠄ Connecting to The SAFE Network...                                                                                                                                                                                                         
Metrics server on http://0.0.0.0:35399/metrics
🔗 Connected to the Network                                                                                                                                                                                                                 
Auditing the Currency, note that this might take a very long time...
Error: 
   0: Failed to verify transfer validity in the network Failed to verify transfer validity in the network failed to get spend at SpendAddress(153cdd): GetRecordError(SplitRecord { result_map_count: 2 })

Location:
   sn_cli/src/subcommands/wallet/audit.rs:47

12 Likes

What?! Did I get it: You managed to use homemade coins for uploading? :exploding_head:

6 Likes

Hmmm, I just followed the readme.md for the faucet and it happened to work from a local server instantiation. Now, whether this should have been prevented, i.e the claim of the genesis supply a 2nd time … I don’t know if that is part of the code base already, or overlooked as this whole faucet mechanism might be temporary means to do these testnets at this time, and not the complete solution yet for the final live network?? :man_shrugging: .

I can’t imagine having two faucets claiming the genesis supply independently and allowing it to be spent is good thing for the network, assuming if that is actually what is happening here? :man_shrugging:

On the other hand, I am not sure on the balance in Maidsafe’s faucet address at this time. Did the supply accidentally double here? I am unclear on the full consequences here, as it allowed me to spend SNT obtained not directly from MaidSafe’s faucet in terms of payment to the nodes.

The safe wallet audit command did log the following errors, which I thought were interesting in this scenario:

[2024-02-24T18:49:05.786654Z INFO sn_networking] Getting record from network of 153cdd(28542e01c860f392444a2e424fa829cb5b83959cd1c4a0bd0f0b7d5f92123c94). with cfg GetRecordCfg { get_quorum: Majority, retry_strategy: Some(Balanced), target_record: "None", expected_holders: {} }
[2024-02-24T18:49:05.789844Z DEBUG sn_networking::cmd] Record 153cdd(28542e01c860f392444a2e424fa829cb5b83959cd1c4a0bd0f0b7d5f92123c94) with task QueryId(23) expected to be held by {}
[2024-02-24T18:49:05.789889Z INFO sn_networking::cmd] We now have 1 pending get record attempts and cached 0 fetched copies
[2024-02-24T18:49:06.026030Z DEBUG sn_networking::get_record_handler] For record 153cdd(28542e01c860f392444a2e424fa829cb5b83959cd1c4a0bd0f0b7d5f92123c94) task QueryId(23), fetch completed with split record
[2024-02-24T18:49:06.026150Z ERROR sn_networking] Encountered a split record for 153cdd(28542e01c860f392444a2e424fa829cb5b83959cd1c4a0bd0f0b7d5f92123c94).

Will wait on Maidsafe’s feedback, :grin: :crossed_fingers:

Update:

I decided to send all my wallet’s balance to myself first, which succeeded (send and receive), then I sent all of it to @Southside post, as I saw a wallet address posted earlier:

Wallet Address: 91ee9092e04e95f07c4a77f6c1e6e1f52291ce571e81407ef84d18f2d132ebe9f2fe481f1938ff99e7761849a6b9f040

The network seemed to have subtracted the coins and generate the receipient’s encrypted transfer payload:

Transmission #1 : 4a04b3ccdecceccc5e171916024ad9cc7f6450a4cca2cc94ccc8ccf7cc80cc3e8bcc05d1ccdbcc1eb6cc342beacc13b4cce3ccedccd7cc15d6cc3330afcc2e064d9ecc11070ca0cccccc8ecc93cc6c87cc501894cc90cc4832a6cccacc42b4cc38eecc8fcc8ecc6af7cc7ffdcc3ab1cc5b252a576908fdcc4b793a368fccadccdfccc3ccb6cc79bbcc89ccdccc04a3cc6000dcd7ccbfcc0258140da8cc7acdcc73b5ccaecc49e9cc93cc0c782acacc2deacce9cc6c587c51cccc8dccd8cce9cc741e98cceaccdfcc5496cc246ac8cc5d132342383ebbcc89cc2c12b9cc6287cc7ccecc3ac4cc9fcc31683ae9cc65262dcdcc88cc7b260befcc7a8ccc242cf2cc4a088cccfbccbaccbfcc76e8cc99cc6e46deccd4ccb1cca8cce6cca9cc06c3ccbecc6000dcb0cc81ccb9ccdecc37d2ccdccc4e8accfacc9acc1603764f2fadcc72fecc2566c7cc724797cc2464aecc57ebcc6f3747fccca0cc2ca8ccc3cc4f6ebbcc21c6cc9dcc7204dccc81cc3000dc9391646574707972636e45a981
Transmission #2: 7c230093cc9bcc3728e5cceaccf7ccd5cc2094cc30d9cc57c6cccbcc3401d5cc216ba6cccdccdecc43e1cc37505197ccc5cc762bb8cc5eaaccfecc1fa8cc55dacc96ccf9cc30ddcc10130ad6cc2e6c8bcc402b7948c5cc32c5cc8eccbfcc54d2ccabcc427faeccb0cc11eccc0231fbcc32c9cc48a1cc5cb6cc74658ccc6215b6cc42fdcc82ccf1cc85cceaccabccaecc8bcc6000dc2c456d4ff0ccfccc80cc0259cdcc3bd4cce2cc8fccb0ccefccdccca0cc41afcc086879320878cfccf8cc98cce9ccd9cca5ccc0cc6e1596cc035d726e5984cc95ccd5cc22d4cc6a8acce5cca7cc220d2887cc202a19161d180771b6cc0bf6ccd8ccb9cc98ccd1cc425f87cccecc53450fadcce8cc710859d8ccb5cccccc3e75bcccfccc5e4c56f5cc58b8cc521a13d5cc3b6300dc6fc6cc683bf5cc38d9ccfecccbccb4cc166ccacc365ea6cc59c1cc370e1fcfccebcc8ecc2b78e6ccbecc1d4504e2ccc1cc84cc3417a4cc6a610420cacc64e9cc43191884cc3000dc9391646574707972636e45a981
Transmission #3: d7cce2cc88cca8cccbcc02a8cc6aa2ccc1cc3d0e379dcc3e4ac9cc5c605d9fcc3160a1ccb3cc4e86cce7ccdbccfacc2d1b025259fecc18fbcc5f2e5e83ccafcca4cc3781cc220fa7cc78bbcc3a86cc71c9cc2ea5ccd7cc782a337d6522c0cceccc7ff6cc77eacc82cc29f8cc0d20c4ccbdcc586e3958d4ccb7ccdccc4934685da5cc89cc21e3cc3d091996cc6000dcb4cc81cc6eeeccbccca3cc5f0182cc7ad9cc80ccc3ccc3ccb5cc0a30b2ccbacc0972a1cc9fcc18728accc3cc13e4cc41c8cc87cc78657012234951c1cc2e4be5cc6488ccfcccdecc0de1cc7b9accd4cc169cccc8ccf1cc59e1cc1a323ec3cc6d9dcce1ccdecc7bcccc0492cc6b72e6ccd4ccfbcc77c7ccebccc7cc7afbccfacc8bccb6cceecc83cc8eccc4ccbbccf3cce6cc4176325e00dca7cca5cc71c2cc7621b0ccdbcc5f84ccd9cc740810a5cc6a0994cc582e82ccebcc08a4cc22d8cc726c763bbacca8cc1e565f5f31caccefcc3df7ccf7cc2ab9ccc8cc56d9cca1cc3000dc9391646574707972636e45a981

This time when I ran safe wallet audit with a wallet balance of 0, it showed the following with a successful completion, but no errors unlike the prior time when I had > 0 balance:

Auditing the Currency, note that this might take a very long time...
Generation 0 - Found first spend: SpendAddress(153cdd)
Generation 1 - Found 0 UTXOs and 1 Spends in 564.660187ms
Generation 2 - Found 1 UTXOs and 1 Spends in 59.329380533s
Generation 3 - Found 0 UTXOs and 2 Spends in 64.720062201s
Generation 4 - Found 2 UTXOs and 3 Spends in 122.457792277s
Generation 5 - Found 11 UTXOs and 3 Spends in 305.135033929s
Generation 6 - Found 4 UTXOs and 4 Spends in 421.319832405s
Generation 7 - Found 4 UTXOs and 3 Spends in 538.680933731s
Generation 8 - Found 5 UTXOs and 3 Spends in 713.444161845s
Generation 9 - Found 5 UTXOs and 3 Spends in 870.39943111s
Generation 10 - Found 11 UTXOs and 2 Spends in 1038.471056975s
Generation 11 - Found 2 UTXOs and 1 Spends in 1099.863317295s
Finished auditing! Through 11 generations, found 45 UTXOs and verified 24 Transactions in 1099.863450058s

10 Likes

Sounds like a heat pump malfunction.

You need solar panels bad. $.14 per kWh in Mid-Atlantic region of U.S., about average for USA I think.

2 Likes

So looking at the network graphs for my AWS Instance with a single node on it it’s clear the network has had a bit of a bad day. It looks like there was a bit of a crisis at 0230. I think quite a few nodes have left because all my nodes are busier from that point. It looks like there was a period of some turmoil but then things settled down.

Download of a 2.3GB file took less than 4 mins.

Uploads are still working!

6 Likes

I decided to change the faucet code to send me a super large supply… to my safe client wallet… and ended up draining my local faucet… forgive me for pretending to be a bad actor on this testnet at this time… (please): .

Logging to directory: "/.../.local/share/safe/client/logs/log_2024-02-24_23-03-58"
Built with git version: 07afae78 / HEAD / 07afae78
Instantiating a SAFE client...
Connecting to the network with 1 peers
⠄ Connecting to The SAFE Network...                                                                                                                                                                                                         
Metrics server on http://0.0.0.0:34465/metrics
🔗 Connected to the Network                                                                                                                                                                                                                 
Requesting token for wallet address: b8447eb004f3db5a7cc6c7503c16b59a035e9b67c4ad1477d33e1d494520e11acadfbf5bf33e6a5b053b3829f4201996
Successfully parsed transfer. 
Verifying transfer with the Network...
Successfully verified transfer.
Successfully stored cash_note to wallet dir.
Old balance: 0.000000000
New balance: 1288489788.500000000
Successfully got tokens from faucet.

FWIW, If the faucet is restarted, it seems to get ‘1288490188.500000000’ as starting balance, however, it failed on the first attempt to claim that on its faucet wallet… but surprisingly worked on the 2nd attempt. Then I tried to send that supply to a 2nd wallet address, which resulted in an error by the network:

Faucet wallet balance: 1288490188.500000000
Failed to send tokens to a2a87560e5ad1c61594b4108bc69ece20be0a34855fb9b4cf619703b17f09e8b68fdd30b97f7e157ba6a7427503006e1: Transfer Error Failed to send tokens due to The transfer was not successfully registered in the network: CouldNotSendMoney("Network Error GetRecord Query Error RecordNotFound.").
Failed to get tokens from faucet, server responded with: "Failed to send tokens: Transfer Error Failed to send tokens due to The transfer was not successfully registered in the network: CouldNotSendMoney(\"Network Error GetRecord Query Error RecordNotFound.\").

But on a 2nd attempt it did parse the transfer, and verified the transfer. Now, I have two wallets with very high amount of balances:

safe-node-142# ./safe wallet balance
Logging to directory: "/.../.local/share/safe/client/logs/log_2024-02-24_23-15-58"
Built with git version: 07afae78 / HEAD / 07afae78
1288489788.500000000

safe-node-143:# ./safe wallet balance
Logging to directory: "/.../.local/share/safe/client/logs/log_2024-02-24_23-26-25"
Built with git version: 07afae78 / HEAD / 07afae78
1288490188.500000000

I realize all of this faucet concept is under development and is a work in progress, and MaidSafe likely didn’t intend anyone to change the limit from 100 coins to such a high amount, so forgive me for experimenting around against this testnet… I was just too curious to see what would be allowed, and what would error out under what scenarios, :grin: .

The wallets with large amount did succeed from wallet A → B as well:

Built with git version: 07afae78 / HEAD / 07afae78
Instantiating a SAFE client...
Connecting to the network with 1 peers
⠄ Connecting to The SAFE Network...                                                                                                                                                                                                         
Metrics server on http://0.0.0.0:37361/metrics
🔗 Connected to the Network                                                                                                                                                                                                                 
Successfully parsed transfer. 
Verifying transfer with the Network...
Successfully verified transfer.
Successfully stored cash_note to wallet dir.
Old balance: 1288490188.500000000
New balance: 2576979977.00000000
9 Likes

Great testing!

I wonder if it’s something like this:

If tokens are not audited all the way to genesis, then tokens from different genesis are not recognized as double spend. They are somehow “inherently valid”.

I hope that’s not the case. Even if it is, I guess it wouldn’t be that difficult to make each genesis unique so that the tokens from new genesis immediately be seen as counterfeit.

2 Likes

I intentionally stopped a upload (ctrl c while uploading) (say it uploaded X of Y chunks), and try to resume it, it seems its aware of prior chunks uploaded including payments for those chunks being handled, but it stalls on the remaining Y - X chunks that are left to be uploaded:

PS > .../safe_binaries/safe wallet balance;  .../safe_binaries/safe files upload $files[2]

Logging to directory: "/.../.local/share/safe/client/logs/log_2024-02-25_06-12-35"
Built with git version: 07afae78 / HEAD / 07afae78
2576979976.999869049
Logging to directory: "/.../.local/share/safe/client/logs/log_2024-02-25_06-12-35"
Built with git version: 07afae78 / HEAD / 07afae78
Instantiating a SAFE client...
Connecting to the network with 48 peers
⠂ Connecting to The SAFE Network...                                                                                                                                                                                                         Metrics server on http://0.0.0.0:37303/metrics
🔗 Connected to the Network                                                                                                                                                                                                                 Starting to chunk ".../uploads/004e0837-df21-425e-ac26-32264d3f6ae9.txt" now.
Chunking 1 files...
Uploading 20 chunks
⠐ [00:00:02] [##########>-----------------------------] 5/20                                                                                                                                                                                ^C

PS >.../safe wallet balance;  .../safe_binaries/safe files upload $files[2]
Logging to directory: "/.../.local/share/safe/client/logs/log_2024-02-25_06-12-41"
Built with git version: 07afae78 / HEAD / 07afae78
2576979976.999863119
Logging to directory: "/.../.local/share/safe/client/logs/log_2024-02-25_06-12-41"
Built with git version: 07afae78 / HEAD / 07afae78
Instantiating a SAFE client...
Connecting to the network with 48 peers
⠂ Connecting to The SAFE Network...                                                                                                                                                                                                         Metrics server on http://0.0.0.0:37421/metrics
🔗 Connected to the Network                                                                                                                                                                                                                 Starting to chunk ".../uploads/004e0837-df21-425e-ac26-32264d3f6ae9.txt" now.
Uploading 15 chunks
⠐ [00:04:00] [---------------------------------------] 0/15      

The safe client doesn’t seem to be exiting… my guess is it shouldn’t take minutes to upload the remaining 15 chunks for a 10MB file as without the CTRL + C, its roughly a minute or less operation for a random set of 20 chunks (10MB).

I repeated the attempts at uploading other random 10MB guid file names after a forced CTRL+C after 5 out of 20 chunks were uploaded successfully and it seems to get the client stalled at 0/15 chunk with 0% progress. I let it run for 30 minutes and no progress. I tried this on two separate LXCs, and same result. I swapped out the peers from 48 to 1 (first one in the network-contacts list), but no impact on the results.

At some point, I tried clearing the chunk_artifacts and uploaded_files local folders, and it got through the the first 5 out of 20 chunks, but then again stalled on the remaining 15.

Anyone else tried this particular sequence of steps and get the same results?

Update:

This common type of ERROR message caught my attention in the safe client logs on two separate LXCs with different wallet addresses (30 minute duration):

[2024-02-25T08:14:50.158273Z ERROR sn_client::files::upload] When paying 2 chunks, got error CouldNotSendMoney("Wallet has pre-unconfirmed transactions. Resend, and try again.")
[2024-02-25T08:17:58.599311Z ERROR sn_client::files::upload] When paying 1 chunks, got error CouldNotSendMoney("Wallet has pre-unconfirmed transactions. Resend, and try again.")
[2024-02-25T08:21:44.006825Z ERROR sn_client::files::upload] When paying 1 chunks, got error CouldNotSendMoney("Wallet has pre-unconfirmed transactions. Resend, and try again.")
[2024-02-25T08:25:28.642010Z ERROR sn_client::files::upload] When paying 1 chunks, got error CouldNotSendMoney("Wallet has pre-unconfirmed transactions. Resend, and try again.")
[2024-02-25T08:29:23.425234Z ERROR sn_client::files::upload] When paying 1 chunks, got error CouldNotSendMoney("Wallet has pre-unconfirmed transactions. Resend, and try again.")
[2024-02-25T08:32:36.011301Z ERROR sn_client::files::upload] When paying 1 chunks, got error CouldNotSendMoney("Wallet has pre-unconfirmed transactions. Resend, and try again.")

There were also a few WARN that caught my attention during the 30 minute waiting period:

[2024-02-25T08:11:04.548134Z WARN sn_networking] No holder of record 'c8994e(9822bff528e0d46b691112161fe6e8d77b96a4f66fe125bb7ea841926dc61834)' found.
...
[2024-02-25T08:40:39.972502Z WARN sn_networking] Failed to PUT record with key: c8994e(9822bff528e0d46b691112161fe6e8d77b96a4f66fe125bb7ea841926dc61834) to network (retry via backoff) with error: GetRecordError(RecordNotFound)
...
[2024-02-25T08:41:02.364776Z WARN sn_networking] No holder of record 'c8994e(9822bff528e0d46b691112161fe6e8d77b96a4f66fe125bb7ea841926dc61834)' found.

Similar type of messages on both LXCs and test runs.

8 Likes

@Shu systematically testing possible error cases with the testnet and finding reproducible bugs :hugs: :partying_face:

9 Likes

Right now, I can’t do a send of a random coin amount between my wallets with a mega big balance to a new wallet with 0 balance, it just stalls after showing Connected to the Network. :frowning: . This worked a few hours ago…

Maybe its due to the Wallet has pre-unconfirmed transactions issue possibly caused by a CTRL + C mid way while uploading (noted in earlier post)? I don’t really know.

I am still able to download the original ‘ubuntu.iso’ at 80d88c666263718d9ee271acdf38710065d4cc235837eed7fa7314f0a53d8080.

Would be curious if the network is still in a healthy state or not from others’ perspective and experimentation? If not, what tipped the scale, and caused it to be not so healthy? :smile: .

4 Likes

That’s the error that can occur when there is a problem with an upload. If you clear out the wallet, create a new one and send it some funds it should work.

2 Likes

Makes sense. Thanks. I didn’t want to loose the wallets’ balance else back to the local faucet it is for now :smiley: . The transfer finally error’ed out confirming it was due to the unconfirmed transactions :

Error: 
   0: Transfer Error Unconfirmed transactions still persist even after retries.
   1: Unconfirmed transactions still persist even after retries

Decided to try a random 20 chunk file again. This time I let it run its course, and it seems it took ~94 minutes, but it said it uploaded the left over chunks to the network, when they weren’t found before, yet no payments were charged for the 20 chunks but also not a new address for the payload was generated or shared. I am guessing this is all because of potentially CTRL + C earlier with these wallets and the wallets getting in a bad shape.

However, I am still confused by the message, the part of uploaded the 20 chunks to the network. How could that happen without a address generated and no payment taken? :thinking: .

safe-node-143# ./safe files upload ../uploads/8896f68c-63c7-49b4-ae4d-eee798353a03.txt 
Logging to directory: "/.../.local/share/safe/client/logs/log_2024-02-25_08-54-58"
Built with git version: 07afae78 / HEAD / 07afae78
Instantiating a SAFE client...
Connecting to the network with 1 peers
⠄ Connecting to The SAFE Network...                                                                                                                                                                                                         Metrics server on http://0.0.0.0:37141/metrics
🔗 Connected to the Network                                                                                                                                                                                                                 Starting to chunk "../uploads/8896f68c-63c7-49b4-ae4d-eee798353a03.txt" now.
Chunking 1 files...
Uploading 20 chunks
⠂ [00:46:54] [----------------------------------------] 0/20                                                                                                                                                                                Retrying failed chunks 20 ...
Unverified file "8896f68c-63c7-49b4-ae4d-eee798353a03.txt", suggest to re-upload again.
**************************************
*          Uploaded Files            *
*                                    *
*  These are not public by default.  *
*     Reupload with `-p` option      *
*      to publish the datamaps.      *
**************************************
Among 20 chunks, found 0 already existed in network, uploaded the leftover 20 chunks in 93 minutes 54 seconds
**************************************
*          Payment Details           *
**************************************
Made payment of 0.000000000 for 20 chunks
Made payment of 0.000000000 for royalties fees
New wallet balance: 1288490188.499979957
1 Like

I’m finding it is worthwhile trying a lower batch size both when uploading and downloading if you have problems with the default or f 16. It’s not really any slower but is more reliable. I’ve been using 4 but 8 is good as well.

2 Likes

My 69 chunks upload is persistently failing 3 chunks.

Can anyone spare an SNT? 12D3KooWBGnPSM7c9KEUSCpgJaXGgopp8j3BuGe7iPbcfWrVNj4A

3 Likes

That’s your node ID, I think you cannot send there. Check the address from client/wallet/main_pubkey

EDIT: And be quick, I’m just about to got to bed,

2 Likes