Re: [bitcoin-dev] Spookchains: Drivechain Analog with One-Time Trusted Setup & APO

[Antoine Riard via bitcoin-dev]

Hi Jeremy,

Thanks for bringing back to awareness covenant-based drivechain designs
again!

I'm not super familiar with the thousands shades of sidechains, and
especially how the variants of pegging mechanisms influence the soundness
of the game-theory backing up the functionaries execution. However it could
be interesting to give security bounds to the defect of any trusted
component, such as the one-time trusted setup, and the impacts on funds. If
it's a full-blown loss, a timevalue loss, a privacy leak, etc...

Started at least an entry for the ZmnSCPxj design:
https://github.com/ariard/bitcoin-contracting-primitives-wg/pull/9

One interesting point from the OG post:
> The recursive covenant could, with the help of `OP_CAT` and
> `OP_CTV`, check that every transaction spending the UTXO has a
> second output that is an `OP_RETURN` with a commitment to the
> sidechain block.
> We can ensure that only one such transaction exists in each
> mainchain block by adding a `<1> OP_CSV`, ensuring that only one
> sidechain-commitment transaction can occur on each mainchain
> block.

Such recursive-covenant "embedded" sidechains could be used as solution to
the double-spend of payment pools and channel factories partitions, as an
instantiation of a "on-chain authoritative board" for partitions statement,
as described earlier this year, in a quest to solve the high interactivity
issue affecting those constructions [0].

Best,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020370.html

Le mer. 14 sept. 2022 à 14:32, Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> *also available here on my blog with nicer
> formatting: https://rubin.io/bitcoin/2022/09/14/drivechain-apo/
> *
>
> This post draws heavily from Zmnscpxj's fantastic post showing how to
> make drivechains with recursive covenants. In this post, I will show
> similar tricks that can accomplish something similar using ANYPREVOUT
> with a one time trusted setup ceremony.
>
> This post presents general techniques that could be applied to many
> different types of covenant.
>
> # Peano Counters
>
> The first component we need to build is a Peano counter graph. Instead
> of using sha-256, like in Zmnscpxj's scheme, we will use a key and
> build a simple 1 to 5 counter that has inc / dec.
>
> Assume a key K1...K5, and a point NUMS which is e.g.
> HashToCurve("Spookchains").
>
> Generate scripts as follows:
>
> ```
> <1 || K1> CHECKSIG
> ...
> <1 || K5> CHECKSIG
> ```
>
> Now generate 2 signatures under Ki with flags `SIGHASH_SINGLE |
> SIGHASH_ANYONECANPAY | SIGHASH_ANYPREVOUT`.
>
>
> ## Rule Increment
> For each Ki, when `i < 5`, create a signature that covers a
> transaction described as:
>
> ```
> Amount: 1 satoshi
> Key: Tr(NUMS, {<1 || K{i+1}> CHECKSIG})
> ```
>
> ## Rule Decrement
> For each Ki, when `i > 1` The second signature should cover:
> ```
> Amount: 1 satoshi
> Key: Tr(NUMS, {<1 || K{i-1}> CHECKSIG})
> ```
>
>
>
> _Are these really Peano?_ Sort of. While a traditional Peano numeral
> is defined as a structural type, e.g. `Succ(Succ(Zero))`, here we
> define them via a Inc / Dec transaction operator, and we have to
> explicitly bound these Peano numbers since we need a unique key per
> element. They're at least spiritually similar.
>
> ## Instantiation
> Publish a booklet of all the signatures for the Increment and
> Decrement rules.
>
> Honest parties should destroy the secret key sets `k`.
>
>
> To create a counter, simply spend to output C:
>
> ```
> Amount: 1 satoshi
> Key: Tr(NUMS, {<1 || K1> CHECKSIG})
> ```
>
>
> The signature from K1 can be bound to C to 'transition' it to (+1):
>
> ```
> Amount: 1 satoshi
> Key: Tr(NUMS, {<1 || K2> CHECKSIG})
> ```
>
> Which can then transition to (+1):
>
> ```
> Amount: 1 satoshi
> Key: Tr(NUMS, {<1 || K3> CHECKSIG})
> ```
>
> Which can then transition (-1) to:
>
> ```
> Amount: 1 satoshi
> Key: Tr(NUMS, {<1 || K2> CHECKSIG})
> ```
>
> This can repeat indefinitely.
>
>
> We can generalize this technique from `1...5` to `1...N`.
>
>
>
> # Handling Arbitrary Deposits / Withdrawals
>
>
> One issue with the design presented previously is that it does not
> handle arbitrary deposits well.
>
> One simple way to handle this is to instantiate the protocol for every
> amount you'd like to support.
>
> This is not particularly efficient and requires a lot of storage
> space.
>
> Alternatively, divide (using base 2 or another base) the deposit
> amount into a counter utxo per bit.
>
> For each bit, instead of creating outputs with 1 satoshi, create
> outputs with 2^i satoshis.
>
> Instead of using keys `K1...KN`, create keys `K^i_j`, where i
> represents the number of sats, and j represents the counter. Multiple
> keys are required per amount otherwise the signatures would be valid
> for burning funds.
>
> ## Splitting and Joining
>
> For each `K^i_j`, it may also be desirable to allow splitting or

