52 years later, only known copy of Unix v4 recovered from randomly found tape, now up and running on a system — first OS version with kernel and core utilities written in C
To all those people who ask me how to get involved in bitcoin open source, here’s the best way:
Opus is much better for me. It’s got a better tempo and takes less effort to get it to go in the right direction.
It works for me!
Haha that sentence was extremely slurred but it sounds like you got the idea!
Yeah that’s a feature. You can forge the PoK on related keys. If a key has a known key then you can’t sub-exponential data with it or any related keys either.
Cool. I think a first step is just to figure out the actual data embedding rate for a few different approaches/assumptions. Has anyone even figured this out for BIP444?
Oh also public derivation could work with the BLS scheme I think. Just don’t commit to the public key in the hash to curve for the PoK and it becomes malleable.
Haha BLS everything of course. I can’t even imagine how you could do it only for the PoK. Any equivalence proof between curves will be a PoK so there’d be no point in the BLS in the first place.
I like “purecoin”. Although I also think it’s not a great direction. It’d still make way more sense than bip444. It would be interesting to present a possible if not realistic soft fork that actually would significantly reduce the amount of data embedding that could be achieved per vbyte. Then a rational debate could be had.
Point taken about locktimes. I don’t think anyone would be in favour of disabling lightning. You’d probably have to leave the spammers with that one.
Thanks for pointing me to the mailing list post. I don’t know what you mean by there’s no way BLS could be implemented on Bitcoin — you could introduce a BLS12-381 address very easily in a soft fork. This would make data sub-exponential data embedding impossible. Also the BLS PoK (ok technically a PoP) can be constructed non-interactively for aggregated BLS multisig.
You can use 128 bit challenge for the PoK (give up batch verification)
Oh that’s interesting. You reveal the bytes *with* the PoK. Ok then I raise you: We use BLS where the PoK is deterministic.
.
Has anyone tried developing a soft fork that would actually verifiably stop all spam?
1. Make a new address type that has a public key + proof of knowledge. 2.5x larger than current addresses. No script nothing else.
2. disable spending to anything other than the new address type.
Spam solved.
You could modify (1) to allow raw multisig also. You can actually do lightning without script using MuSig + adaptor signatures. So everything keeps working… in theory :)
I see a few people calling people “unethical” or “dishonest” for their technical opinions. Don’t do this, as good as it feels. Pick up your cross and just make arguments.
“I’m waiting for my bags to have one last pump so I can rotate to BTC” is the best genre of post.
Oh my sides. It's unbelievable that if not for Bitcoin the entire human species would have been forever enslaved to this preposterous system.
Great question. For now you will need multiple devices. This isn’t a fundamental limitation but a design decision taken to simplify things, especially backups.
Get into it freaks!
nostr:note10hh7uxrp83e8tejre0d0tdc5cfs2hlh9ceznzc2xgpgln07hmuxq354ve3
A beautiful reading but 40 seconds worth of distance run now? Shrinkflation showing up everywhere.
nostr:npub1ynnjxp5clkmuzfdemwxrqntu5u5lerta5hmx8ag2n28x4dmcpygqpuu3gk higher 5000
