Re: [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks
On Tue, Jan 02, 2024 at 11:12:05AM +, Gloria Zhao wrote: > Hi Peter, > > > You make a good point that the commitment transaction also needs to be > included > > in my calculations. But you are incorrect about the size of them. > > > With taproot and ephemeral anchors, a typical commitment transaction > would have > > a single-sig input (musig), two taproot outputs, and an ephemeral anchor > > output. Such a transaction is only 162vB, much less than 1000vB. > > Note that these scenarios are much less interesting for commitment > transactions with no HTLC outputs, so 162 isn't what I would use for the > minimum. > So, I apologize for not using a more accurate minimum, though I think this > helps illustrate the 100x reduction of v3 a lot better. > While I think the true minimum is higher, let's go ahead and use your > number N=162vB. > - Alice is happy to pay 162sat/vB * (162 + 152vB) = 50,868sat > - In a v3 world, Mallory can make the cost to replace 80sat/vB * (1000vB) + > 152 = 80,152sat > - Mallory succeeds, forcing Alice to pay 80,152 - 50,868 = *29,284sat* > more > - In a non-v3 world, Mallory can make the cost to replace 80sat/vB * > (100,000vB) + 152 = 8,000,152sat > - Mallory succeeds, forcing Alice to pay 8,000,152 - 50,868 = > *7,949,284sat > *more (maxed out by the HTLC amount) > > As framed above, what we've done here is quantify the severity of the > pinning damage in the v3 and non-v3 world by calculating the additional > fees Mallory can force Alice to pay using Rule 3. To summarize this > discussion, at the lower end of possible commitment transaction sizes, > pinning is possible but is restricted by 100x, as claimed. Also, you're writeup is still missing a very important point: existing Lightning anchor channels solved pinning by having a CHECKSIG. Only the parties with the right to spend the anchor channel can do that, and all other outputs are unspendable until the commitment transaction confirms. So the question is not whether or not V3 transactions can improve pinning compared to a hypothetical protocol with vulnerabilities. The question, for Lightning, is how much better or worse V3 transactions would be than the status quo. So far, they look like the difference is marginal at best, quite possibly worse. Now, with other protocols, maybe we could make an argument that V3 transactions is worthwhile and for those protocols no other solution is possible. But you have not attempted to make that argument in the documentation provided in your pull-req(s). -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks
On Tue, Jan 02, 2024 at 11:12:05AM +, Gloria Zhao wrote: > Hi Peter, > > > You make a good point that the commitment transaction also needs to be > included > > in my calculations. But you are incorrect about the size of them. > > > With taproot and ephemeral anchors, a typical commitment transaction > would have > > a single-sig input (musig), two taproot outputs, and an ephemeral anchor > > output. Such a transaction is only 162vB, much less than 1000vB. > > Note that these scenarios are much less interesting for commitment > transactions with no HTLC outputs, so 162 isn't what I would use for the > minimum. What scenarios you consider "interesting" is not relevant. You can't pick an arbitrary minimum based on an interesting scenario. You should pick an actual relevant minimum. So with that in mind, let's ask the question: Do we think it's common for channels to be force closed without HTLCs pending? I believe the answer is likely to be yes, because channels are only used some of the time. Can we verify that? Well, I just checked my node, and out of the past 15 force closes, 12 had no HTLCs outstanding. 2 had one HTLC outstanding, and 1 had 2 HTLCs. I also checked a big node I'm connected to, fixedfloat. Again, out of the past 15 force closes, 11 had no HTLCs outstanding, with 4 having 1 HTLC outstanding... but of those only 2 HTLCs were profitable to collect. The other half cost more money in fees than the HTLC value. Looks to me like the supermajority of force closes are the most boring type. And those numbers would be even more tilted in that direction if Lightning implementations had better economics management. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Swift Activation - CTV
On Tue, Jan 2, 2024, 8:52 AM Michael Folkson wrote: > In the interests of time I'll just pick two to respond to but I don't > agree with any of your points. > > > Covenants allow trustless utxos sharing and also are needed for > vaulting. The numerous use cases are documented, built out and on signet to > my knowledge. Check out utxos.org for a good list > > Your knowledge is incorrect. As far as I know in the getting on for 2 > years since the first CTV activation talk/attempt literally no one has > built out a CTV use case and demonstrated it on signet with the possible > exception of James O'Beirne's OP_VAULT which requires other new opcodes in > addition to CTV. > Nice example, thanks. > > > 4. "Best tool for the job" is not the bar. "Safe for all" and "useful > for some" is the bar. > This is the bar, ant CTV has passed it with vaulting alone. If you want to avoid a chain split with an activation attempt (it is > possible you don't care but if you do) you have to address concerns others > have with a particular proposal. > You haven't mentioned one safety concern. It's hard to tell if you have any. There is, of course, the elephant in the room with CTV that is a true concern that nobody talks about. The real danger of CTV isn't whether it's the best, and we know it's nonrecursive. And we can use BIP8, so that isn't an issue either. And we already have shitcoins on BTC, so sapio shouldn't be your issue ( https://github.com/sapio-lang/sapio) Why exactly is your problem? You yourself have admitted it's useful for vaulting, and for reducing the cost of lightning onboarding, even though you ignored the dozens of other use cases enumerated in detail on utxos.org and elsewhere. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Swift Activation - CTV
In the interests of time I'll just pick two to respond to but I don't agree with any of your points. > Covenants allow trustless utxos sharing and also are needed for vaulting. The > numerous use cases are documented, built out and on signet to my knowledge. > Check out[utxos.org](http://utxos.org/)for a good list Your knowledge is incorrect. As far as I know in the getting on for 2 years since the first CTV activation talk/attempt literally no one has built out a CTV use case and demonstrated it on signet with the possible exception of James O'Beirne's OP_VAULT which requires other new opcodes in addition to CTV. I wish this wasn't the case. It is pitiful that we have these individuals (such as yourself) that are so convinced CTV should be activated but refuse to address any concerns raised by others and refuse to work on any of the speculated use cases, instead choosing to just beat the activation drum over and over again. > 4. "Best tool for the job" is not the bar. "Safe for all" and "useful for > some" is the bar. Like any opcodes or tech Bitcoin has deployed in the past. > Changing the bar is not up for discussion. If you want to avoid a chain split with an activation attempt (it is possible you don't care but if you do) you have to address concerns others have with a particular proposal. Just because Satoshi was able to make whatever changes he liked in the early days of Bitcoin's history and smaller groups of contributors then were able to activate changes without much scrutiny (Bitcoin was worth a fraction of what it is today and was only supporting a tiny ecosystem back then) doesn't mean we can do the same today. Appointing Erik as the new Satoshi who can make whatever changes he likes, who defines the bar with ultimate certainty and decides what is and what isn't up for discussion also isn't a viable option. Thanks Michael -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin On Monday, 1 January 2024 at 17:11, Erik Aronesty wrote: > 1. Claiming that something that isn't activated (unusable) isn't used as a > non-argument > > 2. Talking about activation methods is orthogonal. Bip8 is fine. > > 3. Covenants allow trustless utxos sharing and also are needed for vaulting. > The numerous use cases are documented, built out and on signet to my > knowledge. Check out utxos.org for a good list > > 3. No need to discuss wild extremes that are unrelated to ctvs well > documented utility. Plus multi-sig allows governments to encumber (or > accidentally ruin) destination addresses just like covenants. > > 4. "Best tool for the job" is not the bar. "Safe for all" and "useful for > some" is the bar. Like any opcodes or tech Bitcoin has deployed in the past. > Changing the bar is not up for discussion. > > CTV has already been demonstrated "useful for some". The question that needs > to be answered is whether there are any specific objections to safety. > > On Mon, Jan 1, 2024, 11:37 AM Michael Folkson > wrote: > >> Hi Erik >> >>> So what exactly are the risks of CTV over multi-sig? >> >> It is a strange comparison. Multisig is active onchain and is being used >> today for all sorts of things including Lightning and setups that address >> risk of single key loss or malicious signing. When discussing risks of CTV >> there are all sorts of risks that don't apply to multisig. These include >> that it is never used for any of its speculated use cases (multisig is being >> used today), other proposals end up being used instead of it (I'm not sure >> there were or are competing proposals so that multisig stops being used, >> MuSig2 maybe?), chain split risks with activation if there isn't consensus >> to activate it etc. Plus usage of complex (non covenant) scripts that fully >> utilize Taproot trees is still low today. Going straight to covenants >> (imposing restrictions on where funds can be sent) and not bothering with >> imposing all the restrictions you'd like on how funds can be spent in the >> first place seems to me to be putting the cart before the horse. Covenants >> don't ultimately solve the key management issue, they just move it from the >> pre spending phase to the post spending phase. So the benefits (although >> non-zero) aren't as obvious as some of the covenant advocates are >> suggesting. And although CTV is a limited covenant (some argue too limited) >> covenants taken to wild extremes could create all sorts of second order >> effects where funds can't be spent because of complex combinations of >> covenants. Even the strongest CTV proponent seems to suggest that the >> introduction of covenants wouldn't end with CTV. >> >> The way to reduce implementation risk for a use case of a particular >> proposal is to build out that use case and see if CTV is the best tool for >> the job. Repeatedly
Re: [bitcoin-dev] Ordinal Inscription Size Limits
Erik,
Fees AKA costs are the best spam control system and I thank you for
highlighting that.
However, I think that bitcoin has yet to receive sufficient payments
usage to challenge credit card payments system when it comes to a race
to the bottom in terms of processing transactional fees.
In the USA, where I am, large businesses like UBER, Lyft, and many major
telecom, cable, & electric utilities process huge volumes of regular and
irregular credit card payments on a monthly basis. Almost none oft hose
transactions are completed in bitcoin.
A focus on lowering fees by increasing the block size by 10x is the
simplest method to start accepting more payments in bitcoin from larger
businesses.
Brad
On 2023-12-30 01:58, Erik Aronesty via bitcoin-dev wrote:
> Bitcoin already has a spam prevention system called "fees". I don't believe
> it's insufficient. The only issue is the stochastic nature of its
> effectiveness
>
> Which can be resolved with things like payment pools, tree payments
> (https://utxos.org/uses/scaling/), etc.
>
> On Fri, Dec 29, 2023, 9:33 AM Greg Tonoski via bitcoin-dev
> wrote:
>
>>> Unfortunately, as near as I can tell there is no sensible way to
>>> prevent people from storing arbitrary data in witnesses ...
>>
>> To prevent "from storing arbitrary data in witnesses" is the extreme
>> case of the size limit discussed in this thread. Let's consider it along
>> with other (less radical) options in order not to lose perspective, perhaps.
>>
>>> ...without incentivizing even worse behavior and/or breaking
>>> legitimate use cases.
>>
>> I can't find evidence that would support the hypothesis. There had not
>> been "even worse behavior and/or breaking legitimate use cases" observed
>> before witnesses inception. The measure would probably restore
>> incentives structure from the past.
>>
>> As a matter of fact, it is the current incentive structure that poses
>> the problem - incentivizes worse behavior ("this sort of data is toxic
>> to the network") and breaks legitimate use cases like a simple transfer
>> of BTC.
>>
>>> If we ban "useless data" then it would be easy for would-be data
>>> storers to instead embed their data inside "useful" data such as dummy
>>> signatures or public keys.
>>
>> There is significant difference when storing data as dummy signatures
>> (or OP_RETURN) which is much more expensive than (discounted) witness.
>> Witness would not have been chosen as the storage of arbitrary data if
>> it cost as much as alternatives, e.g. OP_RETURN.
>>
>> Also, banning "useless data" seems to be not the only option suggested
>> by the author who asked about imposing "a size limit similar to OP_RETURN".
>>
>>> But from a technical point of view, I don't see any principled way to
>>> stop this.
>>
>> Let's discuss ways that bring improvement rather than inexistence of a
>> perfect technical solution that would have stopped "toxic data"/"crap on
>> the chain". There are at least a few:
>> - https://github.com/bitcoin/bitcoin/pull/28408
>> - https://github.com/bitcoin/bitcoin/issues/29146
>> - deprecate OP_IF opcode.
>>
>> I feel like the elephant in the room has been brought up. Do you want to
>> maintain Bitcoin without spam or a can't-stop-crap alternative, everybody?
>> ___
>> 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] Ordinal Inscription Size Limits
> > . > > In the USA, where I am, large businesses like UBER, Lyft, and many major > telecom, cable, & electric utilities process huge volumes of regular and > irregular credit card payments on a monthly basis. Almost none oft hose > transactions are completed in bitcoin. > Unfortunately block size is not the limiting factor Main chain transactions have to be broadcast and stored on every node in the network which, as you know, cannot scale to the level of Uber payments Lighting and possibly ark are solutions to this problem Both require covenant tech of some kind to scale properly (nonrecursive is fine) Covenant tech (any will do, arguing about which is bike shedding at this point) allows people to share utxos and yet still maintain sovereignty over their assets > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Swift Activation - CTV
1. Claiming that something that isn't activated (unusable) isn't used as a non-argument 2. Talking about activation methods is orthogonal. Bip8 is fine. 3. Covenants allow trustless utxos sharing and also are needed for vaulting. The numerous use cases are documented, built out and on signet to my knowledge. Check out utxos.org for a good list 3. No need to discuss wild extremes that are unrelated to ctvs well documented utility. Plus multi-sig allows governments to encumber (or accidentally ruin) destination addresses just like covenants. 4. "Best tool for the job" is not the bar. "Safe for all" and "useful for some" is the bar. Like any opcodes or tech Bitcoin has deployed in the past. Changing the bar is not up for discussion. CTV has already been demonstrated "useful for some". The question that needs to be answered is whether there are any specific objections to safety. On Mon, Jan 1, 2024, 11:37 AM Michael Folkson wrote: > Hi Erik > > > So what exactly are the risks of CTV over multi-sig? > > It is a strange comparison. Multisig is active onchain and is being used > today for all sorts of things including Lightning and setups that address > risk of single key loss or malicious signing. When discussing risks of CTV > there are all sorts of risks that don't apply to multisig. These include > that it is never used for any of its speculated use cases (multisig is > being used today), other proposals end up being used instead of it (I'm not > sure there were or are competing proposals so that multisig stops being > used, MuSig2 maybe?), chain split risks with activation if there isn't > consensus to activate it etc. Plus usage of complex (non covenant) scripts > that fully utilize Taproot trees is still low today. Going straight to > covenants (imposing restrictions on *where* funds can be sent) and not > bothering with imposing all the restrictions you'd like on *how* funds > can be spent in the first place seems to me to be putting the cart before > the horse. Covenants don't ultimately solve the key management issue, they > just move it from the pre spending phase to the post spending phase. So the > benefits (although non-zero) aren't as obvious as some of the covenant > advocates are suggesting. And although CTV is a limited covenant (some > argue too limited) covenants taken to wild extremes could create all sorts > of second order effects where funds can't be spent because of complex > combinations of covenants. Even the strongest CTV proponent seems to > suggest that the introduction of covenants wouldn't end with CTV. > > The way to reduce implementation risk for a use case of a particular > proposal is to build out that use case and see if CTV is the best tool for > the job. Repeatedly trying to activate CTV when there isn't consensus for > it to be activated does not reduce that implementation risk in any way, > shape or form. > > Thanks > Michael > > > -- > Michael Folkson > Email: michaelfolkson at protonmail.com > GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F > > Learn about Bitcoin: https://www.youtube.com/@portofbitcoin > > On Saturday, 30 December 2023 at 08:59, Erik Aronesty via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > So what exactly are the risks of CTV over multi-sig? > > >> >> > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks
Hi Peter, > You make a good point that the commitment transaction also needs to be included > in my calculations. But you are incorrect about the size of them. > With taproot and ephemeral anchors, a typical commitment transaction would have > a single-sig input (musig), two taproot outputs, and an ephemeral anchor > output. Such a transaction is only 162vB, much less than 1000vB. Note that these scenarios are much less interesting for commitment transactions with no HTLC outputs, so 162 isn't what I would use for the minimum. Looking at expected weights in bolt 3 ( https://github.com/lightning/bolts/blob/master/03-transactions.md#expected-weight-of-the-commitment-transaction) with 1 HTLC and anchors, we get (900 + 172 * num-htlc-outputs + 224 weight)/4 = 324vB. So, I apologize for not using a more accurate minimum, though I think this helps illustrate the 100x reduction of v3 a lot better. While I think the true minimum is higher, let's go ahead and use your number N=162vB. - Alice is happy to pay 162sat/vB * (162 + 152vB) = 50,868sat - In a v3 world, Mallory can make the cost to replace 80sat/vB * (1000vB) + 152 = 80,152sat - Mallory succeeds, forcing Alice to pay 80,152 - 50,868 = *29,284sat* more - In a non-v3 world, Mallory can make the cost to replace 80sat/vB * (100,000vB) + 152 = 8,000,152sat - Mallory succeeds, forcing Alice to pay 8,000,152 - 50,868 = *7,949,284sat *more (maxed out by the HTLC amount) As framed above, what we've done here is quantify the severity of the pinning damage in the v3 and non-v3 world by calculating the additional fees Mallory can force Alice to pay using Rule 3. To summarize this discussion, at the lower end of possible commitment transaction sizes, pinning is possible but is restricted by 100x, as claimed. Best, Gloria On Wed, Dec 20, 2023 at 9:11 PM Peter Todd wrote: > On Wed, Dec 20, 2023 at 03:16:25PM -0500, Greg Sanders wrote: > > Hi Peter, > > > > Thanks for taking the time to understand the proposal and give thoughtful > > feedback. > > > > With this kind of "static" approach I think there are fundamental > > limitations because > > the user has to commit "up front" how large the CPFP later will have to > be. > > 1kvB > > is an arbitrary value that is two orders of magnitude less than the > > possible package > > size, and allows fairly flexible amounts of inputs(~14 taproot inputs > > IIRC?) to effectuate a CPFP. > > Why would you need so many inputs to do a CPFP if they all have to be > confirmed? The purpose of doing a CPFP is to pay fees to get another > transaction mined. Unless you're in some degenerate, unusual, situation > where > you've somehow ended up with just some dust left in your wallet, dust that > is > barely worth its own fees to spend, one or maybe two UTXOs are going to be > sufficient for a fee payment. > > I had incorrectly thought that V3 transctions allowed for a single up-to > 1000vB > transaction to pay for multiple parents at once. But if you can't do that, > due > to the restriction on unconfirmed inputs, I can't see any reason to have > such a > large limit. > > > I'd like something much more flexible, but we're barely at whiteboard > stage > > for alternatives and > > they probably require more fundamental work. So within these limits, we > > have to pick some number, > > and it'll have tradeoffs. > > > > When I think of "pinning potential", I consider not only the parent size, > > and not > > only the maximum child size, but also the "honest" child size. If the > honest > > user does relatively poor utxo management, or the commitment transaction > > is of very high value(e.g., lots of high value HTLCs), the pin is > > essentially zero. > > If the honest user ever only have one utxo, then the "max pin" is > effective > > indeed. > > Which is the situation you would expect in the vast majority of cases. > > > > Alice would have had to pay a 2.6x higher fee than > > expected. > > > > I think that's an acceptable worst case starting point, versus the status > > quo which is ~500-1000x+. > > No, the status quo is signed anchors, like Lightning already has with > anchor > channels. Those anchors could still be zero-valued. But as long as there > is a > signature associated with them, pinning isn't a problem as only the > intended > party can spend them. > > Note BTW that existing Lightning anchor channels inefficiently use two > anchor > outputs when just one is sufficient: > > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004246.html > [Lightning-dev] The remote anchor of anchor channels is redundant > Peter Todd, Dec 13th, 2023 > > -- > 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] Swift Activation - CTV
Hi Erik > So what exactly are the risks of CTV over multi-sig? It is a strange comparison. Multisig is active onchain and is being used today for all sorts of things including Lightning and setups that address risk of single key loss or malicious signing. When discussing risks of CTV there are all sorts of risks that don't apply to multisig. These include that it is never used for any of its speculated use cases (multisig is being used today), other proposals end up being used instead of it (I'm not sure there were or are competing proposals so that multisig stops being used, MuSig2 maybe?), chain split risks with activation if there isn't consensus to activate it etc. Plus usage of complex (non covenant) scripts that fully utilize Taproot trees is still low today. Going straight to covenants (imposing restrictions on where funds can be sent) and not bothering with imposing all the restrictions you'd like on how funds can be spent in the first place seems to me to be putting the cart before the horse. Covenants don't ultimately solve the key management issue, they just move it from the pre spending phase to the post spending phase. So the benefits (although non-zero) aren't as obvious as some of the covenant advocates are suggesting. And although CTV is a limited covenant (some argue too limited) covenants taken to wild extremes could create all sorts of second order effects where funds can't be spent because of complex combinations of covenants. Even the strongest CTV proponent seems to suggest that the introduction of covenants wouldn't end with CTV. The way to reduce implementation risk for a use case of a particular proposal is to build out that use case and see if CTV is the best tool for the job. Repeatedly trying to activate CTV when there isn't consensus for it to be activated does not reduce that implementation risk in any way, shape or form. Thanks Michael -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin On Saturday, 30 December 2023 at 08:59, Erik Aronesty via bitcoin-dev wrote: > So what exactly are the risks of CTV over multi-sig? > >>___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