Re: [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols

[Ruben Somsen via bitcoin-dev]

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@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 
> 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  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 

Re: [bitcoin-dev] Wallet policies for descriptor wallets

[Andrew Poelstra via bitcoin-dev]

I'm really happy to see this discussion. I don't have any comments on the spec
because I think I'd have to be more in-the-weeds trying to implement a hww to
understand how well it works for realistic use cases. But a strong concept-ACk
from me and thanks to Salvatore for exploring this!

On Mon, May 09, 2022 at 11:36:47AM +, darosior via bitcoin-dev wrote:
> 
> Unrelated question, since you mentioned `musig2` descriptors in this context. 
> I thought Musig2 wasn't really
> feasible for hardware signing devices, especially stateless ones. Do you 
> think/know whether it is actually
> possible for a HW to take part in a Musig2?
>

As Salvatore mentioned in his reply, there are a couple ways that hwws can deal
with musig2 -- specifically, having state (and I believe you can get away with
as little state as a single monotonic counter) or having a RNG which is reliable
enough that it at least won't repeat values.

Because these aren't blockers for all hwws, even if they are blockers for some,
I'd really like to see musig2 support in these protocols, or at least for musig2
to be considered in their design.
 

-- 
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

The sun is always shining in space
-Justin Lewis-Webster



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] Third version of Silent Payment implementation

[Ruben Somsen via bitcoin-dev]

Hi woltx,

Excellent work.

>Implements the new scheme suggested by Ruben Somsen that allows multiple
silent addresses per wallet with minimal overhead

To expand on this, the scheme basically allows the resulting address to be
recognizably marked (only recognizable by the recipient of course), which
enables you to distinguish between different payment purposes (e.g. some
people donate to you for purpose A, others for purpose B). Here's my
original comment describing it:

"Naively, the issue is that two keys means twice the scanning, but an
interesting alternative would be to simply use the same key (assuming
you're OK with using the same identity) but add a public identifier f to it
when tweaking. So instead of hash(i*X)*G + X you get hash(i*X)*G + X + f*G
. This means every additional "address" only costs one additional ECC
addition when scanning (relatively cheap compared to doing ECC
multiplications).

The main downside with this is that f becomes crucial for recovering from
backup. If we set f as an index (0, 1, 2, 3...) then you'd only have to
remember how many "addresses" you issued (and perhaps overshoot when
unsure) to ensure recovery of funds, though of course you'd rather also
remember which index is associated with what payment reason.

Absolute worst case scenario you could even do something similar to the gap
limit where you scan the full history (not just the UTXO set so you don't
miss spent outputs) with a default max index of e.g. 100, and then if you
find out most of them are in use, you scan the next 100, etc. Costly, but
thorough, and only needed as a last resort."

Original comment here:
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-sharing

Also good to note that f needs to be communicated to the sender somehow,
perhaps as part of the address format.

Cheers,
Ruben

On Fri, Sep 30, 2022 at 12:35 AM woltx via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> This new version addresses most (or all) requests made in PR:
>
> . Implements the new scheme suggested by Ruben Somsen that allows multiple
> silent addresses per wallet with minimal overhead.
> . Implements a new RPC to retrieve silent addresses, which allows users to
> assign different labels to different addresses. That way, the user knows
> which silent address the UTXO came from.
>
> Example:
>
> ./src/bitcoin-cli -signet -rpcwallet="receiver" getspaddress
> tsp001pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kqxn48tq
>
> # This will return the same address as above (both have no label)
> ./src/bitcoin-cli -signet -rpcwallet="receiver" getspaddress
> tsp001pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kqxn48tq
>
> # New label, new address
> ./src/bitcoin-cli -signet -rpcwallet="receiver" getspaddress 'donation'
> tsp011pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kq80t7lt
>
> In this new scheme, the address has a new field called identifier, which
> tells the receiver and sender how to set the address correctly.
>
> If the receiver, for whatever reason, doesn't know which identifiers have
> been used, there is no problem. The wallet can scan all identifiers from 0
> to 99. Currently, only 100 different identifiers per wallet are allowed.
> This limit, however, can be increased at any time in the future.
>
> Unlike address formats so far, sp addresses are not script-related and may
> eventually include any additional information needed, such as an expiration
> timestamp (or block height). That way, users don't have to track the
> address indefinitely.
>
> As usual I wrote a step by step tutorial:
> https://gist.github.com/w0xlt/c81277ae8677b6c0d3dd073893210875
>
> ___
> 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] RFC for a BIP32 recurrent address derivation scheme

