Ocean validates templates, and therefore Ocean is centralised.
If bitcoin is already totally unstoppable, then our work is done. We can all go home now. [/sarcasm]
I therefore don't think bitcoin is safe enough yet. We have a lot to do. Mining centralisation is the biggest concern for me of course! Therefore I work on efforts like Braidpool and Radpool.
Remember the P2Pool servers? You could start mining by simply pointing your stratum url to one of them.
#Radpool service providers are just like that, but with a more formalised role - so they can earn the mining fee from the miners they serve.
Radpool - an open marketplace for pooling services!
मेरी पहली हिंदी पोस्ट, नेस्टर पर।
Can't find posts in #Hindi here yet। So here we go।
nostr 118n .... let's go!
Good point. I'll post news from the slack channel every now and then.
The initial results look very promising! Are you following Eric's tweets on twitter?
CC nostr:nprofile1qqsvh300dvquh50l5t9et2257pxrsk5ndsdgdcdmnnxl9nc0f6l2ejcpzemhxue69uhkummnw3ex2mrfw3jhxtn0wfnj7hn9u55 nostr:nprofile1qqsyy2wzruqsr27rhfzjx0shd6t4l20xwxa33fnj900hwf46y4z9l7gpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxrhwden5te0wfjkccte9ehx7um5wf5kx6pwv3jj7qgewaehxw309a3xcctnw3ezuun9d3shjtnwdaehgu30amx8yr
I actually did spend some time thinking about using FROST for payments over LN, where instead of multi-hop forwarding of HTLC, all parties run a signature scheme together to commit changes in an atomic manner. However, I think instead of FROST, MuSig2 might be a better choice.
I initially thought FROST like threshold signatures could have helped, but the problem is that some parties could collude and cheat the other parties - depending on thresholds etc. Therefore I think MuSig2 can work better. It can replace the need of multi-hop HTLCs. This of course takes away privacy goals of LN.
I did write about it a bit here: https://github.com/pool2win/ln-synctomic/ to log my thoughts. It is kind of a brain dump atm, and probably has some glaring mistakes 😃
I would love to join a brainstorming session/chat around this. I think a lot is possible for L2 payments using either MuSig2 or federations using FROST.
Collaborative custody will end up empowering control structures rooted in currently existing communities. Control structures that are hierarchical and which take away human freedom.
The principle of voluntary association begs us to stay away from today's societal top down control structures.
Collaborative custody within existing societal structures seems going away from voluntary association.
I am responding to this para from a news article.
"Fedi, which has created a “Community Superapp” that enables collaborative custody of bitcoin"
I don't remember off the top of my head. Which opcodes do you guys use for the liquid implementation?
This my third time engaging with #nostr. Each time is been better and more vibrant. 👏🏾👏🏾
A joy to experience the network effect play out in real time.
Here to stay this time.
This is exactly the larping by mining pools run by a single entity when they claim to be "decentralised".
cashu definitely has a place in the bitcoin ecosystem. critics gonna criticise. Keep building!
We should explore decentralised identity here instead. https://www.w3.org/TR/did-core/
OpenID providers are centralised ID providers who devour any data we send to them. Let's try to avoid doing that.
Unless, again, I am missing something.
I think this spec will be a mistake. TBH, I am confident once the flaws are pointed out, the spec will be withdrawn. OpenID is just centralised identity. We might be better of exploring DID specs around decentralised identity - https://www.w3.org/TR/did-core/ Harder to build, but lets not talk to OpenID providers!
I heard you like ecash, so we used ecash to secure ecash mints.
Blind authentication will allow mint operators to restrict the use of their mint to only registered users, while still providing them great privacy.
This is one of the most-requested features for Cashu.
The spec is now open for discussion: https://github.com/cashubtc/nuts/pull/198
As I understood openid, there needs to be a call back from the open id service to the application - the mint in our case. We should look into how much of a leak this is. Also, please correct me if I am wrong about the call back from open id service provider to the application.
Wow. I was curious on the state of affairs, so I got this data set form kaggle and checked the status of validator ofac compliance. Turns out the data is from 2022. It is frustratingly hard to figure out how many validators and relays are non ofac compliant in 2024. The only thing we can do is look at ofac compliant blocks on mevwatch.info.
Ethereum feels like it provides "censorship resistance by obfuscation"
The question in my head too.
You should come along to the FROST roundtable. They would love to hear about your work on frostr.
That will be much more complicated, from what I understand. let's see where this lands.