Ruben Somsen [ARCHIVE]

📅 Original date posted:2022-10-01
📝 Original message:Hi Bastien,
>Greg already has a draft design that addresses your concerns
Thanks, that is very nice. In that case I currently have no outstanding
objections.
>I'm curious why you would need more than one such output
My reasoning was actually to allow only one OP_TRUE output per transaction,
so I think we agree. Apologies if that wasn't clear.
To summarize:
1. OP_TRUE output must be spent
2. Only one child allowed per transaction
This ensures there is no scenario where a child is propagated that does not
spend the OP_TRUE output.
Cheers,
Ruben
On Fri, Sep 30, 2022 at 2:17 PM Greg Sanders <gsanders87 at gmail.com> wrote:
> It's likely better if the ephemeral output can be any value, including
> dust. This lets contract designers put "trimmed output" value indirectly
> towards CPFP fees without making the parent tx have fees itself.
>
> On Fri, Sep 30, 2022, 8:08 AM Bastien TEINTURIER <bastien at acinq.fr> wrote:
>
>> Hey Ruben,
>>
>> I discussed this further over IRC, and I now agree that this particular
>> change would be very desirable and can likely fit in the initial release
>> (even though I'm not the one writing that code, but I'd be happy to
>> review it and test it).
>>
>> Greg already has a draft design that addresses your concerns: if there is
>> an "ephemeral output" (0-value, OP_TRUE) in an unconfirmed v3 transaction,
>> it MUST be spent by any child v3 transaction. This way, you ensure that
>> any child transaction spending the unconfirmed parent spends the ephemeral
>> output(s). @Greg, correct me if I misunderstood something here. Note that
>> we will need to precisely define the criteria for those "ephemeral
>> outputs"
>> (it can probably simply be "outputs that are 0 sats").
>>
>> Coupled with transactions that pay no fees (and thus require a child to
>> CPFP in order to be included in a block), this ensures those outputs can
>> never leak into the utxo set. How does that sound?
>>
>> I'm curious why you would need more than one such output, can you detail?
>> I believe we only ever need one, spendable by anyone.
>>
>> Cheers,
>> Bastien
>>
>> Le ven. 30 sept. 2022 à 02:14, Ruben Somsen <rsomsen at gmail.com> a écrit :
>>
>>> Hi Bastien,
>>>
>>> >The other change mentioned (making OP_TRUE standard and allowing outputs
>>> that are below dust) can be added later, as those won't be standard until
>>> we start allowing them, so there shouldn't be any backwards-compatibility
>>> issue with postponing this change. But maybe it's still worth having from
>>> the get-go, even though it may take a bit more time? Again, I'm curious
>>> to
>>> have other people's opinion here
>>>
>>> I'm sensitive to not wanting to overload the current discussion but this
>>> also interests me, provided it can be done in a way that is acceptable
>>> (i.e. minimizing the potential UTXO set impact). It would solve a big cost
>>> issue in my spacechains design if transactions could be 0 fees and have a 0
>>> sat output that could be used in order to pay all the fees with CPFP.
>>>
>>> My current view is that a tx containing a single 0 sat OP_TRUE output
>>> should only get relayed if it is a package where the OP_TRUE output is
>>> currently being spent in a way that increases the overall fee rate. But
>>> even then, one theoretical edge case remains:
>>> - Another CPFP tx can feebump the package on a different (non-OP_TRUE)
>>> output with an even higher fee rate
>>> - Subsequently, the tx that is spending the OP_TRUE might fall out of
>>> the mempool if the mempool fee rate rises
>>> - This could cause the 0 sat output to enter the UTXO set (specifically,
>>> rational miners wouldn't refuse to mine such a tx)
>>>
>>> It doesn't seem like this would happen much in practice (nor is there an
>>> incentive to do it on purpose), but the chance isn't 0.
>>>
>>> Cheers,
>>> Ruben
>>>
>>>
>>>
>>> On Thu, Sep 29, 2022 at 4:50 PM Greg Sanders via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> > Right, good catch, this does require new logic to handle this case.
>>>> As Gloria points out, this should be doable, and is definitely worth
>>>> adding (those CSV 1 on every other output are really hacky, glad to
>>>> find a way to get rid of them).
>>>>
>>>> For the record, it turns out ephemeral anchors + v3 solves this
>>>> already, as the anchor must be spent, and the parent tx may only have one
>>>> child. Somehow I missed this implication for a few months. It's great news
>>>> if we can directly source fees from any output claimable, including HTLCs!
>>>>
>>>> On Thu, Sep 29, 2022 at 5:15 AM Bastien TEINTURIER <bastien at acinq.fr>
>>>> wrote:
>>>>
>>>>> Hi Gloria, Greg,
>>>>>
>>>>> > I interpret most of the discussion around limitations as ideas for
>>>>> > future improvements rather than criticisms of the proposal
>>>>>
>>>>> As far as I'm concerned, definitely!
>>>>>
>>>>> My current understanding is that the main change/improvement that would
>>>>> make sense here is restricting the whole v3 package's size (instead of
>>>>> just the child) via committing to a specific value in the taproot annex
>>>>> (also note that it's probably not just the v3 package's size, it should
>>>>> be the whole unconfirmed package including potential v2 unconfirmed
>>>>> ancestors).
>>>>>
>>>>> While I think this would be very valuable and would like to see this
>>>>> happen, I believe that can be done in a second, separate step since
>>>>> this
>>>>> would make relay policy stricter (some v3 transactions that previously
>>>>> propagated wouldn't propagate under this new rule). As long as you are
>>>>> able to find a path to miners through upgraded peers that use this
>>>>> annex
>>>>> approach, you should be able to resolve ACP pinning issues?
>>>>>
>>>>> I'm curious to know how other people feel about that: is it ok to do
>>>>> later or should we try to implement this for the first release of v3
>>>>> transactions?
>>>>>
>>>>> The other change mentioned (making OP_TRUE standard and allowing
>>>>> outputs
>>>>> that are below dust) can be added later, as those won't be standard
>>>>> until
>>>>> we start allowing them, so there shouldn't be any
>>>>> backwards-compatibility
>>>>> issue with postponing this change. But maybe it's still worth having
>>>>> from
>>>>> the get-go, even though it may take a bit more time? Again, I'm
>>>>> curious to
>>>>> have other people's opinion here, I'd be happy to get all of those
>>>>> directly
>>>>> in the first release of v3 transactions, but I don't know how much
>>>>> implementation will have to go into that.
>>>>>
>>>>> > For clarification, package RBF is ParentTx*s*(plural), and
>>>>> ChildTx(singular),
>>>>> > so it might be a bit more complicated than we're thinking
>>>>>
>>>>> Right, good catch, this does require new logic to handle this case.
>>>>> As Gloria points out, this should be doable, and is definitely worth
>>>>> adding (those CSV 1 on every other output are really hacky, glad to
>>>>> find a way to get rid of them).
>>>>>
>>>>> Thanks,
>>>>> Bastien
>>>>>
>>>>> Le lun. 26 sept. 2022 à 18:48, Gloria Zhao <gloriajzhao at gmail.com> a
>>>>> écrit :
>>>>>
>>>>>> Hi Greg, Antoine, Bastien,
>>>>>>
>>>>>> Thanks very much for the feedback! I interpret most of the discussion
>>>>>> around limitations as ideas for future improvements rather than criticisms
>>>>>> of the proposal (please correct me if I'm wrong). I'll try to respond to as
>>>>>> much as possible.
>>>>>>
>>>>>> Also I realize that I didn't contextualize this proposal clearly
>>>>>> enough; it is very tailored for LN Penalty and definitely doesn't close all
>>>>>> pinning attacks possible (sorry for confusing anyone). I also agree that
>>>>>> some bits can be a little ugly or tack-on; I would definitely prefer a
>>>>>> comprehensive RBF revamp to fix all our problems and enable other
>>>>>> fee-bumping strategies such as
>>>>>> sign-ANYONECANPAY-then-bring-your-own-fees-by-adding-inputs-at-broadcast. I
>>>>>> was hoping to get some ideas with the "RBF Improvements" post in January,
>>>>>> but it doesn't seem like we're much closer to a workable proposal. I think
>>>>>> this is a minimally-invasive step that works for Lightning today, a small
>>>>>> fix similar to CPFP carve out.
>>>>>>
>>>>>> > As you likely know from previous discussions the biggest scenario
>>>>>> this does not fix in my estimation is ANYONECANPAY situations. If the
>>>>>> parent transaction can be "inflated" by tacking on additional inputs, this
>>>>>> means the total weight of the parent tx lowers the effective feerate of the
>>>>>> package.
>>>>>>
>>>>>> (For more context to other readers I wrote an explanation for this in
>>>>>> "SIGHASH_ANYONECANPAY Pinning" section of RBF ML post). Yes, this
>>>>>> unfortunately doesn't fix any of the existing pinning attacks for single
>>>>>> transaction RBF but also doesn't make them worse. This boils down to adding
>>>>>> an incentive compatibility rule that ensures you can't replace a
>>>>>> transaction with something that will confirm slower. Package RBF has an
>>>>>> ancestor feerate-based rule for this (note it is quite conservative and not
>>>>>> perfect).
>>>>>>
>>>>>> So in the scenario above with the "inflated" parent that was signed
>>>>>> ACP, the replacement would be rejected because the package ancestor feerate
>>>>>> is lower than the feerate of what is being replaced. But it is imperfect
>>>>>> (explained below) and thus I wouldn't recommend it for single transaction
>>>>>> replacement. So that attack still exists for single transactions, yes.
>>>>>>
>>>>>> The strategy of using ACP to bring-your-own-fees has its own
>>>>>> challenges but hopefully has no current use cases as you say. AFAIK LN
>>>>>> Penalty is not affected by this since it doesn't use ACP, though obviously
>>>>>> I agree we should fix it for the future.
>>>>>>
>>>>>> So when I said "this is intended for fee-bumping presigned txns in
>>>>>> contracting protocols," I should have said "this is intended for
>>>>>> fee-bumping presigned txns specifically using CPFP and anchor outputs."
>>>>>> Apologies for forgetting to contextualize, I've been sitting on this for
>>>>>> too long.
>>>>>>
>>>>>> > The other scenario it doesn't really fix is where
>>>>>> HTLC/commitment-like transactions are being resolved in a batch, but due to
>>>>>> relative time constraints, you may want to accelerate some and not others.
>>>>>> Now you must pay higher rates to replace all of the transaction bumps. This
>>>>>> is a "self-pin" and "get good at utxos noob" type problem, but it's
>>>>>> something that axing rule#3 in favor of a Replace-by-ancestor-feerate
>>>>>> system would get us.
>>>>>>
>>>>>> I understand you to mean "if you don't have enough UTXOs and you're
>>>>>> forced to batch-bump, you over-pay because you need to bring them all to
>>>>>> the highest target feerate." Isn't this kind of separate, wallet-related
>>>>>> problem? Contracting or not, surely every wallet needs to have enough UTXOs
>>>>>> to not batch transactions that shouldn't be batched... I don't see how a
>>>>>> replace-by-ancestor-feerate policy would make any difference for this?
>>>>>>
>>>>>> Also in general I'd like to reiterate that ancestor feerate is not a
>>>>>> panacea to all our RBF incentive compatibility concerns. Like individual
>>>>>> feerate, unless we run the mining algorithm, it cannot tell us exactly how
>>>>>> quickly this transaction would be mined.
>>>>>>
>>>>>> We're estimating the incentive compatibility of the original
>>>>>> transaction(s) and replacement transaction(s), with the goal of not letting
>>>>>> a transaction replace something that would have been more incentive
>>>>>> compatible to mine. As such, we don't want to overestimate how good the
>>>>>> replacement is, and we don't want to underestimate how good the original
>>>>>> transactions are. This rule "The minimum between package feerate and
>>>>>> ancestor feerate of the child is not lower than the individual feerates of
>>>>>> all directly conflicting transactions and the ancestor feerates of all
>>>>>> original transactions" is a conservative estimate.
>>>>>>
>>>>>> > Would kind of be nice if package RBF would detect a "sibling output
>>>>>> spend" conflict, and knock it out of the mempool via the other replacement
>>>>>> rules? Getting rid of the requirement to 1 block csv lock every output
>>>>>> would be quite nice from a smart contracting composability point of view.
>>>>>>
>>>>>> Interesting, so when a transaction hits a mempool tx's descendant
>>>>>> limit, we consider evicting one of its descendants in favor of this
>>>>>> transaction, based on the RBF rules.
>>>>>> Cool idea! After chewing on this for a bit, I think this *also* just
>>>>>> boils down to the fact that RBF should require replacements to be better
>>>>>> mining candidates. As in, if we added this policy and it can make us evict
>>>>>> the sibling and accept a transaction with a bunch of low-feerate ancestor
>>>>>> junk, it would be a new pinning vector.
>>>>>>
>>>>>> > If you're a miner and you receive a non-V3, second descendant of an
>>>>>> unconfirmed V3 transaction, if the offered fee is in the top mempool
>>>>>> backlog, I think you would have an interest to accept such a transaction.
>>>>>>
>>>>>> > So I'm not sure if those two rules are compatible with miners
>>>>>> incentives...
>>>>>>
>>>>>> The same argument can be made for the 26th descendant of a mempool
>>>>>> transaction; it's also not entirely incentive-compatible to reject it, but
>>>>>> that is not the *only* design goal in mempool policy. Of course, the
>>>>>> difference here is that the 25-descendant limit rule is a sensible DoS
>>>>>> protection, while this 1-descendant limit rule is more of a "help the
>>>>>> Bitcoin ecosystem" policy, just like CPFP carve-out, dust limit, etc. I can
>>>>>> of course understand why not everyone would be in favor of this, but I do
>>>>>> think it's worth it.
>>>>>>
>>>>>> > > 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be
>>>>>>
>>>>>> > > larger than 1000 virtual bytes.
>>>>>>
>>>>>> > If I understand correctly the 1000 vb upper bound rational, it
>>>>>> would be to constraint the pinning counterparty to attach a high fee to a
>>>>>> child due to the limited size, if they would like this transaction to be
>>>>>> stuck in the network mempools. By doing so this child has high odds to
>>>>>> confirm.
>>>>>>
>>>>>> Yeah exactly, the "Rule 3 pin" is done by adding a child that's
>>>>>> high-fee (so you have to pay that much to evict it). Because they *don't*
>>>>>> want this tx to confirm, normally, this child would be really large. If
>>>>>> they only have 1000vB for the child, they can't increase the replacement
>>>>>> cost without also fee-bumping the transaction to make it confirm faster.
>>>>>>
>>>>>> > As of today, I think yes you can already fingerprint LN
>>>>>> transactions on the spec-defined amount value of the anchor outputs, 330
>>>>>> sats. There is always one of them on post-anchor commitment transactions.
>>>>>> And sadly I would say we'll always have tricky fingerprints leaking from
>>>>>> unilateral LN closures such as HTLC/PTLC timelocks...
>>>>>>
>>>>>> > I agree with you, this isn't worse than today, unilateral closes
>>>>>> will
>>>>>> probably always be identifiable on-chain.
>>>>>>
>>>>>> Great to hear that there is no privacy worsening!
>>>>>>
>>>>>> Best,
>>>>>> Gloria
>>>>>>
>>>>>> On Mon, Sep 26, 2022 at 5:02 PM Greg Sanders <gsanders87 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Bastien,
>>>>>>>
>>>>>>> > This may be already covered by the current package RBF logic, in
>>>>>>> that
>>>>>>> scenario we are simply replacing [ParentTx, ChildTx1] with
>>>>>>> [ParentTx, ChildTx2] that pays more fees, right?
>>>>>>>
>>>>>>> For clarification, package RBF is ParentTx*s*(plural), and
>>>>>>> ChildTx(singular), so it might be a bit more complicated than we're
>>>>>>> thinking, and currently the V3 proposal would first de-duplicate the
>>>>>>> ParentTx based on what is in the mempool, then look at the "rest" of the
>>>>>>> transactions as a package, then individually. Not the same, not sure how
>>>>>>> different. I'll defer to experts.
>>>>>>>
>>>>>>> Best,
>>>>>>> Greg
>>>>>>>
>>>>>>> On Mon, Sep 26, 2022 at 11:48 AM Bastien TEINTURIER via bitcoin-dev <
>>>>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>>>
>>>>>>>> Thanks Gloria for this great post.
>>>>>>>>
>>>>>>>> This is very valuable work for L2 contracts, and will greatly
>>>>>>>> improve
>>>>>>>> their security model.
>>>>>>>>
>>>>>>>> > "Only 1 anchor output? What if I need to bump counterparty's
>>>>>>>> commitment tx in mempool?"
>>>>>>>> > You won't need to fee-bump a counterparty's commitment tx using
>>>>>>>> CPFP.
>>>>>>>> > You would just package RBF it by attaching a high-feerate child to
>>>>>>>> > your commitment tx.
>>>>>>>>
>>>>>>>> Note that we can also very easily make that single anchor spendable
>>>>>>>> by
>>>>>>>> both participants (or even anyone), so if you see your
>>>>>>>> counterparty's
>>>>>>>> commitment in your mempool, you can bump it without publishing your
>>>>>>>> own commitment, which is quite desirable (your own commitment tx has
>>>>>>>> CSV delays on your outputs, whereas your counterparty's commitment
>>>>>>>> tx
>>>>>>>> doesn't).
>>>>>>>>
>>>>>>>> > "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN
>>>>>>>> transactions based on nVersion?"
>>>>>>>>
>>>>>>>> I agree with you, this isn't worse than today, unilateral closes
>>>>>>>> will
>>>>>>>> probably always be identifiable on-chain.
>>>>>>>>
>>>>>>>> > Would kind of be nice if package RBF would detect a "sibling
>>>>>>>> output spend"
>>>>>>>> > conflict, and knock it out of the mempool via the other
>>>>>>>> replacement rules?
>>>>>>>> > Getting rid of the requirement to 1 block csv lock every output
>>>>>>>> would be
>>>>>>>> > quite nice from a smart contracting composability point of view.
>>>>>>>>
>>>>>>>> +1, that would be very neat!
>>>>>>>>
>>>>>>>> This may be already covered by the current package RBF logic, in
>>>>>>>> that
>>>>>>>> scenario we are simply replacing [ParentTx, ChildTx1] with
>>>>>>>> [ParentTx, ChildTx2] that pays more fees, right?
>>>>>>>>
>>>>>>>> > 1) I do think that we should seriously consider allowing OP_TRUE
>>>>>>>> to become
>>>>>>>> > a standard script type as part of this policy update. If pinning
>>>>>>>> is solved,
>>>>>>>> > then there's no reason to require all those extra bytes for
>>>>>>>> "binding" an
>>>>>>>> > anchor to a specific wallet/user. We can save quite a few bytes
>>>>>>>> by having
>>>>>>>> > the input be empty of witness data.
>>>>>>>> > 2) If we allow for a single dust-value(0 on up) output which is
>>>>>>>> immediately
>>>>>>>> > spent by the package, anchors become even easier to to design. No
>>>>>>>> value has
>>>>>>>> > to be "sapped" from contract participants to make an anchor
>>>>>>>> output. There's
>>>>>>>> > more complications for this, such as making sure the parent
>>>>>>>> transaction is
>>>>>>>> > dropped if the child spend is dropped, but maybe it's worth the
>>>>>>>> squeeze.
>>>>>>>>
>>>>>>>> I also think both of these could be quite useful. This would
>>>>>>>> probably always
>>>>>>>> be used in combination with a parent transaction that pays 0 fees,
>>>>>>>> so the
>>>>>>>> 0-value output would always be spent in the same block.
>>>>>>>>
>>>>>>>> But this means we could end up with 0-value outputs in the utxo
>>>>>>>> set, if for
>>>>>>>> some reason the parent tx is CPFP-ed via another output than the
>>>>>>>> 0-value one,
>>>>>>>> which would be a utxo set bloat issue. But I'd argue that we're
>>>>>>>> probably
>>>>>>>> already creating utxo set bloat with the 330 sat anchor outputs
>>>>>>>> (especially
>>>>>>>> since we use two of them, but only one is usually spent), so it
>>>>>>>> would
>>>>>>>> probably be *better* than what we're doing today.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Bastien
>>>>>>>>
>>>>>>>> Le lun. 26 sept. 2022 à 03:22, Antoine Riard via bitcoin-dev <
>>>>>>>> bitcoin-dev at lists.linuxfoundation.org> a écrit :
>>>>>>>>
>>>>>>>>> Hi Gloria,
>>>>>>>>>
>>>>>>>>> Thanks for the progress on package RBF, few early questions.
>>>>>>>>>
>>>>>>>>> > 2. Any descendant of an unconfirmed V3 transaction must also be
>>>>>>>>> V3.
>>>>>>>>>
>>>>>>>>> > 3. An unconfirmed V3 transaction cannot have more than 1
>>>>>>>>> descendant.
>>>>>>>>>
>>>>>>>>> If you're a miner and you receive a non-V3, second descendant of
>>>>>>>>> an unconfirmed V3 transaction, if the offered fee is in the top mempool
>>>>>>>>> backlog, I think you would have an interest to accept such a transaction.
>>>>>>>>>
>>>>>>>>> So I'm not sure if those two rules are compatible with miners
>>>>>>>>> incentives...
>>>>>>>>>
>>>>>>>>> > 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be
>>>>>>>>> > larger than 1000 virtual bytes.
>>>>>>>>>
>>>>>>>>> If I understand correctly the 1000 vb upper bound rational, it
>>>>>>>>> would be to constraint the pinning counterparty to attach a high fee to a
>>>>>>>>> child due to the limited size, if they would like this transaction to be
>>>>>>>>> stuck in the network mempools. By doing so this child has high odds to
>>>>>>>>> confirm.
>>>>>>>>>
>>>>>>>>> I still wonder if this compatible with miner incentives in period
>>>>>>>>> of empty mempools, in the sense that if you've already a V3 transaction of
>>>>>>>>> size 100Kvb offering 2 sat/vb, it's more interesting than a V3 replacement
>>>>>>>>> candidate of size 1000 vb offering 10 sat/vb. It could be argued the former
>>>>>>>>> should be conserved.
>>>>>>>>>
>>>>>>>>> (That said, the hard thing with any replacement strategy we might
>>>>>>>>> evict a parent transaction *now* to which is attached a high-feerate child
>>>>>>>>> *latter* making for a utxo considered the best ancestor set. Maybe in the
>>>>>>>>> long-term miners should keep every transaction ever accepted...)
>>>>>>>>>
>>>>>>>>> > (Lower bound) the smaller this limit, the fewer UTXOs a child
>>>>>>>>> may use
>>>>>>>>> > to fund this fee-bump. For example, only allowing the V3 child
>>>>>>>>> to have
>>>>>>>>> > 2 inputs would require L2 protocols to manage a wallet with
>>>>>>>>> high-value
>>>>>>>>> > UTXOs and make batched fee-bumping impossible. However, as the
>>>>>>>>> > fee-bumping child only needs to fund fees (as opposed to
>>>>>>>>> payments),
>>>>>>>>> > just a few UTXOs should suffice.
>>>>>>>>>
>>>>>>>>> Reminder for L2 devs, batched fee-bumping of time-sensitive
>>>>>>>>> confirmations of commitment transactions is unsafe, as the counterparty
>>>>>>>>> could enter in a "cat-and-mouse" game to replace one of the batch element
>>>>>>>>> at each block to delay confirmation of the remaining elements in the batch,
>>>>>>>>> I think.
>>>>>>>>>
>>>>>>>>> On the other hand, I wonder if we wouldn't want a higher bound. LN
>>>>>>>>> wallets are likely to have one big UTXO in their fee-bumping reserve pool,
>>>>>>>>> as the cost of acquiring UTXO is non-null and in the optimistic case, you
>>>>>>>>> don't need to do unilateral closure. Let's say you close dozens of channels
>>>>>>>>> at the same time, a UTXO pool management strategy might be to fan-out the
>>>>>>>>> first spends UTXOs in N fan-out outputs ready to feed the remaining
>>>>>>>>> in-flight channels.
>>>>>>>>>
>>>>>>>>> > 1. The rule around unconfirmed inputs was
>>>>>>>>> > originally "A package may include new unconfirmed inputs, but the
>>>>>>>>> > ancestor feerate of the child must be at least as high as the
>>>>>>>>> ancestor
>>>>>>>>> > feerates of every transaction being replaced."
>>>>>>>>>
>>>>>>>>> Note, I think we would like this new RBF rule to also apply to
>>>>>>>>> single transaction package, e.g second-stage HTLC transactions, where a
>>>>>>>>> counterparty pins a HTLC-preimage by abusing rule 3. In that case, the
>>>>>>>>> honest LN node should be able to broadcast a "at least as high ancestor
>>>>>>>>> feerate" HTLC-timeout transaction. With `option_anchor_outputs" there is no
>>>>>>>>> unconfirmed ancestor to replace, as the commitment transaction, whatever
>>>>>>>>> the party it is originating from, should already be confirmed.
>>>>>>>>>
>>>>>>>>> > "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN
>>>>>>>>> transactions based on nVersion?"
>>>>>>>>>
>>>>>>>>> As of today, I think yes you can already fingerprint LN
>>>>>>>>> transactions on the spec-defined amount value of the anchor outputs, 330
>>>>>>>>> sats. There is always one of them on post-anchor commitment transactions.
>>>>>>>>> And sadly I would say we'll always have tricky fingerprints leaking from
>>>>>>>>> unilateral LN closures such as HTLC/PTLC timelocks...
>>>>>>>>>
>>>>>>>>> > "Can a V2 transaction replace a V3 transaction and vice versa?"
>>>>>>>>>
>>>>>>>>> IIUC, a V3 package could replace a V2 package, with the benefit of
>>>>>>>>> the new package RBF rules applied. I think this would be a significant
>>>>>>>>> advantage for LN, as for the current ~85k of opened channels, the old V2
>>>>>>>>> states shouldn't be pinning vectors. Currently, commitment transactions
>>>>>>>>> signal replaceability.
>>>>>>>>>
>>>>>>>>> Le ven. 23 sept. 2022 à 11:26, Gloria Zhao via bitcoin-dev <
>>>>>>>>> bitcoin-dev at lists.linuxfoundation.org> a écrit :
>>>>>>>>>
>>>>>>>>>> Hi everyone,
>>>>>>>>>>
>>>>>>>>>> I'm writing to propose a very simple set of mempool/transaction
>>>>>>>>>> relay
>>>>>>>>>> policies intended to aid L2/contract protocols. I realized that
>>>>>>>>>> the previously proposed Package Mempool Accept package RBF [1]
>>>>>>>>>> had a few remaining problems after digging into the RBF logic
>>>>>>>>>> more [2].
>>>>>>>>>> This additional set of policies solves them without requiring a
>>>>>>>>>> huge RBF overhaul.
>>>>>>>>>>
>>>>>>>>>> I've written an implementation (and docs) for Bitcoin Core:
>>>>>>>>>> https://github.com/bitcoin/bitcoin/pull/25038
>>>>>>>>>>
>>>>>>>>>> (You may notice that this proposal incorporates feedback on the
>>>>>>>>>> PR - thanks Suhas Daftuar, Gregory Sanders, Bastien Teinturier, Anthony
>>>>>>>>>> Towns, and others.)
>>>>>>>>>>
>>>>>>>>>> If you are interested in using package RBF/relay to bump presigned
>>>>>>>>>> transactions, I think you may be interested in reviewing this
>>>>>>>>>> proposal.
>>>>>>>>>> This should solve Rule 3 pinning and perhaps allow us
>>>>>>>>>> to get rid of CPFP carve-out (yay!). I'm keen to hear if people
>>>>>>>>>> find
>>>>>>>>>> the 1-anchor-output, 1000vB child limit too restrictive. Also, if
>>>>>>>>>> you find a
>>>>>>>>>> pinning attack or something that makes it unusable for you, I
>>>>>>>>>> would
>>>>>>>>>> really really like to know.
>>>>>>>>>>
>>>>>>>>>> Note that transactions with nVersion=3 ("V3 transactions") are
>>>>>>>>>> currently non-standard in Bitcoin Core. That means **anything
>>>>>>>>>> that was
>>>>>>>>>> standard before this policy change would still be standard
>>>>>>>>>> afterwards.** If you don't want your transactions to be subject to
>>>>>>>>>> these rules, just continue whatever you're doing and don't use
>>>>>>>>>> nVersion=3. AFAICT this shouldn't break anything, but let me know
>>>>>>>>>> if
>>>>>>>>>> this would be disruptive for you?
>>>>>>>>>>
>>>>>>>>>> **New Policies:**
>>>>>>>>>>
>>>>>>>>>> This includes:
>>>>>>>>>> - a set of additional policy rules applying to V3 transactions
>>>>>>>>>> - modifications to package RBF rules
>>>>>>>>>>
>>>>>>>>>> **V3 transactions:**
>>>>>>>>>>
>>>>>>>>>> Existing standardness rules apply to V3 (e.g. min/max tx weight,
>>>>>>>>>> standard output types, cleanstack, etc.). The following additional
>>>>>>>>>> rules apply to V3:
>>>>>>>>>>
>>>>>>>>>> 1. A V3 transaction can be replaced, even if it does not signal
>>>>>>>>>> BIP125
>>>>>>>>>> replaceability. (It must also meet the other RBF rules around
>>>>>>>>>> fees,
>>>>>>>>>> etc. for replacement to happen).
>>>>>>>>>>
>>>>>>>>>> 2. Any descendant of an unconfirmed V3 transaction must also be
>>>>>>>>>> V3.
>>>>>>>>>>
>>>>>>>>>> *Rationale*: Combined with Rule 1, this gives us the property of
>>>>>>>>>> "inherited" replaceability signaling when descendants of
>>>>>>>>>> unconfirmed
>>>>>>>>>> transactions are created. Additionally, checking whether a
>>>>>>>>>> transaction
>>>>>>>>>> signals replaceability this way does not require mempool
>>>>>>>>>> traversal,
>>>>>>>>>> and does not change based on what transactions are mined. It also
>>>>>>>>>> makes subsequent rules about descendant limits much easier to
>>>>>>>>>> check.
>>>>>>>>>>
>>>>>>>>>> *Note*: The descendant of a *confirmed* V3 transaction does not
>>>>>>>>>> need to be V3.
>>>>>>>>>>
>>>>>>>>>> 3. An unconfirmed V3 transaction cannot have more than 1
>>>>>>>>>> descendant.
>>>>>>>>>>
>>>>>>>>>> *Rationale*: (Upper bound) the larger the descendant limit, the
>>>>>>>>>> more
>>>>>>>>>> transactions may need to be replaced. This is a problematic
>>>>>>>>>> pinning
>>>>>>>>>> attack, i.e., a malicious counterparty prevents the transaction
>>>>>>>>>> from
>>>>>>>>>> being replaced by adding many descendant transactions that aren't
>>>>>>>>>> fee-bumping.
>>>>>>>>>>
>>>>>>>>>> (Lower bound) at least 1 descendant is required to allow CPFP of
>>>>>>>>>> the
>>>>>>>>>> presigned transaction. The contract protocol can create presigned
>>>>>>>>>> transactions paying 0 fees and 1 output for attaching a CPFP at
>>>>>>>>>> broadcast time ("anchor output"). Without package RBF, multiple
>>>>>>>>>> anchor
>>>>>>>>>> outputs would be required to allow each counterparty to fee-bump
>>>>>>>>>> any
>>>>>>>>>> presigned transaction. With package RBF, since the presigned
>>>>>>>>>> transactions can replace each other, 1 anchor output is
>>>>>>>>>> sufficient.
>>>>>>>>>>
>>>>>>>>>> 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be
>>>>>>>>>> larger than 1000 virtual bytes.
>>>>>>>>>>
>>>>>>>>>> *Rationale*: (Upper bound) the larger the descendant size limit,
>>>>>>>>>> the
>>>>>>>>>> more vbytes may need to be replaced. With default limits, if the
>>>>>>>>>> child
>>>>>>>>>> is e.g. 100,000vB, that might be an additional 100,000sats (at
>>>>>>>>>> 1sat/vbyte) or more, depending on the feerate.
>>>>>>>>>>
>>>>>>>>>> (Lower bound) the smaller this limit, the fewer UTXOs a child may
>>>>>>>>>> use
>>>>>>>>>> to fund this fee-bump. For example, only allowing the V3 child to
>>>>>>>>>> have
>>>>>>>>>> 2 inputs would require L2 protocols to manage a wallet with
>>>>>>>>>> high-value
>>>>>>>>>> UTXOs and make batched fee-bumping impossible. However, as the
>>>>>>>>>> fee-bumping child only needs to fund fees (as opposed to
>>>>>>>>>> payments),
>>>>>>>>>> just a few UTXOs should suffice.
>>>>>>>>>>
>>>>>>>>>> With a limit of 1000 virtual bytes, depending on the output
>>>>>>>>>> types, the
>>>>>>>>>> child can have 6-15 UTXOs, which should be enough to fund a
>>>>>>>>>> fee-bump
>>>>>>>>>> without requiring a carefully-managed UTXO pool. With 1000 virtual
>>>>>>>>>> bytes as the descendant limit, the cost to replace a V3
>>>>>>>>>> transaction
>>>>>>>>>> has much lower variance.
>>>>>>>>>>
>>>>>>>>>> *Rationale*: This makes the rule very easily "tacked on" to
>>>>>>>>>> existing
>>>>>>>>>> logic for policy and wallets. A transaction may be up to 100KvB
>>>>>>>>>> on its
>>>>>>>>>> own (`MAX_STANDARD_TX_WEIGHT`) and 101KvB with descendants
>>>>>>>>>> (`DEFAULT_DESCENDANT_SIZE_LIMIT_KVB`). If an existing V3
>>>>>>>>>> transaction
>>>>>>>>>> in the mempool is 100KvB, its descendant can only be 1000vB, even
>>>>>>>>>> if
>>>>>>>>>> the policy is 10KvB.
>>>>>>>>>>
>>>>>>>>>> **Package RBF modifications:**
>>>>>>>>>>
>>>>>>>>>> 1. The rule around unconfirmed inputs was
>>>>>>>>>> originally "A package may include new unconfirmed inputs, but the
>>>>>>>>>> ancestor feerate of the child must be at least as high as the
>>>>>>>>>> ancestor
>>>>>>>>>> feerates of every transaction being replaced."
>>>>>>>>>>
>>>>>>>>>> The package may still include new unconfirmed inputs. However,
>>>>>>>>>> the new rule is modified to be "The minimum between package
>>>>>>>>>> feerate
>>>>>>>>>> and ancestor feerate of the child is not lower than the individual
>>>>>>>>>> feerates of all directly conflicting transactions and the ancestor
>>>>>>>>>> feerates of all original transactions."
>>>>>>>>>>
>>>>>>>>>> *Rationale*: We are attempting to ensure that the replacement
>>>>>>>>>> transactions are not less incentive-compatible to mine. However, a
>>>>>>>>>> package/transaction's ancestor feerate is not perfectly
>>>>>>>>>> representative
>>>>>>>>>> of its incentive compatibility; it may overestimate (some subset
>>>>>>>>>> of
>>>>>>>>>> the ancestors could be included by itself if it has other
>>>>>>>>>> high-feerate
>>>>>>>>>> descendants or are themselves higher feerate than this
>>>>>>>>>> package/transaction). Instead, we use the minimum between the
>>>>>>>>>> package
>>>>>>>>>> feerate and ancestor feerate of the child as a more conservative
>>>>>>>>>> value
>>>>>>>>>> than what was proposed originally.
>>>>>>>>>>
>>>>>>>>>> 2. A new rule is added, requiring that all package transactions
>>>>>>>>>> with
>>>>>>>>>> mempool conflicts to be V3. This also means the "sponsoring"
>>>>>>>>>> child transaction must be V3.
>>>>>>>>>>
>>>>>>>>>> *Note*: Combined with the V3 rules, this means the package must be
>>>>>>>>>> a child-with-parents package. Since package validation is only
>>>>>>>>>> attempted if the transactions do not pay sufficient fees to be
>>>>>>>>>> accepted on their own, this effectively means that only V3
>>>>>>>>>> transactions can pay to replace their ancestors' conflicts, and
>>>>>>>>>> only
>>>>>>>>>> V3 transactions' replacements may be paid for by a descendant.
>>>>>>>>>>
>>>>>>>>>> *Rationale*: The fee-related rules are economically rational for
>>>>>>>>>> ancestor packages, but not necessarily other types of packages.
>>>>>>>>>> A child-with-parents package is a type of ancestor package. It
>>>>>>>>>> may be fine to allow any ancestor package, but it's more difficult
>>>>>>>>>> to account for all of the possibilities. For example, it gets much
>>>>>>>>>> harder to see that we're applying the descendant limits correctly
>>>>>>>>>> if
>>>>>>>>>> the package has a gnarly, many-generation, non-tree shape. I'm
>>>>>>>>>> also
>>>>>>>>>> not sure if this policy is 100% incentive-compatible if the
>>>>>>>>>> sponsor
>>>>>>>>>> is not a direct descendant of the sponsee.
>>>>>>>>>>
>>>>>>>>>> Please see doc/policy/version3_transactions.md and
>>>>>>>>>> doc/policy/packages.md in the PR for the full set of rules.
>>>>>>>>>>
>>>>>>>>>> **Intended usage for LN:**
>>>>>>>>>>
>>>>>>>>>> Commitment transactions should be V3 and have 1 anchor output.
>>>>>>>>>> They
>>>>>>>>>> can be signed with 0 fees (or 1sat/vbyte) once package relay is
>>>>>>>>>> deployed
>>>>>>>>>> on a significant portion of the network. If the commitment tx must
>>>>>>>>>> be broadcast, determine the desired feerate at broadcast time and
>>>>>>>>>> spend the anchor output in a high feerate transaction. I'm going
>>>>>>>>>> to
>>>>>>>>>> call the broadcasted commitment tx "the parent" and the attached
>>>>>>>>>> fee-bumping tx "the child."
>>>>>>>>>>
>>>>>>>>>> - This child must be V3.
>>>>>>>>>> - This child must be at most 1000vB. Note this restricts the
>>>>>>>>>> number of inputs you can use to fund the fee bump. Depending
>>>>>>>>>> on the output types, this is around 6-15.
>>>>>>>>>> - One child may fund fees for multiple commitment tx ("batched
>>>>>>>>>> fee-bumping").
>>>>>>>>>> - To do a second fee-bump to add more fees, replace the
>>>>>>>>>> *child* with a higher-feerate tx. Do not try to attach a
>>>>>>>>>> grandchild.
>>>>>>>>>>
>>>>>>>>>> Otherwise, never try to spend from an unconfirmed V3 transaction.
>>>>>>>>>> The
>>>>>>>>>> descendant limits for V3 transactions are very restrictive.
>>>>>>>>>>
>>>>>>>>>> **Expected Questions:**
>>>>>>>>>>
>>>>>>>>>> "Does this fix Rule 3 Pinning?"
>>>>>>>>>> Yes. The V3 descendant limit restricts both you and your
>>>>>>>>>> counterparty.
>>>>>>>>>> Assuming nodes adopted this policy, you may reasonably assume
>>>>>>>>>> that you
>>>>>>>>>> only need to replace the commitment transaction + up to 1000vB.
>>>>>>>>>>
>>>>>>>>>> "Only 1 anchor output? What if I need to bump counterparty's
>>>>>>>>>> commitment tx in mempool?"
>>>>>>>>>> You won't need to fee-bump a counterparty's commitment tx using
>>>>>>>>>> CPFP.
>>>>>>>>>> You would just package RBF it by attaching a high-feerate child to
>>>>>>>>>> your commitment tx.
>>>>>>>>>>
>>>>>>>>>> "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN
>>>>>>>>>> transactions based on nVersion?"
>>>>>>>>>> Indeed it may be unrealistic to assume V3 transactions will be in
>>>>>>>>>> widespread use outside of L2. IIUC, unilateral closes are already
>>>>>>>>>> obvious LN transactions because of the HTLC inputs. For e.g.
>>>>>>>>>> cooperative closes and opens, I think it makes sense to continue
>>>>>>>>>> using
>>>>>>>>>> V2. So, unless I'm missing something, this shouldn't make it
>>>>>>>>>> worse.
>>>>>>>>>>
>>>>>>>>>> "So a V3 transaction that doesn't signal BIP125 replaceability is
>>>>>>>>>> replaceable? Is that a backward compatibility issue?"
>>>>>>>>>> Yes it's replaceable. It's not an issue AFAICT because,
>>>>>>>>>> under previous policy, the V3 transaction wouldn't have been
>>>>>>>>>> in the mempool in the first place.
>>>>>>>>>>
>>>>>>>>>> "Can a V2 transaction replace a V3 transaction and vice versa?"
>>>>>>>>>> Yes, otherwise someone can use V3 transactions to censor V2
>>>>>>>>>> transactions spending shared inputs. Note if the
>>>>>>>>>> original V3 transaction has an unconfirmed V3 parent, this would
>>>>>>>>>> violate the "inherited V3" rule and would be rejected.
>>>>>>>>>>
>>>>>>>>>> Thanks for reading! Feedback and review would be much appreciated.
>>>>>>>>>>
>>>>>>>>>> [1]:
>>>>>>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019464.html
>>>>>>>>>> [2]:
>>>>>>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>> Gloria
>>>>>>>>>> _______________________________________________
>>>>>>>>>> bitcoin-dev mailing list
>>>>>>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> bitcoin-dev mailing list
>>>>>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> bitcoin-dev mailing list
>>>>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221001/353840a2/attachment-0001.html>

📅 Original date posted:2020-05-30
📝 Original message:Hey Chris,
Excellent write-up. I learned a few new things while reading this
(particularly how to overcome the heuristics for address reuse and address
types), so thank you for that.
I have a few thoughts about how what you wrote relates to Succinct Atomic
Swaps (SAS)[0]. Perhaps it's useful.
>For a much greater anonymity set we can use 2-party ECDSA to create 2-of-2
multisignature addresses that look the same as regular single-signature
addresses
This may perhaps be counter-intuitive, but SAS doesn't actually require
multisig for one of the two outputs, so a single key will suffice. ECDSA is
a signing algorithm that doesn't support single key multisig (at least not
without 2p-ECDSA), but notice how for the non-timelocked SAS output we
never actually have to sign anything together with the other party. We swap
one of the two keys, and the final owner will create a signature completely
on their own. No multisig required, which means we can simply use MuSig,
even today without Schnorr.
Of course the other output will still have to be a 2-of-2, for which you
rightly note 2p-ECDSA could be considered. It may also be interesting to
combine a swap with the opening of a Lightning channel. E.g. Alice and Bob
want to open a channel with 1 BTC each, but Alice funds it in her entirety
with 2 BTC, and Bob gives 1 BTC to Alice in a swap. This makes it difficult
to tell Bob entered the Lightning Network, especially if the channel is
opened in a state that isn't perfectly balanced. And Alice will gain an
uncorrelated single key output.
As a side note, we could use the same MuSig observation on 2-of-2 outputs
that need multisig by turning the script into (A & B) OR MuSig(A,B), which
would shave off quite a few bytes by allowing single sig spending once the
private key is handed over, but this would also make the output stick out
like a sore thumb... Only useful if privacy is not a concern.
>=== Multi-transaction CoinSwaps to avoid amount correlation ===
This can apply cleanly to SAS, and can even be done without passing on any
extra secrets by generating a sharedSecret (Diffie-Hellman key exchange).
Non-timelocked:
CoinSwap AddressB = aliceSecret + bobSecret
CoinSwap AddressC = aliceSecret + bobSecret + hash(sharedSecret,0)*G
CoinSwap AddressD = aliceSecret + bobSecret + hash(sharedSecret,1)*G
The above is MuSig compatible (single key outputs), there are no timelocks
to worry about, and the addresses cannot be linked on-chain.
>they would still need to watch the chain and respond in case a
hash-time-locked contract transaction is broadcasted
Small detail, but it should be noted that this would require the atomic
swap to be set up in a specific way with relative timelocks.
>=== PayJoin with CoinSwap ===
While it's probably clear how to do it on the timelocked side of SAS, I
believe PayJoin can also be applied to the non-timelocked side. This does
require adding a transaction that undoes the PayJoin in case the swap gets
aborted, which means MuSig can't be used. Everything else stays the same:
only one tx if successful, and no timelock (= instant settlement). I can
explain it in detail, if it happens to catch your interest.
Cheers,
Ruben
[0] Succinct Atomic Swaps (SAS)
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017846.html
On Mon, May 25, 2020 at 3:21 PM Chris Belcher via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> === Abstract ===
>
> Imagine a future where a user Alice has bitcoins and wants to send them
> with maximal privacy, so she creates a special kind of transaction. For
> anyone looking at the blockchain her transaction appears completely
> normal with her coins seemingly going from address A to address B. But
> in reality her coins end up in address Z which is entirely unconnected
> to either A or B.
>
> Now imagine another user, Carol, who isn't too bothered by privacy and
> sends her bitcoin using a regular wallet which exists today. But because
> Carol's transaction looks exactly the same as Alice's, anybody analyzing
> the blockchain must now deal with the possibility that Carol's
> transaction actually sent her coins to a totally unconnected address. So
> Carol's privacy is improved even though she didn't change her behaviour,
> and perhaps had never even heard of this software.
>
> In a world where advertisers, social media and other companies want to
> collect all of Alice's and Carol's data, such privacy improvement would
> be incredibly valuable. And also the doubt added to every transaction
> would greatly boost the fungibility of bitcoin and so make it a better
> form of money.
>
> This undetectable privacy can be developed today by implementing
> CoinSwap, although by itself that isn't enough. There must be many
> building blocks which together make a good system. The software could be
> standalone as a kind of bitcoin mixing app, but it could also be a
> library that existing wallets can implement allowing their users to send
> Bitcoin transactions with much greater privacy.
>
> == CoinSwap ==
>
> Like CoinJoin, CoinSwap was invented in 2013 by Greg Maxwell[1]. Unlike
> CoinJoin it is relatively complicated to implement and so far has not
> been deployed. But the idea holds great promise, and fixes many of the
> problems of some kinds of CoinJoins. CoinSwap is the next step for
> on-chain bitcoin privacy.
>
> CoinSwap is a way of trading one coin for another coin in a
> non-custodial way. It is closely related to the idea of an atomic swap.
> Alice and Bob can trade coins with each other by first sending to a
> CoinSwap address and having those coins then sent to Bob:
>
> Alice's Address 1 ----> CoinSwap Address 1 ----> Bob's Address 1
>
> An entirely separate set of transactions gives Bob's coins to Alice in
> return:
>
> Bob's Address 2 ----> CoinSwap Address 2 ----> Alice's Address 2
>
> Where the symbol ----> is a bitcoin transaction.
>
> Privacy is improved because an observer of the blockchain cannot link
> Alice's Address 1 to Alice's Address 2, as there is no transaction
> between them. Alice's Address 2 could either be an address in Alice's
> wallet, or the address of someone else she wants to transfer money to.
> CoinSwap therefore breaks the transaction graph heuristic, which is the
> assumption that if a transaction A -> B is seen then the ownership of
> funds actually went from A to B.
>
> CoinSwap doesnt break any of bitcoin's assumptions or features like an
> auditable supply or pruning. It can be built on today's bitcoin without
> any new soft forks.
>
> CoinSwap can't improve privacy much on its own, so it requires other
> building block to create a truly private system.
>
> === ECDSA-2P ===
>
> The original CoinSwap idea uses 2-of-2 multisig. We can get a slightly
> bigger anonymity set by using 2-of-3 multisigs with a fake third public
> key. For a much greater anonymity set we can use 2-party ECDSA to create
> 2-of-2 multisignature addresses that look the same as regular
> single-signature addresses[2]. Even the old-style p2pkh addresses
> starting with 1 can be CoinSwap addresses.
>
> Because the transactions blend in with the rest of bitcoin, an
> application based on CoinSwap would provide much more privacy than the
> existing equal-output coinjoin apps (JoinMarket, Wasabi Wallet and
> Samourai Wallet's Whirlpool). CoinSwaps would also be cheaper for the
> same amount of privacy, as CoinJoin users usually create multiple
> CoinJoins to get effective privacy, for example JoinMarket's tumbler
> script does between 7-12 coinjoins (which are bigger than regular
> transactions too) when run with default parameters.
>
> Schnorr signatures with Musig provide a much easier way to create
> invisible 2-of-2 multisig, but it is not as suitable for CoinSwap. This
> is because the anonymity set for ECDSA would be much greater. All
> addresses today are ECDSA, and none are schnorr. We'd have to wait for
> schnorr to be added to bitcoin and then wait for users to adopt it. We
> see with segwit that even after nearly 3 years that segwit adoption is
> only about 60%, and segwit actually has a sizeable financial incentive
> for adoption via lower fees. Schnorr when used for single-sig doesn't
> have such an incentive, as Schnorr single-sig costs the same size as
> today's p2wpkh, so we can expect adoption to be even slower. (Of course
> there is an incentive for multisig transactions, but most transactions
> are single-sig). As schnorr adoption increases this CoinSwap system
> could start to use it, but for a long time I suspect it will mostly be
> using ECDSA for a greater anonymity set.
>
> === Liquidity market ===
>
> We can create a liquidity market for CoinSwap very similar to how
> JoinMarket works for CoinJoins. In our example above Alice would be a
> market taker and Bob would be a market maker. The taker Alice pays a fee
> to the maker Bob in return for choosing the amount of a CoinSwap and
> when it happens. This allows an excellent user experience because Alice
> can create CoinSwaps for any size she wants, at any time she wants.
> Right now in JoinMarket there is liquidity to create CoinJoins of sizes
> up to about 200 BTC, and we can expect a similar kind of thing with
> CoinSwap.
>
>
> === Multi-transaction CoinSwaps to avoid amount correlation ===
>
> This CoinSwap is vulnerable to amount correlation:
>
> AliceA (15 BTC) ----> CoinSwap AddressA ----> BobA (15 BTC)
> BobB (15 BTC) ----> CoinSwap AddressB ----> AliceB (15 BTC)
>
> Where AliceA, AliceB are addresses belonging to Alice. BobA, BobB are
> addresses belonging to Bob. If an adversary starts tracking at address
> AliceA they could unmix this CoinSwap easily by searching the entire
> blockchain for other transactions with amounts close to 15 BTC, which
> would lead them to address AliceB. We can beat this amount correlation
> attack by creating multi-transaction CoinSwaps. For example:
>
> AliceA (15 BTC) ----> CoinSwap AddressA ----> BobA (15 BTC)
>
> BobB (7 BTC) ----> CoinSwap AddressB ----> AliceB (7 BTC)
> BobC (5 BTC) ----> CoinSwap AddressC ----> AliceC (5 BTC)
> BobD (3 BTC) ----> CoinSwap AddressD ----> AliceD (3 BTC)
>
> Now in the multi-transaction CoinSwap, the market taker Alice has given
> 10 BTC and got back three transactions which add up to the same amount,
> but nowhere on the blockchain is there an output where Alice received
> exactly 15 BTC.
>
> === Routing CoinSwaps to avoid a single points of trust ===
>
> In the original CoinSwap idea there are only two parties Alice and Bob,
> so when they CoinSwap Bob will know exactly where the Alice's coins
> went. This means Bob is a single point of failure in Alice's privacy,
> and Alice must trust him not to spy on her.
>
> To spread out and decentralize the trust, we can create CoinSwaps where
> Alice's payment is routed through many Bobs.
>
> AliceA ====> Bob ====> Charlie ====> Dennis ====> AliceB
>
> Where the symbol ====> means one CoinSwap. In this situation Alice will
> be a market taker in the liquidity market, and all the other entities
> (Bob, Charlie, Dennis) will be market makers. Only Alice will know the
> entire route, and the makers will only know the previous and next
> bitcoin addresses along the route.
>
> This could be made to work by Alice handling almost everything about the
> CoinSwap on the other maker's behalf. The makers wouldn't have TCP
> connections between each other, but only to Alice, and she would relay
> CoinSwap-relevant information between them. The other makers are not
> aware whether their incoming coins came from Alice herself or the
> previous maker in Alice's route.
>
>
> === Combining multi-transaction with routing ===
>
> Routing and multi-transaction must be combined to get both benefits. If
> Alice owns multiple UTXOs (of value 6 BTC, 8 BTC and 1 BTC) then this is
> easy with this configuration:
>
> Alice
> (6 BTC) (8 BTC) (1 BTC)
> | | |
> | | |
> v v v
> Bob
> (5 BTC) (5 BTC) (5 BTC)
> | | |
> | | |
> v v v
> Charlie
> (9 BTC) (5 BTC) (1 BTC)
> | | |
> | | |
> v v v
> Dennis
> (7 BTC) (4 BTC) (4 BTC)
> | | |
> | | |
> v v v
> Alice
>
> Where the downward arrow symbol is a single CoinSwap hash-time-locked
> contract. Each hop uses multiple transactions so no maker (Bob, Charlie,
> Dennis) is able to use amount correlation to find addresses not directly
> related to them, but at each hop the total value adds up to the same
> amount 15 BTC. And all 3 makers must collude in order to track the
> source and destination of the bitcoins.
>
> If Alice starts with only a single UTXO then the above configuration is
> still vulnerable to amount correlation. One of the later makers (e.g.
> Dennis) knows that the total coinswap amount is 15 BTC, and could search
> the blockchain to find Alice's single UTXO. In such a situation Alice
> must use a branching configuration:
>
> Alice
> (15 BTC)
> |
> |
> v
> Bob
> / \
> / \
> <----------- ----------->
> | |
> (2 BTC) (2 BTC) (2 BTC) (3 BTC) (3 BTC) (3 BTC)
> | |
> | |
> v v
> Charlie Dennis
> (1 BTC) (2 BTC) (3 BTC) (5 BTC) (3 BTC) (1 BTC)
> | | | | | |
> | | | | | |
> v v v v v v
> Edward Fred
> (4 BTC) (1 BTC) (1 BTC) (4 BTC) (2 BTC) (1 BTC)
> | | | | | |
> | | | | | |
> v v v v v v
> Alice Alice
>
> In this diagram, Alice sends 15 BTC to Bob via CoinSwap who sends 6 BTC
> on to Charlie and the remaining 9 BTC to Dennis. Charlie and Dennis do a
> CoinSwap with Edward and Fred who forward the coins to Alice. None of
> the makers except Bob know the full 15 BTC amount and so can't search
> the blockchain backwards for Alice's initial UTXO. Because of multiple
> transactions Bob cannot look forward to search for the amounts he sent 6
> BTC and 9 BTC. A minimum of 3 makers in this example need to collude to
> know the source and destination of the coins.
>
> Another configuration is branch merging, which Alice would find useful
> if she has two or more UTXOs for which there must not be evidence that
> they're owned by the same entity, and so they must not be spent together
> in the same transaction.
>
> Alice Alice
> (9 BTC) (6 BTC)
> | |
> | |
> v v
> Bob Charlie
> (4 BTC) (3 BTC) (2 BTC) (1 BTC) (2 BTC) (3 BTC)
> | | | | | |
> | | | | | |
> \ \ \ / / /
> \ \ \ / / /
> \ \ \ / / /
> >------->-------\ /-------<-------<
> \ /
> Alice
> (15 BTC)
>
> In this diagram Alice sends the two UTXOs (9 BTC and 6 BTC) to two
> different makers, who forward it onto Alice. Because the two UTXOs have
> been transferred to different makers they will likely never be co-spent.
>
> These complex multi-transaction routed coinswaps are only for the
> highest threat models where the makers themselves are adversaries. In
> practice most users would probably choose to use just one or two hops.
>
>
> === Breaking change output and wallet fingerprinting heuristics ===
>
> Equal-output CoinJoins easily leak change addresses (unless they are
> sweeps with no change). CoinSwap doesn't have this flaw which allows us
> to break some of the weaker change output heuristics[3].
>
> For example address reuse. If an output address has been reused it is
> very likely to be a payment output, not a change output. In a CoinSwap
> application we can break this heuristic by having makers randomly with
> some probability send their change to an address they've used before.
> That will make the heuristics think that the real change address is
> actually the payment address, and the real payment is actually the
> change, and could result in an analyzer of the blockchain grouping the
> payment address inside the maker's own wallet cluster.
>
> Another great heuristic to break is the script type heuristic. If the
> maker's input are all in p2sh-p2wpkh addresses, and their payment
> address is also of type p2sh-p2wpkh, then the maker could with some
> probability set the change address to a different type such as p2wpkh.
> This could trick a chain analyzer in a similar way.
>
> === Fidelity bonds ===
>
> Anybody can enter the CoinSwap market as a maker, so there is a danger
> of sybil attacks. This is when an adversary deploys huge numbers of
> maker bots. If the taker Alice chooses maker bots which are all
> controlled by the same person then that person can deanonymize Alice's
> transaction by tracking the coins along the route.
>
> A solution to this is fidelity bonds. This is a mechanism where bitcoin
> value is deliberately sacrificed to make a cryptographic identity
> expensive to obtain. The sacrifice is done in a way that can be proven
> to a third party. One way to create a fidelity bond is to lock up
> bitcoins in a time-locked address. We can code the taker bots to behave
> in a way that creates market pressure for maker bot operators to publish
> fidelity bonds. These fidelity bonds can be created anonymously by
> anyone who owns bitcoin.
>
> Fidelity bonds are a genuine sacrifice which can't be faked, they can be
> compared to proof-of-work which backs bitcoin mining. Then for a sybil
> attacker to be successful they would have to lock up a huge value in
> bitcoin for a long time. I've previously analyzed fidelity bonds for
> JoinMarket[4], and using realistic numbers I calculate that such a
> system would require about 55000 BTC (around 500 million USD at today's
> price) to be locked up for 6 months in time-locked addresses. This is a
> huge amount and provides strong sybil resistance.
>
> ==== Who goes first ====
>
> Fidelity bonds also solve the "who goes first" problem in CoinSwap.
>
> This problem happens because either Alice or Bob must broadcast their
> funding transaction first, but if the other side halts the protocol then
> they can cause Alice or Bob's to waste time and miner fees as they're
> forced to use the contract transactions to get their money back. This is
> a DOS attack. If a malicious CoinSwapper could keep halting the protocol
> they could stop an honest user from doing a CoinSwap indefinitely.
> Fidelity bonds solve this by having the fidelity bond holder go second.
> If the fidelity bond holder halts the protocol then their fidelity bond
> can be avoid by the user in all later CoinSwaps. And the malicious
> CoinSwapper could pack the orderbook with their sybils without
> sacrificing a lot of value for fidelity bonds.
>
> As a concrete example, Alice is a taker and Bob is a maker. Bob
> publishes a fidelity bond. Alice "goes first" by sending her coins into
> a 2-of-2 multisig between her and Bob. When Bob sees the transaction is
> confirmed he broadcasts his own transactions into another 2-of-2
> multisig. If Bob is actually malicious and halts the protocol then he
> will cost Alice some time and money, but Alice will refuse to ever
> CoinSwap with Bob's fidelity bond again.
>
> If DOS becomes a big problem even with fidelity bonds, then its possible
> to have Alice request a "DOS proof" from Bob before broadcasting, which
> is a set of data containing transactions, merkle proofs and signatures
> which are a contract where Bob promises to broadcast his own transaction
> if Alice does so first. If Alice gets DOSed then she can share this DOS
> proof publicly. The proof will have enough information to convince
> anyone else that the DOS really happened, and it means that nobody else
> will ever CoinSwap with Bob's fidelity bond either (or at least assign
> some kind of ban score to lower the probability). I doubt it will come
> to this so I haven't expanded the idea much, but theres a longer writeup
> in the reference[5].
>
> === Private key handover ===
>
> The original proposal for CoinSwap involved four transactions. Two to
> pay into the multisig addresses and two to pay out. We can do better
> than this with private key handover[6]. This is an observation that once
> the CoinSwap preimage is revealed, Alice and Bob don't have to sign each
> other's multisig spend, instead they could hand over their private key
> to the other party. The other party will know both keys of the 2-of-2
> multisig and therefore have unilateral control of the coins. Although
> they would still need to watch the chain and respond in case a
> hash-time-locked contract transaction is broadcasted.
>
> As well as saving block space, it also improves privacy because the
> coins could stay unspent for a long time, potentially indefinitely.
> While in the original coinswap proposal an analyst of the chain would
> always see a funding transaction followed closely in time by a
> settlement transaction, and this could be used as a fingerprint.
>
> We can go even further than private key handover using a scheme called
> SAS: Succinct Atomic Swap[7]. This scheme uses adapter signatures[8] to
> create a similar outcome to CoinSwap-with-private-key-handover, but only
> one party in the CoinSwap must watch and respond to blockchain events
> until they spend the coin. The other party just gets unilateral control
> of their coins without needing to watch and respond.
>
>
> === PayJoin with CoinSwap ===
>
> CoinSwap can be combined with CoinJoin. In original CoinSwap, Alice
> might pay into a CoinSwap address with a regular transaction spending
> multiple of her own inputs:
>
> AliceInputA (1 BTC) ----> CoinSwap Address (3 BTC)
> AliceInputB (2 BTC)
>
> This leaks information that all of those inputs are owned by the same
> person. We can make this example transaction a CoinJoin by involving
> Bob's inputs too. CoinJoin requires interaction but because Alice and
> Bob are already interacting to follow the CoinSwap protocol, so it's not
> too hard to have them interact a bit more to do a CoinJoin too. The
> CoinJoin transaction which funds the CoinSwap address would look like this:
>
> AliceInputA (1 BTC) ----> CoinSwap Address (7 BTC)
> AliceInputB (2 BTC)
> BobInputA (4 BTC)
>
> Alice's and Bob's inputs are both spent in a same transaction, which
> breaks the common-input-ownership heuristic. This form of CoinJoin is
> most similar to the PayJoin protocol or CoinJoinXT protocol. As with the
> rest of this design, this protocol does not have any special patterns
> and so is indistinguishable from any regular bitcoin transaction.
>
> To make this work Bob the maker needs to provide two unrelated UTXOs,
> one that is CoinSwapped and the other CoinJoined.
>
> ==== Using decoy UTXOs to protecting from leaks ====
>
> If Bob the maker was just handing out inputs for CoinJoins to any Alice
> who asked, then malicious Alice's could constantly poll Bob to learn his
> UTXO and then halt the protocol. Malicious Alice could learn all of
> Bob's UTXOs and easily unmix future CoinSwaps by watching their future
> spends.
>
> To defend against this attack we have Bob maintain a list of "decoy
> UTXOs", which are UTXOs that Bob found by scanning recent blocks. Then
> when creating the CoinJoin, Bob doesn't just send his own input but
> sends perhaps 50 or 100 other inputs which don't belong to him. For the
> protocol to continue Alice must partially-sign many CoinJoin
> transactions; one for each of those inputs, and send them back to Bob.
> Then Bob can sign the transaction which contains his genuine input and
> broadcast it. If Alice is actually a malicious spy she won't learn Bob's
> input for sure but will only know 100 other inputs, the majority of
> which have nothing to do with Bob. By the time malicious Alice learns
> Bob's true UTXO its already too late because its been spent and Alice is
> locked into the CoinSwap protocol, requiring time, miner fees and
> CoinSwap fees to get out.
>
> This method of decoy UTXOs has already been written about in the
> original PayJoin designs from 2018[9][10].
>
> === Creating a communication network using federated message boards ===
>
> Right now JoinMarket uses public IRC networks for communication. This is
> subpar for a number of reasons, and we can do better.
>
> I propose that there be a small number of volunteer-operated HTTP
> servers run on Tor hidden services. Their URLs are included in the
> CoinSwap software by default. They can be called message board servers.
> Makers are also servers run on hidden services, and to advertise
> themselves they connect to these message board servers to post the
> makers own .onion address. To protect from spam, makers must provide a
> fidelity bond before being allowed to write to the HTTP server.
>
> Takers connect to all these HTTP message boards and download the list of
> all known maker .onion addresses. They connect to each maker's onion to
> obtain parameters like offered coinswap fee and maximum coinswap size.
> This is equivalent to downloading the orderbook on JoinMarket. Once
> takers have chosen which makers they'll do a CoinSwap with, they
> communicate with those maker again directly through their .onion address
> to transmit the data needed to create CoinSwaps.
>
> These HTTP message board servers can be run quite cheaply, which is
> required as they'd be volunteer run. They shouldn't require much
> bandwidth or disk space, as they are well-protected from spam with the
> fidelity bond requirement. The system can also tolerate temporary
> downtimes so the servers don't need to be too reliable either. It's easy
> to imagine the volunteers running them on a raspberry pi in their own
> home. These message board servers are similar in some ways to the DNS
> seeds used by Bitcoin Core to find its first peers on bitcoin's p2p
> network. If the volunteers ever lose interest or disappear, then the
> community of users could find new volunteer operators and add those URLs
> to the default list.
>
> In order to censor a maker, _all_ the message board servers would have
> to co-operate to censor him. If censorship is happening on a large scale
> (for example if the message board servers only display sybil makers run
> by themselves) then takers could also notice a drop in the total value
> of all fidelity bonds.
>
>
> == How are CoinSwap and Lightning Network different? ==
>
> CoinSwap and Lightning Network have many similarities, so it's natural
> to ask why are they different, and why do we need a CoinSwap system at
> all if we already have Lightning?
>
> === CoinSwap can be adopted unilaterally and is on-chain ===
>
> Today we see some centralized exchange not supporting so-called
> ``privacy altcoins'' because of regulatory compliance concerns. We also
> see some exchanges frowning upon or blocking CoinJoin transaction they
> detect[11]. (There is some debate over whether the exchanges really
> blocked transactions because they were CoinJoin, but the principle
> remains that equal-output CoinJoins are inherently visible as such).
> It's possible that those exchanges will never adopt Lightning because of
> its privacy features.
>
> Such a refusal would simply not be possible with CoinSwap, because it is
> fundamentally an on-chain technology. CoinSwap users pay to bitcoin
> addresses, not Lightning invoices. Anybody who accepts bitcoin today
> will accept CoinSwap. And because CoinSwap transactions can be made
> indistinguishable from regular transactions, it would be very difficult
> to even determine whether they got paid via a CoinSwap or not. So
> CoinSwap is not a replacement for Lightning, instead it is a replacement
> for on-chain privacy technology such as equal-output CoinJoins which are
> implemented today in JoinMarket, Wasabi Wallet and Samourai Wallet.
> Ideally this design, if implemented, would be possible to include into
> the many already-existing bitcoin wallets, and so the CoinSwaps would be
> accessible to everyone.
>
> This feature of CoinSwap will in turn help Lightning Network, because
> those censoring exchanges won't be able to stop transactions with
> undetectable privacy no matter what they do. When they realize this
> they'll likely just implement Lightning Network anyway regardless of the
> privacy.
>
> Bitcoin needs on-chain privacy as well, otherwise the bad privacy can
> leak into layer-2 solutions.
>
> === Different ways of solving liquidity ===
>
> Lightning Network cannot support large payment amounts. Liquidity in
> payment channels on the Lightning network is a scarce resource. Nodes
> which relay lightning payments always take care that a payment does not
> exhaust their liquidity. Users of Lightning today must often be aware of
> inbound liquidity, outbound liquidity and channel rebalancing. There
> even exist services today which sell Lightning liquidity.
>
> This CoinSwap design solves its liquidity problem in a completely
> different way. Because of the liquidity market similar to JoinMarket,
> all the required liquidity is always available. There are never any
> concerns about exhausting channel capacity or a route not being found,
> because such liquidity is simply purchased from the liquidity market
> right before it is used.
>
> It is still early days for Lightning, and liquidity has been a known
> issue since the start. Many people are confident that the liquidity
> issue will be improved. Yet it seems hard to imagine that Lightning
> Network will ever reliably route payments of 200 BTC to any node in the
> network (and it doesn't have to to be successful), yet on JoinMarket
> today as I write these words there are offers to create CoinJoins with
> amounts up to around 200 BTC. We can expect similar large amounts to be
> sendable in CoinSwap. The liquidity market as a solution is known to
> work and has been working for years.
>
> === Sybil resistance ===
>
> CoinSwap can support fidelity bonds and so can be made much more
> resistant to sybil attacks. We saw in the earlier section that realistic
> numbers from JoinMarket imply a sybil attacker would have to lock up
> hundreds of millions of USD worth of bitcoin to successfully deanonymize
> users.
>
> It's difficult to compare this to the cost of a sybil attack in
> Lightning network as such attacks are hard to analyze. For example, the
> attacker needs to convince users to route payments through the
> attacker's own nodes, and maybe they could do this, but putting numbers
> on it is hard. Even so it is very likely that the true cost is much less
> than 500 million USD locked up for months because Lightning nodes can be
> set up for not more than the cost of hardware and payment channel
> capacity, while CoinSwap makers would require expensive fidelity bond
> sacrifices.
>
> As this CoinSwap design would cost much more sybil attack, its privacy
> would be much greater in this respect.
>
>
> == How are CoinSwap, PayJoin and PaySwap different? ==
>
> PayJoin can also be indistinguishable from regular bitcoin transaction,
> so why don't we all just that and not go further?
>
> The answer is the threat models. PayJoin works by having the customer
> and merchant together co-operate to increase both their privacy. It
> works if the adversary of both of them is a passive observer of the
> blockchain.
>
> PayJoin doesnt help a customer at all if the user's adversary is the
> merchant. This situation happens all the time today, for example
> exchanges spying on their customers. CoinSwap can help in this
> situation, as it doesn't assume or require that the second party is your
> friend. The same argument applies to PaySwap.
>
> Obviously PayJoin and PaySwap are still very useful, but they operate
> under different threat models.
>
>
> == Conclusion ==
>
> CoinSwap is a promising privacy protocol because it breaks the
> transaction graph heuristic, but it cant work on its own. In order to
> create a truly private system of sending transactions which would
> improve bitcoin's fungibility, CoinSwap must be combined with a couple
> of other building blocks:
>
> * ECDSA-2P
> * Liquidity market
> * Routed CoinSwaps
> * Multi-transaction CoinSwaps
> * Breaking change output heuristics
> * Fidelity bonds
> * PayJoin with CoinSwap
> * Federated message boards protected from spam with fidelity bonds
>
> CoinSwap transactions could be made to look just like any other regular
> bitcoin transaction, with no distinguishing fingerprint. This would make
> them invisible.
>
> I intend to create this CoinSwap software. It will be almost completely
> decentralized and available for all to use for free. The design is
> published here for review. If you want to help support development I
> accept donations at https://bitcoinprivacy.me/coinswap-donations
>
>
> == References ==
>
> - [1] "CoinSwap: Transaction graph disjoint trustless trading"
> https://bitcointalk.org/index.php?topic=321228.0
>
> - [2]
>
> http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/scriptless-ecdsa/
>
> - [3] https://en.bitcoin.it/wiki/Privacy#Change_address_detection
>
> - [4] "Design for improving JoinMarket's resistance to sybil attacks
> using fidelity bonds"
> https://gist.github.com/chris-belcher/18ea0e6acdb885a2bfbdee43dcd6b5af/
>
> - [5] https://github.com/AdamISZ/CoinSwapCS/issues/50
>
> - [6] https://github.com/AdamISZ/CoinSwapCS/issues/53
>
> - [7]
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017846.html
>
> - [8]
>
> https://github.com/ElementsProject/scriptless-scripts/blob/master/md/atomic-swap.md
>
> - [9]
>
> https://blockstream.com/2018/08/08/en-improving-privacy-using-pay-to-endpoint/
>
> - [10] https://medium.com/@nopara73/pay-to-endpoint-56eb05d3cac6
>
> - [11]
>
> https://cointelegraph.com/news/binance-returns-frozen-btc-after-user-promises-not-to-use-coinjoin
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200530/da6f6938/attachment-0001.html>