[Ruben Somsen via bitcoin-dev]

Hi Eloy,

Nice idea.

Note I thought about and succinctly described a similar scheme here (which
in turn was derived from work by Kixunil):
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-sharing

I agree with your general assessment that this is a scheme that seems like
an improvement over the status quo. Note that both BIP47 and Silent
Payments don't require any interaction with the sender, while this scheme
requires one-time interaction (e.g. this wouldn't be suitable for one-time
donations). I think this would mostly be a convenience feature that
improves the regular interactive payment flow (interact once, instead of
repeatedly asking for addresses with each payment).

>master / purpose' / coin_type' / contact' / index

Despite your explanation, it's still not fully clear to me how "contact" is
defined, but I assume it's just a counter? Just in case, note that you
can't let Bob define it for Carol, as then you can't deterministically
recover your payments without also backing up how it's defined (the seed
alone won't be enough).

The gap limit also needs to be kept in mind. If we allow each xpub to have
its own gap limit, you potentially get an exponential blowup (gaps in the
xpub * gaps in the addresses generated from the xpubs). It may be OK to
define a low default gap limit for these xpubs, since there should be no
reason to expect the same sender to leave any gaps, though this may depend
on how the xpubs are used (e.g. it may also be used to derive addresses for
others) so it's probably important to be explicit about this.

Cheers,
Ruben



On Thu, Sep 22, 2022 at 5:18 PM El_Hoy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There is a known issue on bitcoin, that is that every transaction requires
> a new address to prevent address reuse, making it uncomfortable to make
> recurring payments, as every payment requires a new off-chain interaction.
> A scheme is already mentioned on the [on the BIP32 itself][1], but it
> cannot be implemented as is.
>
> Here I propose a scheme that follows the structure described on [BIP44]
> that should make it possible to send recurring payments using a single
> offline interaction.
>
> The proposed scheme is:
>
> master / purpose' / coin_type' / contact' / index
>
> Where the definitions of all the levels follow BIP44, except for `contact`
> that is described below.
>
> Example usage: Bob wants to make recurring payments to Carol, so he asks
> her for a _contact address_, that is, an extended public key.
>
> Bob can use that public key to generate multiple derived addresses to make
> multiple recurring payments to Carol, the contact address is stored
> off-chain, anyone inspecting the chain will just see normal transactions
> on-chain.
>
> ## Considerations
>
> [BIP47] tries to solve the same issue, but the solution is more complex
> and involves more on-chain transactions that involve data, this
> implementation simpler and requires less work to implement.
>
> Also, the derivation path might need some adjustments for different
> address types on bitcoin.
>
> Finally, this only works in a single direction and does not make it
> possible for Carol to send anything to Bob, as it would require Bob sending
> her a contact address.
>
> ## Advantages
>
> A positive side effect of using this, is that Bob can choose to send
> payments to Carol using multiple outputs, giving him more privacy.
>
> Also, those payments can be easily labeled by the receiving wallet, as
> they are received.
>
> Regards.
>
> ### References
>
> [1]:
> https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#recurrent-business-to-business-transactions-nmih0
> [BIP47]: https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki
> "Reusable Payment Codes for Hierarchical Deterministic Wallets"
> [BIP43]:
> https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki#Purpose
>
> --- Eloy
> ___
> 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] Third version of Silent Payment implementation

[woltx via bitcoin-dev]

This new version addresses most (or all) requests made in PR:

. Implements the new scheme suggested by Ruben Somsen that allows multiple 
silent addresses per wallet with minimal overhead.
. Implements a new RPC to retrieve silent addresses, which allows users to 
assign different labels to different addresses. That way, the user knows which 
silent address the UTXO came from.

Example:

./src/bitcoin-cli -signet -rpcwallet="receiver" getspaddress
tsp001pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kqxn48tq

# This will return the same address as above (both have no label)
./src/bitcoin-cli -signet -rpcwallet="receiver" getspaddress
tsp001pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kqxn48tq

# New label, new address
./src/bitcoin-cli -signet -rpcwallet="receiver" getspaddress 'donation'
tsp011pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kq80t7lt

In this new scheme, the address has a new field called identifier, which tells 
the receiver and sender how to set the address correctly.

If the receiver, for whatever reason, doesn't know which identifiers have been 
used, there is no problem. The wallet can scan all identifiers from 0 to 99. 
Currently, only 100 different identifiers per wallet are allowed. This limit, 
however, can be increased at any time in the future.

