For a cup of tea 
3 Likes
one day 1 dirvine gonna buy you a house! 
9 Likes
It is 
I’m surprised you actually got that far, as that last request, to send from the faucet, has been failing due to an issue with how we send msgs in the network, that’s being solved right now.
That’s because atm, there is only one wallet for a client, and we only have the client path at .safe (just like for node). Later, there will be multiple for both.
So there is no address arg for balance.
All you need to do is call safe wallet balance and you’ll have your balance
10 Likes
Thursday again here we go it’s the peak of the week
12 Likes
How we looking guys?
5 Likes
suave and debonair as always.
3 Likes
So was I cos every time I tried it again I got an error like this
willie@gagarin:~/projects/maidsafe/safe_network$ RUST_BACKTRACE=1 cargo run --bin faucet --release -- send 6000005 8b3d495a878089f69717189bf95298797bbad2b711e179fbe1e4b621ef7e63e52a0b19d0a05815f9c1f1269e770ca285
Finished release [optimized] target(s) in 0.20s
Running `target/release/faucet send 6000005 8b3d495a878089f69717189bf95298797bbad2b711e179fbe1e4b621ef7e63e52a0b19d0a05815f9c1f1269e770ca285`
Loading genesis...
Genesis wallet balance: 0.000462664
Loading faucet...
Faucet wallet balance: 1288490188.499500000
Getting the closest peers to Spend(DbcAddress(c1d99e(11000001)..)).
Sending Query(Spend(GetFees { dbc_id: DbcId(PublicKey(1761..c98b)), priority: Normal })) to the closest peers.
Got response for the req: Query(Spend(GetFees { dbc_id: DbcId(PublicKey(1761..c98b)), priority: Normal })), res: GetFees(Ok(NodeId(a6226c(10100110)..)))
Got response for the req: Query(Spend(GetFees { dbc_id: DbcId(PublicKey(1761..c98b)), priority: Normal })), res: GetFees(Ok(NodeId(781eb1(01111000)..)))
Got response for the req: Query(Spend(GetFees { dbc_id: DbcId(PublicKey(1761..c98b)), priority: Normal })), res: GetFees(Ok(NodeId(84cdb9(10000100)..)))
Got response for the req: Query(Spend(GetFees { dbc_id: DbcId(PublicKey(1761..c98b)), priority: Normal })), res: GetFees(Ok(NodeId(b7a826(10110111)..)))
Got response for the req: Query(Spend(GetFees { dbc_id: DbcId(PublicKey(1761..c98b)), priority: Normal })), res: GetFees(Ok(NodeId(3f4709(00111111)..)))
Got response for the req: Query(Spend(GetFees { dbc_id: DbcId(PublicKey(1761..c98b)), priority: Normal })), res: GetFees(Ok(NodeId(e4037a(11100100)..)))
Got response for the req: Query(Spend(GetFees { dbc_id: DbcId(PublicKey(1761..c98b)), priority: Normal })), res: GetFees(Ok(NodeId(66d247(01100110)..)))
Got response for the req: Query(Spend(GetFees { dbc_id: DbcId(PublicKey(1761..c98b)), priority: Normal })), res: GetFees(Ok(NodeId(27cdfb(00100111)..)))
Getting the closest peers to DbcId(PublicKey(1761..c98b)).
Sending SpendDbc to the closest peers.
Network error: OutboundError(Timeout).
Network error: OutboundError(Timeout).
Network error: OutboundError(Timeout).
Network error: OutboundError(Timeout).
Network error: OutboundError(Timeout).
Network error: OutboundError(Timeout).
Network error: OutboundError(Timeout).
Network error: OutboundError(Timeout).
thread 'main' panicked at 'Tokens shall be successfully sent.: CouldNotSendTokens("Failed to verify transfer validity in the network Not enough close group nodes accepted the spend. Got 0, required: 5.")', /home/willie/projects/maidsafe/safe_network/safenode/src/domain/dbc_genesis.rs:91:10
stack backtrace:
0: rust_begin_unwind
at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/std/src/panicking.rs:575:5
1: core::panicking::panic_fmt
at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/core/src/panicking.rs:64:14
2: core::result::unwrap_failed
at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/core/src/result.rs:1790:5
3: safenode::domain::dbc_genesis::send::{{closure}}
4: tokio::runtime::park::CachedParkThread::block_on
5: tokio::runtime::runtime::Runtime::block_on
6: faucet::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
But you are probably quite familiar with that …
6 Likes
Joshnet?
Or a few roadblocks?
3 Likes
Do I dare to wish that, but based on my GH spying, there surely is a push to get the release process working again. 
6 Likes
Haha, 
9 Likes
Unless things change very fast, I think we will be getting another progress update but no testnet today, the latest from GH is still not releasing memory and is very chatty when just idling
running info or netinfo on the rpcclient causes a prolonged CPU spike and much memory consumed
THis graph shown pkill -e safenode at extreme left, then a couple of smallish > 500Mb uploads followed by querying netinfo on several rpc clients. One more largish upload would exhaust all the memory.
5 Likes
They’re still using in memory storage, so I imagine that’ll happen as it fills up. Hooopefully we’ll get more nodes though and wont max everything out near-instantly (if you can hold yersel back a weee bit @Southside 
)… And we’ve a balance to work out with node count/size as we go forwards too.
8 Likes
Not gonna happen
5 Likes
Go on Joshnet! Well done all. Only the start.
7 Likes
This is the issue I brought up when it was announced and the fee per input was in there. But my post ignored. Good to see others realised it and addressed the issue.
The network payment system would tend towards dust that can never be spent. How long, well the more its used the faster it’d be.
5 Likes
Yes, this is a big relief for me… I couldn’t get my head around how the previous way wouldn’t be a disaster, but didn’t have time to consider it deeply & thought I could be missing something.
Pleased to see it being addressed.
2 Likes
The description on that PR is a bit narrow though.
It could still be feasible as prices fluctuate. What is earned in high traffic (and cost) would be redeemed in low traffic (and cost).
And volume in high traffic is of course high, so that fees in low traffic would more seldom be redeemable wouldn’t necessarily be an issue.
Nonetheless I thought there was too much risk still and wanted to remove that risk completely, by using the reason field to make fees free to merge.
It’s quite simple actually, and would solve that issue completely.
But the reverse stake was an appealing idea at the time so that idea I had kind of got lost in all that.
The fee per tx, when I compared, would be more difficult and complex to implement.
8 Likes
Wouldn’t this solve the whole thing?
3 Likes
Yes it would.
You would keep the full value of the fees you earned.
7 Likes