Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
> BTW I changed one of my OTS calendars to issue fee-bumping txs without the > opt-in RBF flag set as an experiment. I also made sure txs would propagate to > the above node. As of right now, it's up to 32 replacements (once per block), > without any of them mined; the calendars use the strategy of starting at the > minimum possible fee, and bumping the fee up every time a new block arrives > without the tx getting mined. So that's evidence we don't have much full-rbf > hash power at this moment. > > You can see the current status at: https://alice.btc.calendar.opentimestamps.org/ That's interesting. I'm not sure if we can conclude of the absence of full-rbf hash power at this moment, as it could also be a lack of full-rbf propagation path towards such potential hash power. I think the day we see an opt-out replacement transaction mined, it would constitute a good hint of full-rbf hash power (assuming the tx-relay topology stays relatively stable across the transaction issuance...) Anyway, if/when the `fullrbf` patch lands in Bitcoin Core, including automatic outbound connections to few `NODE_REPLACE_BY_FEE` peers, I'm thinking of reaching out to a few mining node operators to advocate them with the new policy setting. Antoine Le lun. 20 juin 2022 à 19:49, Peter Todd a écrit : > On Mon, Jun 13, 2022 at 08:25:11PM -0400, Antoine Riard via bitcoin-dev > wrote: > > For that reason, I believe it would be beneficial to the flourishing of > > multi-party funded transactions to fix the Dos vector by seeing a subset > of > > the network running full-rbf and enabling propagation of honest > multi-party > > transactions to the interested miners, replacing potential non-signaling > > double-spend from a malicious counterparty. Moving towards that > direction, > > I've submitted a small patch against Bitcoin Core enabling it to turn on > > full-rbf as a policy, still under review [3]. The default setting stays > > **false**, i.e keeping opt-in RBF as a default replacement policy. I've > > started to run the patch on a public node at 146.190.224.15. > > BTW I changed one of my OTS calendars to issue fee-bumping txs without the > opt-in RBF flag set as an experiment. I also made sure txs would propagate > to > the above node. As of right now, it's up to 32 replacements (once per > block), > without any of them mined; the calendars use the strategy of starting at > the > minimum possible fee, and bumping the fee up every time a new block arrives > without the tx getting mined. So that's evidence we don't have much > full-rbf > hash power at this moment. > > You can see the current status at: > https://alice.btc.calendar.opentimestamps.org/ > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
HI alicexbt, > Lets consider there are 2 users with name Bob (normal LN user) and Carol (attacker running LN node) which I will use in this email for examples. In this case Bob and Carol can manage security of their OS and it is not affected by others using vulnerable systems or OS. Yes, I believe my argument was the set of components making the security of your LN node is far beyond Bitcoin softwares. Of course, you might review by yourself the millions lines of code entering in the trusted computing base (OS, bootloader, BIOS, device firmwares, essential utilities, ...) on which your cryptocurrency software stack lays out, and as such exercise an extended span of control on your personal computation. Though, while I hope we'll have more LN node operators doing so, I'm not sure it's realistic to expect it will be the behavior standard among them.. > The odds are low as you said, this can be managed by Bob and Carol because they can use a better ISP. Others using ISP with some issues may not affect their LN usage. Sure, though as I would like to underscore being dependent on a Bitcoin node policy and being dependent on a ISP internet traffic routing policy could be analyzed as logically equivalent, all things are equal. That said, if your personal risk aversion is too high for the Lightning security model, once it's well-understood there is a strong reliance on a censorship-resistant tx-relay network back to economically-rational miners, you're free to not use it and satisfy yourself with the Bitcoin base layer. > Bob might use full-rbf as its suggested by LN developers for secure LN usage and better for miners. Carol could use a different RBF policy for some nodes and mining. In this case Bob may get affected at some point because of Carol's choice to use a different RBF policy which was not true above. Indeed, your secure LN usage is going to be dependent of the number of p2p network nodes running an economically-rational policy like full-rbf. That said, I think it's reasonable to assume that the players of the Bitcoin game are economically-rational, and as such incentived to pick up a policy such as full-rbf. I know the term "economically-rational" is poorly defined here, and I think it could be interesting for any academic with an economic background to study the incentives of Bitcoin actors. > Allowing users to create different mempool policies is great. My thought process is to code for happy path, where X policy is expected for replacement and edge cases where Y policy or no policy would be used. Users can try out different policies and even act as attackers. This is also true for other things in mempool, 'spkreuse=conflict' prevents address reuse in the mempool when using knots. If I assume that address reuse is always relayed, this could become a problem if some users and miners adopt this setting in their mempool. Agree, I'm all in for people to experiment with mempool policies. Though at the end it's a software engineering resource question. If users are interested in more features, they're always free to implement themselves. Really, the binary distinction developers-vs-users doesn't make sense and if we would like Bitcoin to be successful in the long-term, we should promote high degree of software literacy among bitcoiners. > This makes sense and I would be interested to follow two things once full-rbf is available in a bitcoin core release: 1. Percentage of transaction getting replaced 2. Miners profit (Fee for replaced Tx - Fee for original Tx) Yes, I would be interested too to have those metrics once full-rbf is available in a bitcoin core release. I think that's something every full-rbf curious node operator could observe on its own with a few more loggers, at least for the first metric. > Can you explain how p2p coinjoin is affected with mempool DoS vector with some examples? What is considered a p2p coinjoin? Joinmarket or [Stonewall][1]? I don't remember the Joinmarket code right now and I don't know the ins and outs of Samourai coinjoin as I'm not sure the code is open source. Though let's say for a p2p coinjoin as one you can build once you have implemented LN's interactive construction protocol [0]. [0] https://github.com/lightning/bolts/pull/851 Here the DoS attack situation : - Alice, Bob and Caroll would like to coinjoin 3 inputs to 3 outputs - Each of the input is singly controlled by one party, e.g Alice owns input A, Bob owns input B, ... - Alice, Bob and Caroll exchanges a PSBT to build a multi-party funded transaction (the coinjoin_tx) - Alice is elected as the multi-party transaction broadcaster once the signatures have been exchanged - The block feerate is around 10sat/vb - One of the transaction input signals opt-in RBF, the transaction is attached a compelling feerate 10sat/vb - Caroll broadcasts a double-spend of her own input C, the double-spend is attached with a low-fee (1sat/vb) and it does _not_ signal opt-in RBF - Alice broadcasts the multi-party
Re: [bitcoin-dev] Bitcoin covenants are inevitable
> On Jun 21, 2022, at 12:28, Keagan McClelland via bitcoin-dev > wrote: > > > > The PoW security of Bitcoin benefits all Bitcoin users, proportional to the > value of BTC they hold; if Bitcoin blocks aren't reliably created the value of > *all* BTC goes down. It doesn't make sense for the entire cost of that > security > to be paid for on a per-tx basis. Actually it does. People who transact are realizing the benefit of money - the avoidance of barter costs. Those who never transact, never realize any benefit. > And there's a high chance paying for it on a > per-tx basis won't work anyway due to lack of consistent demand. > > FWIW I prefer the demurrage route. Having something with finite supply as a > means of measuring economic activity is unprecedented and I believe deeply > important. I'm sympathetic to the argument that the security of the chain > should not be solely the responsibility of transactors. Chain security - censorship resistance (as opposed to individual double-spend security), is entirely dependent upon tx fees. > We realize the value of money on receipt, hold *and* spend and it would be > appropriate for there to be a balance of fees to that effect. There is zero point in saving if you never spend. You can instead just burn your coin. > While inflation may be simpler to implement (just chop off the last few > halvings), I think it would be superior (on the assumption that such a hodl > tax was necessary) to keep the supply fixed and have people's utxo balances > decay, at least at the level of the UX. A hoard decays naturally due to opportunity cost. Investing it requires transaction to invest, and transaction to earn (profit), and transaction to return it (interest). > But also none of this should be reasons we don't improve Bitcoin's value (and > therefore demand) Demand is the only reason we save, and eventually transacting is the only motivation for saving. No transacting implies no demand - and no security. e > Keagan > >> On Mon, Jun 20, 2022 at 2:42 AM Erik Aronesty via bitcoin-dev >> wrote: >> >> >>> On Sun, Jun 19, 2022 at 2:04 PM Manuel Costa via bitcoin-dev >>> wrote: >>> if we start seeing issues with block rewards being too low to maintain >>> acceptable security, we're going to have multiple solutions being >>> implemented for it, and definitely a hard fork to indefinitely maintain >>> some degree of block subsidy >> >> if we failed to first try increasing block demand with advanced transaction >> support, it would seem like we were just throwing money and growth away to >> support one narrative (simplicty of function), while destroying another >> (finite supply) >> >> if stuff like covenant support and mweb gets us higher fees, with stuff like >> on-chain mixing protocols, vaults, and higher utility, it might be more than >> enough to sustain bitcoin on fees alone forever >> >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin covenants are inevitable
> The PoW security of Bitcoin benefits all Bitcoin users, proportional to the value of BTC they hold; if Bitcoin blocks aren't reliably created the value of *all* BTC goes down. It doesn't make sense for the entire cost of that security to be paid for on a per-tx basis. And there's a high chance paying for it on a per-tx basis won't work anyway due to lack of consistent demand. FWIW I prefer the demurrage route. Having something with finite supply as a means of measuring economic activity is unprecedented and I believe deeply important. I'm sympathetic to the argument that the security of the chain should not be solely the responsibility of transactors. We realize the value of money on receipt, hold *and* spend and it would be appropriate for there to be a balance of fees to that effect. While inflation may be simpler to implement (just chop off the last few halvings), I think it would be superior (on the assumption that such a hodl tax was necessary) to keep the supply fixed and have people's utxo balances decay, at least at the level of the UX. But also none of this should be reasons we don't improve Bitcoin's value (and therefore demand) Keagan On Mon, Jun 20, 2022 at 2:42 AM Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > On Sun, Jun 19, 2022 at 2:04 PM Manuel Costa via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> if we start seeing issues with block rewards being too low to maintain >> acceptable security, we're going to have multiple solutions being >> implemented for it, and definitely a hard fork to indefinitely maintain >> some degree of block subsidy >> > > if we failed to first try increasing block demand with advanced > transaction support, it would seem like we were just throwing money and > growth away to support one narrative (simplicty of function), while > destroying another (finite supply) > > if stuff like covenant support and mweb gets us higher fees, with stuff > like on-chain mixing protocols, vaults, and higher utility, it might be > more than enough to sustain bitcoin on fees alone forever > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
