Depends how you cook it.
I expect.
Depends how you cook it.
I expect.
Same here A staple of Egyptian cooking apparently.
I only found this out after paying like £2 for a tin of fava beans in a posh deli. Then realised I could have got them for ~40p in Lidl…
Grow really well here in Tassie - probably about the same for UK? Plant in the late summer or late winter -same as peas. I always have heaps.
I hope this doesn’t come across as me being negative, it has been on my mind and I have refrained but it is a niggle that wont go to rest.
Why QUIC now?
I understand it is better, it is the future it is faster than ducks and all that, but it is also a little like quic-sand, it has slowed progress.
What was so wrong with the stable, boring albeit slower TCP network as a interim stopping point to focus on other aspects of the project.
I guess what this boils down to is the concern a few people occasionally raise of always chasing better.
To be clear I dont generally agree with that sentiment but here I am on the fence.
From what I can see it was more that enough progress was made with tcp and the quic has to be introduced sometime. And maybe quic has been updated enough to be workable. I would also think that the additional speed it provides is needed anyhow as well as being a much better protocol for distributed systems.
Get the pain of switching done now before beta
I get that, the concern is that quic-er v8 turbo comes along before beta and…
I see it as testing. Without that how can they know if Quic is ready?
QUIC is a multi year project to get here. It’s for sure the future and well worth testing out. It should be much faster and much more secure. Rather than us doing all our own DOS prevention etc. then the QUIC spec handles much of it, amongst other things.
A big issue for us over time is hole punch and udp based protocols were much better. Although in fairness TCP hole punch has come a long way. This is why historically we have plunged probably more than 25% of resources into udp based libs to do effectively what QUIC does, but QUIC is substantially better than all our old libs.
I should add, upgrade from TCP to QUIC is something that would be a significant PITA.
True, the question is time and place.
Is quic a case of perfect being the enemy of good was tcp not good enough for beta.
The thing is we finally had what appeared to be a stable base, that was more exciting than performance improvements.
It is very possible that this is not purely a performance improvement and if that is the case, my question will be answered?
Edit:
@dirvine added context as to why during my typing of the above!
From a my perspective, if network devs are anything like game devs, they can’t help themselves.
2 reasons I stopped participating in test-nets:
my knowledge of networking is limited.
No time, too busy jumping off from pancake game dev, to newer, more exciting VR dev, to now, since Quest 3, and Apple vision pro, mixed reality dev. Everything is moving so fast, right?
If the team is like me, they are eager to try something new, if it means better, more efficient end result.
I rebuilt the entire UE4 engine from GitHub, just to enable 2 new features. But it got me a 30% frame rate boost. So the short delay made the end result way better!
I think having a blazing fast network through QUIC is really important to the end user. Just my opinion. It feels like it needs it, to take the network to the next level.
I get that it feels like a bit of a delay, but this project has always been a marathon not a sprint. And to that, it also feels like the race is almost won, Cheers
Isn’t QUIC already in place now and working? It only appeared to take a week or two to swap it out with TCP stack … or am I missing something and there is still much more to do? Because it appears to me (and maybe others?) that it’s already done.
I certainly didn’t feel that pre-QUIC was stable and working well yet. And it has sped up the network a lot IMO and in the opinion of a few others (as I have read). So really not sure what the issue is. User experience is going to be a big issue going forward and TCP stack really doesn’t seem up to the task for a network like this. Also Hole punching would be nice, but it’s not nearly as important as the speed we get with QUIC because people who run nodes (particularly in the beginning) are going to be nerds/geeks anyway and it’s the users (clients) who are going to drive the growth of the network.
So hoping/believing that QUIC install/swap is done? (if so, then really too easy IMO) and we can get back to testing and tracking of other bugs, issues, and limitations.
Could be that I am wrongly assuming the mem issue is due to QUIC, the team did say potential fixes are already in so maybe just a big nothing .
Just doing my part to keep Sundays spicy
If we didn’t try we wouldn’t know! And better to find issues now rather than later. I was very surprised at how much faster quic was reported as being. That certainly seems worthwhile plunging into.
Hmm, I’m not sure it’s slowed progress as yet. It may well just have exposed bugs that were hidden.
TCP is still there via websockets just now. That will likely still work as before (and any move back to TCP should be relatively painless due to how libp2p separates concerns very nicely here).
FYI @josh what’s slowed progress and stable testnets more is actually our switch to node-manager
and teething problems there. And that’s needed for us to be able to upgrade nodes easily…
We don’t know in concrete as yet. If any of the potential fixes do sort this, then it wasn’t quic related (as they’ve been mem-snipping).
If it is quic related, then it’s probably message processing time that’s the issue here, which we could solve via throttling… or fixing the higher consumption process. We’ll hopefully know
interested to see how the claim from omni to SNT will work. if i remember correctly trezor/ledger is not viable a the moment.
If snapshot method then it matters not how the wallet works (ie what hardware/software/paper wallet)
What matters is how the proof of ownership works and that is where maybe a hardware wallet might give troubles.
If you were referring to the ‘bc’ addresses then the omni protocol causes the transfer to the ‘bc’ address to abort and returns the OMNI assets to the sending address.
You worded it better than me
I was wondering about the bit where I have to stick a private key into something. Considering making a new seed and wallet with trezor and transfering a few Omni maid into it so I have got a sacrificial wallet to play with.
I’m currently working on the cli for converting omni to snt. The interaction is designed like this:
$ safe wallet get-faucet <url> <maid_address_or_blank_for_X_tokens>
MAID secret key to decrypt tokens: <user enters maid secret key>
<amount> tokens received to <wallet address>
So yeah, people need to have the secret key for the omni maid available somewhere. There isn’t native hardware wallet integration, but it would be possible to manually get that secret key and use it in the cli.
Bitcoin transaction fees are pretty low at the moment so it may be a good time to send some coins off a hardware wallet to a new address. If everyone had to do this (eg a burn transaction) it would be quite expensive.
There will definitely be a way to do this offline, but only after the initial implementation above has been done.
The offline user experience would be something like:
safe files download <distributions list address>
Open to thoughts about these processes; it’s not always obvious how people will want to do the claim process so any feedback is really useful.
Thanks for info I’m looking forward to trying it out.
Also happy to hear we are hoping to avoid a burn as well.
I’ll generate a test wallet with https://www.bitaddress.org and put a few maid in it to test it out
What is this secret key?
Is it the private key?
Yes the omni maidsafecoin private key (wif encoded)
The reason it’s needed is the distribution is encrypted using this public key, and the private key is needed to decrypt the distribution and claim the snt.
Only the person with the private key can decrypt, so the full distribution list can be made public.
Another option would be for the client to send a safe wallet address signed by the omni maid address. Trezor has a signMessage api so this would work with hardware wallets.
Starting to get off topic! Maybe this can be moved to a new thread?