Roger Ver is just a stupid man who impoverished himself by attacking decentralization.
That at this point we are still discussing the size of block is to be retarded, in any case the block size should be reduced.
Roger Ver is just a stupid man who impoverished himself by attacking decentralization.
That at this point we are still discussing the size of block is to be retarded, in any case the block size should be reduced.
It’s interesting to imagine an alternate reality where Ver embraced the Lightning Network. Bitcoin Jesus on team Bitcoin would've been massive.
He experienced a mind virus. Similar to the COVID one.
As with Fiat the digital payload, the scientific study, the government program, the 4K , oops 8K, should be increased or inflated in order to justify increasing the amount of complicated nonsense needed to justify wealth extraction and the need for workers willing to work for nothing.
The witness discount is tough because I love lightning but we did effectively double block size to create the transaction layer. I don't know the way around that one.
Was there really no way to make a lightning network without the witness discount?
as i see it, the only thing lightning needed was non-malleable signatures, because of the p2p nature of maintaining a current finalization UTXO
we have that with taproot, and that didn't need segwit, segwit was a way to mitigate the malleability problem, and it doesn't exist with schnorr signatures and they were patent-free at the time they inflicted that shit onto the chain
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)
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
The witness discount is completely irrelevant to Lightning and SegWit and not required at all, we could have SegWit and a hard limit of 1MB easily. It was added as a compromise to please big blockers.
Then let's get rid of it!
man, trying to find this video, thet bulgarian government mandated they throw a "you are not alone, suicide is not the answer" message for "suicidal tendencies" song "join the army"
🤦♂️ seriously, this internet is so fucked up
Ha, I was able to search about it without that, I felt like it was a victory. Love that 80s rock sound
i loved me some suicidals when i was angsty teen skateboarder, was very popular with my peers... i love how introspective the lyrics are
"i'm not crazy! institution! you're the one who's crazy! institution! put me in an institution to protect me from the enemy myself"
Let's activate Drivechain and reduce the blocksize to 300kb!
Yeah!
yes, i favor reducing the blocksize and abolishing segwit also, and making all signatures schnorr "taproot" signatures oh yes and deprecate op_return permanently
I searched it - I remember the term coming up a couple years ago but didn't deep dive. I see Adam Back had good things to say about it... Its crazy how much of my thinking about bitcoin I outsource to his opinions...
yeah, not enough people understand the cryptography, so shysters get to rule the day
Can I support bip300 drivechains with my node now? If so, this will be the first time I've tried using my node selectively for the ruleset... And idk how to do it... But so far, from my 3.5 minutes of research, I like it and am willing to learn new things because of it
drivechains are just anchored shitcoins, like ordinals or other shit
i dunno what the stuff involved is, probably nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 would be something of an expert on this, even though it is not going to change the main consensus to be better
today i sorta see where he is coming from about this, like it's some kind of attempt to reassert sanity after several major compromises on the main chain
because if you fork it, and are on the minority, you probably will end up being a bcash or bsv
so it's some kind of a hedge going on
i think the solution lies in finding how to work with what is, without changing the protocol, and if your work-around acquires substantial economic value, it will act as drag against other changes that are shitty
so there is many layers of complexity to understanding it
if support for *specific* drivechains are aimed at creating a drag on introducing dumbshit to the main chain, i'm all for that as well, but you see how many levels of abstraction we are going to here, it's getting positively byzantine
The shitcoininess makes me nervous. Still reading/watching. But it seems like it doesn't necessarily tie in shitcoins, but only potentially does. IMO the security budget only matters while Fiat exists - at some point, if security is good enough to get us there, sats mined will be sufficient inticement to mine no matter what amount they are, simply because that's the total throughput for the economy.
But low fees means miner centralization, simply because low margins cause consolidation in industries. So IMO, F'ing with block size was retarded. I want more people mining. And I'm being a hypocrite in that regard... But anyways. The only thing I think needs to be "fixed" is the speed of transactions. A second layer is the correct solution because the speed of transactions needs not be the speed of settlement. IMO, blocks should be mined even slower... Much slower. I don't want a Mars Coin, Venus Coin, and Jovian League Coin competing with Bitcoin in 1000 years. That can be prevented by slowing blocks by a few hours, which gives miners a chance to monetize energy anywhere in the inner solar system. But I've gotten off topic... I guess there are two things I think need to be fixed. But only tx speed is important in this century. And block size, since they F'd with it. 3 things. It stops there!
speed of transactions does not need to be fixed
10 minutes and the latency of the global internet are a perfect match and lightning state channels (two way transactions that can be securely updated to match a flow of sats in either direction) solve the latency problem, they just bring with them the problem of the brittleness of a source routed network system where a transaction path may not work between when the state of the network was acquired and when a vital hop in the path became congested or went offline
solving these issues can be done other ways, and i have pondered a lot the idea of atomic multipath redundant pathfinding, so transactions literally travel light lightning bolts across the paths that are open and the first one that reaches the end settles it, instead of the standard single path or atomic multipath (AMP) patterns where only one failure in all of the hops in the path causes a failure
AMP only makes bigger payments possible, it did not add redundancy
also, you get it
slower blocks would be better, actually
Speed of transactions absolutely needs to be fixed. What the technology wants and what the user wants are two very different things. Hour long settling times are absolutely fine for bill payments but not great for getting groceries (unless you open a tab I guess)
The problem will hopefully get worse with space colonization. I have been wracking my brain for a system of payment that is location invariant. I think it can be done but it won't be quite as trustless as Bitcoin.
I'm glad there are others thinking about this.
I think we should try all ideas. This is, so far, the main thing I like about drivechains.
yeah, i can see how this might be a positive feature of these things... a means to mitigate the chain migration problem that makes a minority fork greatly disabled from moving to become a majority, especially in this situation where the majority has adopted some stupid shit that any idiot can see is an attack on the chain
I would start from blocking the spam first. Block anything that is not a valid Bitcoin transaction. That should be the top priority. Agree, if anything the block size should be reduced.
So you're suggesting we start censoring transactions at the protocol level? 🤔
It is not censoring, it is ensuring the protocol does what it was ment to do, ensuring the blockchain not being polluted with shit. All the changes so far introduced more problems than solved anything.
A better solution to spam is just to not subsidize spam. If we had left the block size alone, spam wouldn't be a problem.