Unlike address formats so far, sp addresses are not script-related and may 
eventually include any additional information needed, such as an expiration 
timestamp (or block height). That way, users don't have to track the address 
indefinitely.

As usual I wrote a step by step tutorial:
https://gist.github.com/w0xlt/c81277ae8677b6c0d3dd073893210875___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Trustless Address Server – Outsourcing handing out addresses to prevent address reuse

[Ruben Somsen via bitcoin-dev]

Hi all,

In short, this is yet another way to hand out addresses without interaction
between sender and recipient (Silent Payments, BIP47). The idea here is
that in non-ideal cases where you're already exposing your xpub to a server
(most light clients today, unfortunately), you might as well rely on them
to hand out addresses on your behalf.

Other than BTCPay Server, I am not aware of any serious attempts of
exploring this direction. Perhaps this is justified, due to the difficulty
of dealing with the gap limit, but it seems worth discussing nonetheless.

The write-up is available (and kept up-to-date) here as a gist:
https://gist.github.com/RubenSomsen/960ae7eb52b79cc826d5b6eaa61291f6

And here's a copy for the list:


### Introduction

Address reuse prevention generally requires interacting with the recipient
in order to receive a fresh address for each payment. There are various
protocols that ensure no interaction is required such as BIP47[^1] and
Silent Payments[^2], though neither is without downsides.

One area that is seemingly underexplored is that of outsourced interaction.
BTCPay Server[^3] is an example of this. The sender interacts with a
server, which acts on behalf of the recipient and hands out an address from
an xpub. The recipient controls and therefore trusts the server, so
malicious addresses won't be given out.

### Outsourcing and Malicious Keys

The vast majority of light clients today (even ones that support BIP47,
curiously) already control the user's xpub, so it seems logical to think
the interaction can be outsourced to them. However, unlike when running
your own server, a third party server *could* potentially hand out
malicious addresses (i.e. addresses that belong to someone other than you).

The solution to this is identity. As long as the sender knows a public key
by which the recipient can be identified, the recipient can sign the
addresses that are derived from their xpub[^4]. This way the sender can be
sure that the address it receives from the server belongs to the recipient.

### Gap Limit

One big remaining problem is the gap limit[^5]. When an adversary
repeatedly requests addresses from the server but then never uses them,
this could result in a large gap of unused addresses. This is a problem
because when recovering from backup the wallet stops looking for payments
when a large enough gap is encountered. Unfortunately there is no perfect
solution, but mitigations are still possible.

Whenever a sender wants to make their first payment, they could be expected
to obtain an address at a cost (solving captchas, paying over LN,
proof-of-burn[^6]). If the sender doesn't mind (or maybe even desires)
having their payments correlated by the recipient, a fresh xpub[^7] can be
handed out instead of an address in order to enable repeated payments. If
non-correlated payments are preferable, after each successful payment the
server could hand out a blind ecash[^8] token that entitles the sender to
another address.

An alternative mitigation (more user friendly, but more implementation
complexity) would be to require the sender to reveal their intended
transaction to the server prior to receiving the address[^9]. This is not a
privacy degradation, since the server could already learn this information
regardless. If the transaction doesn't end up getting sent, any subsequent
attempt to reuse one of the inputs should either be (temporarily)
blacklisted or responded to with the same address that was given out
earlier[^10].

If despite best efforts the gap limit is inadvertently reached anyway, the
recipient may have to be instructed to ensure they properly receive a
payment to bridge the gap before new addresses can be handed out. The
alternative is to forego privacy when this happens, but this seems unwise.

### Use Case

This protocol seems useful for users that a.) want to use light clients,
b.) accept the privacy degradation of handing out their xpub to a third
party, and c.) want to receive payments non-interactively. If any one of
these is not true, other protocols are likely to be a better choice[^11].
Finally, it should be acknowledged that this protocol introduces more
friction on the sender side due to the need for a gap limit mitigation
strategy.

-- Ruben Somsen


[^1]: BIP47: https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki

[^2]: Silent Payments:
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8

[^3]: BTCPay Server https://btcpayserver.org/

[^4]: *Specifically, this could be a single signature on a merkle root, so
the amount of data that the recipient needs to send to the server can be
minimized and the server can just generate the same tree from the xpub and
hand out merkle proofs to senders. The order of the leaves should be
randomized so senders cannot learn how many payments were made.*

[^5]: Gap limit:
https://bitcoin.stackexchange.com/questions/111534/bitcoin-address-gap-limit

[^6]: Efficient Proof-of-Burn:

Re: [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols

[Greg Sanders via bitcoin-dev]

> 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  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  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

Re: [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols

[Bastien TEINTURIER via bitcoin-dev]

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  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
>