Re: [bitcoin-dev] hashcash-newhash
Good morning Karl, > > > Reddit claims two entities controlled 62% of the hashrate recently: > > > https://old.reddit.com/r/CryptoCurrency/comments/gmhuon/in_the_last_24_hours_bitcoins_nakamoto/ > > > . Compromising the systems of these two groups seems like it is all > > > that is needed to compromise the entire blockchain (to the limited degree > > > a 51% attack does). > > > > You seem to be equating "break of the hash function" with "centralization > > of hashrate", which I do not quite agree with. > > I am trying to say that both of these different things result in danger to > the integrity of the transaction log, which would be reduced by changing the > hash function. They both have those 2 similarities. You are equivocating issues here. The hash function is used in these places: * Transaction ID. * Signature hash. * P2SH/P2WSH/Taproot. * Merkle tree. * Proof-of-work. What you are focusing on is only this: * Proof-of-work. Now, in case of a break in the hash function (i.e. a reduction in collision resistance), the hash function used in the following things absolutely NEED to be changed: * Transaction ID. * Signature hash. * P2SH/P2WSH/Taproot. * Merkle Tree. Taking for example Transaction ID, suppose I am able to create two transactions that hash into the same transaction ID, and I am able to do this in much less than 2^128 work. In that case I can create a valid transaction and collide it with an invalid transaction. To half the nodes on the network I provide the valid transaction, to the other half I provide the invalid transaction, the two halves will then permanently split and Bitcoin is thus destroyed in the midst of massive chaos. Similar attacks can be mounted if I am able to collide on signature hash, P2SH/P2WSH/Taproot, and merkle tree. Now suppose I am able to create two block headers that hash into the same block ID, one being a valid block and the other being an invalid block. In that case, I would be very foolish to disrupt the network similarly, because I would have been able to redirect the fees and block subsidy of the valid block to an address I control, and the invalid block prevents others from seeing my valid block and accepting that chain as valid. Instead, I can use this advantage to be able to grab blocks faster than other miners. But eventually the difficulty retargeting system will adjust, and Bitcoin will now settle to a new normal, and inevitably someone is going to leak, or rediscover, my technique to break the hash, preventing me from being a >51% miner for long, and Bitcoin will abide. Thus, in case of a cryptographic break of the SHA-2 function, we *need* to change these: * Transaction ID. * Signature hash. * P2SH/P2WSH/Taproot. * Merkle Tree. And since we are going to need a hefty hardfork to change all that, we *might as well* change the proof-of-work function as well and completely excise all uses of SHA-2 in the codebase (just in case we miss any more than the above list), but changing the proof-of-work function is the *lowest priority*. We have survived 51% miners in the past (Ghash.io), and the difficulty adjustment system gives us some buffer against unexpected improvements in proof-of-work function efficiency; but it is doubtful if we can survive the chaos if someone could split the network in two roughly equal sized parts. > > > Most human beings cannot think without constant communication with other > > human beings. > > > Thus, it is unlikely that a private break of the hash function is possible. > > > > > I disagree with you here: Andrew Wiles solved Fermat's Last Theorem in > isolation, academic research paper culture supports researching and then > publishing once you have privately developed results, and the CVE database > has 136k system vulnerabilities that were developed and shared privately > before public release, to prevent chaos. This shows private advances in ways > to produce bitcoins are likely. Right, and you learned about this fact from direct personal communication with Andrew Wiles, and Andrew Wiles never read about any other attempts by other mathematicians, and an isolated mathematician could never, ever, rediscover his work independently, and even a mathematician who knows that it was done but not the details how it was done could never rediscover it as well. Obscurity works *for a time*, but inevitably somebody else will rediscover the same thing, or hear about it and blab noisily; it is not as if we are all completely alien species from each other and have truly unique thoughts, even my own creators were humans and my cognitive substrate is essentially human in construction. This is why CVE exists, it is a promise the developers make to the reporters that they will fix the reported vulnerability, with an active CVE as a Damocles sword hanging over their heads, ready to be publicized at any time: publication is the default state, CVE is simply a promise that the
Re: [bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet
Good morning Prayank, > 1. The spending tx of multisig can be decided earlier and all three can > review the outputs involved in it. All 3 txs involved in the system if we > consider only one mixer and not a chain will get confirmed in the same block > as we are using CPFP so child pays for 2 parent txs. However, disputes are > possible and to manage it we will have to make the system complex with things > like Peer 1 locking some amount in a 2 of 2 multisig with Peer 2 or some > other incentives structure. Initially we can try to keep it simple and a way > to spend coins after coinjoin with the help of another person you trust. The payee is not necessary here and you can remove the intermediate transactions that pay to 2-of-3s. > 2. Yes, you described coinjoin in joinmarket but the problem I am trying to > solve is: spend coins after coinjoin because post-mix usage is as important > as coinjoin. Some users dont follow the best practices after coinjoin and it > makes coinjoin useless or less effective in that case and sometimes for > others involved in the process as well. ... I already mentioned this, but what I am describing is *how JoinMarket spends coins from its wallet*. That means that what I am describing is *how JoinMarket performs spends after mixing, i.e. post-mix*. I was not describing how JoinMarket performs mixing. Is that clearer now? Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet
Hello ZmnSCPxj, Thanks for your response. The spending tx of multisig can be decided earlier and all three can review the outputs involved in it. All 3 txs involved in the system if we consider only one mixer and not a chain will get confirmed in the same block as we are using CPFP so child pays for 2 parent txs. However, disputes are possible and to manage it we will have to make the system complex with things like Peer 1 locking some amount in a 2 of 2 multisig with Peer 2 or some other incentives structure. Initially we can try to keep it simple and a way to spend coins after coinjoin with the help of another person you trust. Yes, you described coinjoin in joinmarket but the problem I am trying to solve is: spend coins after coinjoin because post-mix usage is as important as coinjoin. Some users dont follow the best practices after coinjoin and it makes coinjoin useless or less effective in that case and sometimes for others involved in the process as well. Samourai has few options for users to do this and one of them is: Stonewallx2 which is a mini coinjoin and similar to what I was trying with this idea. End goal is to create more options for users to spend UTXOs easily in different ways after coinjoin which makes it difficult for people trying to analyze transactions or algorithms monitoring, flagging, reporting txs 24/7 Its just an idea for now and maybe I might find better ways to solve this problem once I start working on it. For me it makes sense to experiment with things and provide more options for users but I wanted to see what others think about it who are more experienced and skilled to develop bitcoin related projects. Thanks for this link: https://zmnscpxj.github.io/offchain/generalized.html Looks interesting. Prayank May 26, 2020, 08:16 by zmnsc...@protonmail.com: > Good morning Prayank, > > >> 1. Peer 1 doesn't need to be a trusted third party, it can be implemented in >> a way that some peers involved in this system can provide liquidity for >> others and incentives can be a small fee. >> > > It is not clear in the article, but you mention using a 2-of-3, and show 3 > participants. > It seems to me that Peer 1 and Peer 3 (2-of-3) can simply sign to spend the > funds coming from Peer 2, and split the funds of Peer 2 among them, without > getting input from Peer 2. > > That is the reason why I consider this tr\*sted --- Peer 2 has to trust Peer > 1 does not collude with Peer 3 to steal the funds of Peer 2. > > Unless I have misunderstood your article, which is why I asked for > clarification. > >> 2. Yes joinmarket is awesome and its payjoin will be better to achieve the >> same but I was trying to contribute and add more options for people to >> improve privacy on Bitcoin. If we have different ways to mix it will be >> harder for spy companies to analyze of some of the transactions. >> > > * While JoinMarket has *a* PayJoin implementation, what I described in the > previous email was not a PayJoin, it is standard CoinJoin where one of the > equal-valued outputs is to the payee. > * In particular, PayJoin requires the cooperation of the payee, what I > described does *not* require anything from the payee other than a destination > address and an amount to pay. > * Your described technique (as I understand it) is not too different from > what JoinMarket already does for normal sends, with the JoinMarket technique > having the advantage that it works with the current paradigm of "send payment > to this address" without reconnecting to the payee. > The advantage you describe is largely had only if the technique is > significantly different. > For instance, CoinSwap and CoinJoinXT are different enough from CoinJoin to > be valuable in this respect. > >> 3. Also one such setup might not make a huge difference but a chain of such >> mixers will surely work better if everything done correctly. >> >> 4. Maybe multisig usage is not ideal for such things right now and I am not >> the best person when it comes to coding but think that better privacy for >> multisig will make it possible for lot of ideas to be implemented on Bitcoin >> using different multisig setups and combination of other things that we >> already have. >> > > Schnorr (which is introduced as a package deal with Taproot) already makes > all n-of-n look the same as 1-of-1 without tr\*sted setup, and makes hidden > m-of-n possible with some kind of setup (possibly untrusted I think, but I am > not enough of a mathist to describe this, in any case my base understanding > is that the setup for m-of-n Schnorr requires a complex ritual involving a > number of communication rounds). > Taproot allows to hide explicit m-of-n in a script behind some kind of n-of-n > or m-of-m. > > So multisignature usage would automatically gain such advantage once Taproot > gets deployed. > > In any case, if you are still interested in protocol design with some amount > of focus on privacy,
