Yeeeeee jargon me 2 stoopid....

So we could've made LN just be fast and settle on the chain without segwit?

Can we fix it?

I don't care if fork needed. The only thing bitcoin needs is "lightning" fast transactions, F'ing with blocksize and fees is retarded.

(Yes, I will google the jargon, I'm retarded but not ass9)

Reply to this note

Please Login to reply.

Discussion

yeah, i might be misremembering but i'm pretty sure that signature malleability was the big problem for lightning because the state is only settled at the end of the life of a channel

segwit was the solution for this that stayed with the ECDSA signatures, by augmenting them with some extra jazz that does things that stop you from being able to jiggle the bits to have a good signature refer to a bad data

what malleability means is where you "mine" on the signature data to have it generate the same hash as the one the signature applies to, with ECDSA, this is a larger number of possible values, but with schnorr it is only one, and thus it can't be "malleated"

it's actually the big flaw in ECDSA that is the biggest shitty factor in the timeline path of bitcoin because if bitcoin had been released a year or two later it could have been using schnorr signatures from genesis, and there never would have been this vulnerability in the first place, and lightning would not have benefited from it

and i should also point out that taproot is retarded, i don't even understand why they didn't separate the "tapscript" shit from the implementation of schnorr signatures

if you go read up on the history of the blocksize wars and the segwit bullshit you will learn about how there was a lot of chatter about adopting schnorr signatures instead

twice now, this has been fucked up, it's disappointing

I think I read somewhere that ECDSA was broken and if it were the only encryption our keys would be toast, so basically bitcoin is standing on two remaining legs since there are three layers of encryption. This is all far beyond my level. Oh, it was saying that's why spending from the same address twice endangers your keys. The only take away that I understood well enough to stick was that you should always spend the whole txo and change should go to new address.

But that seems worrying. Seems like there are two ways Bitcoin has already broken - doubling blocksize means miners have to centralize, and ECDSA being knocked out means future attackers have less work to do. At least, that's how I hear it. I'm painfully aware of my lack of understanding.

yeah, there is both cryptographic security and privacy reasons to never reuse an address xapo bank's bitcoin devs need to have schooling on this because they make only one address per account that never changes and this is not how you do it, it's the biggest quibble i have with their operation

taproot solves most of this problem btw, they just muddled it up with some shitcoin bullshit, it finally added schnorr signatures to bitcoin... there is nothing on the protocol level stopping you from using taproot addresses the same way except without the malleability problem... they could be used by lightning protocols too, with minimal complexity to upgrade

yeah, to be clear, the more times you sign with the secret key associated with a bitcoin address, the less difficult it is to reverse the public key and get the secret, and spend that UTXO

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 decided to use schnorr signatures on secp256k1 curve just because it seemed like a cool idea, mostly, with taproot in the process of congealing into the protocol (it's now pretty much supported by most of bitcoin nodes) but it was a good idea to use schnorr instead of ecdsa because the security of our nostr identities would be considerably worse with the number of times we sign events with this one secret in nostr

ECDSA is just a HMAC (hashed message authentication code), though i'm probably abusing the "formal" definition, that's what it is, and the problem with it is that due to the way it's calculated there is a fairly substantial number of different hashes that can be valid on a signature, thus it is "malleable" - put it this way, if you are hash-grinding (like mining) and you can cut the bit-size of our seed down to only like 8 bytes (64 bits) of data, it's feasible to sic a farm of machines to the task of trying out variants of that hash value that satisfy the ECDSA signature, potentially within days, or at most weaks, for a large attacker to use

schnorr is simpler than ECDSA, as well as lacking this weakness of imprecision that gives this wide scope for tampering with a message (ie transaction) that could potentially change the payee of the transaction, so you see what the problem is when you fully grasp what malleability means

it's not a weakness that a lone wolf hacker can exploit, it's a weakness that a GOVERNMENT sized hacker can exploit, and that's why it's troublesome

I have a lot to read up on, and I'll be wasting your time until i do it... I *think* what you said is that 64 bits is not enough entropy, so attackers can just roll RNG for a few weeks and be able to spend a utxo... Because multiple signatures can be valid for ECDSA. Is it 64 bits because that's the actual length of the string, or because two possible signatures cuts the real or final entropy in half?

I think I'm also hearing that part of good defense is to keep your sats in many addresses, so an attacker has to knock them down one at a time. (?)

nah, if the keys never have been used they are impenetrable

the reasons for breaking your stack into separate UTXOs is about evading correlation attacks on your stack, associating them to one wallet and thus making it easier to monitor the p2p network to locate your physical location for a $5 wrench attack

Seems like any kyc btc is dangerous, regardless of where you are or wallet practices. Surveillance state isn't going to stop putting in cameras with facial recognition. You get spotted anywhere, you're toast.

yeah, but reusing UTXOs also is bad for THEIR security, it's like them battering the keys and security protocols for their vault, because i have examined my bank deposit address, i'm not the only one using it and there is maybe nearing hundreds of thousands of dollars worth of sats passing through this address

or at least mainly mine, i don't think anyone else is using it

what disturbs me is that they are getting to see some scope of my total income out of this which i don't like, it makes me VERY wary of actually formally KYCing myself to get a "european payment card" when i have a "dirty gibraltar tax haven domiciled card" that works fine more than 29 times out of 30

Oh that's gross... Its not like we need to conserve addresses... I guess they want to save on fees. But it seems like any business doing that is a rug waiting to happen.

I guess they probably have a layered approach. Keep most deposits in addresses that have strict privacy rules, but be more relaxed with the more active customer facing address to save fees. Maybe.

yeah, tell me about it... i'm acutely aware of the risk in a way that i'm distinctly privileged to understand

for the time being, their clout with the payment and banking systems keeps me from moving because finding some other option is gonna be a lot of beta testing and probably the odd bit of lost money, on top of the time

plus, they made it even worse by upping the annual fee for the account so much, unless they show some substantial improvements, like not reusing deposit addresses on chain, i'll be open to choosing a competitor

i should also mention that, thinking about it, this is partly why i have shifted to primarily using LN to do my transfers into the account, and shield myself using my WoS...

Are they on nostr? Would be nice if they could read this