Hi Peter, Answering your latest 2 emails. > I do not consider CVE-2017-12842 to be serious. Indeed, I'm skeptical that we > should even fix it with a fork. SPV validation is very sketchy, and the amount > of work and money required to trigger CVE-2017-12842 is probably as or more > expensive than simply creating fake blocks. > Sergio's RSK Bridge contract being vulnerable to it just indicates it was a > reckless design. I don't think we shall disregard SPV validation yet in a world where we have not really solved the scaling of Bitcoin payments for large range of user segments running on low-cost android mobile with limited validation ressources. On the cost of the attack, yes I think it's probably in the order of creating fake blocks at current difficulty adjustment. On appreciating if a design is reckless or not, it's always good to do it with a full- fledged cost-based threat model in a comparative analysis w.r.t other alternative design in my experience. > To be clear, in this particular case I had specific, insider, knowledge that > the relevant people had in fact seen my report and had already decided to > dismiss it. This isn't a typical case where you're emailing some random company > and don't have any contacts. I personally knew prior to publication that the > relevant people had been given a fair chance to comment, had chosen not to, and > I would likely receive no response at all. Sure thing, it's not a disclosure configuration where the reporter has no out-of-band redundant communication channels available with the software group of maintainers. I can only suggest that Bitcoin Core's `SECURITY.md` to be modified in the sense to give an acknowledgement of reception to finding reports with technical proofs under ~72 hours. I'll let external observers from the community make their own appreciation on what this disclosure episode can say on the state of Bitcoin security problem handling. > I'm not going to say anything further on how I knew this, because I'm not about > to put up people who have been co-operating with me to the risk of harassment > from people like Harding and others; I'm not very popular right now with many > of the Bitcoin Core people working on the mempool code. I think it's up to the maintainers or vendors of any piece of software to justify why they're disregarding sound technical reports coming from a security researcher with a credible and proven track record, especially when it's apparently for hidden social reasons. There is also the option to disclose under pseudonym which I personally already done sometimes in the past. I can understand ones does not wish to do so far for professional reputation reasons. > Anyway, I think the lesson learned here is it's probably not worth bothering > with a disclosure process at all for this type of issue. It just created a > bunch of distracting political drama when simply publishing this exploit > variation immediately probably would not have. I've checked my own archive, on the Lightning-side and from my memory, I can remember two far more serious issues than free-relay attacks which were quickly disclosed without a formal process over the past years: - time-dilation attacks by myself [0] - RBF-pinning on second-stage HTLC by the TheBlueMatt [1] Both were conducted on a less than 7-days timeframe between private report to select developers parties and public full-disclosure. With more experience on handling security issues since TDA initial report in 2019, I still think it's good to give 2-weeks to any vendors if they wish to engage in a mitigation process (unless special or emergency considerations). In matters of ethical infosec and responsible disclosure, the process and timeframe actually followed should matter far more than the "who" of the reporter, and her / his "popularity" score on the social graph be completely disregarded - imho. > If, for example, all Bitcoin nodes were somehow peered in a perfect ring, with > each node having exactly two peers, the sum total bandwidth of using 2 > conflicting proof-of-UTXOs (aka spending the UTXO), would be almost identical > to the sum total bandwidth of just using 1. The only additional bandwidth would > be the three to four nodes at the "edges" of the ring who saw the two different > conflicting versions. > With higher #'s of peers, the total maximum extra bandwidth used broadcasting > conflicts increases proportionally. Yes, higher #'s of peers, higher the total maximum extra outgoing bandwidth used for broadcasting conflicts increase proportionally. I think you can dissociate among transaction-announcement bandwidth (e.g INV(wtxid)) and transaction-fetching bandwidth (e.g GETDATA(wtxid)), you can re-fine the adversarial scenario to have highest DoS impact for each unique proof-of-UTXO. Like what is bandwidth-cost carried on by announcer and bandwidth-cost encumbered by the receiver. Best, Antoine Le jeudi 28 mars 2024 à 20:19:19 UTC, Peter Todd a écrit : > On Thu, Mar 28, 2024 at 07:13:38PM +0000, Antoine Riard wrote: > > > Modulo economic irrationalities with differently sized txs like the > Rule > > #6 > > > attack, the proof-of-UTXO is almost economically paid even when > mempools > > are > > > partitioned because the bandwidth used by a given form of a > transaction is > > > limited to the % of peers that relay it. Eg if I broadcast TxA to 50% > of > > nodes, > > > and TxB to the other 50%, both spending the same txout, the total > cost/KB > > used > > > in total would exactly the same... except that nodes have more than one > > peer. > > > This acts as an amplification fator to attacks depending on the exact > > topology > > > as bandwidth is wasted in proportion to the # of peers txs need to be > > broadcast > > > too. Basically, a fan-out factor. > > > > > If the # of peers is reduced, the impact of this type of attack is also > > > reduced. Of course, a balance has to be maintained. > > > > Sure, proof-of-UTXO is imperfectly economically charged, however I think > > you can > > re-use the same proof-of-UTXO for each subset of Sybilled > transaction-relay > > peers. > > Of course you can. That's the whole point of my scenario above: you can > re-use > the proof-of-UTXO. But since nodes' mempools enforce anti-doublespending, > the > tradeoff is less total nodes seeing each individual conflicting uses. > > If, for example, all Bitcoin nodes were somehow peered in a perfect ring, > with > each node having exactly two peers, the sum total bandwidth of using 2 > conflicting proof-of-UTXOs (aka spending the UTXO), would be almost > identical > to the sum total bandwidth of just using 1. The only additional bandwidth > would > be the three to four nodes at the "edges" of the ring who saw the two > different > conflicting versions. > > With higher #'s of peers, the total maximum extra bandwidth used > broadcasting > conflicts increases proportionally. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/f1868012-8ad2-44ba-b83c-b53d5892b8e6n%40googlegroups.com.