Re: [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks

[Greg Sanders via bitcoin-dev]

Hi Peter,

Thanks for taking the time to understand the proposal and give thoughtful
feedback.

With this kind of "static" approach I think there are fundamental
limitations because
the user has to commit "up front" how large the CPFP later will have to be.
1kvB
is an arbitrary value that is two orders of magnitude less than the
possible package
size, and allows fairly flexible amounts of inputs(~14 taproot inputs
IIRC?) to effectuate a CPFP.
I'd like something much more flexible, but we're barely at whiteboard stage
for alternatives and
they probably require more fundamental work. So within these limits, we
have to pick some number,
and it'll have tradeoffs.

When I think of "pinning potential", I consider not only the parent size,
and not
only the maximum child size, but also the "honest" child size. If the honest
user does relatively poor utxo management, or the commitment transaction
is of very high value(e.g., lots of high value HTLCs), the pin is
essentially zero.
If the honest user ever only have one utxo, then the "max pin" is effective
indeed.

> Alice would have had to pay a 2.6x higher fee than
expected.

I think that's an acceptable worst case starting point, versus the status
quo which is ~500-1000x+.
Not great, not terrible.

Cheers,
Greg


On Wed, Dec 20, 2023 at 2:49 PM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Dec 20, 2023 at 07:13:22PM +, Gloria Zhao wrote:
> > The "damage" of the pin can quantified by the extra fees Alice has to
> pay.
> >
> > For a v3 transaction, Mallory can attach 1000vB at 80sat/vB. This can
> > increase the cost of replacement to 80,000sat.
> > For a non-v3 transaction, Mallory can attach (101KvB - N) before maxing
> out
> > the descendant limit.
> > Rule #4 is pretty negligible here, but since you've already specified
> > Alice's child as 152vB, she'll need to pay Rule #3 + 152sats for a
> > replacement.
> >
> > Let's say N is 1000vB. AFAIK commitment transactions aren't usually
> smaller
> > than this:
>
> You make a good point that the commitment transaction also needs to be
> included
> in my calculations. But you are incorrect about the size of them.
>
> With taproot and ephemeral anchors, a typical commitment transaction would
> have
> a single-sig input (musig), two taproot outputs, and an ephemeral anchor
> output.  Such a transaction is only 162vB, much less than 1000vB.
>
> In my experience, only a minority of commitment transactions that get mined
> have HTLCs outstanding; even if there is an HTLC outstanding, that only
> gets us
> up to 206vB.
>
> > > Mallory can improve the efficiency of his griefing attack by attacking
> > multiple
> > > targets at once. Assuming Mallory uses 1 taproot input and 1 taproot
> > output for
> > > his own funds, he can spend 21 ephemeral anchors in a single 1000vB
> > > transaction.
> >
> > Note that v3 does not allow more than 1 unconfirmed parent per tx.
>
> Ah, pity, I had misremembered that restriction as being removed, as that
> is a
> potentially significant improvement in scenarios where you need to do
> things
> like deal with a bunch of force closes at once.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> ___
> 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] Proposed BIP for OP_CAT

[Greg Sanders via bitcoin-dev]

> This is no
longer an issue in the current age as tapscript enforces a maximum
stack element size of 520 Bytes.

I don't think there's a new limit related to tapscript? In the very
beginning there was no limit, but a 5k limit was put into place, then 520
the same commit that OP_CAT was
disabled: 4bd188c4383d6e614e18f79dc337fbabe8464c82

On Sat, Oct 21, 2023 at 1:09 AM Ethan Heilman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi everyone,
>
> We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode.
> https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki
>
> OP_CAT was available in early versions of Bitcoin. It was disabled as
> it allowed the construction of a script whose evaluation could create
> stack elements exponential in the size of the script. This is no
> longer an issue in the current age as tapscript enforces a maximum
> stack element size of 520 Bytes.
>
> Thanks,
> Ethan
>
> ==Abstract==
>
> This BIP defines OP_CAT a new tapscript opcode which allows the
> concatenation of two values on the stack. This opcode would be
> activated via a soft fork by redefining the opcode OP_SUCCESS80.
>
> When evaluated the OP_CAT instruction:
> # Pops the top two values off the stack,
> # concatenate the popped values together,
> # and then pushes the concatenated value on the top of the stack.
>
> OP_CAT fails if there are less than two values on the stack or if a
> concatenated value would have a combined size of greater than the
> maximum script element size of 520 Bytes.
>
> ==Motivation==
> Bitcoin tapscript lacks a general purpose way of combining objects on
> the stack restricting the expressiveness and power of tapscript. For
> instance this prevents among many other things the ability to
> construct and evaluate merkle trees and other hashed data structures
> in tapscript. OP_CAT by adding a general purpose way to concatenate
> stack values would overcome this limitation and greatly increase the
> functionality of tapscript.
>
> OP_CAT aims to expand the toolbox of the tapscript developer with a
> simple, modular and useful opcode in the spirit of Unix[1]. To
> demonstrate the usefulness of OP_CAT below we provide a non-exhaustive
> list of some usecases that OP_CAT would enable:
>
> * Tree Signatures provide a multisignature script whose size can be
> logarithmic in the number of public keys and can encode spend
> conditions beyond n-of-m. For instance a transaction less than 1KB in
> size could support tree signatures with a thousand public keys. This
> also enables generalized logical spend conditions. [2]
> * Post-Quantum Lamport Signatures in Bitcoin transactions. Lamport
> signatures merely requires the ability to hash and concatenate values
> on the stack. [3]
> * Non-equivocation contracts [4] in tapscript provide a mechanism to
> punish equivocation/double spending in Bitcoin payment channels.
> OP_CAT enables this by enforcing rules on the spending transaction's
> nonce. The capability is a useful building block for payment channels
> and other Bitcoin protocols.
> * Vaults [5] which are a specialized covenant that allows a user to
> block a malicious party who has compromised the user's secret key from
> stealing the funds in that output. As shown in A. Poelstra, "CAT
> and Schnorr Tricks II", 2021,
> https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html
> 
> OP_CAT is sufficent to build vaults in Bitcoin.
> * Replicating CheckSigFromStack  A. Poelstra, "CAT and Schnorr
> Tricks I", 2021,
> https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
>  which would allow the creation of simple covenants and other
> advanced contracts without having to presign spending transactions,
> possibly reducing complexity and the amount of data that needs to be
> stored. Originally shown to work with Schnorr signatures, this result
> has been extended to ECDSA signatures. [6]
>
> The opcode OP_CAT was available in early versions of Bitcoin. However
> OP_CAT was removed because it enabled the construction of a script for
> which an evaluation could have memory usage exponential in the size of
> the script.
> For instance a script which pushed an 1 Byte value on the stack then
> repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack
> value whose size was greater than 1 Terabyte. This is no longer an
> issue because tapscript enforces a maximum stack element size of 520
> Bytes.
>
> ==Specification==
>
> Implementation
> 
>   if (stack.size() < 2)
> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
>   valtype vch1 = stacktop(-2);
>   valtype vch2 = stacktop(-1);
>
>   if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE)
>   return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
>
>   valtype vch3;
>   vch3.reserve(vch1.size() + vch2.size());
>   vch3.insert(vch3.end(), vch1.begin(), vch1.end());
>   vch3.insert(vch3.end(), vch2.begin(), vch2.end());
>
>   popstack(stack);
>   

Re: [bitcoin-dev] Batch exchange withdrawal to lightning requires covenants

[Greg Sanders via bitcoin-dev]

> I do not know if existing splice implementations actually perform such a
check.
Unless all splice implementations do this, then any kind of batched
splicing is risky.

As long as the implementation decides to splice again at some point when a
prior
splice isn't confirming, it will self-resolve once any subsequent splice is
confirmed.

Cheers,
Greg

On Tue, Oct 17, 2023 at 1:04 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Bastien,
>
> I have not gotten around to posting it yet, but I have a write-up in my
> computer with the title:
>
> > Batched Splicing Considered Risky
>
> The core of the risk is that if:
>
> * I have no funds right now in a channel (e.g. the LSP allowed me to have
> 0 reserve, or this is a newly-singlefunded channel from the LSP to me).
> * I have an old state (e.g. for a newly-singlefunded channel, it could
> have been `update_fee`d, so that the initial transaction is old state).
>
> Then if I participate in a batched splice, I can disrupt the batched
> splice by broadcasting the old state and somehow convincing miners to
> confirm it before the batched splice.
>
> Thus, it is important for *any* batched splicing mechanism to have a
> backout, where if the batched splice transaction can no longer be confirmed
> due to some participant disrupting it by posting an old commitment
> transaction, either a subset of the splice is re-created or the channels
> revert back to pre-splice state (with knowledge that the post-splice state
> can no longer be confirmed).
>
> I know that current splicing tech is to run both the pre-splice and
> post-splice state simultaneously until the splicing transaction is
> confirmed.
> However we need to *also* check if the splicing transaction *cannot* be
> confirmed --- by checking if the other inputs to the splice transaction
> were already consumed by transactions that have deeply confirmed, and in
> that case, to drop the post-splice state and revert to the pre-splice state.
> I do not know if existing splice implementations actually perform such a
> check.
> Unless all splice implementations do this, then any kind of batched
> splicing is risky.
>
> Regards,
> ZmnSCPxj
>
> ___
> 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] Combined CTV+APO to minimal TXHASH+CSFS

[Greg Sanders via bitcoin-dev]

Hi Brandon,

Not going to dive too deep here, just adding a bit of color.

> * If the top item on the stack is not a minimally encoded `OP_0`, `OP_1`,
or
  `OP_2`; succeed immediately[^2].

I presume this was supposed to go to OP_4 now.

> ### How does the efficiency compare to [bip118][]?

Just noting BIP118 also allows pubkey of "1" to stand in for the taproot
inner pubkey, which would be a common use-case. "simply" adding an opcode
ala OP_INNER_PUBKEY could also have the same effect of course.

Also, BIP118 also opens the door for non-APO signatures to have a sighash
digest that commits to additional data, closing a couple of taproot
malleability bugs. See
https://github.com/bitcoin-inquisition/bitcoin/issues/19 for more
discussion along those lines. These aren't make or break, but would be nice
to clean up if possible

Best,
Greg

On Tue, Aug 22, 2023 at 3:04 PM Brandon Black via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi list,
>
> https://gist.github.com/reardencode/2aa98700b720174598d21989dd46e781
>
> I'm seeking feedback on this proposal to provide the functionality
> requested by those advocating for bip118 and bip119 in a combined way
> that retains the low risk associated with each of those separate
> proposals. At least part of the reason for creating this is similar to
> my reason for creating bips PR#1472, and my covenant comparo
> spreadsheet, i.e. to help further the discussion of these proposals and
> make more clear the similarities and differences between them.
>
> https://github.com/bitcoin/bips/pull/1472
>
> https://docs.google.com/spreadsheets/d/1YL5ttNb6-SHS6-C8-1tHwao1_19zNQ-31YWPAHDZgfo/edit
>
> It's become clear to me that in large part the separation between
> advocates of these two proposals stems from a lack of full understanding
> of their properties. My hope is that this work helps to clarify our
> thinking about them individually and together, and potentially move
> toward consensus on a path toward enabling better lightning, vaults, and
> likely other amazing ways to use bitcoin in the future.
>
> ---
>
> # Abstract
>
> This proposal is an alternative to [bip119][] and [bip118][], providing the
> functionality of both proposals with no additional overhead in [many
> cases](#compared-to-non-tapscript-ctv), while clearing certain objections
> to
> both, and opening clear upgrade paths.
>
> This is, in essence, an initially constrained version of Russel O'Connor's
> [OP_TXHASH+OP_CSFS proposal][].
>
> We define three new Tapscript-only opcodes. Replacing `OP_SUCCESS80`,
> `OP_SUCCESS187`, and `OP_SUCCESS188` with `OP_TXHASH`,
> `OP_CHECKSIGFROMSTACK`,
> and `OP_CHECKSIGFROMSTACKVERIFY` respectively.
>
> # Summary
>
> For `OP_TXHASH`, we define exactly 5 methods of hashing the transaction
> depending
> on a minimally encoded numeric argument popped from the stack:
>
> argument | behavior
>  | -
>0 | as in [bip119][]
>1 | as in [bip118][] with sighash flag `0x41`
>2 | as in [bip118][] with sighash flag `0xc1`
>3 | as in [bip118][] with sighash flag `0x43`
>4 | as in [bip118][] with sighash flag `0xc3`
>
> `OP_CHECKSIGFROMSTACK(VERIFY)` is defined similarly to the [implementation
> in
> the Elements project][OP_CHECKSIGFROMSTACK in elements], but does not
> internally SHA256 hash the data argument. As [bip340][] defines signatures
> on
> arbitrary length messages, and these `OP_CHECKSIGFROMSTACK(VERIFY)` are
> defined only in Tapscript, the internal hashing is unnecessarily
> restrictive.
> Users may wish to use pre-hashed values as in this proposal, or non-SHA256
> hashes available in script.
>
> # Motivation
>
> Much ink has been spilled on the discussion of what is next for bitcoin
> scipt
> development. The two proposals nearest to consensus are [bip118][] and
> [bip119][], but the proponents of each disagree about the relative priority
> and the merrits of the other. Here, we'll briefly outline some of the
> objections to each and demonstrate how this proposal reduces those
> objections.
> We will not discuss the concerns about the introduction of covenants or
> recursive covenants generally.
>
> ## [CTV][bip119] Objections
>
> * Not general enough
> * Inefficient when otherwise validating the hash (e.g. when combined with
>   `OP_CHECKSIGFROMSTACK`)
> * Uses `OP_NOPx` extension semantics even though `OP_SUCCESSx` is available
>
> ## [APO][bip118] Objections
>
> * Not general enough
> * Accidentally enables inefficient, hard to use covenants
> * Uses new Tapscript key version to avoid accidents
>
> ## Solutions
>
> * By providing the behavior of both [bip118][] and [bip119][], this
> proposal
>   is more general than either of those proposals. It also provides explicit
>   upgrade hooks for further generality (e.g. to
>   [full OP_TXHASH][OP_TXHASH+OP_CSFS proposal]).
> * By splitting the hashing from the validation of [bip119], the hash can be
>   used in ways other 

Re: [bitcoin-dev] On the experiment of the Bitcoin Contracting Primitives WG and marking this community process "up for grabs"

[Greg Sanders via bitcoin-dev]

Hi antoine,

Simplicity was just a stand in for "functionally complete" handwave.

Cheers,
Greg

On Thu, Jul 20, 2023, 1:46 AM Antoine Riard  wrote:

> Hi Greg,
>
> I'm very meeting your development approach with regards to starting smalls
> about consensus change primitives, and I think taproot has demonstrated
> some good historical process, which has good archives about how development
> was conducted (e.g the community-wide taproot review of which the Bitcoin
> Contracting Primitives WG was built on this experience [0]).
>
> I don't know about saying that the BOLTs (and its process) should be
> authoritative over the running code of implementations. While it's
> definitely a mark of some bar of technical review and inter-compatibility,
> I think ultimately each BOLT has to be judged individually on its own
> technical merits. And I think we had a bunch of cases in the past when "the
> map is not the territory". Even there are few areas of critical Lightning
> operations which are not documented by the BOLTs to the best of my
> knowledge (such as fee-bumping and transactions broadcast reactions as it
> was for on-chain DLCs [1]).
>
> Lastly, there is a huge area of uncertainty about the technical fitness of
> Simplicity for 2/small party channels. I remember a Russell O'connor
> presentation about Simplicity back in Paris (2017 or 2018 ?) and asking him
> how it would work in a chain of transactions, while the answer was iirc
> "yes it has been designed with this constraint", it's a very open question
> when you have off-chain states which advances in independence from the
> on-chain state between a dynamic number of counterparties (kinda the
> interactivity issue for payment pools). Here I guess you would have to come
> to a consensus to the model of logic followed for the analysis of such
> distributed systems e.g Leslie Lamport's temporal logic [2]. Additionally,
> the theoretical foundations on the Coq prover are still actively studied by
> Xavier Leroy at the College de France and some novel insights might be
> interesting for using formal verification in terms of Bitcoin consensus
> changes development (and I don't know if all the works and lessons have
> been translated from French to English).
>
> Best,
> Antoine
>
> [0] https://github.com/ajtowns/taproot-review
> [1]
> https://github.com/discreetlogcontracts/dlcspecs/blob/master/Non-Interactive-Protocol.md
> [2] https://en.wikipedia.org/wiki/Temporal_logic_of_actions
>
> Le mer. 19 juil. 2023 à 21:45, Greg Sanders  a
> écrit :
>
>> Hello Keagen,
>>
>> Most of the complexity of LN cannot be resolved with covenants. Of the
>> things that can be simplified in my experience, you're going to need more
>> than CTV to get significant gains. And in the end, channels can only get so
>> simple since we have many other BOLTs to deal with. And even then, you're
>> going to have to convince LN spec writers to include such changes, whatever
>> they are, then get deployment.
>>
>> Step 1 is finding a primitive that seems interesting. It's important to
>> moderate enthusiasm for any primitive with reality, and probably by being
>> concrete by writing specs that use a primitive, and code it up to discover
>> what we're overlooking. We're always overlooking something! In my humble
>> opinion these are step 2 and 3 of gathering mind-share.
>>
>> As a more productive tact, if we're thinking beyond 2/small party
>> channels, probably better to snap your fingers, pretend we have Simplicity,
>> see what we can build, and work backwards from there to see if we can
>> accomplish this within the confines of bitcoin script?
>>
>> Cheers,
>> Greg
>>
>> On Wed, Jul 19, 2023 at 3:59 PM Keagan McClelland via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi Antoine,
>>>
>>> Thank you for the effort you've put towards this. I generally agree that
>>> a smooth functioning Lightning Network is of greater importance than
>>> advanced contracting capabilities. However, as I dive deeper into some of
>>> the more ambitious goals for LN development I am learning that a great deal
>>> of complexity of some current lightning (LN) proposals can be handily
>>> discharged with CTV. While I am not intimately familiar with all of the
>>> other covenant schemes to the same level of technical proficiency, I have a
>>> suspicion that a number of them, if not all of them, are capable of
>>> discharging the same flavor and amount of complexity as well. Others should
>>> chime in if they can confirm this claim.
>>>
>>> I have been publicly on the record as supporting the addition of some
>>> covenant scheme into Bitcoin for some time and have long held on
>>> theoretical grounds that the addition of such a mechanism is both necessary
>>> and inevitable if Bitcoin is to survive in the long term. However, as I've
>>> started to work more directly with the Lightning protocol, these
>>> theoretical and purely logical arguments became far more concrete and
>>> immediately 

Re: [bitcoin-dev] On the experiment of the Bitcoin Contracting Primitives WG and marking this community process "up for grabs"

[Greg Sanders via bitcoin-dev]

Hello Keagen,

Most of the complexity of LN cannot be resolved with covenants. Of the
things that can be simplified in my experience, you're going to need more
than CTV to get significant gains. And in the end, channels can only get so
simple since we have many other BOLTs to deal with. And even then, you're
going to have to convince LN spec writers to include such changes, whatever
they are, then get deployment.

Step 1 is finding a primitive that seems interesting. It's important to
moderate enthusiasm for any primitive with reality, and probably by being
concrete by writing specs that use a primitive, and code it up to discover
what we're overlooking. We're always overlooking something! In my humble
opinion these are step 2 and 3 of gathering mind-share.

As a more productive tact, if we're thinking beyond 2/small party channels,
probably better to snap your fingers, pretend we have Simplicity, see what
we can build, and work backwards from there to see if we can accomplish
this within the confines of bitcoin script?

Cheers,
Greg

On Wed, Jul 19, 2023 at 3:59 PM Keagan McClelland via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Antoine,
>
> Thank you for the effort you've put towards this. I generally agree that a
> smooth functioning Lightning Network is of greater importance than advanced
> contracting capabilities. However, as I dive deeper into some of the more
> ambitious goals for LN development I am learning that a great deal of
> complexity of some current lightning (LN) proposals can be handily
> discharged with CTV. While I am not intimately familiar with all of the
> other covenant schemes to the same level of technical proficiency, I have a
> suspicion that a number of them, if not all of them, are capable of
> discharging the same flavor and amount of complexity as well. Others should
> chime in if they can confirm this claim.
>
> I have been publicly on the record as supporting the addition of some
> covenant scheme into Bitcoin for some time and have long held on
> theoretical grounds that the addition of such a mechanism is both necessary
> and inevitable if Bitcoin is to survive in the long term. However, as I've
> started to work more directly with the Lightning protocol, these
> theoretical and purely logical arguments became far more concrete and
> immediately beneficial.
>
> I say this primarily to challenge the idea that covenants are a
> distraction from lightning development. It may very well be that your areas
> of focus on LN preclude you from splitting your attention and none of this
> email should be interpreted as a criticism of you applying your efforts in
> the highest leverage manner you can manage. That said, I don't want
> observers of this thread to walk away with the impression that they are two
> independent efforts as covenants can significantly contribute to LN's
> maturity. When and how should they be prioritized? Unfortunately I don't
> feel able to comment on that at this time. All I know is that Lightning
> would almost certainly benefit substantially from having a covenant
> primitive.
>
> Cheers,
> Keags
>
> On Tue, Jul 18, 2023 at 3:40 PM Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi list,
>>
>> Last year amid the failure of the CTV speedy trial activation and intense
>> conversations about a rainbow of covenant proposals, I introduced the idea
>> of a new community process to specify covenants [0]. This post is to resume
>> the experiment so far and officially mark the process maintenance as "up
>> for grabs", as I won't actively pursue it further (after wavering on such a
>> decision a bit during May / June).
>>
>> Few of the goals announced at that time were to build a consistent
>> framework to evaluate covenant proposals, see the common grounds between
>> proposals if they could be composed or combined by their authors, open the
>> consensus  changes development process beyond the historical boundaries of
>> Bitcoin Core and maintain high-quality technical archive as a consensus
>> discussions have spawned half a decade from intellectual conception to
>> activation in average (at least for segwit, schnorr, taproot).
>>
>> Such effort was a speak-by-the-act answer to the issues in
>> consensus development changes pointed out by Jeremy Rubin in April of last
>> year [1]: namely the lack of a "codified checklist" for consensus changes,
>> that "consensus is memoryless" and "bitcoin core is not bitcoin"
>> (independently of the technical concerns as I have as limited or
>> non-adequate primitive for vaults / payment pools I expressed during the
>> same time). Other complementary initiatives have been undertaken during the
>> same period, AJ with the bitcoin-inquisition fork where the community of
>> developers and contracting primitives of researchers on a consensus-enabled
>> fork of core [2]. And Dave Harding with the careful archiving of all
>> covenant proposals under the Optech umbrella 

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

[Greg Sanders via bitcoin-dev]

>> "Can a V2 transaction replace a V3 transaction and vice versa?"

> Circling back to my ACP point, this regime still allows pinning anytime
you are sharing a transaction with someone else where you don't have
control over *all* the inputs. So anytime you are doing a coinjoin-like
transaction, someone else's inputs can be self-double-spent, requiring you
to satisfy rule#3 when replacing theirs, if they're bip125-signaling. If
they're not bip125 signaling, you'll have to somehow detect this and/or
double-spend your input back to yourself.

Talking with someone offline I realized we can un-pin coinjoins with V3
which I previously thought untenable. You "just" have to stage all utxos
that are going to be mixed in separately into a timelocked utxo that is
immediately spendable by all joining parties(or the person and the coinjoin
coordinator who is trusted to not pin, they're taking fees usually
anyways). Then once all utxos for a mix are staged, continue the coinjoin
as before with V3. You only need a timelock long enough to stop pinning;
not very long. If you do 2-of-2 with a coordinator, you can start the join
whenever you think you have enough utxos staged. If using coordinator
model, you can then do this in a chained fashion, doing mix after mix, with
only one utxo setup step.

Seems really obvious in retrospect, with the downside of one additional tx
per mixing participant and less composability with other protocols.

Just thought it important to point out in public, in lieu of a "real" fix
like replace by feerate which hasn't been designed yet.

Cheers,
Greg

On Fri, Sep 23, 2022 at 2:48 PM Greg Sanders  wrote:

> Hello Gloria,
>
> Great work on synthesizing so much feedback into a proposal like this!
>
> Death to carve-out rule.
>
> I'd like to elaborate on some caveats and give a few incomplete thoughts.
>
> There are basically two types of pinning in my estimation today:
>
> 1) rule#3 pinning: Make it uneconomical to replace whatever is in mempool
> via large in size but low feerate junk that won't get mined anytime soon.
> Replacing this with feerate-based policy seems apt, but fraught with DoS
> risks.
>
> 2) package limit pinning: disallowing transaction propagation by package
> limits being hit: size, ancestor count, descendant count. Today it is
> mitigated by having all outputs be 1 csv timelocked, and having up to 2
> anchor outputs(1 without carve-out rule).
>
> 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.
>
> > "Does this fix Rule 3 Pinning?"
>
> 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. Due to this pinning attack there aren't many(?) deployed schemes
> that use the signature type.
>
> To mitigate this we would likely have to opt into a more complex policy
> scheme, committing in the annex to "total mempool package weight", which
> would allow mempool package limits to be picked at signing time.
>
> Maybe ANYONECANPAY isn't a very useful paradigm in general, I cannot speak
> to that, but it came up in eltoo-related designs using BIP118, which adopts
> ACP-like signing behavior. This can be mitigated via straight forward
> policy updates as well for BIP118 deployment, but off topic so will leave
> it there.
>
> 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.
>
> > "Can a V2 transaction replace a V3 transaction and vice versa?"
>
> Circling back to my ACP point, this regime still allows pinning anytime
> you are sharing a transaction with someone else where you don't have
> control over *all* the inputs. So anytime you are doing a coinjoin-like
> transaction, someone else's inputs can be self-double-spent, requiring you
> to satisfy rule#3 when replacing theirs, if they're bip125-signaling. If
> they're not bip125 signaling, you'll have to somehow detect this and/or
> double-spend your input back to yourself.
>
>
> Finally, a couple suggestions I've already made elsewhere:
>
> 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" 

Re: [bitcoin-dev] Standardisation of an unstructured taproot annex

[Greg Sanders via bitcoin-dev]

Hi Antoine,

> If I understand correctly, this would require modifying current Taproot
support on the Lightning-side, where all P2TR spends must add an annex and
commit to it in the BIP341 signature digest.

huh?

Going to need a citation for this.

People should really not be building protocols that are meant to go into
production on top of undeveloped upgrade hooks,
and we should not be encumbered by these premature choices if so. Maybe I'm
misunderstanding, which is why a citation
would be handy.

Best,
Greg

On Sun, Jun 18, 2023 at 4:32 PM Antoine Riard 
wrote:

> Hi all,
>
> > * Opt-in annex (every input must commit to an annex even if its is
> empty) -> make sure existing multi-party protocols remain unaffected
>
> By requiring every input to commit to an annex even if it is empty, do you
> mean rejecting a transaction where the minimal annex with its 0x50 tag is
> absent ?
>
> If I understand correctly, this would require modifying current Taproot
> support on the Lightning-side, where all P2TR spends must add an annex and
> commit to it in the BIP341 signature digest. This would be quite a
> mandatory upgrade for Lightning nodes, as failure to do so would break
> propagations of their `option_taproot` channel transactions.
>
> > * Limit maximum size of the value to 256 bytes -> protect opt-in users
>
> There is another approach where the maximum size/weight of the
> witness/transaction is introduced as a TLV record itself:
> https://github.com/bitcoin-inquisition/bitcoin/pull/28
>
> Note this branch also implements the "only allow tlv record 0" with the
> TLV format from bips #1381.
>
> Best,
> Antoine
>
> Le ven. 16 juin 2023 à 14:31, Greg Sanders via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a écrit :
>
>> Hi Joost,
>>
>> I haven't thought a ton about the specific TLV format, but that seems
>> like a reasonable place to start as it shouldn't unduly
>> impact current users, and is pretty simple from an accounting perspective.
>> It also can be further relaxed in the future if we so decide by using max
>> tx size policy "hints" in an annex field.
>>
>> I'll let others chime in at this point!
>>
>> Cheers,
>> Greg
>>
>> On Fri, Jun 16, 2023 at 7:27 AM Joost Jager 
>> wrote:
>>
>>> Hi Greg,
>>>
>>> On Thu, Jun 15, 2023 at 12:39 PM Greg Sanders 
>>> wrote:
>>>
>>>> > Would it then still be necessary to restrict the annex to a maximum
>>>> size?
>>>>
>>>> I think it's worth thinking about to protect the opt-in users, and can
>>>> also be used for other anti-pinning efforts(though clearly not sufficient
>>>> by itself for the many many pinning vectors we have :) )
>>>>
>>>
>>> Thinking about the most restrictive policy that would still enable
>>> annex-vaults (which I believe has great potential for improving bitcoin
>>> custody) and is in line with work already done, I get to:
>>>
>>> * Opt-in annex (every input must commit to an annex even if its is
>>> empty) -> make sure existing multi-party protocols remain unaffected
>>> * Tlv format as defined in https://github.com/bitcoin/bips/pull/1381 ->
>>> future extensibility
>>> * Only allow tlv record 0 - unstructured data -> future extensibility
>>> * Limit maximum size of the value to 256 bytes -> protect opt-in users
>>>
>>> Unfortunately the limit of 126 bytes in
>>> https://github.com/bitcoin-inquisition/bitcoin/pull/22 isn't sufficient
>>> for these types of vaults. If there are two presigned txes (unvault and
>>> emergency), those signatures would already take up 2*64=128 bytes. Then you
>>> also want to store 32 bytes for the ephemeral key itself as the key can't
>>> be reconstructed from the schnorr signature. The remaining bytes could be
>>> used for a third presigned tx and/or additional vault parameters.
>>>
>>> Can you think of remaining practical objections to making the annex
>>> standard under the conditions listed above?
>>>
>>> Joost
>>>
>>>> ___
>> 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] Standardisation of an unstructured taproot annex

[Greg Sanders via bitcoin-dev]

Hi Joost,

I haven't thought a ton about the specific TLV format, but that seems like
a reasonable place to start as it shouldn't unduly
impact current users, and is pretty simple from an accounting perspective.
It also can be further relaxed in the future if we so decide by using max
tx size policy "hints" in an annex field.

I'll let others chime in at this point!

Cheers,
Greg

On Fri, Jun 16, 2023 at 7:27 AM Joost Jager  wrote:

> Hi Greg,
>
> On Thu, Jun 15, 2023 at 12:39 PM Greg Sanders 
> wrote:
>
>> > Would it then still be necessary to restrict the annex to a maximum
>> size?
>>
>> I think it's worth thinking about to protect the opt-in users, and can
>> also be used for other anti-pinning efforts(though clearly not sufficient
>> by itself for the many many pinning vectors we have :) )
>>
>
> Thinking about the most restrictive policy that would still enable
> annex-vaults (which I believe has great potential for improving bitcoin
> custody) and is in line with work already done, I get to:
>
> * Opt-in annex (every input must commit to an annex even if its is empty)
> -> make sure existing multi-party protocols remain unaffected
> * Tlv format as defined in https://github.com/bitcoin/bips/pull/1381 ->
> future extensibility
> * Only allow tlv record 0 - unstructured data -> future extensibility
> * Limit maximum size of the value to 256 bytes -> protect opt-in users
>
> Unfortunately the limit of 126 bytes in
> https://github.com/bitcoin-inquisition/bitcoin/pull/22 isn't sufficient
> for these types of vaults. If there are two presigned txes (unvault and
> emergency), those signatures would already take up 2*64=128 bytes. Then you
> also want to store 32 bytes for the ephemeral key itself as the key can't
> be reconstructed from the schnorr signature. The remaining bytes could be
> used for a third presigned tx and/or additional vault parameters.
>
> Can you think of remaining practical objections to making the annex
> standard under the conditions listed above?
>
> Joost
>
>>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Standardisation of an unstructured taproot annex

[Greg Sanders via bitcoin-dev]

Hi Joost,

> Ignoring the argument that policy may provide a false sense of security

This may take longer form arguments than I'm willing to make on this
thread, but I think this only true in a shallower sense that we cannot know
for sure that anything will be confirmed quickly. When crafting policy, we
are trying to make as reliable-as-possible systems to allow people to pay
miners. That may mean opening up the annex to potential use-cases, but it
certainly means allowing current users of the p2p network to make
reasonable feerate transactions in coinjoin-like scenarios. Ideally we
shoot for as many use cases as we can, to pay these miners.

> Would it then still be necessary to restrict the annex to a maximum size?

I think it's worth thinking about to protect the opt-in users, and can also
be used for other anti-pinning efforts(though clearly not sufficient by
itself for the many many pinning vectors we have :) )

Cheers,
Greg

On Thu, Jun 15, 2023 at 5:36 AM Joost Jager  wrote:

> Hi Greg,
>
> Getting back to this:
>
> Another solution could be to make annex usage "opt-in"
>> by requiring all inputs to commit to an annex to be relay-standard. In
>> this case, you've opted into a possible
>> vector, but at least current usage patterns wouldn't be unduly affected.
>>
>
> Ignoring the argument that policy may provide a false sense of security, I
> think this is an interesting idea. Opt-in would enable convenants through
> presigned txes with atomic on-chain signature backup, without needing to
> worry about non-annex multi-party protocols (coinjoin and dual funded
> lightning mentioned previously) that may suffer from annex inflation or the
> last signer presenting an unexpected annex. The downside is just that extra
> empty annex byte per input, if there are other inputs involved. To me that
> would be a reasonable trade-off.
>
> Would it then still be necessary to restrict the annex to a maximum size?
> Perhaps not opting into annex for multi-party protocols is sufficient. Or
> otherwise, #24007 may be helpful. It is hard to pick a constant usually.
>
> Joost.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Standardisation of an unstructured taproot annex

[Greg Sanders via bitcoin-dev]

> Regarding the potential payload extension attack, I believe that the
changes proposed in the [3] to allow tx replacement by smaller witness
would provide a viable solution?

The only plausible case I could see moving forward is replacing the
transaction to a form that has *no* annex or scriptpath spends, ala
https://github.com/bitcoin/bitcoin/pull/24007#issuecomment-1308104119 .
It's much easier to think about one-off replacements from an anti-DoS
perspective.

We would have to think a lot harder if that actually solves the problem and
maintains the prospective use-cases before diving into analysis, regardless.

Cheers,
Greg


On Sat, Jun 10, 2023 at 5:02 AM Joost Jager via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Antoine,
>
> On Sat, Jun 10, 2023 at 2:23 AM Antoine Riard 
> wrote:
>
>> From a taproot annex design perspective, I think this could be very
>> valuable if you have a list of unstructured data use-cases you're thinking
>> about ?
>>
>
> The annex's list of unstructured data use-cases includes existing data
> storage uses that utilize OP_RETURN or inscriptions. Consider ordinals,
> timestamps, and any other data already stored on the chain. These
> applications would immediately benefit from the annex's improved space
> efficiency.
>
> However, the primary advantage I see in the annex is that its data isn't
> included in the calculation of the txid or a potential parent commit
> transaction's txid (for inscriptions). I've explained this at [1]. This
> feature makes the annex a powerful tool for applications that would ideally
> use covenants.
>
> The most critical application in this category, for me, involves
> time-locked vaults. Given the positive reception to proposals such as
> OP_VAULT [2], I don't think I'm alone in this belief. OP_VAULT is probably
> a bit further out, but pre-signed transactions signed using an ephemeral
> key can fill the gap and improve the safeguarding of Bitcoin in the short
> term.
>
> Backing up the ephemeral signatures of the pre-signed transactions on the
> blockchain itself is an excellent way to ensure that the vault can always
> be 'opened'. However, without the annex, this is not as safe as it could
> be. Due to the described circular reference problem, the vault creation and
> signature backup can't be executed in one atomic operation. For example,
> you can store the backup in a child commit/reveal transaction set, but the
> vault itself can be confirmed independently and the backup may never
> confirm. If you create a vault and lose the ephemeral signatures, the funds
> will be lost.
>
> This use case for the annex has been labeled 'speculative' elsewhere. To
> me, every use case appears speculative at this point because the annex
> isn't available. However, if you believe that time-locked vaults are
> important for Bitcoin and also acknowledge that soft forks, such as the one
> required for OP_VAULT, aren't easy to implement, I'd argue that the
> intermediate solution described above is very relevant.
>
>
>> As raised on the BIP proposal, those unstructured data use-cases could
>> use annex tags with the benefit to combine multiple "types" of unstructured
>> data in a single annex payload. As you're raising smaller bits of
>> unstructured data might not afford the overhead though my answer with this
>> observation would be to move this traffic towards some L2 systems ? In my
>> mind, the default of adding a version byte for the usage of unstructured
>> data comes with the downside of having future consensus enabled use-cases
>> encumbering by the extended witness economic cost.
>>
>
> When it comes to the trade-offs associated with various encodings, I fully
> acknowledge their existence. The primary motivation behind my proposal to
> adopt a simple approach to the Taproot annex is to avoid a potentially long
> standardization process. While I am not entirely familiar with the
> decision-making process of Bitcoin Core, my experience with other projects
> suggests that simpler changes often encounter less resistance and can be
> implemented more swiftly. Perhaps I am being overly cautious here, though.
>
>
>> About the annex payload extension attack described by Greg. If my
>> understanding of this transaction-relay jamming griefing issue is correct,
>> we can have an annex tag in the future where the signer is committing to
>> the total weight of the transaction, or even the max per-input annex size ?
>> This should prevent a coinjoin or aggregated commitment transaction
>> counterparty to inflate its annex space to downgrade the overall
>> transaction feerate, I guess. And I think this could benefit unstructured
>> data use-cases too.
>>
>
> Regarding the potential payload extension attack, I believe that the
> changes proposed in the [3] to allow tx replacement by smaller witness
> would provide a viable solution?
>
> Joost
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021737.html
> [2] 

Re: [bitcoin-dev] Standardisation of an unstructured taproot annex

[Greg Sanders via bitcoin-dev]

No in this case the txid is identical. Only the wtxid is malleated, with
annex data stuffed to max transaction size.

Cheers,
Greg

On Sat, Jun 3, 2023, 8:36 AM Joost Jager  wrote:

> > Depending on policy to mitigate this annex malleability vector could
>> mislead developers into believing their transactions are immune to
>> replacement, when in fact they might not be.
>>
>> The issue I'm talking about is where someone's transaction is denied
>> entry into the mempool entirely because a counter-party decided to put in a
>> strictly worse transaction for miners by bloating the weight of it, not
>> adding fees. A strictly worse "API" for paying miners for no gain seems
>> like a bad trade to me, especially when there are reasonable methods for
>> mitigating this.
>>
>
> Just to expand this, an example would be a transaction with inputs A' and
> B' signed by two parties A and B. A has a fully signed transaction in
> hands, but can't publish it because B created and published an alternative
> version of it with a large annex for input B'. Wouldn't miners just accept
> A's version because it's fee rate is higher? I am looking at this case
> assuming the user has a direct connection to a miner, ignoring any
> potential concerns related to p2p transport.
>
> Joost
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Standardisation of an unstructured taproot annex

[Greg Sanders via bitcoin-dev]

> I think this avoidance of a circular reference is also why LN-Symmetry
uses the annex?

The annex trick specifically is used to force the publication of the
missing piece of the control block corresponding to the new taproot output.
This is to maintain the node's O(1) state while also keeping 0.5RTT channel
updates. Could have also been done with a dangling OP_RETURN, with the
associated restrictions on which sighashes you can use since you now have
to commit to multiple outputs(disallows SIGHASH_SINGLE).

There's also a fair exchange protocol that obviates the need for it using
signature adapters, but the requisite APIs don't exist yet, and doesn't
lend itself naturally to 3+ party scenarios.

> Depending on policy to mitigate this annex malleability vector could
mislead developers into believing their transactions are immune to
replacement, when in fact they might not be.

The issue I'm talking about is where someone's transaction is denied entry
into the mempool entirely because a counter-party decided to put in a
strictly worse transaction for miners by bloating the weight of it, not
adding fees. A strictly worse "API" for paying miners for no gain seems
like a bad trade to me, especially when there are reasonable methods for
mitigating this.

> It may thus be more prudent to permit the utilization of the annex
without restrictions, inform developers of its inherent risks, and
acknowledge that Bitcoin, in its present state, might not be ideally suited
for certain types of applications?

Mempool policy should be an attempt to bridge the gap between node anti-DoS
and an entity's ability to pay miners more via feerate-ordered queue. I
don't think the answer to this problem is to zero out all ability to limit
the sizes of multi-party, multi-input transactions for speculative use
cases.

Greg



On Sat, Jun 3, 2023 at 7:31 AM Joost Jager via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sat, Jun 3, 2023 at 9:49 AM Joost Jager  wrote:
>
>> The removal of the need for a commitment transaction also enables the
>> inclusion of data within a single transaction that relies on its own
>> transaction identifier (txid). This is possible because the txid
>> calculation does not incorporate the annex, where the data would be housed.
>> This feature can be beneficial in scenarios that require the emulation of
>> covenants through the use of presigned transactions involving an ephemeral
>> signer.
>>
>
> I think this avoidance of a circular reference is also why LN-Symmetry
> uses the annex?
>
> Joost
> ___
> 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] Standardisation of an unstructured taproot annex

[Greg Sanders via bitcoin-dev]

Hello Joost, David,

Thanks for the link to my ln-symmetry draft David. I'd also be curious as
to the usage you have in
mind Joost.

It's probably helpful to cite the most recent discussions on the topic,
which is probably
https://github.com/bitcoin-inquisition/bitcoin/pull/22 , where
bitcoin-inquisition has included
the `annexcarrier` option. I have a particular use for APO-enabled payment
channel designs
that doesn't require consensus meaning, so some effort was put in to try
something out there.

Attempting to summarize the linked PR:

I think the biggest remaining issue to this kind of idea, which is why I
didn't propose it for mainnet,
is the fact that BIP341/342 signature hashes do not cover *other* inputs'
annex fields, which we
briefly discussed here
https://github.com/bitcoin-inquisition/bitcoin/pull/22#discussion_r1143382264
.

This means that in a coinjoin like scenario, even if the other joining
parties prove they don't have any
crazy script paths, a malicious party can make the signed transaction into
a maximum sized transaction
package, causing griefing. The mitigation in the PR I linked was to limit
it to 126 bytes, basically punting
on the problem by making the grief vector small. Another solution could be
to make annex usage "opt-in"
by requiring all inputs to commit to an annex to be relay-standard. In this
case, you've opted into a possible
vector, but at least current usage patterns wouldn't be unduly affected.
For those who opt-in, perhaps the first
order of business would be to have a field that limits the total
transaction weight, by policy only?

Some logs related to that here:
https://gist.github.com/instagibbs/7406931d953fd96fea28f85be50fc7bb

Related discussion on possible BIP118 modifications to mitigate this in
tapscript-spending circumstances:
https://github.com/bitcoin-inquisition/bitcoin/issues/19

Anyways, curious to hear what people think and want to make sure everyone
is on the same page.

Best,
Greg

On Fri, Jun 2, 2023 at 9:08 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2023-06-02 05:00, Joost Jager via bitcoin-dev wrote:
> > the benefits of making the annex available in a
> > non-structured form are both evident and immediate. By allowing
> > developers to utilize the taproot annex without delay, we can take
> > advantage of its features today,
>
> Hi Joost,
>
> Out of curiosity, what features and benefits are available today?  I
> know Greg Sanders wants to use annex data with LN-Symmetry[1], but
> that's dependent on a soft fork of SIGHASH_ANYPREVOUT.  I also heard you
> mention that it could allow putting arbitrary data into a witness
> without having to commit to that data beforehand, but that would only
> increase the efficiency of witness stuffing like ordinal inscriptions by
> only 0.4% (~2 bytes saved per 520 bytes pushed) and it'd still be
> required to create an output in order to spend it.
>
> Is there some other way to use the annex today that would be beneficial
> to users of Bitcoin?
>
> -Dave
>
> [1]
>
> https://github.com/lightning/bolts/compare/master...instagibbs:bolts:eltoo_draft#diff-156a655274046c49e6b1c2a22546ed66366d3b8d97b8e9b34b45fe5bd8800ae2R119
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Transaction Relay over Nostr

[Greg Sanders via bitcoin-dev]

Hi Joost, David,

In my mind, weak blocks' main benefit would be that it improves block relay
by giving PoW-hints on what are in miner's mempools. Non-standard
transactions could even be cached(even if not validated until block
inclusion), which would tolerate more heterogeneity in policies without
drastically increasing relay times. Of course, it can also have the side
effect of gossiping better transaction packages, though I think this would
be a ton of work to really take advantage of. Perhaps we might be able to
do better in a post-cluster-mempool world, gossiping chunks.

At present I think energy would be best spent writing a weak blocks BIP
proposal, since one has never been written before(?), and it would be
fairly trivial to swap out p2p things with RPC calls if so desired for fast
experimentation over alternative relays.

Cheers,
Greg



On Tue, May 30, 2023 at 8:58 AM Joost Jager via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi David,
>
>
>> A block template is an ordered list of raw transactions that can all be
>> included in the next block (with some space reserved for a coinbase
>> transaction).  A full node can validate those transactions and calculate
>> how much fee they pay.  A Nostr relay can simply relay almost[1] any
>> template that pays more fees than the previous best template it saw for
>> the next block.  That can be more flexible than the current
>> implementation of submitblock with package relay which still enforces a
>> lot of the rules that helps keep a regular relay node safe from DoS and
>> a miner node able to select mineable transactions quickly.
>>
>
> Interesting idea! This would also make it easy for external services to
> try to do the best possible block building using advanced algorithms.
> Miners would just select the best template available from various sources
> including nostr.
>
>
>> A weak block is a block whose header doesn't quite hash to low enough of
>> a value to be included on the chain.  It still takes an extraordinary
>> amount of hashrate to produce, so it's inherently DoS resistant.  If
>> miners are producing block that include transactions not seen by typical
>> relay nodes, that can reduce the efficiency and effectiveness of BIP152
>> compact block relay, which hurts the profitability of miners of custom
>> blocks.  To compensate, miners could relay weak blocks through Nostr to
>> full nodes and other miners so that they could quickly relay and accept
>> complete blocks that later included the same custom transactions.  This
>> would also help fee estimation and provide valuable insights to those
>> trying to get their transactions included into the next block.
>>
>
> I believe this would be useful right away, wouldn't it? Looking at
> mempool.space's block audit, there are definitely blocks that have a
> "surprising" content and might take long to download.
>
> The anti-dos measures that you describe for both weak blocks and block
> templates seem very robust, but they would require a more intelligent nostr
> relay to enforce. Not sure if it is still allowed to call it nostr at that
> point. Perhaps it becomes more of a specialised bitcoin relay. btcstr -
> "bitcoin stuff transmitted by relays".
>
> Regarding size, the block template and weak block could both be sent in
>> BIP152 compact block format as a diff against the expected contents of a
>> typical node, allowing Alice to send just a small amount of additional
>> data for relay over what she'd have to send anyway for each transaction
>> in a package.  (Although it's quite possible that BetterHash or Stratum
>> v2 have even better solutions, possibly already implemented.)
>>
>
> Sounds like a great way to repurpose what already exists to reduce
> resource usage for these additional message types.
>
>
>> If nothing else, I think Nostr could provide an interesting playground
>> for experimenting with various relay and mining ideas we've talked about
>> for years, so thanks again for working on this!
>>
>
> I think so too! The main question on my mind though is how to actually
> make this work. There is a bit of a chicken-egg problem here with users and
> miners possibly waiting for each other to adopt.
>
> Joost
> ___
> 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] Package Relay Proposal

[Greg Sanders via bitcoin-dev]

Hi Tom,

Yesterday a PR was opened to do just that, with caveats:
https://github.com/bitcoin/bitcoin/pull/27609

For higher level tracking of the project:
https://github.com/bitcoin/bitcoin/issues/27463

Cheers,
Greg

On Wed, May 10, 2023 at 11:39 AM Tom Trevethan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The submitpackage RPC is available on regtest in the current core
> release. Is there any plan or timeline for deploying this on mainnet in the
> next release? Can't find any recent discussion. It would be very helpful
> given current (and likely future) issues with mempool purge.
>
> Tom
> ___
> 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] BIP for OP_VAULT

[Greg Sanders via bitcoin-dev]

Hi Luke,

I think this works as with OP_FLU based construct, for the simplest single
key case.

e.g., single key hot wallet(or MuSig2/FROST wallet)

 1 " OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKSIG"
OP_FORWARD_LEAF_UPDATE

The  is appended at spending time.

This allows the utxo to go to $recover cold storage at any point like
before, otherwise the time matures and the funds can be spent by a single
key. Rate-limiting like usual can be bolted on as well using OP_FORWARD_*
opcodes, I'm pretty sure. This would as you note require wallet support,
where the hot wallet would have to be aware of the vault, or be scanning
inputs looking for this type of leaf.

Unfortunately this doesn't extend to things like OP_CHECKSIGADD, since the
pubkeys are all pushed first, then the opcodes run. OP_CHECKMULTISIG would
have worked probably.

To generalize I think you'd need recursive taproot, or a proper replacement
for Bitcoin script :)

Cheers,
Greg

On Mon, Mar 13, 2023 at 4:55 PM Luke Dashjr  wrote:

> In ordinary use cases, you wouldn't clawback; that would only be in the
> extreme case of the wallet being compromised. So typical usage would just
> be receive -> send, like wallets currently do.
>
> Luke
>
>
> On 3/13/23 10:56, Greg Sanders wrote:
>
> Didn't finish sentence: but in practice would end up with pretty similar
> usage flows imho, and as noted in PR, would take a different wallet
> paradigm,
> among other technical challenges.
>
> On Mon, Mar 13, 2023 at 10:55 AM Greg Sanders 
> wrote:
>
>> Hi Luke,
>>
>> Can you elaborate why the current idealized functionality of deposit ->
>> trigger -> withdrawal is too complicated for
>> everyday use but the above deposit -> withdrawal ->
>> resolve(claim/clawback)  wouldn't be? I admit at a high level
>> it's a fine paradigm, but in practice would end
>>
>> Let's ignore implementation for the discussion, since that's in flux.
>>
>> Cheers,
>> Greg
>>
>> On Sat, Mar 11, 2023 at 3:53 PM Luke Dashjr via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> I started reviewing the BIP, but stopped part way through, as it seems
>>> to have a number of conceptual issues.
>>>
>>> I left several comments on the PR
>>> (https://github.com/bitcoin/bips/pull/1421#pullrequestreview-1335925575),
>>>
>>> but ultimately I think it isn't simplified enough for day-to-day use,
>>> and would harm privacy quite a bit.
>>>
>>> Instead, I would suggest a new approach where:
>>>
>>> 1) Joe receives funds with a taproot output like normal.
>>> 2) Joe sends funds to Fred, but Fred cannot spend them until N blocks
>>> later (covenant-enforced relative locktime). Ideally, this should
>>> use/support a taproot keypath spend somehow. It would be nice to blind
>>> the particular relative locktime somehow too, but that may be too
>>> expensive.
>>> 2b) If Joe's funds were stolen, Joe can spend Fred's UTXO within the N
>>> block window to a recovery output.
>>>
>>> Unfortunately, the implementation details for this kind of setup are
>>> non-obvious and will likely require yet another address format (or at
>>> least recipient-wallet changes), but certainly seems within the scope of
>>> possibility.
>>>
>>> Thoughts?
>>>
>>> Luke
>>>
>>>
>>> On 2/13/23 16:09, James O'Beirne via bitcoin-dev wrote:
>>> > Since the last related correspondence on this list [0], a number of
>>> > improvements have been made to the OP_VAULT draft [1]:
>>> >
>>> > * There is no longer a hard dependence on package relay/ephemeral
>>> >   anchors for fee management. When using "authorized recovery," all
>>> >   vault-related transactions can be bundled with unrelated inputs and
>>> >   outputs, facilitating fee management that is self contained to the
>>> >   transaction. Consequently, the contents of this proposal are in
>>> theory
>>> >   usable today.
>>> >
>>> > * Specific output locations are no longer hardcoded in any of the
>>> >   transaction validation algorithms. This means that the proposal is
>>> now
>>> >   compatible with future changes like SIGHASH_GROUP, and
>>> >   transaction shapes for vault operations are more flexible.
>>> >
>>> > ---
>>> >
>>> > I've written a BIP that fully describes the proposal here:
>>> >
>>> >
>>> https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawiki
>>> >
>>> > The corresponding PR is here:
>>> >
>>> > https://github.com/bitcoin/bips/pull/1421
>>> >
>>> > My next steps will be to try for a merge to the inquisition repo.
>>> >
>>> > Thanks to everyone who has participated so far, but especially to AJ
>>> and
>>> > Greg for all the advice.
>>> >
>>> > James
>>> >
>>> > [0]:
>>> >
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html
>>> > [1]: https://github.com/bitcoin/bitcoin/pull/26857
>>> >
>>> > ___
>>> > bitcoin-dev mailing list
>>> > bitcoin-dev@lists.linuxfoundation.org
>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> 

Re: [bitcoin-dev] BIP for OP_VAULT

[Greg Sanders via bitcoin-dev]

Hi Brandon,

Thank you for chiming in, causing me to think a bit more deeply on the
privacy issues
and what seems possible.

> I like that in James' current PR proposal we can explicitly batch via
the implied input/output summation rules while avoiding address reuse.
If we can retain some or all of that, I think it would be good for on
chain efficiency and potentially privacy.

Rotating trigger authorization keys maintains batchability and stops
address reuse.
Remember that anytime you share any path, like recovery path, for batching,
it becomes
obvious at spend-time. Rotating inner pubkeys only doesn't seem to help
much.

Coinjoins being the other batching scenario which could benefit perhaps are
quite a heavy
lift. You'd need the recovery policy(every other branch) to be agreed upon,
have everyone unvault
to this new joint vault, then mix, and withdrawal back to the original
vault. If someone is going through
all that effort, I suspect they'll just use a NUMS to reduce fingerprinting.

> Many inputs with different internal keys can be combined to satisfy the
total output value for a single output, as long as their scriptpubkeys
with FLU and NUMS internal key are equal This enables avoiding address
reuse within the vault.

To reiterate, we can just cycle any key in the $trigger branch with OP_FLU,
which accomplishes the same thing.
Or in authorization-less $trigger, add a random number which is dropped.

> Many inputs with the same scriptpubkey can be combined to satisfy a
single CTV output template. This allows a user to unfsck themselves if
they initiate a withdrawal that cannot be satisfied because they didn't
send enough sats to satisfy their template.

I think that would fit the deprecated OP_FORWARD_OUTPUTS, but OP_CTV
commits to total
number of inputs to remove txid malleability. I think the real solution to
this mistake would be to hit
the big red RECOVERY button that you're relying on for vault security
anyways.

Cheers,
Greg

On Mon, Mar 13, 2023 at 3:04 PM Brandon Black 
wrote:

> Hi Gents,
>
> > > I don't think replacing the internal-public-key makes sense -- if it
> > was immediately spendable via the keypath before there's no reason for
> > it not to be immediately spendable now.
> >
> > Slavishly following the current proposal was the idea to make sure all
> > functionality was captured; I agree with this change.
>
> I think we do need to replace the internal key with a hardcoded NUMS
> point to allow us to batch multiple vault inputs which might have
> different internal keys but the same OP_FLU/OP_VAULT_TRIGGER script to
> the same time+template-restricted output.
>
> I like that in James' current PR proposal we can explicitly batch via
> the implied input/output summation rules while avoiding address reuse.
> If we can retain some or all of that, I think it would be good for on
> chain efficiency and potentially privacy.
>
> My thoughts on batching:
>
> Many inputs with different internal keys can be combined to satisfy the
> total output value for a single output, as long as their scriptpubkeys
> with FLU and NUMS internal key are equal This enables avoiding address
> reuse within the vault.
>
> Many inputs with the same scriptpubkey can be combined to satisfy a
> single CTV output template. This allows a user to unfsck themselves if
> they initiate a withdrawal that cannot be satisfied because they didn't
> send enough sats to satisfy their template.
>
> Best,
>
> --Brandon
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning

[Greg Sanders via bitcoin-dev]

After getting neutral to negative feedback on the choice, I have switched
to OP_TRUE on the BIP and implementation.

Cheers,
Greg

On Sat, Feb 4, 2023 at 11:03 AM Peter Todd  wrote:

> On Fri, Feb 03, 2023 at 09:07:29PM -0500, Greg Sanders wrote:
> > I'm not particularly persuaded, but also not wedded to either idea.
> >
> > Fixed up tests for the OP_TRUE case here:
> > https://github.com/instagibbs/bitcoin/tree/ephemeral-anchors-true
>
> Thanks.
>
> Looking through that, I think a lot of those test cases don't actually
> need to
> be changed to OP_2, as they aren't trying to test anything related to
> standardness.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP for OP_VAULT

[Greg Sanders via bitcoin-dev]

Didn't finish sentence: but in practice would end up with pretty similar
usage flows imho, and as noted in PR, would take a different wallet
paradigm,
among other technical challenges.

On Mon, Mar 13, 2023 at 10:55 AM Greg Sanders  wrote:

> Hi Luke,
>
> Can you elaborate why the current idealized functionality of deposit ->
> trigger -> withdrawal is too complicated for
> everyday use but the above deposit -> withdrawal ->
> resolve(claim/clawback)  wouldn't be? I admit at a high level
> it's a fine paradigm, but in practice would end
>
> Let's ignore implementation for the discussion, since that's in flux.
>
> Cheers,
> Greg
>
> On Sat, Mar 11, 2023 at 3:53 PM Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I started reviewing the BIP, but stopped part way through, as it seems
>> to have a number of conceptual issues.
>>
>> I left several comments on the PR
>> (https://github.com/bitcoin/bips/pull/1421#pullrequestreview-1335925575),
>>
>> but ultimately I think it isn't simplified enough for day-to-day use,
>> and would harm privacy quite a bit.
>>
>> Instead, I would suggest a new approach where:
>>
>> 1) Joe receives funds with a taproot output like normal.
>> 2) Joe sends funds to Fred, but Fred cannot spend them until N blocks
>> later (covenant-enforced relative locktime). Ideally, this should
>> use/support a taproot keypath spend somehow. It would be nice to blind
>> the particular relative locktime somehow too, but that may be too
>> expensive.
>> 2b) If Joe's funds were stolen, Joe can spend Fred's UTXO within the N
>> block window to a recovery output.
>>
>> Unfortunately, the implementation details for this kind of setup are
>> non-obvious and will likely require yet another address format (or at
>> least recipient-wallet changes), but certainly seems within the scope of
>> possibility.
>>
>> Thoughts?
>>
>> Luke
>>
>>
>> On 2/13/23 16:09, James O'Beirne via bitcoin-dev wrote:
>> > Since the last related correspondence on this list [0], a number of
>> > improvements have been made to the OP_VAULT draft [1]:
>> >
>> > * There is no longer a hard dependence on package relay/ephemeral
>> >   anchors for fee management. When using "authorized recovery," all
>> >   vault-related transactions can be bundled with unrelated inputs and
>> >   outputs, facilitating fee management that is self contained to the
>> >   transaction. Consequently, the contents of this proposal are in theory
>> >   usable today.
>> >
>> > * Specific output locations are no longer hardcoded in any of the
>> >   transaction validation algorithms. This means that the proposal is now
>> >   compatible with future changes like SIGHASH_GROUP, and
>> >   transaction shapes for vault operations are more flexible.
>> >
>> > ---
>> >
>> > I've written a BIP that fully describes the proposal here:
>> >
>> >
>> https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawiki
>> >
>> > The corresponding PR is here:
>> >
>> > https://github.com/bitcoin/bips/pull/1421
>> >
>> > My next steps will be to try for a merge to the inquisition repo.
>> >
>> > Thanks to everyone who has participated so far, but especially to AJ and
>> > Greg for all the advice.
>> >
>> > James
>> >
>> > [0]:
>> >
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html
>> > [1]: https://github.com/bitcoin/bitcoin/pull/26857
>> >
>> > ___
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP for OP_VAULT

[Greg Sanders via bitcoin-dev]

Hi Luke,

Can you elaborate why the current idealized functionality of deposit ->
trigger -> withdrawal is too complicated for
everyday use but the above deposit -> withdrawal ->
resolve(claim/clawback)  wouldn't be? I admit at a high level
it's a fine paradigm, but in practice would end

Let's ignore implementation for the discussion, since that's in flux.

Cheers,
Greg

On Sat, Mar 11, 2023 at 3:53 PM Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I started reviewing the BIP, but stopped part way through, as it seems
> to have a number of conceptual issues.
>
> I left several comments on the PR
> (https://github.com/bitcoin/bips/pull/1421#pullrequestreview-1335925575),
> but ultimately I think it isn't simplified enough for day-to-day use,
> and would harm privacy quite a bit.
>
> Instead, I would suggest a new approach where:
>
> 1) Joe receives funds with a taproot output like normal.
> 2) Joe sends funds to Fred, but Fred cannot spend them until N blocks
> later (covenant-enforced relative locktime). Ideally, this should
> use/support a taproot keypath spend somehow. It would be nice to blind
> the particular relative locktime somehow too, but that may be too
> expensive.
> 2b) If Joe's funds were stolen, Joe can spend Fred's UTXO within the N
> block window to a recovery output.
>
> Unfortunately, the implementation details for this kind of setup are
> non-obvious and will likely require yet another address format (or at
> least recipient-wallet changes), but certainly seems within the scope of
> possibility.
>
> Thoughts?
>
> Luke
>
>
> On 2/13/23 16:09, James O'Beirne via bitcoin-dev wrote:
> > Since the last related correspondence on this list [0], a number of
> > improvements have been made to the OP_VAULT draft [1]:
> >
> > * There is no longer a hard dependence on package relay/ephemeral
> >   anchors for fee management. When using "authorized recovery," all
> >   vault-related transactions can be bundled with unrelated inputs and
> >   outputs, facilitating fee management that is self contained to the
> >   transaction. Consequently, the contents of this proposal are in theory
> >   usable today.
> >
> > * Specific output locations are no longer hardcoded in any of the
> >   transaction validation algorithms. This means that the proposal is now
> >   compatible with future changes like SIGHASH_GROUP, and
> >   transaction shapes for vault operations are more flexible.
> >
> > ---
> >
> > I've written a BIP that fully describes the proposal here:
> >
> >
> https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawiki
> >
> > The corresponding PR is here:
> >
> > https://github.com/bitcoin/bips/pull/1421
> >
> > My next steps will be to try for a merge to the inquisition repo.
> >
> > Thanks to everyone who has participated so far, but especially to AJ and
> > Greg for all the advice.
> >
> > James
> >
> > [0]:
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html
> > [1]: https://github.com/bitcoin/bitcoin/pull/26857
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP for OP_VAULT

[Greg Sanders via bitcoin-dev]

AJ,

Interesting stuff! Just a couple thoughts on these proposed opcodes, at
least one we discussed elsewhere:

1) OP_FORWARD_SELF is a JET of OP_FLU in the revaulting common case. Maybe
obvious but I missed this initially and thought it was useful to be pointed
out.

2)  Using these extended primitives, you can do rate-limiting of the two
step unvaulting, or just a single step vault by committing to the partial
values. For the single stage case it's something like:

$recovery = Same As Before

$withdrawal =  OP_CSV OP_DROP  OP_CHECKSIG OP_DUP
 OP_LESSTHANOREQUAL OP_VERIFY OP_FORWARD_PARTIAL OP_FORWARD_TARGET
OP_FORWARD_SELF

$withdrawal is spent by:

   <0<=v<=V> 

where "V"  is the max allowed withdrawal value, and "deposit-delay" the
required gap in withdrawals

Due to the OP_LEQ, you are bound to ~21 BTC in value for this operation,
but for larger vaults it's pretty trivial to add larder fixed denominations
to "peel out" value until you get to your final ~21 BTC.

This rate-limiting(in either the two-stage or one-stage scheme) can limit
the risk of theft during a watchtower outage to a constant value per utxo
per time period of watchtower failure. As we've seen in the past with LN
infrastructure, software risks are often correlated, so it's a good idea to
build in belt and suspenders where we can or at least have them available
when possible.

Cheers,
Greg


On Tue, Mar 7, 2023 at 7:45 AM Anthony Towns  wrote:

> On Mon, Mar 06, 2023 at 10:25:38AM -0500, James O'Beirne via bitcoin-dev
> wrote:
> > What Greg is proposing above is to in essence TLUV-ify this proposal.
>
> FWIW, the way I'm thinking about this is that the "OP_VAULT" concept is
> introducing two things:
>
>  a) the concept of "forwarding" the input amount to specified
> outputs in a way that elegantly allows merging/splitting
>
>  b) various restrictions on the form of the output scripts
>
> These concepts go together well, because restricting an output script is
> only an interesting thing to do if you're moving value from this input
> into it. And then it's just a matter of figuring out a nice way to pick
> opcodes that combine those two concepts in interesting ways.
>
> This is different from TLUV, in that TLUV only did part (b), and
> assumed you'd do part (a) manually somehow, eg via "OP_IN_OUT_AMOUNT"
> and arithmetic opcodes. The advantage of this new approach over that
> one is that it makes it really easy to get the logic right (I often
> forgot to include the IN_OUT_AMOUNT checks at all, for instance), and
> also makes spending multiple inputs to a single output really simple,
> something that would otherwise require kind-of gnarly logic.
>
> I think there are perhaps four opcodes that are interesting in this class:
>
>idx sPK OP_FORWARD_TARGET
>  -- sends the value to a particular output (given by idx), and
> requires that output have a particular scriptPubKey (given
> by sPK).
>
>idx [...] n script OP_FORWARD_LEAF_UPDATE
>  -- sends the value to a particular output (given by idx), and
> requires that output to have almost the same scriptPubKey as this
> input, _except_ that the current leaf is replaced by "script",
> with that script prefixed by "n" pushes (of values given by [...])
>
>idx OP_FORWARD_SELF
>  -- sends the value to a particular output (given by idx), and
> requires that output to have the same scriptPubKey as this input
>
>amt OP_FORWARD_PARTIAL
>  -- modifies the next OP_FORWARD_* opcode to only affect "amt",
> rather than the entire balance. opcodes after that affect the
> remaining balance, after "amt" has been subtracted. if "amt" is
> 0, the next OP_FORWARD_* becomes a no-op.
>
> Then each time you see OP_FORWARD_TARGET or OP_FORWARD_LEAF_UPDATE, you
> accumulate the value that's expected to be forwarded to the output by
> each input, and verify that the amount for that output is greater-or-equal
> to the accumulated value.
>
> > ## Required opcodes
> > - OP_VAULT: spent to trigger withdrawal
> > - OP_VAULT_RECOVER: spent to recover
>
> Naming here is OP_VAULT ~= OP_FORWARD_LEAF_UPDATE; OP_VAULT_RECOVER ~=
> OP_FORWARD_TARGET.
>
> > For each vault, vaulted coins are spent to an output with the taproot
> > structure
> >
> >   taproot(internal_key, {$recovery_leaf, $trigger_leaf, ...})
> >
> > where
> >
> >   $trigger_leaf =
> >   

Re: [bitcoin-dev] BIP for OP_VAULT

[Greg Sanders via bitcoin-dev]

Hi James,

I think everything except the hinted "withdrawal authorization" is spot on.

For withdrawal authorization, I think we'll have to go deeper into the TLUV
direction
as AJ suggested for at least a couple reasons:

1) You need the withdrawal authorization committed at deposit time
2) You need to make sure cheeky opcodes cannot be prepended to the script
at spend time

OP_FORWARD_LEAF_UPDATE(OP_FLU) seems to fit the bill, at the cost of maybe
adding another opcode for "refunds" as he notes.

Cheers,
Greg

On Mon, Mar 6, 2023 at 10:25 AM James O'Beirne 
wrote:

> I'm glad to see that Greg and AJ are forming a habit of hammering
> this proposal into shape. Nice work fellas.
>
> To summarize:
>
> What Greg is proposing above is to in essence TLUV-ify this proposal.
>
> I.e. instead of relying on hashed commitments and recursive script
> execution (e.g.  + later presentation of preimage
> script for execution), OP_VAULT would instead move through its
> withdrawal process by swapping out tapleaf contents according to
> specialized rules. If this is opaque (as it was to me), don't fret -
> I'll describe it below in the "mechanics" section.
>
>
> The benefits of this TLUVification are
>
> - we can avoid any nested/recursive script execution. I know the
>   recursive stuff rankles some greybeards even in spite of it being
>   bounded to a single call. I'm not sure I share the concern but
>   maintaining the status quo seems good.
>
> - the spec is easier to reason about, more or less. The opcodes
>   introduced don't have variadic witness requirements, and each opcode
>   is only consumed in a single way.
>
> - there's less general indirection. Instead of saying "okay, here's the
>   hash of the script I'm going to use to authorize trigger
>   transactions," we're just outright including the trigger auth script
>   in the tapleaf at the birth of the vault as regular 'ol script that is
>   evaluated before execution of the OP_VAULT instruction.
>
>   Similarly, instead of relying on an implicit rule that an OP_VAULT can
>   be claimed by a recovery flow, we're relying on a specific tapleaf that
>   facilitates that recovery with OP_VAULT_RECOVER, described below.
>
> Basically, OP_VAULT would just be implemented in a way that feels
> more native to Taproot primitives.
>
> Greg also introduces different opcodes to facilitate consistent
> witness structure, rather than the variable ones we have now
> since OP_VAULT and OP_UNVAULT can each be spent in two different
> contexts. I've changed those a little here; instead of the three general
> ones Greg gave, we whittled it down to two: OP_VAULT and
> OP_VAULT_RECOVER.
>
>
> So I think that, barring significant implementation complexity - which
> I'll find out about soon and don't expect - this is a good change to the
> proposal. As Greg noted, it doesn't really change anything about the
> usage or expressiveness... other than the fact that, as a bonus, it
> might allow an optional withdrawal authorization script (i.e. trigger
> output => final target), which could be useful if e.g. some kind of
> size-limiting opcode (e.g. OP_TX_MAXSIZE or something) came around in
> the future as a kind of pinning fix.
>
> If that last bit lost you, don't worry - that is speculative, but the
> point is that this rework composes well with other stuff.
>
>
> # CTV use
>
> Another thing that has dawned on us is that we might as well just reuse
> OP_CHECKTEMPLATEVERIFY for withdrawal target spends. Ben Carmen and
> others realized early on that you can synthesize CTV-like behavior by
> spending to a 0-delay OP_UNVAULT output, so something CTVish has always
> implicitly been a part of the proposal. But CTV is better studied and
> basically as simple as the OP_UNVAULT spend semantics, so the thought is
> that we might as well reuse all the existing work (and scrutiny) from
> CTV.
>
> As a concrete example, an issue with the existing proposal is that the
> existing CTVish OP_UNVAULT behavior has txid malleability, since it
> doesn't commit to nVersion or nLockTime or the input sequences. Using
> CTV solves this issue. Otherwise we'd basically reinvent it - "something
> something convergent evolution."
>
> I think this is a satisfying development, because there's clearly demand
> for CTV use in other contexts (DLC efficiency, e.g.), and if it's
> required behavior for practical vaults, I think pulling in the existing
> BIP-119 that's been worked over for years reduces the conceptual
> surface area added by OP_VAULT.
>
>
> # New mechanics of the proposal
>
> So here I'm going to describe my rendering of Greg and AJ's suggestions.
>
>
> ## Required opcodes
>
> - OP_VAULT: spent to trigger withdrawal
> - OP_VAULT_RECOVER: spent to recover
> - OP_CHECKTEMPLATEVERIFY: spent into final withdrawal target
>
>
> Creating an initial deposit
> ---
>
> For each vault, vaulted coins are spent to an output with the taproot
> structure
>
>   taproot(internal_key, 

Re: [bitcoin-dev] BIP for OP_VAULT

[Greg Sanders via bitcoin-dev]

Greetings AJ,

Glad I could resurrect the idea!

> Then instead of `idx hash delay OP_TRIGGER_FORWARD` you
write `idx hash delay 2 "OP_CSV OP_DROP OP_FORWARD_OUTPUTS"
OP_FORWARD_LEAF_UPDATE`

Interesting idea! (I'll let you be the one to scope creep the proposal :) )

To be pedantic, EXPR_TRIGGER would become:

<2>  OP_FORWARD_LEAF_UPDATE

and at spend time the idx and hash are put into the witness stack.

To be clear,  could be embedded in the 

Re: [bitcoin-dev] BIP for OP_VAULT

[Greg Sanders via bitcoin-dev]

Hello James,

First off, thank you for crafting an interesting idea like this that is
aimed at solving a serious problem. I see a lot of excitement about the use
cases, and I think it's worth iterating on.

Attempting to keep the idealized functionality constant, I'd like to
explore a design detour. I'm attempting to decouple the 3 functionalities
of `OP_VAULT` and `OP_UNVAULT` into their constituent functions with names
I just made up.

The goals of this e-mail:

1) Removing variable number of arguments based on values of arguments for
the opcodes.
To me as a spec reader, I find it very difficult to parse what's precisely
happening when. I think the only/last opcode to support this behavior was
OP_CHECKMULTISIG(could be wrong), and now I know another reason why OP_CSA
construct is nicer going forward with taproot.

2) Remove the recursive evaluation functionality used for authentication,
without reducing the efficacy of the targeted solution. Recursive
evaluation has a fraught history in Bitcoin script, makes composing
functionality with tooling likely more difficult, and has a lot of
templated behavior. If we can rely on regular old tapscript to get us where
we need to go, I'd prefer that.

3) Increase legibility of the spec. There's a ton going on, breaking things
up and naming them based on the method rather than the goal may help here.

4) Not (greatly) increase the expressiveness of the proposal. It's a
targeted proposal, and I'd like to respect that. These covenant opcodes are
intended to be drop-in replacements for the OP_(UN)VAULT opcodes.

To recap, there are three things happen in idealized OP_VAULT scenario:
1) Money comes out, then has to wait (trigger transaction)
2) Money waits long enough, then withdrawals to dynamic set of outputs that
are declared at trigger time (withdrawal transaction)
3) Money to single specified output script picked up front, with no wait
(recovery)

Below is a sketch of a replacement for the two opcodes. Ignore my
inconsistency on VERIFY/non-VERIFY behavior, seeing if people agree with
this general direction:

`OP_TRIGGER_FORWARD`: Takes exactly three arguments:
1) output index to match against (provided at spend time normally)
2) target-outputs-hash: 32 byte hash to be forwarded to output given at (1)
(provided at spend time normally)
3) spend-delay: value to be forwarded to output given at (1)

Fails script immediately if there aren't enough inputs or they're the wrong
format.

These last two arguments are "forwarded" to output at index declared in
first argument, resulting in:

`EXPR_WITHDRAW:  OP_CHECKSEQUENCEVERIFY OP_DROP
 OP_FORWARD_OUTPUTS`

As the derived tapscript, embedded in a output scriptpubkey of the form:
`tr(NUMS,{...,EXPR_WITHDRAW})`, meaning we literally take the control block
from the spending input, swap the inner pubkey for `NUMS`, use
`EXPR_WITHDRAW` as the tapleaf, reconstruct the merkle root. If the output
scriptpubkey doesnt match, fail.

This TLUV-ish script/inner pubkey replacement is meant to allow arbitrary
other conditions, which is where the "recovery" path comes in for typical
usage.

If output at the target output index doesn't match the constructed script,
the evaluation fails.

`OP_FORWARD_DESTINATION`: Takes exactly two arguments:
1) `dest-vout-idx`: index of output that contains the so-called "recovery"
path
2) : the hash of the script destination

Fails immediately if the reconstructed output script doesn't match.

`OP_FORWARD_OUTPUTS` takes exactly one argument:
1) target-outputs-hash: commits to all outputs' scripts and values

Fails immediately if transaction's outputs(including value) hash doesn't
match.

**Typical usage**:
```
DEPOSITING TO VAULT SCRIPT:

EXPR_RECOVERY:   OP_FORWARD_DESTINATION
EXPR_TRIGGER: OP_TRIGGER_FORWARD

tr(KEY, {EXPR_RECOVERY, EXPR_TRIGGER})
```

```
EXPR_WITHDRAW:  OP_CHECKSEQUENCEVERIFY OP_DROP
 OP_FORWARD_OUTPUTS
```

```
TRIGGERING WITHDRAWAL TIMER SCRIPT:

tr(NUMS, {EXPR_RECOVERY,EXPR_WITHDRAW}) <--- note EXPR_RECOVERY is forced
by the OP_TRIGGER_FORWARD TLUV action
```

Could save 2 WU having OP_FORWARD_OUTPUTS take the  directly
as an argument, or keep it more general as I did.

Would love to know what you and others think about this direction. I
apologies for any misunderstandings I have about the current OP_VAULT BIP!

Cheers,
Greg

On Mon, Feb 13, 2023 at 4:09 PM James O'Beirne via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Since the last related correspondence on this list [0], a number of
> improvements have been made to the OP_VAULT draft [1]:
>
> * There is no longer a hard dependence on package relay/ephemeral
>   anchors for fee management. When using "authorized recovery," all
>   vault-related transactions can be bundled with unrelated inputs and
>   outputs, facilitating fee management that is self contained to the
>   transaction. Consequently, the contents of this proposal are in theory
>   usable today.
>
> * Specific output locations are no 

Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning

[Greg Sanders via bitcoin-dev]

I'm not particularly persuaded, but also not wedded to either idea.

Fixed up tests for the OP_TRUE case here:
https://github.com/instagibbs/bitcoin/tree/ephemeral-anchors-true

On Fri, Feb 3, 2023 at 5:10 PM Peter Todd  wrote:

> On Thu, Feb 02, 2023 at 03:47:28PM -0500, Greg Sanders wrote:
> > > OP_TRUE is the obvious way to do this, and it results with a 1 on the
> > stack,
> > which plays better with other standardness rules.
> >
> > What other standardness rules? MINAMALIF? How does that interact with the
> > proposal?
>
> It makes sense to require scripts to leave just a single OP_TRUE on the
> stack
> at the end of execution, as otherwise that can be a source of malleability
> in
> certain circumstances where the scriptSig ends up providing the OP_TRUE. I
> don't believe we actually implement this as a rule right now. But you could
> easily imagine that happening in a future upgrade.
>
> Leaving an OP_2 on the stack doesn't achieve that and would require a
> special-cased workaround. Spending the time now to do the obvious thing -
> use
> OP_TRUE as the canonical anyone-can-spend output - avoids this issue.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning

[Greg Sanders via bitcoin-dev]

> OP_TRUE is the obvious way to do this, and it results with a 1 on the
stack,
which plays better with other standardness rules.

What other standardness rules? MINAMALIF? How does that interact with the
proposal?

On Thu, Feb 2, 2023 at 3:22 PM Peter Todd  wrote:

> On Thu, Feb 02, 2023 at 01:36:24PM -0500, Greg Sanders wrote:
> > Quickly checked, it fails a number of standardness tests in
> unit/functional
> > tests in Bitcoin Core, at least.
> >
> > OP_2 was actually Luke Jr's idea circa 2017 for about the same reasons, I
> > just independently arrived at the same conclusion.
>
> Well, frankly I really don't like the idea of using OP_2 just to avoid
> changing
> some unit tests. We're doing something that many people will use for years
> to
> come, that's unnecessarily obscure just because we don't want to spend a
> bit of
> some modifying some tests to pass.
>
> OP_TRUE is the obvious way to do this, and it results with a 1 on the
> stack,
> which plays better with other standardness rules. OP_2 means we *also* may
> need
> to special case having a 2 on the stack in certain implementations of other
> standardness rules.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning

[Greg Sanders via bitcoin-dev]

Quickly checked, it fails a number of standardness tests in unit/functional
tests in Bitcoin Core, at least.

OP_2 was actually Luke Jr's idea circa 2017 for about the same reasons, I
just independently arrived at the same conclusion.

On Thu, Feb 2, 2023 at 10:06 AM Peter Todd  wrote:

> On Thu, Feb 02, 2023 at 09:59:09AM -0500, Greg Sanders wrote:
> > Hi Peter,
> >
> > For the most principled of reasons:
> >
> > Because I have to change test vectors everywhere!
>
> Specifically, you mean you'd have to change tests that test something is
> non-standard?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning

[Greg Sanders via bitcoin-dev]

Hi Peter,

For the most principled of reasons:

Because I have to change test vectors everywhere!

Greg

On Thu, Feb 2, 2023 at 9:52 AM Peter Todd  wrote:

> On Fri, Jan 27, 2023 at 09:05:20AM -0500, Greg Sanders via bitcoin-dev
> wrote:
> > Hello again dev,
> >
> > Due to the interest in the proposal and the prodding of certain folks,
> I've
> > written up a short draft BIP of the Ephemeral Anchors idea here:
> >
> https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki
> >
> > The pull request at https://github.com/bitcoin/bitcoin/pull/26403 has
> been
> > refreshed on top of the latest V3 proposal, but the BIP itself is
> > unaffected.
>
> The BIP states that:
>
> Why OP_2 not OP_TRUE? OP_TRUE is often used in test vectors, using
> OP_2 has
> the same benefits and none of these common collisions.
>
> Why is a "collision" harmful in this case?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Reference example bech32m address for future segwit versions

[Greg Sanders via bitcoin-dev]

David,

I'm merely speaking in a descriptive sense. I predict that most custodians
are reluctant to whitelist
a witness version they know is insecure.

I'm not sure what's best for not colliding with future versions, I'll let
other wiser folks weigh in.

Cheers,
Greg

On Tue, Jan 31, 2023 at 6:33 PM David A. Harding  wrote:

> On 2023-01-31 04:30, Greg Sanders wrote:
> > Hi David,
> >
> > From practical experience, I think you'll find that most exchanges
> > will not enable sends to future segwit versions,
> > as from a risk perspective it's likely a mistake to send funds there.
>
> Hi Greg!,
>
> I thought the best practice[1] was that wallets would spend to the
> output indicated by any valid bech32m address.  You seem to implying
> that the best practice is the opposite: that wallets should only send to
> outputs they know can be secured (i.e., which are not currently
> anyone-can-spend).  The more restrictive approach seems kind of sad to
> me since any problem which can result in a user accidentally withdrawing
> to a future segwit version could even more easily result in them
> withdrawing to a witness program for which there is no solution (i.e.,
> no key or script is known to spend).
>
> If it is a best practice, then I think there's a benefit to being able
> to test it even when other people's proprietary software is involved.  A
> wallet or service likely to follow that best practice may be more likely
> to follow other best practices which cannot be as easily tested for.
> But, if it's going to be tested, I want the testing to use the address
> least likely to cause problems for protocol developers in the future.
> Do you (and others on this list) have any reason to believe OP_16
> OP_PUSH2  would be a problematic script, or can you think of a
> better script?
>
> Thanks!,
>
> -Dave
>
> [1] BIP350, emphasis in original: "[...] we emphatically recommend [...]
> ensuring that your implementation supports sending to v1 **and higher
> versions.**"
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Reference example bech32m address for future segwit versions

[Greg Sanders via bitcoin-dev]

Hi David,

>From practical experience, I think you'll find that most exchanges will not
enable sends to future segwit versions,
as from a risk perspective it's likely a mistake to send funds there. That
said, as long as we don't change
the checksum again(!), updating to new versions should be fairly straight
forward. Every update will be a matter
of allowing a new version and a new length instead of requiring
library updates. Making sure the most popular
open source libraries support it is probably the best way to spend energy
ensuring that future upgrades go smoothly.

Best,
Greg

On Mon, Jan 30, 2023 at 8:25 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi y'all!,
>
> One of the benefits proposed for bech32 (and, by extension, bech32m) is
> that spender wallets shouldn't need to be upgraded to pay segwit outputs
> defined in future soft forks.  For example, Bitcoin Core today can pay a
> bech32m address for a segwit v2 output, even though no meaning has been
> assigned to output scripts matching a segwit v2 template.
>
> However, testing this behavior in production[1] can create an annoyance
> for developers of future soft forks.  They will need to deal with any
> existing outputs paid to the templates used in that proposed soft fork.
> See, for example, some discussion by developer 0xB10C about payments to
> segwit v1 addresses before activation of the taproot soft fork:
> https://b10c.me/blog/007-spending-p2tr-pre-activation/
>
> I was wondering if it would be useful to have a canonical examples of
> future segwit addresses that are designed to be very unlikely to
> interfere with future soft forks but which would still reasonably
> exercise wallets supporting bech32m.  I think of this as the rough
> equivalent of the RFC2606 domain "example.com" which has been reserved
> for examples in documentation.
>
> Specifically, I'm thinking of the following addresses, one each for
> mainnet and testnet:
>
> - HRP: bc for mainnet; tb for testent
> - Witness version: 16 (the last segwit version)
> - Witness program: 0x.  Two bytes is the minimum allowed
>by BIP141, but it's far too small to make any sort of secure
> commitment,
>so I'm hoping it won't conflict with any future use
>
> I think we should try to start with just one reserved address per
> network, but if that isn't enough, I think we could allow any two-byte
> witness program with witness version 16.
>
> Outputs paid to reserved addresses will still be anyone-can-spend, so
> there's no change required to Bitcoin Core or other software and those
> outputs can still be cleaned out of the UTXO set.  Additionally, if we
> ever *really* need that address space for a soft fork, it will be
> available.
>
> Are there any objections to this idea, or suggestions for a better way
> to go about it?
>
> Thanks!,
>
> -Dave
>
> [1] Testing in production should be avoided because it uses block space
> that could otherwise be used by actual value transfers.  Also, it costs
> money and pollutes the UTXO set (at least temporarily).  However, when
> testing whether proprietary third-party software, such as an exchange,
> supports payments to future segwit versions, sometimes the only
> convenient method is to actually pay the address for a future segwit
> version.  Additionally, my specific use case is just to write
> documentation
> about bech32m---but I worry that people will pay my example of a future
> segwit
> version address.
> ___
> 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] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning

[Greg Sanders via bitcoin-dev]

Hello again dev,

Due to the interest in the proposal and the prodding of certain folks, I've
written up a short draft BIP of the Ephemeral Anchors idea here:
https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki

The pull request at https://github.com/bitcoin/bitcoin/pull/26403 has been
refreshed on top of the latest V3 proposal, but the BIP itself is
unaffected.

Cheers,
Greg

On Wed, Nov 30, 2022 at 10:32 AM Greg Sanders  wrote:

> Small update.
>
> A bit ago I went ahead and implemented ephemeral anchors on top of the V3
> proposal to see what the complexity looks like:
> https://github.com/bitcoin/bitcoin/pull/26403
>
> Roughly 130 loc excluding tests, using OP_2 instead of OP_TRUE to not camp
> the value that is used elsewhere.
>
> Please let me know if you have any early feedback on this!
>
> Greg
>
> On Thu, Oct 20, 2022 at 9:42 AM Greg Sanders  wrote:
>
>> So it doesn't look like I'm ignoring a good question:
>>
>> No solid noninteractive ideas, unless we get some very flexible sighash
>> softfork. Interactively, I think you can get collaborative fee bumps under
>> the current consensus regime and ephemeral anchors. The child will just be
>> built with inputs from different people.
>>
>> On Wed, Oct 19, 2022 at 11:12 AM James O'Beirne 
>> wrote:
>>
>>> I'm also very happy to see this proposal, since it gets us closer to
>>> having a mechanism that allows the contribution to feerate in an
>>> "unauthenticated" way, which seems to be a very helpful feature for vaults
>>> and other contracting protocols.
>>>
>>> One possible advantage of the sponsors interface -- and I'm curious for
>>> your input here Greg -- is that with sponsors, assuming we relaxed the "one
>>> sponsor per sponsoree" constraint, multiple uncoordinated parties can
>>> collaboratively bump a tx's feerate. A simple example would be a batch
>>> withdrawal from an exchange could be created with a low feerate, and then
>>> multiple users with a vested interest of expedited confirmation could all
>>> "chip in" to raise the feerate with multiple sponsor transactions.
>>>
>>> Having a single ephemeral output seems to create a situation where a
>>> single UTXO has to shoulder the burden of CPFPing a package. Is there some
>>> way we could (possibly later) amend the ephemeral anchor interface to allow
>>> for this kind of collaborative sponsoring? Could you maybe see "chained"
>>> ephemeral anchors that would allow this?
>>>
>>>
>>> On Tue, Oct 18, 2022 at 12:52 PM Jeremy Rubin via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> Excellent proposal and I agree it does capture much of the spirit of
>>>> sponsors w.r.t. how they might be used for V3 protocols.
>>>>
>>>> The only drawbacks I see is they don't work for lower tx version
>>>> contracts, so there's still something to be desired there, and that the
>>>> requirement to sweep the output must be incentive compatible for the miner,
>>>> or else they won't enforce it (pass the buck onto the future bitcoiners).
>>>> The Ephemeral UTXO concept can be a consensus rule (see
>>>> https://rubin.io/public/pdfs/multi-txn-contracts.pdf "Intermediate
>>>> UTXO") we add later on in lieu of managing them by incentive, so maybe it's
>>>> a cleanup one can punt.
>>>>
>>>> One question I have is if V3 is designed for lightning, and this is
>>>> designed for lightning, is there any sense in requiring these outputs for
>>>> v3? That might help with e.g. anonymity set, as well as potentially keep
>>>> the v3 surface smaller.
>>>>
>>>> On Tue, Oct 18, 2022 at 11:51 AM Greg Sanders via bitcoin-dev <
>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>>> > does that effectively mark output B as unspendable once the child
>>>>> gets confirmed?
>>>>>
>>>>> Not at all. It's a normal spend like before, since the parent has been
>>>>> confirmed. It's completely unrestricted, not being bound to any
>>>>> V3/ephemeral anchor restrictions on size, version, etc.
>>>>>
>>>>> On Tue, Oct 18, 2022 at 11:47 AM Arik Sosman via bitcoin-dev <
>>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>>
>>>>>> Hi Greg,
>>>>>>
>>>>>> Thank you very m

Re: [bitcoin-dev] OP_VAULT: a new vault proposal

[Greg Sanders via bitcoin-dev]

Hi James and co,

Currently there is no way to make this compatible with scripthashes of any
kind, since the script interpreter has no insight into the OP_UNVAULT
outputs' "execution script", and one of the arguments of OP_UNVAULT is
freeform, resulting in an unpredictable output scriptpubkey.

I think the fix is just requiring a single additional witness data item
during OP_VAULT spend(for unvault path), mandating the
 to be included in the witness stack as an input to
OP_VAULT opcode, and transaction introspection then checks to make sure the
witness item and the corresponding output script template matches the
expected.

This would only be necessary for the unvaulting path, and not for the
recovery path.

Cheers,
Greg

On Mon, Jan 9, 2023 at 2:10 PM rot13maxi via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hey James,
>
> Really cool proposal. I’ve been thinking a lot lately about script paths
> for inheritance. In a lot of the “have a relative time lock that allows a
> different key to spend coins, or allows a smaller threshold of a multisig
> to spend” schemes, you have the problem of needing to “refresh” all of your
> coins when the timelock is close to maturation. In a lot of the “use
> multisig with ephemeral keys to emulate covenants” schemes, you have to
> pre-commit to the terminal destination well in advance of the spend-path
> being used, which leads to all kinds of thorny questions about security and
> availability of *those* keys. In other words, you either have to have
> unbound destinations but a timer that needs resetting, or you have unbound
> time but fixed destinations. This design gets you the best of both because
> the destination SPKs aren’t committed to until the unvaulting process
> starts. This (or something like this with destination binding at
> unvault-time) would be an incredibly useful tool for inheritance designs in
> wallets.
>
> I need to think a bit more about the recovery path not having any real
> encumbrances on it. Maybe in practice if you’re worried about DoS, you have
> UTXOs that commit to multiple vault paths that have tweaked recovery
> destinations or something, or maybe it really is the right move to say that
> if recovery is triggered, you probably do want it for all of your inflight
> unvaultings.
>
> Looking forward to reading this a few more times and talking more about
> it.
>
> Thanks!
> rijndael
>
>
> On Mon, Jan 9, 2023 at 11:07 AM, James O'Beirne via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> For the last few years, I've been interested in vaults as a way to
> substantially derisk custodying Bitcoin, both at personal and commercial
> scales. Instead of abating with familiarity, as enthusiasm sometimes
> does, my conviction that vaults are an almost necessary part of bitcoin's
> viability has only grown over the years.
>
> Since people first started discussing vaults, it's been pretty clear that
> some kind of covenant-enabling consensus functionality is necessary to
> provide the feature set necessary to make vault use practical.
>
> Earlier last year I experimented with using OP_CTV[1], a limited covenant
> mechanism, to implement a "minimum-viable" vault design. I found that the
> inherent limitations of a precomputed covenant scheme left the resulting
> vault implementation wanting, even though it was an improvement over
> existing strategies that rely on presigned transactions and (hopefully)
> ephemeral keys.
>
> But I also found proposed "general" covenant schemes to be
> unsuitable for this use. The bloated scriptPubKeys, both in size and
> complexity, that would result when implementing something like a vault
> weren't encouraging. Also importantly, the social-consensus quagmire
> regarding which covenant proposal to actually deploy feels at times
> intractable.
>
> As a result, I wanted to explore a middle way: a design solely concerned
> with making the best vault use possible, with covenant functionality as a
> secondary consideration. In other words, a proposal that would deliver
> the safety benefits of vaults to users without getting hung up on
> trying to solve the general problem of covenants.
>
> At first this design, OP_VAULT, was just sort of a pipe dream. But as I
> did more thinking (and eventually implementing) I became more convinced
> that, even if it isn't considered for soft-fork, it is a worthwhile
> device to serve as a standard benchmark against which other proposals
> might be judged.
>
> I wrote a paper that summarizes my findings and the resulting proposal:
> https://jameso.be/vaults.pdf
>
> along with an accompanying draft implementation:
> https://github.com/bitcoin/bitcoin/pull/26857
>
> I might work on a BIP if there's interest.
>
> James
>
> [1]: https://github.com/jamesob/simple-ctv-vault
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty

[Greg Sanders via bitcoin-dev]

This will greatly centralize the network as well as not actually achieve
the intended goal which is literally impossible.

On Mon, Dec 5, 2022, 8:27 AM El_Hoy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The only option I see against the attack Peter Todd is doing to opt-in RBF
> and 0Conf bitcoin usage is working on a bitcoin core implementation that
> stops propagation of full-rbf replaced blocks. Running multiple of such
> nodes on the network will add a risk to miners that enable full-rbf that
> would work as an incentive against that.
>
> Obviously that would require adding an option on bitcoin core (that is not
> technically but politically difficult to implement as Petter Todd already
> have commit access to the main repository).
>
> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun
> wallet developers) could work on a fork and run several nodes with such
> functionality. As far as I understand the percolation model, with 10 to 20
> nodes running such a rule would create a significant risk for full-rbf
> miners.
>
> Regards.
>
> ---  Eloy
>
>
> On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev
>> wrote:
>> > On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev
>> wrote:
>> > > FYI I've gotten a few hundred dollars worth of donations to this
>> effort, and
>> > > have raised the reward to about 0.02 BTC, or $400 USD at current
>> prices.
>> >
>> > Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb):
>>
>> I'm turning it back on when (if) the mempool settles down. I've got more
>> than
>> enough donations to give another run at it (the majority was donated
>> privately
>> FWIW). There's a risk of the mempool filling up again of course; hard to
>> avoid
>> that.
>>
>> Right now of course it's really easy to double spend with the obvious
>> low-fee/high-fee method as the min relay fee keeps shifting.
>>
>> >
>> https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c
>> >
>> > The block it was claimed in seems to have been about an hour after the
>> > default mempool filled up:
>> >
>> > https://twitter.com/murchandamus/status/1592274621977477120
>> >
>> > That block actually seems to have included two
>> > alice.btc.calendar.opentimestamps.org txs, the other paying $7.88
>> > (309sat/vb):
>> >
>> >
>> https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf
>>
>> The second is because I turned down the full-rbf reward to more normal fee
>> levels. There's also another full-rbf double-spend from the Bob calendar,
>> along
>> the same lines:
>> 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008d2cd2
>>
>> I double-spent the txin of the high fee tx that got mined. But I
>> mistakenly had
>> RBF enabled in that double-spend, so while it propagated initially, I
>> believe
>> it was replaced when something (someone?) rebroadcast the high-fee 397dcb
>> tx.
>>
>> > Timeline (utc) to me looks like:
>> >
>> >  - 13:12 - block 763148 is mined: last one that had a min fee <
>> 1.5sat/vb
>> >  - 13:33 -
>> f503868c64d454c472859b793f3ee7cdc8f519c64f8b1748d8040cd8ce6dc6e1
>> >is announced and propogates widely (1.2sat/vb)
>> >  - 18:42 -
>> 746daab9bcc331be313818658b4a502bb4f3370a691fd90015fabcd7759e0944
>> >is announced and propogates widely (1.2sat/vb)
>> >  - 21:52 - ba967010 tx is announced and propogates widely, since
>> >conflicting tx 746daab9 has been removed from default
>> >  mempools
>> >  - 21:53 - murch tweets about default mempool filling up
>> >  - 22:03 - 397dcbe4 tx is announced and propogates widely, since
>> >conflicting tx f503868 has already been removed from default
>> >  mempools
>>
>> Is that 22:03 time for 397 from your node's logs? It was originally
>> announced
>> hours earlier. From one of my full-rbf nodes:
>>
>> 2022-11-14T14:08:37Z [mempool] replacing tx
>> 764867062b67fea61810c3858d587da83a28290545e882935a32285028084317 with
>> 397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c for
>> 0.00468 additional fees, -1 delta bytes
>>
>> >  - 22:35 - block 763189 is mined
>> >  - 22:39 - block 763190 is mined
>> >  - 23:11 - block 763191 is mined
>> >  - 23:17 - block 763192 is mined including 397dcbe4
>> >
>> > miningpool.observer reports both 397dcbe4 and ba967010 as missing in the
>> > first three blocks, and gives similar mempool ages for those txs to what
>> > my logs report:
>> >
>> >
>> https://miningpool.observer/template-and-block/000436aba59d8430061e0e50592215f7f263bfb1073ccac7
>> >
>> https://miningpool.observer/template-and-block/0005600404792bacfd8a164d2fe9843766afb2bfbd937309
>> >
>> 

Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning

[Greg Sanders via bitcoin-dev]

Small update.

A bit ago I went ahead and implemented ephemeral anchors on top of the V3
proposal to see what the complexity looks like:
https://github.com/bitcoin/bitcoin/pull/26403

Roughly 130 loc excluding tests, using OP_2 instead of OP_TRUE to not camp
the value that is used elsewhere.

Please let me know if you have any early feedback on this!

Greg

On Thu, Oct 20, 2022 at 9:42 AM Greg Sanders  wrote:

> So it doesn't look like I'm ignoring a good question:
>
> No solid noninteractive ideas, unless we get some very flexible sighash
> softfork. Interactively, I think you can get collaborative fee bumps under
> the current consensus regime and ephemeral anchors. The child will just be
> built with inputs from different people.
>
> On Wed, Oct 19, 2022 at 11:12 AM James O'Beirne 
> wrote:
>
>> I'm also very happy to see this proposal, since it gets us closer to
>> having a mechanism that allows the contribution to feerate in an
>> "unauthenticated" way, which seems to be a very helpful feature for vaults
>> and other contracting protocols.
>>
>> One possible advantage of the sponsors interface -- and I'm curious for
>> your input here Greg -- is that with sponsors, assuming we relaxed the "one
>> sponsor per sponsoree" constraint, multiple uncoordinated parties can
>> collaboratively bump a tx's feerate. A simple example would be a batch
>> withdrawal from an exchange could be created with a low feerate, and then
>> multiple users with a vested interest of expedited confirmation could all
>> "chip in" to raise the feerate with multiple sponsor transactions.
>>
>> Having a single ephemeral output seems to create a situation where a
>> single UTXO has to shoulder the burden of CPFPing a package. Is there some
>> way we could (possibly later) amend the ephemeral anchor interface to allow
>> for this kind of collaborative sponsoring? Could you maybe see "chained"
>> ephemeral anchors that would allow this?
>>
>>
>> On Tue, Oct 18, 2022 at 12:52 PM Jeremy Rubin via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Excellent proposal and I agree it does capture much of the spirit of
>>> sponsors w.r.t. how they might be used for V3 protocols.
>>>
>>> The only drawbacks I see is they don't work for lower tx version
>>> contracts, so there's still something to be desired there, and that the
>>> requirement to sweep the output must be incentive compatible for the miner,
>>> or else they won't enforce it (pass the buck onto the future bitcoiners).
>>> The Ephemeral UTXO concept can be a consensus rule (see
>>> https://rubin.io/public/pdfs/multi-txn-contracts.pdf "Intermediate
>>> UTXO") we add later on in lieu of managing them by incentive, so maybe it's
>>> a cleanup one can punt.
>>>
>>> One question I have is if V3 is designed for lightning, and this is
>>> designed for lightning, is there any sense in requiring these outputs for
>>> v3? That might help with e.g. anonymity set, as well as potentially keep
>>> the v3 surface smaller.
>>>
>>> On Tue, Oct 18, 2022 at 11:51 AM Greg Sanders via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> > does that effectively mark output B as unspendable once the child
>>>> gets confirmed?
>>>>
>>>> Not at all. It's a normal spend like before, since the parent has been
>>>> confirmed. It's completely unrestricted, not being bound to any
>>>> V3/ephemeral anchor restrictions on size, version, etc.
>>>>
>>>> On Tue, Oct 18, 2022 at 11:47 AM Arik Sosman via bitcoin-dev <
>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>>> Hi Greg,
>>>>>
>>>>> Thank you very much for sharing your proposal!
>>>>>
>>>>> I think there's one thing about the second part of your proposal that
>>>>> I'm missing. Specifically, assuming the scenario of a v3 transaction with
>>>>> three outputs, A, B, and the ephemeral anchor OP_TRUE. If a child
>>>>> transaction spends A and OP_TRUE, does that effectively mark output B as
>>>>> unspendable once the child gets confirmed? If so, isn't the implication
>>>>> therefore that to safely spend a transaction with an ephemeral anchor, all
>>>>> outputs must be spent? Thanks!
>>>>>
>>>>> Best,
>>>>> Arik
>>>>>
>>>>> On Tue, Oct 18, 2022, at 

Re: [bitcoin-dev] Solving Multi-Party Flows Pinning with Opt-in Full-RBF Spent-nVersion Signaling

[Greg Sanders via bitcoin-dev]

> ...and the attacker also pays out the nose if they're exploiting rule #3.

I agree the attacker puts more at stake in this case. If we're assuming
they pay the price and get mined, they can be booted from the protocol
whenever they get mined. I was speaking about the worst case scenario where
it's never mined.

> We shouldn't assume it will always exist.

Just making sure people know that today it does impact things today.

On Wed, Nov 2, 2022, 10:33 AM Peter Todd  wrote:

> On Wed, Nov 02, 2022 at 10:19:00AM -0400, Greg Sanders wrote:
> > Sorry, I forgot one point which is pertinent to this conversation.
> >
> > *Even with* fullrbf-everywhere and V3, pinning via rule#3 and rule#5 are
> > still an issue in coinjoin scenarios.
> >
> > Each coinjoin adversary can double-spend their coin to either full
> package
> > weight(101kvb),
> > or give 24 descendants, which means you quickly pay out the nose in
> rule#3
>
> ...and the attacker also pays out the nose if they're exploiting rule #3.
>
> > or are excluded
> > from RBFing it if you have 4+ greifers in your coinjoin violating rule#5.
> >
> > If we instead narrowed this policy to marking a transaction output as
> > opt-in to V3, it gets a bit more interesting. *Unfortunately,
> > double-spending counterparties can still cause rule#3 pain, one 100kvb
> > package of junk per peer,* but rule#5 violations is at least contained to
> > coinjoins with ~50 peers(assuming two transactions booted per input
> > double-spent, which would be the V3 max bumped per input).
>
> There's no hard technical reason for rule #5 to even exist. It's simply a
> conservative DoS limit to avoid having to do "too much" computation when
> processing a replacement in some replacement implementations. We shouldn't
> assume it will always exist. And like rule #3 pinning, exploiting it costs
> money.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Solving Multi-Party Flows Pinning with Opt-in Full-RBF Spent-nVersion Signaling

[Greg Sanders via bitcoin-dev]

Sorry, I forgot one point which is pertinent to this conversation.

*Even with* fullrbf-everywhere and V3, pinning via rule#3 and rule#5 are
still an issue in coinjoin scenarios.

Each coinjoin adversary can double-spend their coin to either full package
weight(101kvb),
or give 24 descendants, which means you quickly pay out the nose in rule#3
or are excluded
from RBFing it if you have 4+ greifers in your coinjoin violating rule#5.

If we instead narrowed this policy to marking a transaction output as
opt-in to V3, it gets a bit more interesting. *Unfortunately,
double-spending counterparties can still cause rule#3 pain, one 100kvb
package of junk per peer,* but rule#5 violations is at least contained to
coinjoins with ~50 peers(assuming two transactions booted per input
double-spent, which would be the V3 max bumped per input).

It's still worth exploring, but very speculatively.

Greg

On Wed, Nov 2, 2022 at 10:04 AM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, Nov 01, 2022 at 10:21:59PM -0400, Antoine Riard via bitcoin-dev
> wrote:
> > Hi list,
> >
> > Reading Suhas's post on mempool policy consistency rules, and the
> grounded
> > suggestion that as protocol developers we should work on special policy
> > rules to support each reasonable use case on the network rather to
> arbiter
> > between class of use-cases in the design of an
> > unified set of rules, reminded me there is another solution to solve
> > multi-party funding pinning rather than wide deployment of fullrbf. This
> > was communicated to me a while back, and it was originally dismissed
> > because of the privacy trade-offs (and potential slight fees overhead
> > cost). However, if widely adopted, they might sound acceptable to
> > contracting protocol developers and operators.
>
> Strong NACK.
>
> Zeroconf is, at best, a very marginal usecase. The only services that have
> spoken up in support of it are Bitrefill and Muun, and the latter says
> they're
> working to get rid of their vulnerability to it. People attempting to make
> it
> secure have repeatedly done sybil attacks against the network in attempts
> to
> measure transaction propagation. And of course, if transaction fees and
> full
> mempools are in our near future - as is widely expected - mempool
> consistency
> will even further diminish making zeroconf even harder to achieve.
>
> Incurring a bunch of engineering costs and harming privacy for the sake of
> continuing this nonsense is ridiculous.
>
> If anything, we should be moving to full-RBF so we can undo the privacy
> cost
> that is opt-in-RBF: right now 30% of transactions are having to harm their
> privacy by signalling support for it. Full-RBF will allow that wallet
> distinguisher to be eliminated.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> ___
> 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] Solving Multi-Party Flows Pinning with Opt-in Full-RBF Spent-nVersion Signaling

[Greg Sanders via bitcoin-dev]

My idea, which I hated and didn't propose, was to mark utxos specifically
for this exact purpose, but this is extremely ugly from a wallet/consensus
perspective. nVersion is cleaner(well, except the below issue), at the cost
of forcibly marking all utxos in a transaction the same way.

> On the validation-side, there is one engineering issue, as I think there
is no access to the spent nversion fields by the mempool logic.

I don't think Core tracks this value in the utxo set either, because
currently there's no use-case for it today? Am I mistaken?

/**
 * A UTXO entry.
 *
 * Serialized format:
 * - VARINT((coinbase ? 1 : 0) | (height << 1))
 * - the non-spent CTxOut (via TxOutCompression)
 */

Greg


On Wed, Nov 2, 2022 at 6:27 AM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi list,
>
> Reading Suhas's post on mempool policy consistency rules, and the grounded
> suggestion that as protocol developers we should work on special policy
> rules to support each reasonable use case on the network rather to arbiter
> between class of use-cases in the design of an
> unified set of rules, reminded me there is another solution to solve
> multi-party funding pinning rather than wide deployment of fullrbf. This
> was communicated to me a while back, and it was originally dismissed
> because of the privacy trade-offs (and potential slight fees overhead
> cost). However, if widely adopted, they might sound acceptable to
> contracting protocol developers and operators.
>
> ## The Problem: Pinning Contracting Protocols Funding Flows with Opt-out
> Double-Spend
>
> As originally laid out [0], multi-party collaborative flows
> (coinjoin/dual-funding/swaps/splicing/etc), where every participant
> contributes at least one input, are suffering from a low-cost and
> high-success DoS vector with asymmetric damages. E.g with lightning
> interactive transaction construction protocols limits of 252 inputs, 1
> single input can bleed the timevalue of the remaining 251 inputs, or engage
> in a MEV attack where the fee-bumping entity is lured to inflate feerate
> beyond the current blockspace demand. The attack can be hidden and a
> posteriori assigning blame consistently stays an open question in the lack
> of a consensus mechanism between participants on the network mempools
> states.
>
> The issue lies in the fact that participants joining inputs together don't
> have control, or even view, of the replacement signaling of any potential
> double-spend of the other participants inputs. Indeed the opt-in fullrbf
> signaling is enforced based on the nSequence field, and this one is fully
> malleable by the UTXO spender. There is no current mechanism to require
> replacement signaling provable to a third-party only on the knowledge of
> the UTXO spents.
>
> # The Solution: Opt-in Full-Replace-by-Fee Spent-nVersion Signaling
>
> A new policy is specified in a new way a transaction can signal that it is
> replaceable.
>
> 1. A confirmed transaction is considered to have opted in to allowing
> replacement of any of its spends (or their descendants), if the last bit of
> the nVersion field is set.
>
> Rational: The future replacement status of any UTXO spend can be
> determined by inspecting the nVersion, therefore protecting the
> collaborative participants of a multi-party flows that the target
> transaction should propagate to the miners, if the fee/feerate offered are
> the best ones without opt-out based pinning. It can be required the UTXOs
> to have few confirmations in case of shallow reorgs to increase DoS
> protection.
>
> ## Solution trade-offs
>
> On the validation-side, there is one engineering issue, as I think there
> is no access to the spent nversion fields by the mempool logic. This would
> presume we add some new cache of all the confirmed UTXOs, so ~50M * 4bytes,
> 300 MB of additional state for policy-enforcing full-nodes. I don't know if
> there is another strong drawback, even the reorg logic the replaceable
> spends shouldn't be evicted if the confirmed ancestor is back to the
> mempool, as mempool validity shouldn't be reevaluated before a replacement
> candidate shows up. A fee penalty could be requested for nVersion-signaling
> transactions to compensate for the additional state stored by full-node
> operators (even if obviously they're not the ones earning the fees).
>
> For the contracting protocols wallets, as you don't know in advance which
> coins are going to be used for a collaborative flow, you're better off to
> mark all your coins nVersion fields opting fullrbf. Otherwise, you will
> have to go through an on-chain fee cost to change the replacement status of
> the spends of your coins. However, this policy bookmarking comes as a
> protocol fingerprint leak for an observer of the transaction logs. If all
> the second-layers used by default, this is constituting a single anonymity
> set, though it might still be the privacy gains we're harvesting from
> Taproot output 

Re: [bitcoin-dev] Preventing/detecting pinning of jointly funded txs

[Greg Sanders via bitcoin-dev]

Assigning blame here seems to be the paramount concern here. If we can
assign blame, most coinjoin-like protocols can terminate in bounded block
time, assuming fees are properly set.

It's also worth noting that in coinjoin cases, they're obviously coinjoins,
so pinging explorers over Tor HS seems purely additive to me. The use-cases
that can't use it are other privacy methods like coinswap and similar,
where there's no blockchain indication anything different is happening. The
larger the coinjoin, the more potential honest users, the more potential
for a duplicitous double-spend to be gossiped among those peers.

For dual funding LN channels, that number is pretty small(2), so I suspect
the DoS concerns are fairly subtle. Might be worth talking to
CLN/Eclair/Other LN teams that are working through those subtleties as we
speak.

Greg

On Tue, Nov 1, 2022 at 11:52 PM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Oct 28, 2022 at 03:21:53AM +1000, Anthony Towns via bitcoin-dev
> wrote:
> > What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
> > solve that problem if they have only opt-in RBF available?
>
> ref:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021124.html
>
> So, having a go at answering my own question.
>
> I think ultimately the scenario here is:
>
>  * you have a joint funding protocol, where everyone says "here's
>an unspent utxo that will be my contribution", collaborates on signing
>a transaction spending all those utxos, and then broadcasts it
>
>  * everyone jointly agrees to pay some amount in fees for that
>transaction, targeting confirmation within N blocks
>
>  * the goal is to have the transaction confirm, obviously; but it's also
>acceptable to discover a conflicting transaction, as that will
>demonstrate that a particular participant has been dishonest (their
>utxo was not "unspent"), allowing the overall protocol to make progress
>
> The question then is how much effort do you have to go to to make such a
> protocol work?
>
> As an extreme example, you could always have each participant maintain
> a dedicated amount of hashpower: eg, if each participant individually
> controls 0.5% of hashpower, then having two honest participants would
> give you a 75% chance of confirmation within 137 blocks (roughly a day),
> even if your transaction failed to relay at all, and the only way to
> prevent confirmation is for a conflicting transaction to be confirmed
> earlier. Of course, needing to have 0.5% of hashpower would mean fewer
> than 200 people globally could participate in such a protocol, and
> requires something like $10M in capital investment just for ASICs in
> order to participate.
>
> I think the next step from that pretty much requires introducing the
> assumption that the vast majority of the bitcoin p2p network (both nodes
> and hashrate) will accept your transaction, at least in a world where all
> your collaborators are honest and don't create conflicting transactions.
> You can limit that assumption a little bit, but without most p2p peers
> being willing to relay your tx, you start having privacy issues; and
> without most miners being willing to mine your tx, you start getting
> problems with predicting fees. And in any event, I don't think anyone's
> trying to make weird transactions here, just get their otherwise normal
> transactions to actually confirm.
>
> I think the same approach used to detect double spend races by people
> accepting zeroconf would work here too. That is setup a couple of
> anonymous bitcoin nodes, let them sit for a couple of weeks so their
> mempools are realistic, then when you broadcast a jointly funded
> transaction, query their mempools: if your new tx made it there, it
> likely made it to mining pools too, and you're fine; if it didn't, then
> the transaction that's blocking it almost certainly did, so you can find
> out what that is and can go from there.
>
> (If you don't see either your tx, or a conflicting one, then it likely
> means the nodes that broadcasted your tx are being sybil attacked, either
> because their peers are directly controlled by an attacker, or they've
> been identified by an attacker and attacked in some other way; presumably
> you could pick a couple of node that have been confirmed by both your
> anonymous nodes' as valid and reachable, and connect to them to break
> out of the sybil attack; if that doesn't work either, you probably need
> to change ISPs or put your active node via a (different) VPN provider...)
>
> Your capital expenses are much lower that way: perhaps on the order of
> $20/month to run a couple of nodes on AWS or linode or similar.
>
> But, you might say, what if I don't even want to run multiple bitcoin
> nodes 24/7 indefinitely? Can we outsource that, like we outsource mining
> by paying tx fees?
>
> That seems harder, particularly if you want to avoid whoever you're
> outsourcing too 

Re: [bitcoin-dev] On mempool policy consistency

[Greg Sanders via bitcoin-dev]

> I think that's a huge oversimplification of "rational" -- otherwise
you might as well say that deliberately pinning txs is also rational,
because it allows the person doing the pinning to steal funds from their
counterparty by forcing a timeout to expire.

To be clear, a pinner is attempting to *not* pay
the most fees, by definition. If we're somehow sure something is a pin,
we should not allow it, because miners rationally do not want it vs
an "honest" bid for fees. V3 design is one attempt to carve out a safe
space for fee bidding. Carving out a safe space for *non-bidding* is not the
same thing.

I think this mostly boils down having knobs or not. I'm fine with knobs
with paternalistic defaults, especially when a non-zero percentage of users
disagree with a value in either direction.

Greg

On Tue, Nov 1, 2022 at 11:07 PM Anthony Towns  wrote:

> On Mon, Oct 31, 2022 at 12:25:46PM -0400, Greg Sanders via bitcoin-dev
> wrote:
> > For 0-conf services we have potential thieves who are willing
> > to *out-bid themselves* to have funds come back to themselves. It's not a
> > "legitimate" use-case, but a rational one.
>
> I think that's a huge oversimplification of "rational" -- otherwise
> you might as well say that deliberately pinning txs is also rational,
> because it allows the person doing the pinning to steal funds from their
> counterparty by forcing a timeout to expire.
>
> There's no need for us as developers, or us as node operators, to support
> every use case that some individual might find rational at some point in
> time. After all, it might be individually rational for someone to want the
> subsidy to stop decreasing, or to include 8MB of transactions per block.
>
> Note that it's also straightforwardly rational and incentive compatible
> for miners to not want this patch to be available, under the following
> scenario:
>
>  - a significant number of on-chain txs are for zeroconf services
>  - fee income would be reduced if zeroconf services went away
>(both directly due to the absence of zeroconf payments, and by
>reducing mempool pressure, reducing fee income from the on-chain txs
>that remain)
>  - miners adopting fullrbf would cause zeroconf services to go away,
>(and won't enable a comparable volume of new services that generates
>comparable transaction volume)
>  - including the option in core would make other miners adopting
>fullrbf more likely
>
> I think the first three of those are fairly straightforward and objective,
> at least at this point in time. The last is just a risk; but without
> any counterbalancing benefit, why take it?
>
> Gaining a few thousand sats due to high feerate replacement txs from
> people exploiting zeroconf services for a few months before all those
> services shutdown doesn't make up for the lost fee income over the months
> or years it might have otherwise taken people to naturally switch to
> some better alternative.
>
> Even if fullrbf worked for preventing pinning that likely doesn't directly
> result in much additional fee income: once you know that pinning doesn't
> work, you just don't try it, which means there's no opportunity for
> miners to profit from a bidding war from the pinners counterparties
> repeatedly RBFing their preferred tx to get it mined.
>
> That also excludes second order risks: if you can't do zeroconf with BTC
> anymore, do you switch to ERC20 tokens, and then trade your BTC savings
> for ETH or USDT, and do enough people do that to lower the price of BTC?
> If investors see BTC being less used for payments, does that lower their
> confidence in bitcoin's future, and cause them to sell?
>
> > Removing a
> > quite-likely-incentive-compatible option from the software just
> encourages
> > miners to adopt an additional patch
>
> Why shouldn't miners adopt an additional patch if they want some unusual
> functionality?
>
> Don't we want/expect miners to have the ability to change the code in
> meaningful ways, at a minimum to be able to cope with the scenario where
> core somehow gets coopted and releases bad code, or to be able to deal
> with the case where an emergency patch is needed?
>
> Is there any evidence miners even want this option? Peter suggested
> that some non-signalling replacements were being mined already [0], but
> as far as I can see [1] all of those are simply due to the transaction
> they replaced not having propagated in the first place (or having been
> evicted somehow? hard to tell without any data on the original tx).
>
> [0]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021012.html
> [1] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1292692367
>
> > 2)

Re: [bitcoin-dev] On mempool policy consistency

[Greg Sanders via bitcoin-dev]

Thanks for your full thoughts Suhas,

The idea of V3 is that we're currently leaving fees on the table by
allowing use-cases to be pinned, not that we like Lightning and we think
miners should stop being profit maximizing somehow to enable safer/better
layer 2 systems.

If someone wants to bump fees for V3 transactions(or replace them!),
there's a much simpler "API" to do so than in legacy policy land. The fact
that it disallows more idiotic ways to add more total fees means wallets
"shouldn't do that". If it ends up that V3 is disallowing too many
"natural" ways to fee bump, that's a strike against the V3 idea and should
be discussed. For 0-conf services we have potential thieves who are willing
to *out-bid themselves* to have funds come back to themselves. It's not a
"legitimate" use-case, but a rational one.

I have mostly come around to not pushing for fullrbf due to the issues you
mentioned, except taking away the option. Removing a
quite-likely-incentive-compatible option from the software just encourages
miners to adopt an additional patch if they ever deem it necessary to
increase their revenue, even if that revenue is from hurting 0-conf
businesses.

Maybe putting/leaving in a default-false flag for disabling these "carve
outs" is the least bad option. V3 usage patterns shouldn't crumble if a
large majority of miners opt out, but 0-conf use cases crumble after a
small percentage of adoption.

To recap my thoughts:

1) I have put away my fullrbf hats, I will not advocate anyone running it
as I think it doesn't really do anything useful for users who aren't trying
to double-spend merchants.
2) Forcing miners to honor fees left on the table with respect to 0-conf,
or forcing them to run a custom patchset to go around it, is a step
backwards.

Greg

On Mon, Oct 31, 2022 at 11:03 AM Suhas Daftuar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> AJ,
>
> Thanks for the thoughtful post. I think your observations about how we
> view mempool policy in the Bitcoin Core project, and how that seems to be
> changing in the discussions around `-mempoolfullrbf`, are on-point and
> provide a helpful baseline for considering future policy changes.
>
> For a long time I viewed fullrbf as an eventuality and I considered myself
> to be philosophically supportive of the idea.  However, after giving this
> issue some thought in the past few weeks, I am reversing my thinking on
> this.  Concretely, I will argue that we should continue to maintain a relay
> policy where replacements are rejected for transactions that don't opt-in
> to RBF (as described in BIP 125), and moreover, that we should remove the
> `-mempoolfullrbf` flag from Bitcoin Core’s latest release candidate and not
> plan to release software with that flag, unless (or until) circumstances
> change on the network, which I'll discuss below.
>
> This is, of course, a nuanced topic, and among the considerations is a
> philosophy of how to think about the relay policy and configuration options
> that we make available in Bitcoin Core (a consideration that is perhaps
> unique to that project, but I think relevant for this mailing list).
>
> I'll start with some technical issues regarding the benefits of enabling
> fullrbf on the network.  In the current BIP 125 regime, every time a
> transaction is created, a choice is made whether to subject the transaction
> to BIP 125’s RBF rules or not (based on the sequence values of the
> inputs).  So given that users can already opt-in to RBF, the benefit of a
> “fullrbf” network policy would be if, somehow, RBF users were still denied
> the benefits of RBF due to the existence of other transactions that don’t
> opt-in.
>
> Along those lines, Antoine Riard brought up[1] a DoS vector that is
> available to someone who wants to interfere with multi-party funded
> transactions, and suggested that fullrbf would eliminate the problem.
> After exploring that question again in this thread (thanks to Greg Sanders
> for clarifying this to me), I understand that the issue is around ensuring
> that a multiparty (coinjoin-type) protocol is able to make eventual
> progress, by having a candidate multiparty transaction either eventually
> confirm or become conflicted with something that has been confirmed, in
> which case the double-spend information could be used to start a new
> coinjoin round with fewer participants.  The concern Antoine and Greg have
> brought up is that non-rbf transactions can persist in the mempool
> ~indefinitely (at a low feerate and not subject to replacement) and
> interfere with progress being made in a coinjoin protocol.
>
> However, it seems to me that similar problems exist for such a protocol
> even in a fullrbf world, as we understand that term today.  I mentioned the
> ability for rbf “pinning” to interfere with relay of the multiparty
> transaction (even if the conflicting transaction signals for RBF – a set of
> large but low feerate conflicting transactions can persist in the 

Re: [bitcoin-dev] On mempool policy consistency

[Greg Sanders via bitcoin-dev]

During off-channel discussion, Suhas made a great point that even with
fullrbf, you can get stuck by bip125 rule#5 pinning if an adversary
controls a number of inputs(4 with default mempool settings).

Implication being, while we can mitigate rule#3 damage potentially with
fullrbf, we cannot actually make promises about mempool entry beyond quite
small transaction sizes. Adversary has to make 100 transactions, 4 chains
of 25, but it achieves the original pin.

On Thu, Oct 27, 2022 at 1:44 PM Greg Sanders  wrote:

> > For instance, the double-spend could be low-feerate and large, and
> effectively pin any attempt to replace it.
>
> Yes, this is the biggest hole left. You *could* replace it with RBF when
> before you simply could not, so perhaps the pinning door is slightly
> smaller in scenarios where going feerates are significantly higher than min.
>
> > Or it could be higher feerate and confirm and B/C have to start all over.
>
> Coinjoins have "blame rounds" exactly for this. Ruling out the above hole
> where you don't want to pay the 100kvb rule#3 penalty, you can kick the
> griefer out. Without replacement, you likely can not.
>
> > Or, A could stall things in the signing phase and B/C have to figure out
> when to give up on the channel with A.
>
> Again, blame rounds solve this.
>
> So to recap, it makes it *possible* to over-bid your griefer, vs simply
> not able to and have funds tied up for weeks(or guess you're being pinned
> and double-spend your input, which again looks blame-worthy).
>
> Properly replacing rule#3 would give these protocols higher assurances,
> but this is where we're at now.
>
> On Thu, Oct 27, 2022 at 1:35 PM Suhas Daftuar via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I have more to say on this broader topic, but since you've brought up
>> this particular example I think it's worth commenting:
>>
>> On Thu, Oct 27, 2022 at 1:23 PM Anthony Towns via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Is that true? Antoine claims [1] that opt-in RBF isn't enough to avoid
>>> a DoS issue when utxos are jointly funded by untrusting partners, and,
>>> aiui, that's the main motivation for addressing this now.
>>>
>>> [1]
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>>>
>>> The scenario he describes is: A, B, C create a tx:
>>>
>>>   inputs: A1, B1, C1 [opts in to RBF]
>>>   fees: normal
>>>   outputs:
>>> [lightning channel, DLC, etc, who knows]
>>>
>>> they all analyse the tx, and agree it looks great; however just before
>>> publishing it, A spams the network with an alternative tx, double
>>> spending her input:
>>>
>>>   inputs: A1 [does not opt in to RBF]
>>>   fees: low
>>>   outputs: A
>>>
>>> If A gets the timing right, that's bad for B and C because they've
>>> populated their mempool with the 1st transaction, while everyone else
>>> sees the 2nd one instead; and neither tx will replace the other. B and
>>> C can't know that they should just cancel their transaction, eg:
>>>
>>>   inputs: B1, C1 [opts in to RBF]
>>>   fees: 50% above normal
>>>   outputs:
>>> [smaller channel, refund, whatever]
>>>
>>> and might instead waste time trying to fee bump the tx to get it mined,
>>> or similar.
>>>
>>> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
>>> solve that problem if they have only opt-in RBF available?
>>>
>>
>> I think this is not a real example of a DoS vector that is available
>> because we support non-rbf signaling transactions. Even in a world where
>> all transactions are replaceable, person A could double-spend their input
>> in a way that is annoying for B and C.  For instance, the double-spend
>> could be low-feerate and large, and effectively pin any attempt to replace
>> it.  Or it could be higher feerate and confirm and B/C have to start all
>> over.  Or, A could stall things in the signing phase and B/C have to figure
>> out when to give up on the channel with A.
>>
>> So I find this example to be unconvincing.  Are there any other examples
>> where having a non-replacement policy for some transactions causes problems
>> for protocols people are trying to build?
>>
>> Thanks,
>> Suhas
>> ___
>> 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] On mempool policy consistency

[Greg Sanders via bitcoin-dev]

> For instance, the double-spend could be low-feerate and large, and
effectively pin any attempt to replace it.

Yes, this is the biggest hole left. You *could* replace it with RBF when
before you simply could not, so perhaps the pinning door is slightly
smaller in scenarios where going feerates are significantly higher than min.

> Or it could be higher feerate and confirm and B/C have to start all over.

Coinjoins have "blame rounds" exactly for this. Ruling out the above hole
where you don't want to pay the 100kvb rule#3 penalty, you can kick the
griefer out. Without replacement, you likely can not.

> Or, A could stall things in the signing phase and B/C have to figure out
when to give up on the channel with A.

Again, blame rounds solve this.

So to recap, it makes it *possible* to over-bid your griefer, vs simply not
able to and have funds tied up for weeks(or guess you're being pinned and
double-spend your input, which again looks blame-worthy).

Properly replacing rule#3 would give these protocols higher assurances, but
this is where we're at now.

On Thu, Oct 27, 2022 at 1:35 PM Suhas Daftuar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I have more to say on this broader topic, but since you've brought up this
> particular example I think it's worth commenting:
>
> On Thu, Oct 27, 2022 at 1:23 PM Anthony Towns via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Is that true? Antoine claims [1] that opt-in RBF isn't enough to avoid
>> a DoS issue when utxos are jointly funded by untrusting partners, and,
>> aiui, that's the main motivation for addressing this now.
>>
>> [1]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>>
>> The scenario he describes is: A, B, C create a tx:
>>
>>   inputs: A1, B1, C1 [opts in to RBF]
>>   fees: normal
>>   outputs:
>> [lightning channel, DLC, etc, who knows]
>>
>> they all analyse the tx, and agree it looks great; however just before
>> publishing it, A spams the network with an alternative tx, double
>> spending her input:
>>
>>   inputs: A1 [does not opt in to RBF]
>>   fees: low
>>   outputs: A
>>
>> If A gets the timing right, that's bad for B and C because they've
>> populated their mempool with the 1st transaction, while everyone else
>> sees the 2nd one instead; and neither tx will replace the other. B and
>> C can't know that they should just cancel their transaction, eg:
>>
>>   inputs: B1, C1 [opts in to RBF]
>>   fees: 50% above normal
>>   outputs:
>> [smaller channel, refund, whatever]
>>
>> and might instead waste time trying to fee bump the tx to get it mined,
>> or similar.
>>
>> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
>> solve that problem if they have only opt-in RBF available?
>>
>
> I think this is not a real example of a DoS vector that is available
> because we support non-rbf signaling transactions. Even in a world where
> all transactions are replaceable, person A could double-spend their input
> in a way that is annoying for B and C.  For instance, the double-spend
> could be low-feerate and large, and effectively pin any attempt to replace
> it.  Or it could be higher feerate and confirm and B/C have to start all
> over.  Or, A could stall things in the signing phase and B/C have to figure
> out when to give up on the channel with A.
>
> So I find this example to be unconvincing.  Are there any other examples
> where having a non-replacement policy for some transactions causes problems
> for protocols people are trying to build?
>
> Thanks,
> Suhas
> ___
> 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] On mempool policy consistency

[Greg Sanders via bitcoin-dev]

To add a wrinkle, or possibly a confirmation of your long message, up to
readers to decipher, there historically has been at least one more RBF
related option that was included, then removed later in Core.

Introduced as "permitrbf" in b768108d9c0b83330572711aef1e569543130d5e with
default "true", later renamed to "replacebyfee", then finally as
"mempoolreplacement".

It was later removed in 8053e5cdade87550f0381d51feab81dedfec6c46 with the
message:

"
Remove -mempoolreplacement to prevent needless block prop slowness.

At this point there is no reasonable excuse to disable opt-in RBF,
and, unlike when this option was added, there are now significant
issues created when disabling it (in the form of compact block
reconstruction failures). Further, it breaks a lot of modern wallet
behavior.
"

So there is some precedence to including an option that protocol devs don't
find useful, then removing it N years later to make sure it doesn't impact
compact blocks.

Peering into the "precedence" lense, I think this does lend itself to the
theory that the transition should be as uniform as possible to avoid
degradation of fast block propagation. If not removing options(which is
deemed user hostile by a number of folks including me), then at least for a
flag day switchover.

Cheers,
Greg

On Wed, Oct 26, 2022 at 7:53 PM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi *,
>
> TLDR: Yes, this post is too long, and there's no TLDR. If it's any
> consolation, it took longer to write than it does to read?
>
> On Tue, Jun 15, 2021 at 12:55:14PM -0400, Antoine Riard via bitcoin-dev
> wrote:
> > Subject: Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0
> > I'm writing to propose deprecation of opt-in RBF in favor of full-RBF
>
> > If there is ecosystem agreement on switching to full-RBF, but 0.24 sounds
> > too early, let's defer it to 0.25 or 0.26. I don't think Core has a
> > consistent deprecation process w.r.t to policy rules heavily relied-on by
> > Bitcoin users, if we do so let sets a precedent satisfying as many folks
> as
> > we can.
>
> One precedent that seems to be being set here, which to me seems fairly
> novel for bitcoin core, is that we're about to start supporting and
> encouraging nodes to have meaningfully different mempool policies. From
> what I've seen, the baseline expectation has always been that while
> certainly mempools can and will differ, policies will be largely the same:
>
>   Firstly, there is no "the mempool". There is no global mempool. Rather
>   each node maintains its own mempool and accepts and rejects transaction
>   to that mempool using their own internal policies. Most nodes have
>   the same policies, but due to different start times, relay delays,
>   and other factors, not every node has the same mempool, although they
>   may be very similar.
>
>   -
> https://bitcoin.stackexchange.com/questions/98585/how-to-find-if-two-transactions-in-mempool-are-conflicting
>
> Up until now, the differences between node policies supported by different
> nodes running core have been quite small, with essentially the following
> options available:
>
>  -minrelaytxfee, -maxmempool - changes the lowest fee rate you'll accept
>
>  -mempoolexpiry - how long to keep txs in the mempool
>
>  -datacarrier - reject txs creating OP_RETURN outputs
>
>  -datacarriersize - maximum size of OP_RETURN data
>
>  -permitbaremultisig - prevent relay of bare multisig
>
>  -bytespersigop - changes how SIGOP accounting works for relay and
>  mining prioritisation
>
> as well as these, marked as "debug only" options (only shown with
> -help-debug):
>
>  -incrementalrelayfee - make it easier/harder to spam txs by only
>  slightly bumping the fee; marked as a "debug only" option
>
>  -dustrelayfee - make it easier/harder to create uneconomic utxos;
>  marked as a "debug only" option
>
>  -limit{descendant,ancestor}{count,size} - changes how large the
>  transaction chains can be; marked as a "debug only" option
>
> and in theory, but not available on mainnet:
>
>  -acceptnonstdtxn - relay/mine non standard transactions
>
> There's also the "prioritisetransaction" rpc, which can cause you to keep
> a low feerate transaction in your mempool longer than you might otherwise.
>
> I think that -minrelaytxfee, -maxmempool and -mempoolexpiry are the only
> ones of those options commonly set, and those only rarely result in any
> differences in the txs at the top of the mempool.
>
> There are also quite a few parameters that aren't even runtime
> configurable:
>
>  - MAX_STANDARD_TX_WEIGHT
>  - MIN_STANDARD_TX_NONWITNESS_SIZE (see also #26265)
>  - MAX_P2SH_SIGOPS (see also #26348)
>  - MAX_STANDARD_TX_SIGOPS_COST
>  - MAX_STANDARD_P2WSH_STACK_ITEMS
>  - MAX_STANDARD_P2WSH_STACK_ITEM_SIZE
>  - MAX_STANDARD_TAPSCRIPT_STACK_ITEM_SIZE
>  - MAX_STANDARD_P2WSH_SCRIPT_SIZE
>  - MAX_STANDARD_SCRIPTSIG_SIZE
>  - EXTRA_DESCENDANT_TX_SIZE_LIMIT
>  - MAX_REPLACEMENT_CANDIDATES

Re: [bitcoin-dev] Relaxing minimum non-witness transaction size policy restriction

[Greg Sanders via bitcoin-dev]

As there has been some feedback to the same effect, I've opened a competing
PR for separate evaluation here:
https://github.com/bitcoin/bitcoin/pull/26398

Please give feedback if anyone has any.

On Thu, Oct 20, 2022 at 8:13 PM Peter Todd  wrote:

> On Thu, Oct 20, 2022 at 08:07:54PM -0400, Greg Sanders wrote:
> > I don't doubt the use case(it's why I opened the issue!). I didn't want
> the
> > proposal to die in case people found it odd that 61, 62, 63, but not 64
> > bytes ended up being broadcast able.
> >
> > Perhaps this is not an issue, especially since this isn't a consensus
> > change like the Great Consensus Cleanup. Willing to change my proposal
> and
> > PR if people have no strong objections.
>
> I think it's fine if we only restrict 64 bytes. We have a specific reason
> to do
> that and it's ok if we just tell people that. Only fairly-technical
> use-cases
> are affected anyway.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Greg Sanders via bitcoin-dev]

> Yeah, there are several policy features that are not consensus related
but end up de facto setting rules for how bitcoin behaves.

Yes, it's status quo so wallets "just know" not to do them. The fact that
the status quo would be changing is important, in that it may degrade UX
for 0-conf deposits. If bip125 was full rbf, the status quo would be the
other way around, but here we are.

> need to evaluate from several angles first incentives-wise

Right, if people have put their heads together and found a few
possibilities, we should explore the possibilities. CPFP would be an
interesting one used to lock in FX risk, or at least make the
double-spender over-pay to exploit the delta, especially for larger
amounts/new users with no track record.

> I'd also ask if there might also be other solutions for solving the
pinning issue as well if we dig deep into it? Perhaps there are those with
tradeoffs, but those tradeoffs being less significant than the tradeoffs of
rbf policy?

There's been a lot of work on crafting an opt-in policy that blunts the
edges of pinning attacks, and I think we've gotten to the point where it
can be said if you opt into this scheme: "If I have a required key in every
transaction input script, I can safely and efficiently fee bump the
transaction" through a mixture of RBF/CPFP, depending on structure.

Please see
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021036.html
and issues linked in that e-mail, if you're interested in the set of policy
changes required to get there. Note that these would still all be opt-in.

This unfortunately rules out any "coinjoin" like scenario, including
dual-funding lightning channels(which is close to landing finally). The
good news is that those cases seem to not have theft risk, just normal DoS
risk of funds being stuck for potentially weeks. It would also rule out
anything like coinpools, or other advanced constructs that don't actually
exist yet.

Maybe the above proposals make RBF'ing super reliable compared to today,
and that changes the calculus for wallet authors, but this is still a ways
out as these are still early proposals.

> it will hurt whenever it happens

Yes it's a risk that this never gets satisfactorily resolved, which is why
I was mentioning a potentially long "timeout" being decided in the near-ish
future. Let's gather what we can, start building aspirationally towards
that, and try to not beat this horse again.

Greg

On Fri, Oct 21, 2022 at 10:19 AM Sergej Kotliar 
wrote:

>
>
> On Fri, 21 Oct 2022 at 16:01, Greg Sanders  wrote:
>
>> Full-rbf is an odd duck, because while it is not a consensus issue, it
>> does affect a large % of transactions made by wallets already, contrary to
>> most policy changes.
>>
>
> Yeah, there are several policy features that are not consensus related but
> end up de facto setting rules for how bitcoin behaves. Minrelayfee being
> another, and probably other examples out there that I don't know of.
>
>
>> It's also a UX issue, not a safety issue for retail wallet users(except
>> Muun, who have given a clear timeline). Clearly considerations would be
>> very different otherwise, but retail wallets by and large do not consider
>> 0-conf as a valid deposit, or at least put up some warning symbols to that
>> effect.
>>
>> Can only speak for myself, but I am looking for a concrete timeframe from
>> 0-conf stakeholders. I have no preference for any particular time frame, as
>> long as it can be agreed upon in the near-ish future. This keeps the
>> transition technically speaking very simple, and removes uncertainty from
>> decision making going forward.
>>
>
> It's hard to give a timeframe because it's not clear what the path forward
> for these stakeholders is. Most of what I've heard in this channel is
> things like "just use Lightning" but that's contradicted by user data. So
> the action becomes "stop accepting payments onchain" which isn't really a
> timeframe type issue, it will hurt whenever it happens. Maybe a thorough
> discussion for a way forward would be useful here. Jeremy Rubin suggested
> an interesting idea for using CPFP to force a transaction to complete.
> We'll evaluate it and see if it works in the wild for zero-conf of RBF
> today and report findings, need to evaluate from several angles first
> incentives-wise. There might also be other solutions.
>
> I'd also ask if there might also be other solutions for solving the
> pinning issue as well if we dig deep into it? Perhaps there are those with
> tradeoffs, but those tradeoffs being less significant than the tradeoffs of
> rbf policy?
>
>
> Best,
> Sergej
>
>>
>> On Fri, Oct 21, 2022 at 8:02 AM Sergej Kotliar 
>> wrote:
>>
>>> On Thu, 20 Oct 2022 at 23:07, Greg Sanders  wrote:
>>>
 A large number of coins/users sit on custodial rails and this would
 essentially encumber protocol developers to those KYC/AML institutions. If
 Binance decides to never support Lightning in favor of BNC-wrapped BTC,

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Greg Sanders via bitcoin-dev]

Full-rbf is an odd duck, because while it is not a consensus issue, it does
affect a large % of transactions made by wallets already, contrary to most
policy changes. We have a status quo that is understandable, but
unfortunately long-term incentive incompatible.

It's also a UX issue, not a safety issue for retail wallet users(except
Muun, who have given a clear timeline). Clearly considerations would be
very different otherwise, but retail wallets by and large do not consider
0-conf as a valid deposit, or at least put up some warning symbols to that
effect.

Can only speak for myself, but I am looking for a concrete timeframe from
0-conf stakeholders. I have no preference for any particular time frame, as
long as it can be agreed upon in the near-ish future. This keeps the
transition technically speaking very simple, and removes uncertainty from
decision making going forward.

To make a follow-on consensus analogy, I am in the BIP8
lock-on-timeout=true camp for full rbf. If metrics arise that shows we're
ready early, great. If not, I still want to avoid having this discussion
again in N+ years.

Cheers,
Greg

On Fri, Oct 21, 2022 at 8:02 AM Sergej Kotliar  wrote:

> On Thu, 20 Oct 2022 at 23:07, Greg Sanders  wrote:
>
>> A large number of coins/users sit on custodial rails and this would
>> essentially encumber protocol developers to those KYC/AML institutions. If
>> Binance decides to never support Lightning in favor of BNC-wrapped BTC,
>> should this be an issue at all for reasoning about a path forward?
>>
>
> This is a big question here, with the caveat that it's not just binance
> but in fact the majority of wallets and services that people use with
> bitcoin today.
> But the question remains as you phrased: At which point do we break
> backwards compatibility? Another analogy would be to have sunset the old
> P2PKH addresses during rollout of Segwit - it would certainly have led to
> Segwit getting rolled out faster. The rbf change actually breaks more
> things than that, takes more effort to address than just implementing a new
> address format. Previously in the Bitcoin Core process we've chosen to keep
> backwards compatibility and only roll out opt-in changes with broad
> consensus over them, with the default behavior being to not roll out
> changes that are controversial. At which point it's time to back away from
> that - I honestly don't know. There is probably such a point, and we should
> maybe have some kind of discussion around that topic on a higher level,
> just as you phrased it, and I'll paraphrase:
> If a majority of bitcoin wallets and services continue using legacy
> patterns and features, preventing progress, at which point do we want to
> break compatibility with them?
>
> Best,
> Sergej
>
>
> On Thu, Oct 20, 2022 at 3:59 PM Anthony Towns via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev
>>> wrote:
>>> > > If someone's going to systematically exploit your store via this
>>> > > mechanism, it seems like they'd just find a single wallet with a good
>>> > > UX for opt-in RBF and lowballing fees, and go to town -- not
>>> something
>>> > > where opt-in rbf vs fullrbf policies make any difference at all?
>>> > Sort of. But yes once this starts being abused systemically we will
>>> have to
>>> > do something else w RBF payments, such as crediting the amount in BTC
>>> to a
>>> > custodial account. But this option isn't available to your normal
>>> payment
>>> > processor type business.
>>>
>>> So, what I'm hearing is:
>>>
>>>  * lightning works great, but is still pretty small
>>>  * zeroconf works great for txs that opt-out of RBF
>>>  * opt-in RBF is a pain for two reasons:
>>> - people don't like that it's not treated as zeroconf
>>> - the risk of fiat/BTC exchange rate changes between
>>>   now and when the tx actually confirms is worrying
>>>   even if it hasn't caused real problems yet
>>>
>>> (Please correct me if that's too far wrong)
>>>
>>> Maybe it would be productive to explore this opt-in RBF part a bit
>>> more? ie, see if "we" can come up with better answers to some question
>>> along the lines of:
>>>
>>>  "how can we make on-chain payments for goods priced in fiat work well
>>>   for payees that opt-in to RBF?"
>>>
>>> That seems like the sort of thing that's better solved by a collaboration
>>> between wallet devs and merchant devs (and protocol devs?), rather than
>>> just one or the other?
>>>
>>> Is that something that we could talk about here? Or maybe it's better
>>> done via an optech workgroup or something?
>>>
>>> If "we'll credit your account in BTC, then work out the USD coversion
>>> and deduct that for your purchase, then you can do whatever you like
>>> with any remaining BTC from your on-chain payment" is the idea, maybe we
>>> should just roll with that design, but make it more decentralised: have
>>> the initial payment setup a lightning 

Re: [bitcoin-dev] Relaxing minimum non-witness transaction size policy restriction

[Greg Sanders via bitcoin-dev]

I don't doubt the use case(it's why I opened the issue!). I didn't want the
proposal to die in case people found it odd that 61, 62, 63, but not 64
bytes ended up being broadcast able.

Perhaps this is not an issue, especially since this isn't a consensus
change like the Great Consensus Cleanup. Willing to change my proposal and
PR if people have no strong objections.

Greg

On Thu, Oct 20, 2022, 7:21 PM Peter Todd  wrote:

> On Tue, Oct 11, 2022 at 08:50:07AM -0400, Greg Sanders via bitcoin-dev
> wrote:
> > Hello fellow Bitcoiners,
> >
> > After looking at some fairly exotic possible transaction types, I ran
> into
> > the current policy limit requiring transactions to be 85 non-witness
> > serialized bytes. This was introduced as a covert fix to policy fix
> > for CVE-2017-12842. Later the real motivation was revealed, but the
> > "reasonable" constant chosen was not.
> >
> > I'd like to propose relaxing this to effectively the value BlueMatt
> > proposed in the Great Consensus Cleanup: 65 non-witness bytes. This would
> > allow a single input, single output transaction with 4 bytes of OP_RETURN
> > padding, rather than padding out 21 bytes to get to p2wpkh size.
> >
> > The alternative would be to also allow anything below 64 non-witness
> bytes,
> > but this seems fraught with footguns for a few bytes gain.
>
> What footguns exactly? Spending a single input to OP_RETURN with no
> payload is
> a valid use to get rid of dust in the UTXO set.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Greg Sanders via bitcoin-dev]

> If it were growing in line with lightning capacity in BTC, per
bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
getting from 15% to 80% would then be about 8 years.

I'd caution against any metrics-based approach like this, unless it's
simply used for ballparking potential adoption curves to set a a timeframe
people can live with.

A large number of coins/users sit on custodial rails and this would
essentially encumber protocol developers to those KYC/AML institutions. If
Binance decides to never support Lightning in favor of BNC-wrapped BTC,
should this be an issue at all for reasoning about a path forward?

Hoping to be wrong,
Greg



On Thu, Oct 20, 2022 at 3:59 PM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev
> wrote:
> > > If someone's going to systematically exploit your store via this
> > > mechanism, it seems like they'd just find a single wallet with a good
> > > UX for opt-in RBF and lowballing fees, and go to town -- not something
> > > where opt-in rbf vs fullrbf policies make any difference at all?
> > Sort of. But yes once this starts being abused systemically we will have
> to
> > do something else w RBF payments, such as crediting the amount in BTC to
> a
> > custodial account. But this option isn't available to your normal payment
> > processor type business.
>
> So, what I'm hearing is:
>
>  * lightning works great, but is still pretty small
>  * zeroconf works great for txs that opt-out of RBF
>  * opt-in RBF is a pain for two reasons:
> - people don't like that it's not treated as zeroconf
> - the risk of fiat/BTC exchange rate changes between
>   now and when the tx actually confirms is worrying
>   even if it hasn't caused real problems yet
>
> (Please correct me if that's too far wrong)
>
> Maybe it would be productive to explore this opt-in RBF part a bit
> more? ie, see if "we" can come up with better answers to some question
> along the lines of:
>
>  "how can we make on-chain payments for goods priced in fiat work well
>   for payees that opt-in to RBF?"
>
> That seems like the sort of thing that's better solved by a collaboration
> between wallet devs and merchant devs (and protocol devs?), rather than
> just one or the other?
>
> Is that something that we could talk about here? Or maybe it's better
> done via an optech workgroup or something?
>
> If "we'll credit your account in BTC, then work out the USD coversion
> and deduct that for your purchase, then you can do whatever you like
> with any remaining BTC from your on-chain payment" is the idea, maybe we
> should just roll with that design, but make it more decentralised: have
> the initial payment setup a lightning channel between the customer and
> the merchant with the BTC (so it's not custodial), but do some magic to
> allow USD amounts to be transferred over it (Taro? something oracle based
> so that both parties are confident a fair exchange rate will be used?).
>
> Maybe that particular idea is naive, but having an actual problem to
> solve seems more constructive than just saying "we want rbf" "but we
> want zeroconf" all the time?
>
> (Ideally the lightning channels above would be dual funded so they could
> be used for routing more generally; but then dual funded channels are
> one of the things that get broken by lack of full rbf)
>
> > > I thought the "normal" avenue for fooling non-RBF zeroconf was to
> create
> > > two conflicting txs in advance, one paying the merchant, one paying
> > > yourself, connect to many peers, relay the one paying the merchant to
> > > the merchant, and the other to everyone else.
> > > I'm just basing this off Peter Todd's stuff from years ago:
> > >
> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
> > >
> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
> > Yeah, I know the list still rehashes a single incident from 10 years ago
> to
> > declare the entire practice as unsafe, and ignores real-world data that
> of
> > the last million transactions we had zero cases of this successfully
> > abusing us.
>
> I mean, the avenue above isn't easy to exploit -- you have to identify
> the merchant's node so that they get the bad tx, and you have to connect
> to many peers so that your preferred tx propogates to miners first --
> and probably more importantly, it's relatively easy to detect -- if the
> merchant has a few passive nodes that the attacker doesn't know about
> it, and uses those to watch for attempted doublespends while it tries
> to ensure the real tx has propogated widely. So it doesn't surprise me
> at all that it's not often attempted, and even less often successful.
>
> > > > Currently Lightning is somewhere around 15% of our total bitcoin
> > > > payments.
> > > So, based on last 

Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning

[Greg Sanders via bitcoin-dev]

So it doesn't look like I'm ignoring a good question:

No solid noninteractive ideas, unless we get some very flexible sighash
softfork. Interactively, I think you can get collaborative fee bumps under
the current consensus regime and ephemeral anchors. The child will just be
built with inputs from different people.

On Wed, Oct 19, 2022 at 11:12 AM James O'Beirne 
wrote:

> I'm also very happy to see this proposal, since it gets us closer to
> having a mechanism that allows the contribution to feerate in an
> "unauthenticated" way, which seems to be a very helpful feature for vaults
> and other contracting protocols.
>
> One possible advantage of the sponsors interface -- and I'm curious for
> your input here Greg -- is that with sponsors, assuming we relaxed the "one
> sponsor per sponsoree" constraint, multiple uncoordinated parties can
> collaboratively bump a tx's feerate. A simple example would be a batch
> withdrawal from an exchange could be created with a low feerate, and then
> multiple users with a vested interest of expedited confirmation could all
> "chip in" to raise the feerate with multiple sponsor transactions.
>
> Having a single ephemeral output seems to create a situation where a
> single UTXO has to shoulder the burden of CPFPing a package. Is there some
> way we could (possibly later) amend the ephemeral anchor interface to allow
> for this kind of collaborative sponsoring? Could you maybe see "chained"
> ephemeral anchors that would allow this?
>
>
> On Tue, Oct 18, 2022 at 12:52 PM Jeremy Rubin via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Excellent proposal and I agree it does capture much of the spirit of
>> sponsors w.r.t. how they might be used for V3 protocols.
>>
>> The only drawbacks I see is they don't work for lower tx version
>> contracts, so there's still something to be desired there, and that the
>> requirement to sweep the output must be incentive compatible for the miner,
>> or else they won't enforce it (pass the buck onto the future bitcoiners).
>> The Ephemeral UTXO concept can be a consensus rule (see
>> https://rubin.io/public/pdfs/multi-txn-contracts.pdf "Intermediate
>> UTXO") we add later on in lieu of managing them by incentive, so maybe it's
>> a cleanup one can punt.
>>
>> One question I have is if V3 is designed for lightning, and this is
>> designed for lightning, is there any sense in requiring these outputs for
>> v3? That might help with e.g. anonymity set, as well as potentially keep
>> the v3 surface smaller.
>>
>> On Tue, Oct 18, 2022 at 11:51 AM Greg Sanders via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> > does that effectively mark output B as unspendable once the child gets
>>> confirmed?
>>>
>>> Not at all. It's a normal spend like before, since the parent has been
>>> confirmed. It's completely unrestricted, not being bound to any
>>> V3/ephemeral anchor restrictions on size, version, etc.
>>>
>>> On Tue, Oct 18, 2022 at 11:47 AM Arik Sosman via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> Hi Greg,
>>>>
>>>> Thank you very much for sharing your proposal!
>>>>
>>>> I think there's one thing about the second part of your proposal that
>>>> I'm missing. Specifically, assuming the scenario of a v3 transaction with
>>>> three outputs, A, B, and the ephemeral anchor OP_TRUE. If a child
>>>> transaction spends A and OP_TRUE, does that effectively mark output B as
>>>> unspendable once the child gets confirmed? If so, isn't the implication
>>>> therefore that to safely spend a transaction with an ephemeral anchor, all
>>>> outputs must be spent? Thanks!
>>>>
>>>> Best,
>>>> Arik
>>>>
>>>> On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote:
>>>>
>>>> Hello Everyone,
>>>>
>>>> Following up on the "V3 Transaction" discussion here
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
>>>> , I would like to elaborate a bit further on some potential follow-on work
>>>> that would make pinning severely constrained in many setups].
>>>>
>>>> V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks
>>>> under some constraints[0]. This means that when a replacement is to be made
>>>> and propagated, it costs the expected amount of fees to do so. This 

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Greg Sanders via bitcoin-dev]

Another downside is that the sender may not opt into a non-pinnable future
format like "V3 transactions", making CPFP difficult. They may spend a lot
of fees to do this however, so maybe we're really reaching here.

On Wed, Oct 19, 2022 at 12:07 PM Sergej Kotliar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> It's an interesting idea, presumably it would work w the new package relay.
> Scorched earth bidding war is definitely fine to deter this type of abuse.
> Need to consider it more thoroughly from all sides tho. CPFP on the server
> side generally has a couple of downsides:
> * Requires a hot wallet to receive bitcoin
> * an entity that is reliably known to do CPFP can be abused by people
> looking to consolidate utxos, which can be quite costly. Might be solvable
> with a set of conditionals, and bad UX for abusers is less of a concern :)
>
> Will follow up after more deliberation, thanks!
>
>
> On Wed, 19 Oct 2022 at 17:43, Jeremy Rubin 
> wrote:
>
>> If they do this to you, and the delta is substantial, can't you sweep all
>> such abusers with a cpfp transaction replacing their package and giving you
>> the original txn?
>>
>> On Wed, Oct 19, 2022, 7:33 AM Sergej Kotliar via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi all,
>>>
>>> Chiming in on this thread as I feel like the real dangers of RBF as
>>> default policy aren't sufficiently elaborated here. It's not only about the
>>> zero-conf (I'll get to that) but there is an even bigger danger called the
>>> american call option, which risks endangering the entirety of BIP21 "Scan
>>> this QR code with your wallet to buy this product" model that I believe
>>> we've all come to appreciate. Specifically, in a scenario with high
>>> volatility and many transactions in the mempools (which is where RBF would
>>> come in handy), a user can make a low-fee transaction and then wait for
>>> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
>>> up, user can cancel his transaction and make a new - cheaper one. The
>>> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
>>> (it's actually quite easily managed), it's FX risk as the merchant must
>>> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
>>> some transactions lose money to FX and others earn money - that evens out
>>> in the end. But if there is an _easily accessible in the wallet_ feature to
>>> "cancel transaction" that means it will eventually get systematically
>>> abused. A risk of X% loss on many payments that's easy to systematically
>>> abuse is more scary than a rare risk of losing 100% of one occasional
>>> payment. It's already possible to execute this form of abuse with opt-in
>>> RBF, which may lead to us at some point refusing those payments (even with
>>> confirmation) or cumbersome UX to work around it, such as crediting the
>>> bitcoin to a custodial account.
>>>
>>> To compare zeroconf risk with FX risk: I think we've had one incident in
>>> 8 years of operation where a user successfully fooled our server to accept
>>> a payment that in the end didn't confirm. To successfully fool (non-RBF)
>>> zeroconf one needs to have access to mining infrastructure and probability
>>> of success is the % of hash rate controlled. This is simply due to the fact
>>> that the network currently won't propagage the replacement transaction to
>>> the miner, which is what's being discussed here. American call option risk
>>> would however be available to 100% of all users, needs nothing beyond the
>>> wallet app, and has no cost to the user - only upside.
>>>
>>> Bitrefill currently processes 1500-2000 onchain payments every day. For
>>> us, a world where bitcoin becomes de facto RBF by default, means that we
>>> would likely turn off the BIP21 model for onchain payments, instruct
>>> Bitcoin users to use Lightning or deposit onchain BTC to a custodial
>>> account that we have.
>>> This option is however not available for your typical
>>> BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
>>> from other merchants or payment providers how they see this new behavior
>>> and how they would counteract it.
>>>
>>> Currently Lightning is somewhere around 15% of our total bitcoin
>>> payments. This is very much not nothing, and all of us here want Lightning
>>> to grow, but I think it warrants a serious discussion on whether we want
>>> Lightning adoption to go to 100% by means of disabling on-chain commerce.
>>> For me personally it would be an easier discussion to have when Lightning
>>> is at 80%+ of all bitcoin transactions. Currently far too many bitcoin
>>> users simply don't have access to Lightning, and of those that do and hold
>>> their own keys Muun is the biggest wallet per our data, not least due to
>>> their ease-of-use which is under threat per the OP. It's hard to assess how
>>> many users would switch to Lightning in such a scenario, the communication
>>> 

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Greg Sanders via bitcoin-dev]

Isn't the extreme of this that the merchant tries to lock in gains on the
upswing via CPFP, and users on the downswing, both doing scorched earth,
tossing the delta to fees?

Seems like a MAD situation?

On Wed, Oct 19, 2022 at 11:44 AM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If they do this to you, and the delta is substantial, can't you sweep all
> such abusers with a cpfp transaction replacing their package and giving you
> the original txn?
>
> On Wed, Oct 19, 2022, 7:33 AM Sergej Kotliar via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi all,
>>
>> Chiming in on this thread as I feel like the real dangers of RBF as
>> default policy aren't sufficiently elaborated here. It's not only about the
>> zero-conf (I'll get to that) but there is an even bigger danger called the
>> american call option, which risks endangering the entirety of BIP21 "Scan
>> this QR code with your wallet to buy this product" model that I believe
>> we've all come to appreciate. Specifically, in a scenario with high
>> volatility and many transactions in the mempools (which is where RBF would
>> come in handy), a user can make a low-fee transaction and then wait for
>> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
>> up, user can cancel his transaction and make a new - cheaper one. The
>> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
>> (it's actually quite easily managed), it's FX risk as the merchant must
>> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
>> some transactions lose money to FX and others earn money - that evens out
>> in the end. But if there is an _easily accessible in the wallet_ feature to
>> "cancel transaction" that means it will eventually get systematically
>> abused. A risk of X% loss on many payments that's easy to systematically
>> abuse is more scary than a rare risk of losing 100% of one occasional
>> payment. It's already possible to execute this form of abuse with opt-in
>> RBF, which may lead to us at some point refusing those payments (even with
>> confirmation) or cumbersome UX to work around it, such as crediting the
>> bitcoin to a custodial account.
>>
>> To compare zeroconf risk with FX risk: I think we've had one incident in
>> 8 years of operation where a user successfully fooled our server to accept
>> a payment that in the end didn't confirm. To successfully fool (non-RBF)
>> zeroconf one needs to have access to mining infrastructure and probability
>> of success is the % of hash rate controlled. This is simply due to the fact
>> that the network currently won't propagage the replacement transaction to
>> the miner, which is what's being discussed here. American call option risk
>> would however be available to 100% of all users, needs nothing beyond the
>> wallet app, and has no cost to the user - only upside.
>>
>> Bitrefill currently processes 1500-2000 onchain payments every day. For
>> us, a world where bitcoin becomes de facto RBF by default, means that we
>> would likely turn off the BIP21 model for onchain payments, instruct
>> Bitcoin users to use Lightning or deposit onchain BTC to a custodial
>> account that we have.
>> This option is however not available for your typical
>> BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
>> from other merchants or payment providers how they see this new behavior
>> and how they would counteract it.
>>
>> Currently Lightning is somewhere around 15% of our total bitcoin
>> payments. This is very much not nothing, and all of us here want Lightning
>> to grow, but I think it warrants a serious discussion on whether we want
>> Lightning adoption to go to 100% by means of disabling on-chain commerce.
>> For me personally it would be an easier discussion to have when Lightning
>> is at 80%+ of all bitcoin transactions. Currently far too many bitcoin
>> users simply don't have access to Lightning, and of those that do and hold
>> their own keys Muun is the biggest wallet per our data, not least due to
>> their ease-of-use which is under threat per the OP. It's hard to assess how
>> many users would switch to Lightning in such a scenario, the communication
>> around it would be hard. My intuition says that the majority of the current
>> 85% of bitcoin users that pay onchain would just not use bitcoin anymore,
>> probably shift to an alt. The benefits of Lightning are many and obvious,
>> we don't need to limit onchain to make Lightning more appealing. As an
>> anecdote, we did experiment with defaulting to bech32 addresses some years
>> back. The result was that simply users of the wallets that weren't able to
>> pay to bech32 didn't complete the purchase, no support ticket or anything,
>> just "it didn't work 路‍♂️" and user moved on. We rolled it back, and later
>> implemented a wallet selector to allow modern wallets to pay to bech32
>> while other wallets can pay to P2SH. This type 

Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF against package limit pinning

[Greg Sanders via bitcoin-dev]

itments or eltoo settlement transactions,
> with only one fee-bumping output. It's a cool space performance trick, but
> a) I think this is still more a whiteboard idea than a sound proposal and
> b) sounds more a long-term, low-hanging fruit optimization of blockspace
> consumption.
>
> Best,
> Antoine
>
> Le mar. 18 oct. 2022 à 09:53, Greg Sanders via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a écrit :
>
>> Hello Everyone,
>>
>> Following up on the "V3 Transaction" discussion here
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
>> , I would like to elaborate a bit further on some potential follow-on work
>> that would make pinning severely constrained in many setups].
>>
>> V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks under
>> some constraints[0]. This means that when a replacement is to be made and
>> propagated, it costs the expected amount of fees to do so. This is a great
>> start. What's left in this subset of pinning is *package limit* pinning. In
>> other words, a fee-paying transaction cannot enter the mempool due to the
>> existing mempool package it is being added to already being too large in
>> count or vsize.
>>
>> Zooming into the V3 simplified scenario for sake of discussion, though
>> this problem exists in general today:
>>
>> V3 transactions restrict the package limit of a V3 package to one parent
>> and one child. If the parent transaction includes two outputs which can be
>> immediately spent by separate parties, this allows one party to disallow a
>> spend from the other. In Gloria's proposal for ln-penalty, this is worked
>> around by reducing the number of anchors per commitment transaction to 1,
>> and each version of the commitment transaction has a unique party's key on
>> it. The honest participant can spend their version with their anchor and
>> package RBF the other commitment transaction safely.
>>
>> What if there's only one version of the commitment transaction, such as
>> in other protocols like duplex payment channels, eltoo? What about multi
>> party payments?
>>
>> In the package RBF proposal, if the parent transaction is identical to an
>> existing transaction in the mempool, the parent will be detected and
>> removed from the package proposal. You are then left with a single V3 child
>> transaction, which is then proposed for entry into the mempool. In the case
>> of another parent output already being spent, this is simply rejected,
>> regardless of feerate of the new child.
>>
>> I have two proposed solutions, of which I strongly prefer the latter:
>>
>> 1) Expand a carveout for "sibling eviction", where if the new child is
>> paying "enough" to bump spends from the same parent, it knocks its sibling
>> out of the mempool and takes the one child slot. This would solve it, but
>> is a new eviction paradigm that would need to be carefully worked through.
>>
>> 2) Ephemeral Anchors (my real policy-only proposal)
>>
>> Ephemeral Anchors is a term which means an output is watermarked as an
>> output that MUST be spent in a V3 package. We mark this anchor by being the
>> bare script `OP_TRUE` and of course make these outputs standard to relay
>> and spend with empty witness data.
>>
>> Also as a simplifying assumption, we require the parent transaction with
>> such an output to be 0-fee. This makes mempool reasoning simpler in case
>> the child-spend is somehow evicted, guaranteeing the parent will be as well.
>>
>> Implications:
>>
>> a) If the ephemeral anchor MUST be spent, we can allow *any* value, even
>> dust, even 0, without worrying about bloating the utxo set. We relax this
>> policy for maximum smart contract flexibility and specification simplicity..
>>
>> b) Since this anchor MUST be spent, any spending of other outputs in the
>> same parent transaction MUST directly double-spend prior spends of the
>> ephemeral anchor. This causes the 1 block CSV timelock on outputs to be
>> removed in these situations. This greatly magnifies composability of smart
>> contracts, as now we can do things like safely splice directly into new
>> channels, into statechains, your custodial wallet account, your cold
>> wallet, wherever, without requiring other wallets to support arbitrary
>> scripts. Also it hurts that 1 CSV time locked scripts may not be miniscript
>> compatible to begin with...
>>
>> c) *Anyone* can bump the transaction, without any transaction key
>> material. This is essentially achieving

Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning

[Greg Sanders via bitcoin-dev]

> (see https://rubin.io/public/pdfs/multi-txn-contracts.pdf "Intermediate
UTXO")

I think I remember you trying to explain this to me a long time ago. Thanks
for the callback!

> One question I have is if V3 is designed for lightning, and this is
designed for lightning, is there any sense in requiring these outputs for
v3? That might help with e.g. anonymity set, as well as potentially keep
the v3 surface smaller.

The fingerprinting angle is yet another thing to consider. There are
definitely uses of V3 that do not require ephemeral anchors, and you can
save a healthy amount of bytes not requiring them. I think in the cases
where RBF of the parent is possible, at least.

f.e., I think V3 alone makes splicing robust even in the presence of
external inputs, since the commitment tx(s) can (package) RBF the splice at
any point. V3 may have enough value-add by itself where the additional
bytes and inability to opt out of "transaction sponsor" style bumps may be
undesirable.

Lastly this would tie deployments of these improvements together. Something
to consider.

Cheers,
Greg

On Tue, Oct 18, 2022 at 12:41 PM Jeremy Rubin  wrote:

> Excellent proposal and I agree it does capture much of the spirit of
> sponsors w.r.t. how they might be used for V3 protocols.
>
> The only drawbacks I see is they don't work for lower tx version
> contracts, so there's still something to be desired there, and that the
> requirement to sweep the output must be incentive compatible for the miner,
> or else they won't enforce it (pass the buck onto the future bitcoiners).
> The Ephemeral UTXO concept can be a consensus rule (see
> https://rubin.io/public/pdfs/multi-txn-contracts.pdf "Intermediate UTXO")
> we add later on in lieu of managing them by incentive, so maybe it's a
> cleanup one can punt.
>
> One question I have is if V3 is designed for lightning, and this is
> designed for lightning, is there any sense in requiring these outputs for
> v3? That might help with e.g. anonymity set, as well as potentially keep
> the v3 surface smaller.
>
> On Tue, Oct 18, 2022 at 11:51 AM Greg Sanders via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> > does that effectively mark output B as unspendable once the child gets
>> confirmed?
>>
>> Not at all. It's a normal spend like before, since the parent has been
>> confirmed. It's completely unrestricted, not being bound to any
>> V3/ephemeral anchor restrictions on size, version, etc.
>>
>> On Tue, Oct 18, 2022 at 11:47 AM Arik Sosman via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi Greg,
>>>
>>> Thank you very much for sharing your proposal!
>>>
>>> I think there's one thing about the second part of your proposal that
>>> I'm missing. Specifically, assuming the scenario of a v3 transaction with
>>> three outputs, A, B, and the ephemeral anchor OP_TRUE. If a child
>>> transaction spends A and OP_TRUE, does that effectively mark output B as
>>> unspendable once the child gets confirmed? If so, isn't the implication
>>> therefore that to safely spend a transaction with an ephemeral anchor, all
>>> outputs must be spent? Thanks!
>>>
>>> Best,
>>> Arik
>>>
>>> On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote:
>>>
>>> Hello Everyone,
>>>
>>> Following up on the "V3 Transaction" discussion here
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
>>> , I would like to elaborate a bit further on some potential follow-on work
>>> that would make pinning severely constrained in many setups].
>>>
>>> V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks under
>>> some constraints[0]. This means that when a replacement is to be made and
>>> propagated, it costs the expected amount of fees to do so. This is a great
>>> start. What's left in this subset of pinning is *package limit* pinning. In
>>> other words, a fee-paying transaction cannot enter the mempool due to the
>>> existing mempool package it is being added to already being too large in
>>> count or vsize.
>>>
>>> Zooming into the V3 simplified scenario for sake of discussion, though
>>> this problem exists in general today:
>>>
>>> V3 transactions restrict the package limit of a V3 package to one parent
>>> and one child. If the parent transaction includes two outputs which can be
>>> immediately spent by separate parties, this allows one party to disallow a
>>> spend from the other. In Gloria's proposal fo

Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning

[Greg Sanders via bitcoin-dev]

> does that effectively mark output B as unspendable once the child gets
confirmed?

Not at all. It's a normal spend like before, since the parent has been
confirmed. It's completely unrestricted, not being bound to any
V3/ephemeral anchor restrictions on size, version, etc.

On Tue, Oct 18, 2022 at 11:47 AM Arik Sosman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Greg,
>
> Thank you very much for sharing your proposal!
>
> I think there's one thing about the second part of your proposal that I'm
> missing. Specifically, assuming the scenario of a v3 transaction with three
> outputs, A, B, and the ephemeral anchor OP_TRUE. If a child transaction
> spends A and OP_TRUE, does that effectively mark output B as unspendable
> once the child gets confirmed? If so, isn't the implication therefore that
> to safely spend a transaction with an ephemeral anchor, all outputs must be
> spent? Thanks!
>
> Best,
> Arik
>
> On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote:
>
> Hello Everyone,
>
> Following up on the "V3 Transaction" discussion here
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
> , I would like to elaborate a bit further on some potential follow-on work
> that would make pinning severely constrained in many setups].
>
> V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks under
> some constraints[0]. This means that when a replacement is to be made and
> propagated, it costs the expected amount of fees to do so. This is a great
> start. What's left in this subset of pinning is *package limit* pinning. In
> other words, a fee-paying transaction cannot enter the mempool due to the
> existing mempool package it is being added to already being too large in
> count or vsize.
>
> Zooming into the V3 simplified scenario for sake of discussion, though
> this problem exists in general today:
>
> V3 transactions restrict the package limit of a V3 package to one parent
> and one child. If the parent transaction includes two outputs which can be
> immediately spent by separate parties, this allows one party to disallow a
> spend from the other. In Gloria's proposal for ln-penalty, this is worked
> around by reducing the number of anchors per commitment transaction to 1,
> and each version of the commitment transaction has a unique party's key on
> it. The honest participant can spend their version with their anchor and
> package RBF the other commitment transaction safely.
>
> What if there's only one version of the commitment transaction, such as in
> other protocols like duplex payment channels, eltoo? What about multi party
> payments?
>
> In the package RBF proposal, if the parent transaction is identical to an
> existing transaction in the mempool, the parent will be detected and
> removed from the package proposal. You are then left with a single V3 child
> transaction, which is then proposed for entry into the mempool. In the case
> of another parent output already being spent, this is simply rejected,
> regardless of feerate of the new child.
>
> I have two proposed solutions, of which I strongly prefer the latter:
>
> 1) Expand a carveout for "sibling eviction", where if the new child is
> paying "enough" to bump spends from the same parent, it knocks its sibling
> out of the mempool and takes the one child slot. This would solve it, but
> is a new eviction paradigm that would need to be carefully worked through.
>
> 2) Ephemeral Anchors (my real policy-only proposal)
>
> Ephemeral Anchors is a term which means an output is watermarked as an
> output that MUST be spent in a V3 package. We mark this anchor by being the
> bare script `OP_TRUE` and of course make these outputs standard to relay
> and spend with empty witness data.
>
> Also as a simplifying assumption, we require the parent transaction with
> such an output to be 0-fee. This makes mempool reasoning simpler in case
> the child-spend is somehow evicted, guaranteeing the parent will be as well.
>
> Implications:
>
> a) If the ephemeral anchor MUST be spent, we can allow *any* value, even
> dust, even 0, without worrying about bloating the utxo set. We relax this
> policy for maximum smart contract flexibility and specification simplicity..
>
> b) Since this anchor MUST be spent, any spending of other outputs in the
> same parent transaction MUST directly double-spend prior spends of the
> ephemeral anchor. This causes the 1 block CSV timelock on outputs to be
> removed in these situations. This greatly magnifies composability of smart
> contracts, as now we can do things like safely splice directly into new
> channels, into statechains, your cus

[bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF against package limit pinning

[Greg Sanders via bitcoin-dev]

Hello Everyone,

Following up on the "V3 Transaction" discussion here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
, I would like to elaborate a bit further on some potential follow-on work
that would make pinning severely constrained in many setups].

V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks under
some constraints[0]. This means that when a replacement is to be made and
propagated, it costs the expected amount of fees to do so. This is a great
start. What's left in this subset of pinning is *package limit* pinning. In
other words, a fee-paying transaction cannot enter the mempool due to the
existing mempool package it is being added to already being too large in
count or vsize.

Zooming into the V3 simplified scenario for sake of discussion, though this
problem exists in general today:

V3 transactions restrict the package limit of a V3 package to one parent
and one child. If the parent transaction includes two outputs which can be
immediately spent by separate parties, this allows one party to disallow a
spend from the other. In Gloria's proposal for ln-penalty, this is worked
around by reducing the number of anchors per commitment transaction to 1,
and each version of the commitment transaction has a unique party's key on
it. The honest participant can spend their version with their anchor and
package RBF the other commitment transaction safely.

What if there's only one version of the commitment transaction, such as in
other protocols like duplex payment channels, eltoo? What about multi party
payments?

In the package RBF proposal, if the parent transaction is identical to an
existing transaction in the mempool, the parent will be detected and
removed from the package proposal. You are then left with a single V3 child
transaction, which is then proposed for entry into the mempool. In the case
of another parent output already being spent, this is simply rejected,
regardless of feerate of the new child.

I have two proposed solutions, of which I strongly prefer the latter:

1) Expand a carveout for "sibling eviction", where if the new child is
paying "enough" to bump spends from the same parent, it knocks its sibling
out of the mempool and takes the one child slot. This would solve it, but
is a new eviction paradigm that would need to be carefully worked through.

2) Ephemeral Anchors (my real policy-only proposal)

Ephemeral Anchors is a term which means an output is watermarked as an
output that MUST be spent in a V3 package. We mark this anchor by being the
bare script `OP_TRUE` and of course make these outputs standard to relay
and spend with empty witness data.

Also as a simplifying assumption, we require the parent transaction with
such an output to be 0-fee. This makes mempool reasoning simpler in case
the child-spend is somehow evicted, guaranteeing the parent will be as well.

Implications:

a) If the ephemeral anchor MUST be spent, we can allow *any* value, even
dust, even 0, without worrying about bloating the utxo set. We relax this
policy for maximum smart contract flexibility and specification simplicity..

b) Since this anchor MUST be spent, any spending of other outputs in the
same parent transaction MUST directly double-spend prior spends of the
ephemeral anchor. This causes the 1 block CSV timelock on outputs to be
removed in these situations. This greatly magnifies composability of smart
contracts, as now we can do things like safely splice directly into new
channels, into statechains, your custodial wallet account, your cold
wallet, wherever, without requiring other wallets to support arbitrary
scripts. Also it hurts that 1 CSV time locked scripts may not be miniscript
compatible to begin with...

c) *Anyone* can bump the transaction, without any transaction key material.
This is essentially achieving Jeremy's Transaction Sponsors (
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html)
proposal without consensus changes. As long as someone gets a fully signed
parent, they can execute a bump with minimal wallet tooling. If a
transaction author doesn’t want a “sponsor”, do not include the output.

d) Lightning Carve-out(
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002240.html)
is superseded by this logic, as we are not restricted to two immediately
spendable output scenarios. In its place, robust multi-party fee bumping is
possible.

e) This also benefits more traditional wallet scenarios, as change outputs
can no longer be pinned, and RBF/CPFP becomes robust. Payees in simple
spends cannot pin you. Batched payouts become a lot less painful. This was
one of the motivating use cases that created the term “pinning” in the
first place(
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015717.html),
even if LN/L2 discussion has largely overtaken it due to HTLC theft risks.

Open Question(s):


   1.

   If we allow non-zero value in ephemeral 

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Greg Sanders via bitcoin-dev]

 AJ,

Thanks for the latest PR and discussion, even if we know we're all (very,
very, very) tired of it running almost 10 years now. I think we're close to
a resolution, (2), or (3) as you note.

As ariard notes in
https://github.com/bitcoin/bitcoin/pull/26323#issuecomment-1280071572 we
seem to have sketched out the sane design space for the transition, so now
it's time to choose how we want to spend our energy and time on this.

I do think patch complexity is a real concern, which
means fullrbf-signalling PR has a harder road to deployment and gets push
back from fullrbf-default-now folks who correctly argue this. It seems
useful to "prove a point" on the nature of these schemes, but not much else.

Personally I have no qualms with kicking back flag-day-fullrbf another
release cycle and 6 additional months to obviate the need for a 24.0
backport(however small!) and to give a bit more time to weigh choices.
People can begin testing with their node software on an opt-in basis(but
not the required ~10% of nodes), 25.0+ nodes will flag-day, then a year
from now the community can start testing if miners have picked up said
changes.

Speaking to no one in particular, there's no virtue in dragging on the
discussion to "prove a point" to "merchants"/"Core devs" when we could be
spending our time more wisely fixing the many other issues with our mempool
and wallet ecosystem.

Best,
Greg

On Sun, Oct 16, 2022 at 4:09 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Oct 13, 2022 at 02:35:22PM +1000, Anthony Towns via bitcoin-dev
> wrote:
> > On Wed, Oct 12, 2022 at 04:11:05PM +, Pieter Wuille via bitcoin-dev
> wrote:
> > > In my view, it is just what I said: a step towards getting full RBF
> > > on the network, by allowing experimentation and socializing the notion
> > > that developers believe it is time.
> > We "believe it is time" for what exactly, though? (a) To start
> > deprerecating accepting zeroconf txs on mainnet, over the next 6, 12 or
> > 18 months; or (b) to start switching mainnet mining and relay nodes over
> > to full RBF?
>
> For what it's worth, that was a serious question: I don't feel like I
> know what other people's answer to it is.
>
> Seems to me like there's fundamentally maybe three approaches:
>
>  1) Continue supporting and encouraging accepting unconfirmed "on-chain"
> payments indefinitely
>
>  2) Draw a line in the sand now, but give people who are currently
> accepting unconfirmed txs time to update their software and business
> model
>
>  3) Encourage mainnet miners and relay nodes to support unconditional
> RBF immediately, no matter how much that increases the risk to
> existing businesses that are still accepting unconfirmed txs
>
> I think Antoine gave a pretty decent rationale for why we shouldn't
> indefinitely continue with conditional RBF in [0] [1] -- it makes it
> easy to disrupt decentralised pooling protocols, whether that be for
> establishing lightning channels or coinjoins or anything else.
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
>
> It's also an unstable equilibrium -- if everyone does first-seen-is-final
> at the mempool level, everything is fine; but it only takes a few
> defectors to start relaying and mining full RBF txs to spoil zeroconf
> for everyone -- so even if it were desirable to maintain it forever,
> it's probably not actually possible to maintain it indefinitely.
>
> If so, that leaves the choice between (2) and (3). You might argue
> that there's a 4th option: ignore the problem and think about it later;
> but to me that seems like it will just eventually result in outcome (3).
>
>
> At least a few people are already running full RBF relay nodes [2] [3]
> [4], and there's a report that non-signalling RBF txs are now getting
> mined [5] when they weren't a few months ago [6]. I wasn't able to
> confirm the latter to my satisfaction: looking at mempool.observer, the
> non-RBF signalling conflicting txs don't seem to have been consistently
> paying a higher feerate, so I couldn't rule out the possibility that
> the difference might just be due to inconsistent relaying.
>
> [2] https://twitter.com/murchandamus/status/1552488955328831492
> [3] https://twitter.com/LukeDashjr/status/977211607947317254
> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html
> [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html
> [6]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html
>
> It seems to me that the best approach for implementing (3) would be
> to change the default for -mempoolfullrbf to true immediately, which
> is both what Knots has been doing for years, and what #26305 proposes
> [7].  So from seeing what people are actually *doing*, I could easily
> be convinced that (3) 

Re: [bitcoin-dev] Validity Rollups on Bitcoin

[Greg Sanders via bitcoin-dev]

Thanks for the writeup John,

Is there a one page cheat sheet of "asks" for transaction
introspection/OP_ZKP(?) and their uses both separately and together for
different rollup architectures?

On Tue, Oct 11, 2022 at 11:52 AM John Light via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> Today I am publishing "Validity Rollups on Bitcoin", a report I produced
> as part of the Human Rights Foundation's ZK-Rollup Research Fellowship.
>
> Here's the preface:
>
> > Ever since Satoshi Nakamoto first publicly announced bitcoin, its
> supporters, critics, and skeptics alike have questioned how the protocol
> would scale as usage increases over time. This question is more important
> than ever today, as blocks are increasingly full or close to full of
> transactions. So-called "Layer 2" (L2) protocols such as the Lightning
> Network have been deployed to take some transaction volume "offchain" but
> even Lightning needs to use _some_ bitcoin block space. It's clear that as
> bitcoin is adopted by more and more of the world's population (human and
> machine alike!) more block space will be needed. Another thread of inquiry
> concerns whether bitcoin's limited scripting capabilities help or hinder
> its value as electronic cash. Researchers and inventors have shown that the
> electronic cash transactions first made possible by bitcoin could be given
> new form by improving transaction privacy, supporting new types of smart
> contracts, and even creating entirely new blockchain-based assets.
> >
> > One of the results of the decade-plus research into scaling and
> expanding the capabilities of blockchains such as bitcoin is the invention
> of the validity rollup. Given the observed benefits that validity rollups
> have for the blockchains that have already implemented them, attention now
> turns to the question of whether they would be beneficial for bitcoin and
> existing bitcoin L2 protocols such as Lightning, too. We explore this
> question by examining validity rollups from several angles, including their
> history, how they work on a technical level, how they could be built on
> bitcoin, and what the benefits, costs, and risks of building them on
> bitcoin might be. We conclude that validity rollups have the potential to
> improve the scalability, privacy, and programmability of bitcoin without
> sacrificing bitcoin's core values or functionality as a peer-to-peer
> electronic cash system. Given the "trustless" nature of validity rollups as
> cryptographically-secured extensions of their parent chain, and given
> bitcoin's status as the most secure settlement layer, one could even say
> these protocols are a _perfect match_ for one another.
>
> You can find the full report here:
>
> https://bitcoinrollups.org
>
> Happy to receive any comments and answer any questions the bitcoin dev
> community may have about the report!
>
> Best regards,
> John Light
> ___
> 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] Relaxing minimum non-witness transaction size policy restriction

[Greg Sanders via bitcoin-dev]

Propagation of these kinds of transactions will be hampered until  becomes 10%+ of the network or so, like any other policy
relaxation.

On Tue, Oct 11, 2022 at 9:08 AM KING JAMES HRMH 
wrote:

> I am reading between the lines, wouldn't that mean an older client like
> v0.18 may not be able to receive a transaction from a newer client if it
> has to validate 85 non-witness serialized bytes? If so we should not
> concern but retain the backward compatibility especially since this was for
> a vulnerability? I have not checked to code to see what it does.
>
> KING JAMES HRMH
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
> --
> *From:* bitcoin-dev  on
> behalf of Greg Sanders via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org>
> *Sent:* Tuesday, October 11, 2022 11:50:07 PM
> *To:* Bitcoin Dev 
> *Subject:* [bitcoin-dev] Relaxing minimum non-witness transaction size
> policy restriction
>
> Hello fellow Bitcoiners,
>
> After looking at some fairly exotic possible transaction types, I ran into
> the current policy limit requiring transactions to be 85 non-witness
> serialized bytes. This was introduced as a covert fix to policy fix
> for CVE-2017-12842. Later the real motivation was revealed, but the
> "reasonable" constant chosen was not.
>
> I'd like to propose relaxing this to effectively the value BlueMatt
> proposed in the Great Consensus Cleanup: 65 non-witness bytes. This would
> allow a single input, single output transaction with 4 bytes of OP_RETURN
> padding, rather than padding out 21 bytes to get to p2wpkh size.
>
> The alternative would be to also allow anything below 64 non-witness
> bytes, but this seems fraught with footguns for a few bytes gain.
>
> The PR is here with more relevant background and alternatives included in
> the thread:
> https://github.com/bitcoin/bitcoin/pull/26265
>
> Please let us know if there's a fundamental issue with this approach, or
> any other feedback.
>
> Best,
> Greg
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Minor DoS vulnerability in BIP144 lack of tx witness data size limit

[Greg Sanders via bitcoin-dev]

There are a number of issues with adding arbitrary size restrictions to
consensus(I personally think it's additional complexity for negative gain),
but most of all this may resolve in burned coins.

On Tue, Oct 11, 2022 at 6:22 AM Loki Verloren via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> The recent 998 of 999 multisig segwit transaction highlights a problem
> with BIP144. As the solution applied for btcd shows, effectively a single
> transaction witness can be the same as the maximum block size.
>
> 11000 bytes may not be so unreasonable but now there is a special case
> with a block over 33k worth of witness data.
>
> A concrete limit should be set on the maximum size of a transaction
> witness, and this should be discussed in a more general sense about total
> transaction sizes.
>
> In the absence of a specification, it becomes impossible to properly
> implement and the status quo devolves to the actual implementation in the
> bitcoin core repository code.
>
> I think the weight calculation should escalate exponentially to discourage
> putting transactions like this on the chain. The price was equivalent to
> about $5 to do this.
>
> ___
> 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] Relaxing minimum non-witness transaction size policy restriction

[Greg Sanders via bitcoin-dev]

Hello fellow Bitcoiners,

After looking at some fairly exotic possible transaction types, I ran into
the current policy limit requiring transactions to be 85 non-witness
serialized bytes. This was introduced as a covert fix to policy fix
for CVE-2017-12842. Later the real motivation was revealed, but the
"reasonable" constant chosen was not.

I'd like to propose relaxing this to effectively the value BlueMatt
proposed in the Great Consensus Cleanup: 65 non-witness bytes. This would
allow a single input, single output transaction with 4 bytes of OP_RETURN
padding, rather than padding out 21 bytes to get to p2wpkh size.

The alternative would be to also allow anything below 64 non-witness bytes,
but this seems fraught with footguns for a few bytes gain.

The PR is here with more relevant background and alternatives included in
the thread:
https://github.com/bitcoin/bitcoin/pull/26265

Please let us know if there's a fundamental issue with this approach, or
any other feedback.

Best,
Greg
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Greg Sanders via bitcoin-dev]

David, Dario,

The only other effort I'm aware of is
https://github.com/bitcoin/bitcoin/pull/25600 , which as you can see, has
no consensus yet, isn't in 24.0, so at earliest would be 25.0, even if
somehow immediate resolution to the discussions were found.

Cheers,
Greg

On Fri, Oct 7, 2022 at 1:21 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2022-10-07 06:20, Dario Sneidermanis via bitcoin-dev wrote:
> > Hello list,
> >
> > I'm Dario, from Muun wallet [...] we've been reviewing the latest
> > bitcoin core release
> > candidate [...] we understood we had at least a year from the initial
> > opt-in  deployment until opt-out was deployed, giving us enough time to
> > adapt
> > Muun to the new policies. However, when reviewing the 24.0 release
> > candidate
> > just a few  days ago, we realized that zero-conf apps (like Muun) must
> > *immediately turn off* their zero-conf features.
>
> Hi Dario,
>
> I'm wondering if there's been some confusion.  There are two RBF-related
> items in the current release notes draft:[1]
>
> 1. "A new mempoolfullrbf option has been added, which enables the
> mempool to accept transaction replacement without enforcing BIP125
> replaceability signaling. (#25353)"
>
> 2. "The -walletrbf startup option will now default to true. The wallet
> will now default to opt-in RBF on transactions that it creates.
> (#25610)"
>
> The first item (from PR #25353) does allow a transaction without a
> BIP125 signal to be replaced, but this configuration option is set to
> disabled by default.[2]  There have been software forks of Bitcoin Core
> since at least 2015 which have allowed replacement of non-signaling
> transactions, so this option just makes that behavior a little bit more
> accessible to users of Bitcoin Core.  Some developers have announced
> their intention to propose enabling this option by default in a future
> release, which I think is the behavior you're concerned about, but
> that's not planned for the release of 24.0 to the best of my knowledge.
>
> The second item (from PR #25610) only affects Bitcoin Core's wallet, and
> in particular transactions created with it through the RPC interface.
> Those transactions will now default to signaling BIP125 replacability.
> This option has been default false for many years for the RPC, but for
> the GUI it's been default true since Bitcoin Core 0.16, released in
> early 2018[3].  It's no different than another popular wallet beginning
> to signal BIP125 support by default.
>
> In short, I don't think anything in Bitcoin Core 24.0 RC1 significantly
> changes the current situation related to transaction replacability.  All
> it does is give Bitcoin Core RPC users by default the same settings long
> used for GUI users and introduce an option that those who object to
> non-signalled RBF will later be able to use to disable their relay of
> non-signalled replacements.
>
> Does the above information resolve your concerns?
>
> Thanks,
>
> -Dave
>
> [1]
>
> https://github.com/bitcoin-core/bitcoin-devwiki/wiki/24.0-Release-Notes-draft
>
> [2] $ bin/bitcoind -help | grep -A3 mempoolfullrbf
>-mempoolfullrbf
> Accept transaction replace-by-fee without requiring
> replaceability
> signaling (default: 0)
>
> [3]
>
> https://bitcoincore.org/en/2018/02/26/release-0.16.0/#replace-by-fee-by-default-in-gui
> ___
> 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] New transaction policies (nVersion=3) for contracting protocols

[Greg Sanders via bitcoin-dev]

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

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

[Greg Sanders via bitcoin-dev]

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

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

[Greg Sanders via bitcoin-dev]

Hello Gloria,

Great work on synthesizing so much feedback into a proposal like this!

Death to carve-out rule.

I'd like to elaborate on some caveats and give a few incomplete thoughts.

There are basically two types of pinning in my estimation today:

1) rule#3 pinning: Make it uneconomical to replace whatever is in mempool
via large in size but low feerate junk that won't get mined anytime soon.
Replacing this with feerate-based policy seems apt, but fraught with DoS
risks.

2) package limit pinning: disallowing transaction propagation by package
limits being hit: size, ancestor count, descendant count. Today it is
mitigated by having all outputs be 1 csv timelocked, and having up to 2
anchor outputs(1 without carve-out rule).

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.

> "Does this fix Rule 3 Pinning?"

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. Due to this pinning attack there aren't many(?) deployed schemes
that use the signature type.

To mitigate this we would likely have to opt into a more complex policy
scheme, committing in the annex to "total mempool package weight", which
would allow mempool package limits to be picked at signing time.

Maybe ANYONECANPAY isn't a very useful paradigm in general, I cannot speak
to that, but it came up in eltoo-related designs using BIP118, which adopts
ACP-like signing behavior. This can be mitigated via straight forward
policy updates as well for BIP118 deployment, but off topic so will leave
it there.

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.

> "Can a V2 transaction replace a V3 transaction and vice versa?"

Circling back to my ACP point, this regime still allows pinning anytime you
are sharing a transaction with someone else where you don't have control
over *all* the inputs. So anytime you are doing a coinjoin-like
transaction, someone else's inputs can be self-double-spent, requiring you
to satisfy rule#3 when replacing theirs, if they're bip125-signaling. If
they're not bip125 signaling, you'll have to somehow detect this and/or
double-spend your input back to yourself.


Finally, a couple suggestions I've already made elsewhere:

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
do think that any L2 uptake of these new rules will take significant
time... maybe we should be a bit more ambitious?

Cheers,
Greg

On Fri, Sep 23, 2022 at 11:27 AM Gloria Zhao via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 

Re: [bitcoin-dev] More uses for CTV

[Greg Sanders via bitcoin-dev]

Hi James,

Could you elaborate on a L2 contract where speedy
settlement of the "first part" can be done, while having the rest
take their time? I'm more thinking about time-out based protocols.

Naturally my mind drifts to LN, where getting the proper commitment
transaction confirmed in a timely fashion is required to get the proper
balances back. The one hitch is that for HTLCs you still need speedy
resolution otherwise theft can occur. And given today's "layered
commitment" style transaction where HTLCs are decoupled from
the balance output timeouts, I'm not sure this can save much.

I don't know enough about vault designs to judge.

CTV style commitments have popped up in a couple places in my
work on eltoo(emulated via APO sig-in-script), but mostly in the
context of reducing interactivity in protocols, not in byte savings per se.

Thanks!

Greg

On Fri, Aug 19, 2022 at 12:34 PM James O'Beirne via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Over the past few months there have been a few potential uses of
> OP_CHECKTEMPLATEVERIFY (BIP-119)
> (https://github.com/bitcoin/bitcoin/pull/21702) that I've found
> interesting.
>
> # Congestion control redux
>
> When I first heard of CTV, a presentation Jeremy did at Chaincode back
> in 2018 or '19, he cited congestion control as one of its main use
> cases.
>
> The pitch went something like
>
> > When there is a high demand for blockspace it becomes very expensive
> > to make transactions. By using OP_CHECKTEMPLATEVERIFY, a large volume
> > payment processor may aggregate all their payments into a single O(1)
> > transaction for purposes of confirmation. Then, some time later, the
> > payments can be expanded out of that UTXO when the demand for
> > blockspace is decreased.
>
> (from https://utxos.org/uses/scaling/)
>
> At the time that didn't particularly grab me; the idea of smoothing fee
> rates seemed nice but marginal.
>
> But recently, two particular cases have made me reassess the value of
> congestion control.
>
> The first stems from the necessity of L2 protocols (payment channels,
> vaults, etc.) to, under certain circumstances, settle to the chain in a
> timely way in order to prevent abuse of the protocol. If some
> unexpected condition (a protocol exploit, large network disconnect, en
> masse vault breach, etc.) creates a situation where a large number of
> contracts need to settle to the chain in short order, mempools could
> fill up and protocol failures could happen for want of mempool/block
> space
> (
> https://github.com/jamesob/mempool.work#failure-one-mempool-to-rule-them-all
> ).
>
> In such a case, CTV could be used effectively to "compress" settlement
> commitments, get them on-chain, and then facilitate later unpacking of
> the CTV ouputs into the contract's true end state.
>
> This amounts to `n` contract-control outputs (e.g. a lightning funding
> transaction outputs) being spent into a single CTV output, which
> commits to the final settlement state. Multiple parties could
> trustlessly collaborate to settle into a single CTV output using
> SIGHASH_ALL | ANYONECANPAY. This requires a level of interaction
> similar to coinjoins.
>
> Put simply, CTV allows deferring the chainspace required for the final
> settlement outputs, but still immediately requires space for the
> inputs. This might sound like a temporary reprieve from half-ish of the
> space required to settle, but in many (most?) cases the outputs require
> substantially more space than the inputs, given that often we're
> settling a single UTXO into multiple payouts per party. A 2, 3, or
> 4-fold increase (depending on the contracting pattern) in capacity
> isn't a silver bullet, but it could ameliorate the damage of unexpected
> settlement "tidal waves."
>
> Conceptually, CTV is the most parsimonious way to do such a scheme,
> since you can't really get smaller than a SHA256 commitment, and that's
> essentially all CTV is.
>
> The second congestion control case is related to a recent post Bram
> made about stability under a no-block-subsidy regime. He posted
>
> > If transaction fees came in at an even rate over time all at the
> > exact same level then they work fine for security, acting similarly
> > to fixed block rewards. Unfortunately that isn't how it works in the
> > real world. There's a very well established day/night cycle with fees
> > going to zero overnight and even longer gaps on weekends and
> > holidays. If in the future Bitcoin is entirely dependent on fees for
> > security (scheduled very strongly) and this pattern keeps up
> > (overwhelmingly likely) then this is going to become a serious
> > problem.
>
> (from
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020702.html
> )
>
> Ryan Grant points out that CTV's congestion control use could help to
> smooth fees, creating a less spiky incentive to mine
> (
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020702.html
> ).
>
> Admittedly the original 

Re: [bitcoin-dev] Trying all address types in message signing verification (BIP)

[Greg Sanders via bitcoin-dev]

Please see BIP322
https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki

On Wed, Jul 20, 2022, 5:46 PM Peter (Coinkite Inc) via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Ali.
>
> > This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My
> proposal is simply going to standardize the practice of placing the segwit
> address into the address field, and does not require alterations to the
> message signing format like those BIPs.
>
> COLDCARD makes signatures exacly like that, when told to sign with a
> segwit address:
>
> % ckcc msg -s Hello
> Hello
> bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5
>
> HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYbbmqSRXqI5mNTWH9qkDoqZTpnPc=
>
> Unfortunately, I do not know of any "verifiers" that will accept the above
> signature, but there is no alternative since the various BIP-322 proposals
> never gained wide acceptance.
>
> Bitcoin Core does not support verifying that message, even though the UX
> makes it look possible. In effect segwit features never got implemented to
> that depth in Core. It's sad because the community is not maintaining core
> (Core?) features to the same depth as Satoshi did when he was active in the
> project.
>
> > PS. I am pretty sure that there is a BIP for the original signing method
> - what is its number?
>
> My understanding that the original approach was directly from Satoshi
> himself when the original client was written. It has never been codified in
> a BIP as far as I know.
>
> A related issue the the "ascii armor" that is sometimes used. It's a
> little like RFC2440  but
> newline-treatment isn't defined well enough for good interoperability, in
> my personal experience.
>
> So in summary... yes a "defacto" BIP is needed and useful to do, in my
> opinion. Then Core should be updated to support it as well.
>
> ---
> @DocHEX  ||  Coinkite  ||  PGP: A3A31BAD 5A2A5B10
>
>
> On Wed, Jul 20, 2022 at 04:10:09AM +, Ali Sherief wrote:
> > [my third attempt at getting this message through. Surprisingly, I
> managed to send this at the second try with the correct SMTP, From, To and
> all, but maybe it was caught in GreyListing (protonmail).]
> >
> > I was thinking about creating a BIP to address the lack of
> standardization for Segwit message signatures, but I want some advice
> before proceeding.
> >
> > The current state of affairs is that the wallets that do support signing
> and verifying a bitcoin message can only sign legacy addresses. It is
> technically possible to sign and verify segwit addresses, since ECDSA only
> depends on the public key (hence why you need a private key to sign
> messages).
> >
> > However, because there is no generally-accepted standard for signing
> segwit messages, the wallets that do support this feature simply insert the
> segwit address into the address field. Verification also only works using
> the procedure on that specific wallet software, if only because the
> conventional tools for verifying messages attempt to reconstruct a legacy
> address only.
> >
> > This BIP is not going to enforce anything, it's just going to set
> guidelines for writing a message signing and verification procedure.
> >
> > This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My
> proposal is simply going to standardize the practice of placing the segwit
> address into the address field, and does not require alterations to the
> message signing format like those BIPs.
> >
> > In summary, in the verification part, the following address hashing
> algorithms will be tried in sequence in an attempt to reconstruct the
> address in the signed message:
> > - P2PKH (legacy address)
> > - P2WPKH-P2SH (nested segwit)
> > - P2WPKH with version from 0 to MAX_WITNESS_VERSION (covers native
> segwit with version 0 as well as future native segwit address types such as
> Taproot) - where MAX_WITNESS_VERSION is the maximum supported witness
> version by the bech32 encoding.
> >
> > The verification procedure stops if any of these hashes yield the
> correct address, and fails if all of the above methods fail to reproduce
> the address in the signed message.
> >
> > In the signing procedure, the only modification is the insertion of the
> segwit address in place of the legacy address in the signed message.
> >
> > If this BIP is approved, it does not require any changes to existing
> signed messages, and the original sign/verify algorithms will continue to
> interoperate with this improved sign/verify algorithm, without any action
> necessary from the developers.
> >
> > So as you can see, this is the entire framework of the BIP I plan to
> draft. There is no need for any auxilliary feature additions into this BIP.
> I just want to hear the mailing list's advice about how I should draft such
> a BIP.
> >
> > - Ali
> >
> > PS. I am pretty sure that there is a BIP for the original signing method
> - what is its number?
> >
>

Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

[Greg Sanders via bitcoin-dev]

The attacker isn't guaranteed to spend *any* funds to disrupt the protocol
indefinitely, that's the issue here. In this scenario, her input double
spend is at an impractical feerate, and is never included in a block,
sitting at the bottom of the mempool.

The other users' only practical choice is to double-spend their own input
to get their money back(at competitive rates much higher than the
attacker), or wait and hope you win a propagation race somewhere.



On Fri, Jul 8, 2022 at 10:53 AM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, Jul 05, 2022 at 08:46:51PM +, alicexbt wrote:
> > Hi Peter,
> >
> > > Note that Wasabi already has a DoS attack vector in that a participant
> can stop
> > > participating after the first phase of the round, with the result that
> the
> > > coinjoin fails. Wasabi mitigates that by punishing participating in
> future
> > > rounds. Double-spends only create additional types of DoS attack that
> need to
> > > be detected and punished as well - they don't create a fundamentally
> new
> > > vulerability.
> >
> > I agree some DoS vectors are already mitigated however punishment in
> this case will be difficult because the transaction is broadcasted after
> signing and before coinjoin tx broadcast.
> >
> > Inputs are already checked multiple times for double spend during
> coinjoin round: https://github.com/zkSNACKs/WalletWasabi/pull/6460
> >
> > If all the inputs in the coinjoin transaction that failed to relay are
> checked and one or more are found to be spent later, what will be punished
> and how does this affect the attacker with thousands of UTXOs or normal
> users?
>
> Point is, the attacker is thousands of UTXOs can also DoS rounds by simply
> failing to complete the round. In fact, the double-spend DoS attack
> requires
> more resources, because for a double-spend to be succesful, BTC has to be
> spent
> on fees.
>
> It's just a fact of life that a motivated attacker can DoS attack Wasabi by
> spending money. That's a design choice that's serving them well so far.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> ___
> 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] Playing with full-rbf peers for fun and L2s security

[Greg Sanders via bitcoin-dev]

One key difference seems to be that properly punishing someone based on
mempool behavior seems much more difficult. As we all know there is no "the
mempool".



On Sun, Jun 26, 2022, 8:43 PM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sun, Jun 26, 2022 at 04:40:24PM +, alicexbt via bitcoin-dev wrote:
> > Hi Antoine,
> >
> > Thanks for sharing the DoS attack example with alternatives.
> >
> > > - Caroll broadcasts a double-spend of her own input C, the
> double-spend is attached with a low-fee (1sat/vb) and it does _not_ signal
> opt-in RBF
> > > - Alice broadcasts the multi-party transaction, it is rejected by the
> network mempools because Alice double-spend is already present
> >
> > I think this affects almost all types of coinjoin transaction including
> coordinator based implementations. I tried a few things and have already
> reported details for an example DoS attack to one of the team but there is
> no response yet.
> >
> > It was fun playing with RBF, DoS and Coinjoin. Affected projects should
> share their opinion about full-rbf as it seems it might improve things.
> >
> > Example:
> >
> > In Wasabi an attacker can broadcast a transaction spending input used in
> coinjoin after sending signature in the round. This would result in a
> coinjoin tx which never gets relayed:
> https://nitter.net/144bytes/status/1540727534093905920
>
> Note that Wasabi already has a DoS attack vector in that a participant can
> stop
> participating after the first phase of the round, with the result that the
> coinjoin fails. Wasabi mitigates that by punishing participating in future
> rounds. Double-spends only create additional types of DoS attack that need
> to
> be detected and punished as well - they don't create a fundamentally new
> vulerability.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> ___
> 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] Playing with full-rbf peers for fun and L2s security

[Greg Sanders via bitcoin-dev]

> It is not possible to guarantee that a transaction will be mined within N
blocks irrespective of fees. It is vulnerable if a project's security
relies on it, and should fix it by changing the security assumptions.

It's not possible to guarantee that any funds can be moved ever. But we
still build an entire system assuming we can via an interesting mix of
cryptography and incentives.

On Wed, Jun 15, 2022 at 9:45 PM alicexbt  wrote:

> Hi Greg,
>
>
> The security of LN and other related systems are something like: "given
> proper fees offered, can a transaction be mined within N blocks?" You're
> simply not allowed to out-bid your attacker in certain circumstances due to
> today's miner incentive-incompatible relay policies.
>
>
> It is not possible to guarantee that a transaction will be mined within N
> blocks irrespective of fees. It is vulnerable if a project's security
> relies on it, and should fix it by changing the security assumptions.
> Miners can try full-rbf or other policy without core so I won't consider
> opt-in as incentive-incompatible.
>
> > ... arguments about how many people RBF being sufficient or not ...
>
> The idea that we should only build robust systems after the broken ones
> are attacked is not a serious argument.
>
>
> Its true and was even mentioned in PR #16171 that a policy is only useful
> if enough nodes and miners follow it. We should build robust systems but I
> don't think this change will help in doing it.
>
> This is a strawman.
>
> Full-RBF is a simple, obvious, incentive-compatible step to getting closer
> to more robust layer two systems. Fixing the rest of the holes is for
> future proposals which are a bit more involved and definitely less mature.
>
>
> I do not have issues with multiple RBF policies being tried out and
> full-rbf being one of them. My disagreements are with rationale, lack of
> basic options in Bitcoin Core to employ/disable different RBF policies
> and a few arguments made in support for full-rbf. Whether it appears
> strawman or offtopic on github, there should be a place to share these
> disagreements.
>
> If Knots has these knobs, just use Knots rather than lobby all
> implementations to have miner incentive incompatible knobs?
>
>
> Everyone can share options that would help users in the bitcoin
> implementation used by 90% nodes. I don't think this is reserved only for a
> few developers. I would personally use Knots and others are free to try the
> suggestion or continue using Bitcoin Core.
>
> /dev/fd0
>
>
> Sent with Proton Mail  secure email.
>
> --- Original Message ---
> On Thursday, June 16th, 2022 at 6:32 AM, Greg Sanders <
> gsander...@gmail.com> wrote:
>
> > If something relies on a policy which can be changed without breaking
> consensus rules, how is it secure in any case with or without full rbf?
>
> The security of LN and other related systems are something like: "given
> proper fees offered, can a transaction be mined within N blocks?" You're
> simply not allowed to out-bid your attacker in certain circumstances due to
> today's miner incentive-incompatible relay policies.
>
> There is also a time-value dimension to this with other simpler systems
> where your funds can be locked up for potentially weeks for similar reasons.
>
> > ... arguments about how many people RBF being sufficient or not ...
>
> The idea that we should only build robust systems after the broken ones
> are attacked is not a serious argument.
>
> > I am not opposed to full-rbf; rather, I am opposed to the notion that
> full-rbf will solve all problems
>
> This is a strawman.
>
> Full-RBF is a simple, obvious, incentive-compatible step to getting closer
> to more robust layer two systems. Fixing the rest of the holes is for
> future proposals which are a bit more involved and definitely less mature.
>
> > would suggest users to try Bitcoin Knots instead
> > Developers should provide basic RBF policy options rather than
> attempting to define what constitutes a good policy and removing the
> ability to disable something when necessary.
>
> If Knots has these knobs, just use Knots rather than lobby all
> implementations to have miner incentive incompatible knobs?
>
> Cheers,
> Greg
>
> On Wed, Jun 15, 2022 at 8:27 PM alicexbt via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Antoine,
>>
>>
>> Thanks for opening the pull request to add support for full-rbf in
>> Bitcoin Core. I have a few disagreements with the approach and questions.
>>
>> Recent discussions among LN devs have brought back on the surface
>> concerns about the security of multi-party funded transactions (coinjoins,
>> dual-funded LN channels, on-chain DLCs, ...). It turns out there is a
>> low-fruit, naive DoS vector playable against the funding flow of any such
>> construction due to the lack of existent full-rbf transaction-relay
>> topology on today's p2p network [0] [1].
>>
>>
>> 1)If something relies on a policy which can be changed 

Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

[Greg Sanders via bitcoin-dev]

> If something relies on a policy which can be changed without breaking
consensus rules, how is it secure in any case with or without full rbf?

The security of LN and other related systems are something like: "given
proper fees offered, can a transaction be mined within N blocks?" You're
simply not allowed to out-bid your attacker in certain circumstances due to
today's miner incentive-incompatible relay policies.

There is also a time-value dimension to this with other simpler systems
where your funds can be locked up for potentially weeks for similar reasons.

>  ... arguments about how many people RBF being sufficient or not ...

The idea that we should only build robust systems after the broken ones are
attacked is not a serious argument.

> I am not opposed to full-rbf; rather, I am opposed to the notion that
full-rbf will solve all problems

This is a strawman.

Full-RBF is a simple, obvious, incentive-compatible step to getting closer
to more robust layer two systems. Fixing the rest of the holes is for
future proposals which are a bit more involved and definitely less mature.

>  would suggest users to try Bitcoin Knots instead
> Developers should provide basic RBF policy options rather than attempting
to define what constitutes a good policy and removing the ability to
disable something when necessary.

If Knots has these knobs, just use Knots rather than lobby all
implementations to have miner incentive incompatible knobs?

Cheers,
Greg

On Wed, Jun 15, 2022 at 8:27 PM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Antoine,
>
>
> Thanks for opening the pull request to add support for full-rbf in Bitcoin
> Core. I have a few disagreements with the approach and questions.
>
> Recent discussions among LN devs have brought back on the surface concerns
> about the security of multi-party funded transactions (coinjoins,
> dual-funded LN channels, on-chain DLCs, ...). It turns out there is a
> low-fruit, naive DoS vector playable against the funding flow of any such
> construction due to the lack of existent full-rbf transaction-relay
> topology on today's p2p network [0] [1].
>
>
> 1)If something relies on a policy which can be changed without breaking
> consensus rules, how is it secure in any case with or without full rbf? If
> I write a python script that expects user to enter char 'a' or 'b' but user
> can enter 'c' and there is no code to handle exceptions or other chars,
> will it be secure?
>
> 2)full-rbf is not default in the 2 open pull requests, so this experiment
> still relies on users changing RBF policies manually. If majority of nodes
> use default opt-in policy, how would this affect vulnerable projects?
>
> If you're a mining operator looking to increase your income, you might be
> interested to experiment with full-rbf as a policy.
>
>
> Miners can only increase their income if users replace transactions. 2-3%
> transactions are replaced with opt-in RBF, if someone did not replace
> earlier why would they do it with full RBF? Or even if we add some users in
> it who could not signal for some reasons, do you think it would be anything
> above 5%?
>
> If you're a Bitcoin user or business and you don't like full-rbf, please
> express an opinion on how it might affect your software/operations. I'm
> always interested to learn more about mempool and transaction-relay
> interactions with upper-layers and applications and to listen to feedback
> in those areas, and I guess a lot of other Bitcoin researchers/devs too. I
> know there have been a lot of concerns about full-rbf in the past, however
> I believe the Bitcoin ecosystem has matured a lot since then.
>
>
> I am not opposed to full-rbf; rather, I am opposed to the notion that
> full-rbf will solve all problems and the lack of basic options in Bitcoin
> Core to employ/disable different RBF policies. There is also a speculation
> about making full RBF default in an year which isn't relevant to discuss at
> this point without trying different RBF policies.
>
> I would suggest users to try Bitcoin Knots instead which already has an
> option to disable all RBF policies if required, opt-in and full RBF policy.
> This can also be done using GUI if not familiar with config option
> mempoolreplacement​.
>
> The rationale in PR #16171 was insufficient to justify removing it in the
> first place, had 2 NACKs and was reopened to merge it. Why bother with a
> few lines of code that may allow someone disable it if required in local
> mempool since it's only useful when a big percentage of miners utilize it
> and essentially underused according to the PR author? Developers should
> provide basic RBF policy options rather than attempting to define what
> constitutes a good policy and removing the ability to disable something
> when necessary.
>
>
> /dev/fd0
>
> Sent with Proton Mail  secure email.
>
> --- Original Message ---
> On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via 

Re: [bitcoin-dev] Package Relay Proposal

[Greg Sanders via bitcoin-dev]

Hi Gloria,

Thanks for working on this important proposal!

Still a lot to digest, but I just had on area of comment/question:

> A child-with-unconfirmed-parents package sent between nodes must abide by
the rules below, otherwise the package is malformed and the sender should
be disconnected.

> However, if the child has confirmed parents, they must not be in the
package.

If my naive understanding is correct, this means things like otherwise
common situations such as a new block will result in disconnects, say when
the sender doesn't hear about a new block which makes the relay package
superfluous/irrelevant. Similar would be disconnection
when confirmed gets turned into unconfirmed, but those situations are
extremely uncommon. The other rules are entirely under the control
of the sender, which leads me to wonder if it's appropriate.

Cheers,
Greg

On Tue, May 17, 2022 at 12:09 PM Gloria Zhao via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi everybody,
>
> I’m writing to propose a set of p2p protocol changes to enable package
> relay, soliciting feedback on the design and approach. Here is a link
> to the most up-to-date proposal:
>
> https://github.com/bitcoin/bips/pull/1324
>
> If you have concept or approach feedback, *please respond on the
> mailing list* to allow everybody to view and participate in the
> discussion. If you find a typo or inaccurate wording, please feel free
> to leave suggestions on the PR.
>
> I’m also working on an implementation for Bitcoin Core.
>
>
> The rest of this post will include the same contents as the proposal,
> with a bit of reordering and additional context. If you are not 100%
> up-to-date on package relay and find the proposal hard to follow, I
> hope you find this format more informative and persuasive.
>
>
> ==Background and Motivation==
>
> Users may create and broadcast transactions that depend upon, i.e.
> spend outputs of, unconfirmed transactions. A “package” is the
> widely-used term for a group of transactions representable by a
> connected Directed Acyclic Graph (where a directed edge exists between
> a transaction that spends the output of another transaction).
>
> Incentive-compatible mempool and miner policies help create a fair,
> fee-based market for block space. While miners maximize transaction
> fees in order to earn higher block rewards, non-mining users
> participating in transaction relay reap many benefits from employing
> policies that result in a mempool with the same contents, including
> faster compact block relay and more accurate fee estimation.
> Additionally, users may take advantage of mempool and miner policy to
> bump the priority of their transactions by attaching high-fee
> descendants (Child Pays for Parent or CPFP).  Only considering
> transactions one at a time for submission to the mempool creates a
> limitation in the node's ability to determine which transactions have
> the highest feerates, since it cannot take into account descendants
> until all the transactions are in the mempool. Similarly, it cannot
> use a transaction's descendants when considering which of two
> conflicting transactions to keep (Replace by Fee or RBF).
>
> When a user's transaction does not meet a mempool's minimum feerate
> and they cannot create a replacement transaction directly, their
> transaction will simply be rejected by this mempool. They also cannot
> attach a descendant to pay for replacing a conflicting transaction.
> This limitation harms users' ability to fee-bump their transactions.
> Further, it presents a security issue in contracting protocols which
> rely on **presigned**, time-sensitive transactions to prevent cheating
> (HTLC-Timeout in LN Penalty [1] [2] [3], Unvault Cancel in Revault
> [4], Refund Transaction in Discreet Log Contracts [5], Updates in
> eltoo [6]). In other words, a key security assumption of many
> contracting protocols is that all parties can propagate and confirm
> transactions in a timely manner.
>
> In the past few years, increasing attention [0][1][2][3][6] has been
> brought to **pinning attacks**, a type of censorship in which the
> attacker uses mempool policy restrictions to prevent a transaction
> from being relayed or getting mined.  TLDR: revocation transactions
> must meet a certain confirmation target to be effective, but their
> feerates are negotiated well ahead of broadcast time. If the
> forecasted feerate was too low and no fee-bumping options are
> available, attackers can steal money from their counterparties. I walk
> through a concrete example for stealing Lightning HTLC outputs at
> ~23:58 in this talk [7][8].  Note that most attacks are only possible
> when the market for blockspace at broadcast time  demands much higher
> feerates than originally anticipated at signing time. Always
> overestimating fees may sidestep this issue temporarily (while mempool
> traffic is low and predictable), but this solution is not foolproof
> and wastes users' money. The feerate 

Re: [bitcoin-dev] Improving BIP 8 soft fork activation

[Greg Sanders via bitcoin-dev]

I think you may be confused. Mandatory signaling is not the same thing as
mandatory activation on timeout, aka Lock On Timeout aka LOT=true.

These are two related but separate things.

On Thu, May 12, 2022, 6:53 PM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Russell,
>
>
> As far as I understand things, I believe the whole notion of a MUST_SIGNAL
> state is misguided today. Please correct me if I'm misunderstanding
> something here.
>
> Back when BIP8 was first proposed by Shaolin Fry, we were in a situation
> where many existing clients waiting for segwit signalling had already been
> deployed. The purpose of mandatory signaling at that point in time was to
> ensure all these existing clients would be activated together with any BIP8
> clients.
>
>
> I won't consider it misguided. Not using MUST_SIGNAL gives opportunity for
> drama and politics during signaling. MUST_SIGNAL phase is initiated when
> height + 2016 >= timeoutheight and if a mining pool is still not sure about
> signaling at that point, maybe they are not interested in mining bitcoin
> anymore.
>
> Rephrasing 'motivation' section in BIP 8:
>
> BIP 9 activation is dependent on near unanimous hashrate signaling which
> may be impractical and result in veto by a small minority of
> non-signaling hashrate. All consensus rules are ultimately enforced by full
> nodes, eventually any new soft fork will be enforced by the economy. BIP 8
> provides optional flag day activation after a reasonable time, as well as
> for accelerated activation by majority of hash rate before the flag date.
>
> We also don't need such a signal span over multiple blocks. Indeed, using
> version bits and signaling over multiple blocks is quite bad because it
> risks losing mining power if miners don't conform, or are unable to
> conform, to the version bits signal. (Recall at the time taproot's
> signaling period started, the firmware needed for many miners to signal
> version bits did not even exist yet!).
>
>
> Solutions to these problems:
>
> 1)Developers plan and ship the binaries with activation code in time.
> 2)Mining pools pay attention, participate in soft fork discussions, hire
> competent developers and reach out to developers in community if require
> help.
> 3)Mining pools understand the loss involved in mining invalid blocks and
> upgrade during the first month of signaling.
>
> If some mining pools still mine invalid blocks, Bitcoin should still work
> normally as it did during May-June 2021 when 50% hashrate went down due to
> some issues in China.
>
>
> /dev/fd0
>
> Sent with ProtonMail  secure email.
>
> --- Original Message ---
> On Thursday, May 12th, 2022 at 12:52 AM, Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hi alicexbt,
>
> As far as I understand things, I believe the whole notion of a MUST_SIGNAL
> state is misguided today. Please correct me if I'm misunderstanding
> something here.
>
> Back when BIP8 was first proposed by Shaolin Fry, we were in a situation
> where many existing clients waiting for segwit signalling had already been
> deployed. The purpose of mandatory signaling at that point in time was to
> ensure all these existing clients would be activated together with any BIP8
> clients.
>
> However, if such other clients do not exist, the MUST_SIGNAL state no
> longer accomplishes its purpose. Going forward, I think there is little
> reason to expect such other clients to exist alongside a BIP8 deployment.
> If everyone uses a BIP8 deployment, then there are no other clients to
> activate. Alternatively, Speedy Trial was specifically designed to avoid
> this parallel deployment for the reason that several people object to
> allowing their client's non-BIP8 activation logic to be hijacked in this
> manner.
>
> Now I understand that some people would like *some* signal on the chain
> that indicates a soft-fork activation in order to allow people who object
> to the fork to make an "anti-fork" that rejects blocks containing the
> soft-fork signal. And while some sort of mandatory version bit signaling
> *could* be used for this purpose, we do not *have* to use version bits. We
> also don't need such a signal span over multiple blocks. Indeed, using
> version bits and signaling over multiple blocks is quite bad because it
> risks losing mining power if miners don't conform, or are unable to
> conform, to the version bits signal. (Recall at the time taproot's
> signaling period started, the firmware needed for many miners to signal
> version bits did not even exist yet!).
>
> A soft-fork signal to enable an "anti-fork" only needs to be on a single
> block and it can be almost anything. For example we could have a signal
> that at the block at lockin or perhaps the block at activation requires
> that the coinbase must *not* contain the suffix "taproot sucks!". This
> suffices to prepare an "anti-fork" which would simply require that 

Re: [bitcoin-dev] Bringing a nuke to a knife fight: Transaction introspection to stop RBF pinning

[Greg Sanders via bitcoin-dev]

Great point in this specific case I unfortunately didn't consider! So
basically the design degenerates to the last option I gave, where the
counterparty
can send off N(25) weight-bound packages.

A couple thoughts:

0) Couldn't we relative-time lock update transactions's state input by 1
block as well to close the vector off? People are allowed
one "update transaction package" at a time in mempool, so if detected
in-mempool it can be RBF'd, or in-block can be immediately responded to.
1) other usages of ANYONECANPAY like behavior may not have these issues,
like vault structures.


On Thu, May 12, 2022, 3:17 AM David A. Harding  wrote:

> On 2022-05-10 08:53, Greg Sanders via bitcoin-dev wrote:
> > We add OPTX_SELECT_WEIGHT(pushes tx weight to stack, my addition to
> > the proposal) to the "state" input's script.
> > This is used in the update transaction to set the upper bound on the
> > final transaction weight.
> > In this same input, for each contract participant, we also
> > conditionally commit to the change output's scriptpubkey
> > via OPTX_SELECT_OUTPUT_SCRIPTPUBKEY and OPTX_SELECT_OUTPUTCOUNT==2.
> > This means any participant can send change back
> > to themselves, but with a catch. Each change output script possibility
> > in that state input also includes a 1 block
> > CSV to avoid mempool spending to reintroduce pinning.
>
> I like the idea!   However, I'm not sure the `1 CSV` trick helps much.
> Can't an attacker just submit to the mempool their other eltoo state
> updates?  For example, let's assume Bob and Mallory have a channel with
>  >25 updates and Mallory wants to prevent update[-1] from being committed
> onchain before its (H|P)TLC timeout.  Mallory also has at least 25
> unencumbered UTXOs, so she submits to the mempool update[0], update[1],
> update[...], update[24]---each of them with a different second input to pay
> fees.
>
> If `OPTX_SELECT_WEIGHT OP_TX` limits each update's weight to 1,000
> vbytes[1] and the default node relay/mempool policy of allowing a
> transaction and up to 24 descendants remains, Mallory can pin the
> unsubmitted update[-1] under 25,000 vbytes of junk---which is 25% of
> what she can pin under current mempool policies.
>
> Alice can't RBF update[0] without paying for update[1..24] (BIP125 rule
> #3), and an RBF of update[24] will have its additional fees divided by
> its size plus the 24,000 vbytes of update[1..24].
>
> To me, that seems like your proposal makes escaping the pinning at most
> 75% cheaper than today.  That's certainly an improvement---yay!---but
> I'm not sure it eliminates the underlying concern.  Also depending on
> the mempool ancestor/descendant limits makes it harder to raise those
> limits in the future, which is something I think we might want to do if
> we can ensure raising them won't increase node memory/CPU DoS risk.
>
> I'd love to hear that my analysis is missing something though!
>
> Thanks!,
>
> -Dave
>
> [1] 1,000 vbytes per update seems like a reasonable value to me.
> Obviously there's a tradeoff here: making it smaller limits the amount
> of pinning possible (assuming mempool ancestor/descendant limits remain)
> but also limits the number and complexity of inputs that may be added.
> I don't think we want to discourage people too much from holding
> bitcoins in deep taproot trees or sophisticated tapscripts.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bringing a nuke to a knife fight: Transaction introspection to stop RBF pinning

[Greg Sanders via bitcoin-dev]

Hello devs,

I've had this thought rattling around and thought it was worth putting to a
wider audience since
I haven't really seen it in other contexts. I've been working on eltoo
designs for Elements and
eventual inclusion into Bitcoin. With that in mind there's been a
reasonable amount of discussion
on the remaining unknowns on how well eltoo could work. To me the biggest
issue is BIP125 rule#3.

To quote:"The replacement transaction pays an absolute fee of at least the
sum paid by the original
transactions."

In the ANYONECANPAY-like scenarios like eltoo that require "bring your own
fees", this essentially
means the counterparty(or anyone, if you don't include chaperone sigs[0])
can post a series of low
feerate update transactions, or the final update, with bloated
inputs/outputs(depending on flags),
and this results in illicit HTLC timeouts as the channel is unable to be
settled in time, unless you fork
over quite a few sats. This is a problem in both "vanilla" eltoo[1] from
the original paper, as well as the
"layered commitments" style of eltoo[2]. This problem is highly reminiscent
of the ANYONECANPAY
pinning that others have discussed for vaults and other usecases, in that
anyone can include new
inputs(and sometimes outputs) to make the overall feerate lower. To
promptly get the final transactions
settled, you are forced to over-pay, and essentially refund your griefing
counterparty by knocking their
inputs out of the mempool.

Fixing BIP125 rule#3 would be great. It's also a while out at a minimum.

There are thoughts on how to mitigate some cases[3] of this pinning using
policy, and could be extended
to cover this particular pinning case(restrict both transaction weight AND
the weight of the descendant
package, or maybe just include the txns weight in the original idea?). This
might be the simplest idea,
if it ends up being deemed incentive compatible and deployed.

In case the above is not incentive compatible, we can use more drastic
measures. Another tactic would
be to use transaction introspection opcodes to smooth around these policy
issues.

Elements has its own set of transaction introspection codes[4], but fairly
standard introspection codes
seem to be sufficient.

This example is using Rusty's quite recent OP_TX proposal[5] with a single
extension but as mentioned
before it's all fairly standard. The actual eltoo-enabling opcode
implementation is basically orthogonal
to this problem, so I'm simply focusing on restricting the size of the
transaction package being
submitted to mempools.

For simplicity of a working example, we'll assume a set of "state" outputs
that are continuously being spent
off-chain and sent to a committed set of outputs. In vanilla eltoo case
this corresponds to the first
input and output you typically see in diagrams. The state transitions
include no fees themselves,
sending inputs of sum value N to outputs that sum to the value of N.
Vanilla eltoo uses SIGHASH_SINGLE
to bind just the first input/ouput pair. To post on-chain, we will need to
include at least one input,
and likely an output for change.

We add OPTX_SELECT_WEIGHT(pushes tx weight to stack, my addition to the
proposal) to the "state" input's script.
This is used in the update transaction to set the upper bound on the final
transaction weight.
In this same input, for each contract participant, we also conditionally
commit to the change output's scriptpubkey
via OPTX_SELECT_OUTPUT_SCRIPTPUBKEY and OPTX_SELECT_OUTPUTCOUNT==2. This
means any participant can send change back
to themselves, but with a catch. Each change output script possibility in
that state input also includes a 1 block
CSV to avoid mempool spending to reintroduce pinning. This allows the
change value to be anything, contra to
what SIGHASH_ALL would give you instead.

With this setup, you can't CPFP-spend the fee change outputs you create,
but you can RBF as much as
you'd like by RBFing at higher feerates, using any number of inputs you'd
like provided the total tx
weight doesn't exceed the OPTX_SELECT_WEIGHT argument.

With more engineering we can re-enable CPFP of this change output as well.
Handwaves here, but we could
encumber change outputs to either the aformentioned 1 block CSV encumbered
outputs or one to another
OPTX_SELECT_WEIGHT, recursively. This would allow each counterparty to CPFP
N times, each transaction
a maximum weight, and use the 1 block CSV as an "escape hatch" to get their
fee output back out from
the covenant structure. We could mix and match strategies here as well
allowing bigger transactions at
each step, or more steps. I suspect you'd want a single weight-bound CPFP
that can later be RBF'd any
number of times under this same weight limit.

TL;DR: Mempool is hard, let's use transaction weight, output count, and
output scriptpubkey,
and ??? introspection to avoid solving life's hard problems.

0:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-May/001994.html
1: https://blockstream.com/eltoo.pdf
2:

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Greg Sanders via bitcoin-dev]

The proposed use case for the ANYSCRIPT part of APOAS explicitly doesn't
commit to amount, so I'd also assume it not be re-added or at least be able
to be opened out.

On Sat, Apr 30, 2022, 4:47 AM Nadav Ivgi via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi darosior,
>
> It's interesting to note that APOAS|SINGLE (with the ANYONECANPAY
> behaviour and without covering the spent input index) has some interesting
> uses for cases where the covenant only needs to restrict a single output
> (so useful for e.g. vaults or spacechains, but not for batch channels or
> congestion control).
>
> For example in the vault use-case, it makes it possible to bump fees on
> the unvault tx by adding more inputs and a change output, as well as
> unvault multiple vaulted outputs in a single transaction.
>
> For spacechains, it makes it possible to add the spaceblock hash OP_RETURN
> and pay fees directly in the tx chain, instead of having to use an
> additional tx to prepare an output that gets spent in the tx chain  (see
> the diagram in [0]).
>
> > via `sha_sequences` and maybe also `sha_amounts`
>
> CTV does not commit to the input amounts. This has some practical
> implications:
>
> 1. If it is committed, sending an even slightly incorrect amount will make
> the covenant-encumbered spend path unusable.
>
> With CTV, sending a slightly lower amount results in slightly lower fees,
> while any extra gets spent/burned on fees. The covenant spend path only
> becomes unusable if the amount is too low to cover for the outputs (+relay
> fee for it to also be standard).
>
> 2. The ability to allow for additional inputs with unknown amounts makes
> it possible to fee-bump the covenant spending transaction (with whole utxos
> and no change). You can have one tapleaf for spending the covenant output
> alone, and another one for attaching an extra fee input to it.
>
> This also makes it possible to resolve the under-payment issue described
> in (1), by adding an input that covers the original intended amount.
>
> So my suggestion would be to either not cover `sha_amounts` in the msg
> hash, or to make it optional behind a flag.
>
> shesek
>
> [0] https://github.com/fiatjaf/simple-ctv-spacechain
>
> On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I would like to know people's sentiment about doing (a very slightly
>> tweaked version of) BIP118 in place of
>> (or before doing) BIP119.
>>
>> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for
>> over 6 years. It presents proven and
>> implemented usecases, that are demanded and (please someone correct me if
>> i'm wrong) more widely accepted than
>> CTV's.
>>
>> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made
>> optional [0], can emulate CTV just fine.
>> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more
>> expensive to use. But we can consider CTV
>> an optimization of APO-AS covenants.
>>
>> CTV advocates have been presenting vaults as the flagship usecase.
>> Although as someone who've been trying to
>> implement practical vaults for the past 2 years i doubt CTV is necessary
>> nor sufficient for this (but still
>> useful!), using APO-AS covers it. And it's not a couple dozen more
>> virtual bytes that are going to matter for
>> a potential vault user.
>>
>> If after some time all of us who are currently dubious about CTV's stated
>> usecases are proven wrong by onchain
>> usage of a less efficient construction to achieve the same goal, we could
>> roll-out CTV as an optimization.  In
>> the meantime others will have been able to deploy new applications
>> leveraging ANYPREVOUT (Eltoo, blind
>> statechains, etc..[1]).
>>
>>
>> Given the interest in, and demand for, both simple covenants and better
>> offchain protocols it seems to me that
>> BIP118 is a soft fork candidate that could benefit more (if not most of)
>> Bitcoin users.
>> Actually i'd also be interested in knowing if people would oppose the
>> APO-AS part of BIP118, since it enables
>> CTV's features, for the same reason they'd oppose BIP119.
>>
>>
>> [0] That is, to not commit to the other inputs of the transaction (via
>> `sha_sequences` and maybe also
>> `sha_amounts`). Cf
>> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
>> .
>>
>> [1] https://anyprevout.xyz/ "Use Cases" section
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

[Greg Sanders via bitcoin-dev]

Ironically assumptions of bad faith are going to kill any proposal,
resulting in the status quo.

Let's keep the assumption of good faith, unless you are actually accusing
people of being a NSA-adjacent asset.

On Thu, Apr 21, 2022 at 10:08 AM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There are a number of individuals who have stated opposition to attempting
> to activate a CTV soft fork in the near term:
>
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
>
> sheshek found some issues with the list and some of them are not really an
> opposition for CTV. Others do not have any technical details to consider.
>
> The saddest thing is that if Jeremy's soft fork activation attempt causes
> the uncertainty, confusion and disruption I fear it could it will make
> future soft forks that do have community consensus orders of magnitude
> harder to pull off.
>
>
>
> Calling CTV an attack on bitcoin or doing personal attacks on Jeremy and
> other developers on social media that support CTV won't help. Developers
> should be free to propose improvements and write code. Users can decide if
> they want to run this code. Just because someone is opposing a change and
> prefers status quo does not mean it is better for Bitcoin. Attackers have
> used such things in past for many open source projects.
>
> Example: Someone signed up on the Tor Project mailing list and then
> participated in discussions to advocate against the removal of malicious
> servers
>
> https://nitter.net/campuscodi/status/1466748897003544579
>
>
> dev/fd0
>
> Sent with ProtonMail  secure email.
>
> --- Original Message ---
> On Wednesday, April 20th, 2022 at 6:54 PM, Michael Folkson via bitcoin-dev
>  wrote:
>
> > The client has a Speedy trial release similar to Taproots with
> parameters proposed to be
>
> As I've said before I was hoping we'd avoid this exercise. Best case, it
> wastes the time of people who could be working on all sorts of valuable
> projects for the ecosystem. Worst case, we take a Russian roulette style
> gamble with a chain split.
>
> But here's a summary of the basic facts:
>
> The latest Bitcoin Core release candidate (23.0) does not contain any new
> soft fork code, either CTV code or any new activation code. Running Bitcoin
> Core 23.0 out the box will not signal for any new soft fork and will not
> enforce any new soft fork rules (CTV or otherwise). Of course it will
> continue to enforce Taproot rules as Taproot activated last year.
>
> There are a number of individuals who have stated opposition to attempting
> to activate a CTV soft fork in the near term:
>
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> Most of those individuals haven't logged their opposition on Jeremy's site:
> https://utxos.org/signals/
>
> Hence their views haven't been included or discussed in Jeremy's latest
> blog post.
>
> Chain split risk
>
> I can't predict how many full nodes and miners will run Jeremy's client
> attempting to activate CTV. One would expect that many will continue to run
> versions of Bitcoin Core that will not enforce CTV rules and will not
> activate it. But whether Jeremy's client will be a majority, significant
> minority, insignificant minority of full nodes and miners would be
> speculation on my part. (Personally I highly doubt those running Jeremy's
> client will be a majority which leaves a significant minority and
> insignificant minority as the most likely options).
>
> Jeremy's client is intending to use Speedy Trial presumably with similar
> parameters to that used for Taproot. That would mean seeking 90 percent of
> miners to signal for this CTV soft fork activation attempt.
>
> Assuming 90 percent of miners don't signal for it in one of the Speedy
> Trial windows then the activation attempt will have failed and it will be
> back in Jeremy's court whether he tries again with a different activation
> attempt.
>
> Assuming 90 percent of miners do signal for it (unlikely in my opinion but
> presumably still a possibility) then the CTV soft fork could activate
> unless full nodes resist it. This resistance would most likely be in the
> form of a UASF style client which rejects blocks that apply the CTV rules
> and/or includes transactions that don't meet the CTV rules post activation.
> We would now be in chain split territory with two different assets and
> blockchains like we had with BTC and BCH.
>
> If I oppose this activation attempt and the associated chain split risk
> what should I do?
>
> Firstly, you can register your opposition to this soft fork activation
> attempt on Jeremy's site: https://utxos.org/signals/
>
> It seems Jeremy will continue this activation attempt regardless but it
> will be useful for others to see clearly that this a contentious soft fork
> activation attempt and act accordingly. So far only 3 individuals'
> opposition is registered on his site.
>
> 

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

[Greg Sanders via bitcoin-dev]

> One point of discomfort I have with Eltoo that I think is not universal,
but is shared by some others, is that non-punitive channels may not be good
for high-value channels as you do want, especially in a congested
blockspace world, punishments to incentivize correct behavior (otherwise
cheating may look like a free option).

Without derailing the conversation too far, "fully" punitive channels also
make large value channels more dangerous from the perspective of bugs
causing old states to be published. High value channels you'll need to have
very high uptime. If you're available, your counterparty is incentivized to
do a mutual close to reduce fees and remove timelocks on outputs. I think
these tradeoffs will result in both types existing for N==2.

On Sat, Feb 19, 2022 at 8:56 AM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This is a fascinating post and I'm still chewing on it.
>
> Chiming in with two points:
>
> Point 1, note with respect to evictions, revivals, CTV, TLUV:
>
> CTV enables 1 person to be evicted in O(log N) or one person to leave in
> O(log N). TLUV enables 1 person to leave in O(1) O(log N) transactions, but
> evictions take (AFAICT?) O(N) O(log N) transactions because the un-live
> party stays in the pool. Hence OP_EVICT helps also make it so you can kick
> someone out, rather than all having to leave, which is an improvement.
>
> CTV rejoins work as follows:
>
> suppose you have a pool with 1 failure, you need to do log N txns to evict
> the failure, which creates R * log_R(N) outputs, which can then do a
> transaction to rejoin.
>
> For example, suppose I had 64 people in a radix 4 tree. you'd have at the
> top level 4 groups of 16, then 4 groups of 4 people, and then 1 to 4 txns.
> Kicking 1 person out would make you do 3 txns, and create 12 outputs total.
> A transaction spending the 11 outputs that are live would capture 63 people
> back into the tree, and with CISA would not be terribly expensive. To be a
> bit more economical, you might prefer to just join the 3 outputs with 16
> people in it, and yield 48 people in one pool. Alternatively, you can
> lazily re-join if fees make it worth it/piggybacking another transaction,
> or operate independently or try to find new, better, peers.
>
> Overall this is the type of application that necessitates *exact* byte
> counting. Oftentimes things with CTV seem inefficient, but when you crunch
> the numbers it turns out not to be so terrible. OP_EVICT seems promising in
> this regard compared to TLUV or accumulators.
>
> Another option is to randomize the CTV trees with multiple outputs per
> party (radix Q), then you need to do Q times the evictions, but you end up
> with sub-pools that contain more people/fractional liquidity (this might
> happen naturally if CTV Pools have channels in them, so it's good to model).
>
>
> Point 2, on Eltoo:
>
> One point of discomfort I have with Eltoo that I think is not universal,
> but is shared by some others, is that non-punitive channels may not be good
> for high-value channels as you do want, especially in a congested
> blockspace world, punishments to incentivize correct behavior (otherwise
> cheating may look like a free option).
>
> Thus I'm reluctant to fully embrace designs which do not permit nested
> traditional punitive channels in favor of Eltoo, when Eltoo might not have
> product-market-fit for higher valued channels.
>
> If someone had a punitive-eltoo variant that would ameliorate this concern
> almost entirely.
>
> Cheers,
>
> Jeremy
>
>
>
> --
> @JeremyRubin 
>
> On Fri, Feb 18, 2022 at 3:40 PM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Good morning ariard,
>>
>>
>> > > A statechain is really just a CoinPool hosted inside a
>> > >  Decker-Wattenhofer or Decker-Russell-Osuntokun construction.
>> >
>> > Note, to the best of my knowledge, how to use LN-Penalty in the context
>> of multi-party construction is still an unsolved issue. If an invalidated
>> state is published on-chain, how do you guarantee that the punished output
>> value is distributed "fairly" among the "honest" set of users ? At least
>> > where fairness is defined as a reasonable proportion of the balances
>> they owned in the latest state.
>>
>> LN-Penalty I believe is what I call Poon-Dryja?
>>
>> Both Decker-Wattenhofer (has no common colloquial name) and
>> Decker-Russell-Osuntokun ("eltoo") are safe with N > 2.
>> The former has bad locktime tradeoffs in the unilateral close case, and
>> the latter requires `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`.
>>
>>
>> > > In principle, a set of promised outputs, if the owners of those
>> > > outputs are peers, does not have *any* inherent order.
>> > > Thus, I started to think about a commitment scheme that does not
>> > > impose any ordering during commitment.
>> >
>> > I think we should dissociate a) *outputs publication ordering* from the
>> b) *spends paths 

Re: [bitcoin-dev] Thoughts on fee bumping

[Greg Sanders via bitcoin-dev]

One quick thought to the proposal and perhaps to sponsors in general(didn't
have time to go over original proposal again):

Since sponsors can come from anywhere, the wallet application must have
access to the mempool to know what inputs must be double spent to RBF the
sponsor transaction.

Seems like an important difference to be considered.

On Fri, Feb 11, 2022 at 3:49 AM James O'Beirne via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There's been much talk about fee-bumping lately, and for good reason -
> dynamic fee management is going to be a central part of bitcoin use as
> the mempool fills up (lord willing) and right now fee-bumping is
> fraught with difficulty and pinning peril.
>
> Gloria's recent post on the topic[0] was very lucid and highlights a
> lot of the current issues, as well as some proposals to improve the
> situation.
>
> As others have noted, the post was great. But throughout the course
> of reading it and the ensuing discussion, I became troubled by the
> increasing complexity of both the status quo and some of the
> proposed remedies.
>
> Layering on special cases, more carve-outs, and X and Y percentage
> thresholds is going to make reasoning about the mempool harder than it
> already is. Special consideration for "what should be in the next
> block" and/or the caching of block templates seems like an imposing
> dependency, dragging in a bunch of state and infrastructure to a
> question that should be solely limited to mempool feerate aggregates
> and the feerate of the particular txn package a wallet is concerned
> with.
>
> This is bad enough for protocol designers and Core developers, but
> making the situation any more intractable for "end-users" and wallet
> developers feels wrong.
>
> I thought it might be useful to step back and reframe. Here are a few
> aims that are motivated chiefly by the quality of end-user experience,
> constrained to obey incentive compatibility (i.e. miner reward, DoS
> avoidance). Forgive the abstract dalliance for a moment; I'll talk
> through concretes afterwards.
>
>
> # Purely additive feerate bumps should never be impossible
>
> Any user should always be able to add to the incentive to mine any
> transaction in a purely additive way. The countervailing force here
> ends up being spam prevention (a la min-relay-fee) to prevent someone
> from consuming bandwidth and mempool space with a long series of
> infinitesimal fee-bumps.
>
> A fee bump, naturally, should be given the same per-byte consideration
> as a normal Bitcoin transaction in terms of relay and block space,
> although it would be nice to come up with a more succinct
> representation. This leads to another design principle:
>
>
> # The bandwidth and chain space consumed by a fee-bump should be minimal
>
> Instead of prompting a rebroadcast of the original transaction for
> replacement, which contains a lot of data not new to the network, it
> makes more sense to broadcast the "diff" which is the additive
> contribution towards some txn's feerate.
>
> This dovetails with the idea that...
>
>
> # Special transaction structure should not be required to bump fees
>
> In an ideal design, special structural foresight would not be needed
> in order for a txn's feerate to be improved after broadcast.
>
> Anchor outputs specified solely for CPFP, which amount to many bytes of
> wasted chainspace, are a hack. It's probably uncontroversial at this
> point to say that even RBF itself is kind of a hack - a special
> sequence number should not be necessary for post-broadcast contribution
> toward feerate. Not to mention RBF's seemingly wasteful consumption of
> bandwidth due to the rebroadcast of data the network has already seen.
>
> In a sane design, no structural foresight - and certainly no wasted
> bytes in the form of unused anchor outputs - should be needed in order
> to add to a miner's reward for confirming a given transaction.
>
> Planning for fee-bumps explicitly in transaction structure also often
> winds up locking in which keys are required to bump fees, at odds
> with the idea that...
>
>
> # Feerate bumps should be able to come from anywhere
>
> One of the practical downsides of CPFP that I haven't seen discussed in
> this conversation is that it requires the transaction to pre-specify the
> keys needed to sign for fee bumps. This is problematic if you're, for
> example, using a vault structure that makes use of pre-signed
> transactions.
>
> What if the key you specified n the anchor outputs for a bunch of
> pre-signed txns is compromised? What if you'd like to be able to
> dynamically select the wallet that bumps fees? CPFP does you no favors
> here.
>
> There is of course a tension between allowing fee bumps to come from
> anywhere and the threat of pinning-like attacks. So we should venture
> to remove pinning as a possibility, in line with the first design
> principle I discuss.
>
>
> ---
>
> Coming down to earth, the "tabula rasa" thought experiment above 

Re: [bitcoin-dev] Taproot Fields for PSBT

[Greg Sanders via bitcoin-dev]

I may be misunderstanding the question, but it seems essential data for the
finalizer role, which may not know such information on its own.

On Wed, Nov 24, 2021 at 11:15 PM Sjors Provoost via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Andrew,
>
> I'm confused why PSBT_IN_TAP_BIP32_DERIVATION and
> PSBT_OUT_TAP_BIP32_DERIVATION
> contain not just the derivation path for the xonlypubkey, but also the
> tapleaf merkle path.
>
> First I thought it was perhaps necessary in order for a signer to guess
> which
> script leaves it can sign with its own keys. But you can't really know
> that without
> actually seeing the script. When a signer looks at a script, it presumably
> already
> knows the leaf path.
>
> - Sjors
>
> Op 22 jun. 2021, om 23:22 heeft Andrew Chow via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
>
> Hi All,
>
> I would like to propose a BIP which defines new fields for Taproot
> support in PSBT.
>
> The full text is below, and the rendered file can be found at
>
>
> Now at: https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki
>
> -
> | Taproot Key BIP 32 Derivation Path
> | PSBT_IN_TAP_BIP32_DERIVATION = 0x16
> | 
> | The 32 byte X-only public key
> |  * <32-bit uint> <32-bit uint>*
> | A compact size unsigned integer representing the number of leaf
> hashes, followed by a list of leaf hashes, followed by the master key
> fingerprint concatenated with the derivation path of the public key. The
> derivation path is represented as 32-bit little endian unsigned integer
> indexes concatenated with each other. Public keys are those needed to
> spend this output. The leaf hashes are of the leaves which involve this
> public key.
>
>
> |-
> | Taproot Key BIP 32 Derivation Path
> | PSBT_OUT_TAP_BIP32_DERIVATION = 0x07
> | 
> | The 32 byte X-only public key
> |  * <32-bit uint> <32-bit uint>*
>
>
> ___
> 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] Reorgs on SigNet - Looking for feedback on approach and parameters

[Greg Sanders via bitcoin-dev]

> Sometimes that reorg could be deeper if you would be lucky enough to get
a block with more work than N following blocks combined

Each block is credited for its contribution to total chainwork by the
difficulty target, not the hash of the block itself.

On Sun, Sep 12, 2021 at 10:42 PM vjudeu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > - 1 block reorgs: these are a regular feature on mainnet, everyone
>should cope with them; having them happen multiple times a day to
>make testing easier should be great
>
> Anyone can do 1 block reorg, because nonce is not signed, so anyone can
> replace that with better value. For example, if you have block
> 0086d6b2636cb2a392d45edc4ec544a10024d30141c9adf4bfd9de533b53 with
> 0x0007f4cc nonce, you can replace that with 0x00110241 nonce and get
> 00096a1c4239d994547185c80308a552cba85d5bd28a51e9dc583ae5eadb block,
> where everything is identical, except the nonce.
>
> Sometimes that reorg could be deeper if you would be lucky enough to get a
> block with more work than N following blocks combined.
>
> On 2021-09-08 09:59:29 user Anthony Towns via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > On Tue, Sep 07, 2021 at 06:07:47PM +0200, 0xB10C via bitcoin-dev wrote:
> > The reorg-interval X very much depends on the user's needs. One could
> > argue that there should be, for example, three reorgs per day, each 48
> > blocks apart.
>
> Oh, wow, I think the last suggestion was every 100 blocks (every
> ~16h40m). Once every ~8h sounds very convenient.
>
> > Such a short reorg interval allows developers in all time
> > zones to be awake during one or two reorgs per day.
>
> And also for there to reliably be reorgs when they're not awake, which
> might be a useful thing to be able to handle, too :)
>
> > Developers don't
> > need to wait for, for example, a week until they can test their reorgs
> > next. However, too frequent reorgs could hinder other SigNet users.
>
> Being able to run `bitcoind -signet -signetacceptreorg=0` and never
> seeing any reorgs should presumably make this not a problem?
>
> For people who do see reorgs, having an average of 2 or 3 additional
> blocks every 48 blocks is perhaps a 6% increase in storage/traffic.
>
> > # Scenario 1: Race between two chains
> >
> > For this scenario, at least two nodes and miner scripts need to be
> > running. An always-miner A continuously produces blocks and rejects
> > blocks with the to-be-reorged version bit flag set. And a race-miner R
> > that only mines D blocks at the start of each interval and then waits X
> > blocks. A and R both have the same hash rate. Assuming both are well
> > connected to the network, it's random which miner will first mine and
> > propagate a block. In the end, the A miner chain will always win the
> race.
>
> I think this description is missing that all the blocks R mines have
> the to-be-reorged flag set.
>
> > 3. How deep should the reorgs be on average? Do you want to test
> >deeper reorgs (10+ blocks) too?
>
> Super interested in input on this -- perhaps we should get optech to
> send a survey out to their members, or so?
>
> My feeling is:
>
>  - 1 block reorgs: these are a regular feature on mainnet, everyone
>should cope with them; having them happen multiple times a day to
>make testing easier should be great
>
>  - 2-3 block reorgs: good for testing the "your tx didn't get enough
>confirms to be credited to your account" case, even though it barely
>ever happens on mainnet
>
>  - 4-6 block reorgs: likely to violate business assumptions, but
>completely technically plausible, especially if there's an attack
>against the network
>
>  - 7-100 block reorgs: for this to happen on mainnet, it would probably
>mean there was a bug and pools/miners agree the chain has to
>be immediately reverted -- eg, someone discovers and exploits an
>inflation bug, minting themselves free bitcoins and breaking the 21M
>limit (eg, the 51 block reorg in Aug 2010); or someone discovers a
>bug that splits the chain, and the less compatible chain is reverted
>(eg, the 24 block reorg due to the bdb lock limit in Mar 2013);
>or something similar. Obviously the bug would have to have been
>discovered pretty quickly after it was exploited for the reorg to be
>under a day's worth of blocks.
>
>  - 100-2000+ block reorgs: severe bug that wasn't found quickly, or where
>getting >50% of miners organised took more than a few hours. This will
>start breaking protocol assumptions, like pool payouts, lightning's
>relative locktimes, or liquid's peg-in confirmation requirements, and
>result in hundres of MBs of changes to the utxo set
>
> Maybe it would be good to do reorgs of 15, 150 or 1500 blocks as a
> special fire-drill event, perhaps once a month/quarter/year or so,
> in some pre-announced window?
>
> I think sticking to 1-6 block reorgs initially is a fine way to 

Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

[Greg Sanders via bitcoin-dev]

Funny AJ mentions the multisig idea, because I know for a fact it's being
used in certain permissioned systems in this exact way. Regulators will
dream up these ideas with or without more useful covenants!

On Mon, Jul 5, 2021 at 9:46 PM Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I find this point to be incredibly important. Indeed I, like several
> others, have historically been concerned with
> covenants in the unbounded form. However, as more and more research has
> been done in what they can accomplish, the
> weighting of such arguments naturally has to be reduced. More importantly,
> AJ's point here neuters anti-covanent
> arguments rather strongly.
>
> Matt
>
> On 7/5/21 01:04, Anthony Towns via bitcoin-dev wrote:
> > On Sun, Jul 04, 2021 at 09:02:25PM -0400, Russell O'Connor via
> bitcoin-dev wrote:
> >> Bear in mind that when people are talking about enabling covenants, we
> are
> >> talking about whether OP_CAT should be allowed or not.
> >
> > In some sense multisig *alone* enables recursive covenants: a government
> > that wants to enforce KYC can require that funds be deposited into
> > a multisig of "2   2 CHECKMULTISIG", and that
> > "recipient" has gone through KYC. Once deposited to such an address,
> > the gov can refus to sign with gov_key unless the funds are being spent
> > to a new address that follows the same rules.
> >
> > (That's also more efficient than an explicit covenant since it's all
> > off-chain -- recipient/gov_key can jointly sign via taproot/MuSig at
> > that point, so that full nodes are only validating a single pubkey and
> > signature per spend, rather than having to do analysis of whatever the
> > underlying covenant is supposed to be [0])
> >
> > This is essentially what Liquid already does -- it locks bitcoins into
> > a multisig and enforces an "off-chain" covenant that those bitcoins can
> > only be redeemed after some valid set of signatures are entered into
> > the Liquid blockchain. Likewise for the various BTC-on-Ethereum tokens.
> > To some extent, likewise for coins held in exchanges/custodial wallets
> > where funds can be transferred between customers off-chain.
> >
> > You can "escape" from that recursive covenant by having the government
> > (or Liquid functionaries, or exchange admins) change their signing
> > policy of course; but you could equally escape any consensus-enforced
> > covenant by having a hard fork to stop doing consensus-enforcement (cf
> > ETH Classic?). To me, that looks more like a difference of procedure
> > and difficulty, rather than a fundamental difference in kind.
> >
> > Cheers,
> > aj
> >
> > [0] https://twitter.com/pwuille/status/1411533549224693762
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0

[Greg Sanders via bitcoin-dev]

Transaction analysis tools do take the signal into account, but I'm unsure
if retail, non-custodial wallets use this information.

Historically the biggest pushback has been from services like Bitrefill
which have had quite a bit of success with 0-conf payments, but perhaps LN
adoption is at a point where it's less of an impact?

On Fri, Jun 18, 2021 at 4:15 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Russel O'Connor recently opined
> 
> that RBF should be standard treatment of all transactions, rather than as a
> transaction opt-in/out. I agree with that. Any configuration in a
> transaction that has not been committed into a block yet simply can't be
> relied upon. Miners also have a clear incentive to ignore RBF rules and
> mine anything that passes consensus. At best opting out of RBF is a weak
> defense, and at worst it's simply a false sense of security that is likely
> to actively lead to theft events.
>
> Do we as a community want to support 0-conf payments in any way at this
> point? It seems rather silly to make software design decisions to
> accommodate 0-conf payments when there are better mechanisms for fast
> payments (ie lightning).
>
> One question I have is: how does software generally inform the user about
> 0-conf payment detection? Does software generally tell the user something
> along the lines of "This payment has not been finalized yet. All recipients
> should wait until the transaction has at least 1 confirmation, and most
> recipients should wait for 6 confirmations" ? I think unless we pressure
> software to be very explicit about what counts as finality, users will
> simply continue to do what they've always done. Rolling out this policy
> change over the course of a year or two seems fine, no need to rush. But I
> suppose it would depend on how often 0-conf is used in the bitcoin
> ecosystem at this point, which I don't have any data on.
>
> On Tue, Jun 15, 2021 at 10:00 AM Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi,
>>
>> I'm writing to propose deprecation of opt-in RBF in favor of full-RBF as
>> the Bitcoin Core's default replacement policy in version 24.0. As a
>> reminder, the next release is 22.0, aimed for August 1st, assuming
>> agreement is reached, this policy change would enter into deployment phase
>> a year from now.
>>
>> Even if this replacement policy has been deemed as highly controversial a
>> few years ago, ongoing and anticipated changes in the Bitcoin ecosystem are
>> motivating this proposal.
>>
>> # RBF opt-out as a DoS Vector against Multi-Party Funded Transactions
>>
>> As explained in "On Mempool Funny Games against Multi-Party Funded
>> Transactions'', 2nd issue [0], an attacker can easily DoS a multi-party
>> funded transactions by propagating an RBF opt-out double-spend of its
>> contributed input before the honest transaction is broadcasted by the
>> protocol orchester. DoSes are qualified in the sense of either an attacker
>> wasting timevalue of victim's inputs or forcing exhaustion of the
>> fee-bumping  reserve.
>>
>> This affects a series of Bitcoin protocols such as Coinjoin, onchain DLCs
>> and dual-funded LN channels. As those protocols are still in the early
>> phase of deployment, it doesn't seem to have been executed in the wild for
>> now.  That said, considering that dual-funded are more efficient from a
>> liquidity standpoint, we can expect them to be widely relied on, once
>> Lightning enters in a more mature phase. At that point, it should become
>> economically rational for liquidity service providers to launch those DoS
>> attacks against their competitors to hijack user traffic.
>>
>> Beyond that, presence of those DoSes will complicate the design and
>> deployment of multi-party Bitcoin protocols such as payment
>> pools/multi-party channels. Note, Lightning Pool isn't affected as there is
>> a preliminary stage where batch participants are locked-in their funds
>> within an account witnessScript shared with the orchestrer.
>>
>> Of course, even assuming full-rbf, propagation of the multi-party funded
>> transactions can still be interfered with by an attacker, simply
>> broadcasting a double-spend with a feerate equivalent to the honest
>> transaction. However, it tightens the attack scenario to a scorched earth
>> approach, where the attacker has to commit equivalent fee-bumping reserve
>> to maintain the pinning and might lose the "competing" fees to miners.
>>
>> # RBF opt-out as a Mempools Partitions Vector
>>
>> A longer-term issue is the risk of mempools malicious partitions, where
>> an attacker exploits network topology or divergence in mempools policies to
>> partition network mempools in different subsets. From then a wide range of
>> attacks can be envisioned such as package pinning [1], artificial
>> congestion to provoke LN channels closure or 

Re: [bitcoin-dev] Time to lower minrelaytxfee ?

[Greg Sanders via bitcoin-dev]

No strong opinions but:

Denial of service attacks can become 5x cheaper.

If you don't thoroughly test
https://github.com/bitcoin/bitcoin/issues/16499 these
changes you can end up with bugs that can cause issues on p2p network.

On Fri, Aug 21, 2020 at 4:00 AM Dan Bryant via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> It's been 5 years since minrealytxfee was lowered.  At the time
> bitcoin was trading for $255 and it was agreed that the fee of 5000
> sat/vkB was too high.  It was lowered to 1000 sat/vkB.  In regards to
> how much anti-DoS protection that provided, it comes out to $0.00255 /
> vkB in USD terms.  To have parity with the last reduction, we would
> need to reduce minrealytxfee to 22 sat/vKB, though an even more
> conservative reduction to 100 or 50 sat/vKB would be welcome.
>
> With the growing adoption of LN, there is a need for ultra-low-fee
> on-chain TXNs.  Having these queue and confirm overnight, or even
> waiting until the Sunday lull would still probably be welcome to many
> users.  The fact that the mempool is going empty at least every week
> indicates that miners have not reached the floor of what they are
> willing to mine.
>
> About 2 years ago there was a PR (#13922) to try to make a reduction
> from 1000 to 200 sat/vkB.  It was widely accepted but the submitter
> eventually closed it in favor of PR #13990.
>
> If minrelaytxfee is already parameterized and configurable in
> bitcoin.conf, how could it be detrimental to operation of a node to
> change the default?
>
> References:
>
> *
> https://github.com/bitcoin/bitcoin/commit/9e93640be6c49fa1505ba5c5df8c89210da5a6e4
> * https://github.com/bitcoin/bitcoin/pull/13922
> * https://github.com/bitcoin/bitcoin/pull/13990
> ___
> 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] Bech32 weakness and impact on bip-taproot addresses

[Greg Sanders via bitcoin-dev]

Can you make it clear what the bold vs not-bold numbers mean?

On Wed, Jul 15, 2020 at 4:56 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> That brings me to Matt's point: there is no need to do this right now. We
>> can simply amend BIP173 to only permit length 20 and length 32 (and only
>> length 20 for v0, if you like; but they're so far apart that permitting
>> both shouldn't hurt), for now. Introducing the "new" address format (the
>> one using an improved checksum algorithm) only needs to be there in time
>> for when a non-32-byte-witness-program would come in sight.
>>
>
> As a prerequisite to taproot activation, I was looking into amending
> BIP173 as stated above.  However after reviewing
> https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb#detection-of-insertion-errors
> it seems that insertions of 5 characters or more is "safe" in the sense
> that there is low probability of creating a valid checksum by doing so
> randomly.
>
> This means we could safely allow witness programs of lengths *20*, 23,
> 26, 29, *32*, 36, and 40 (or 39).  These correspond to Bech32 addresses
> of length *42*, 47, 52, 57, *62*, 68, and 74 (or 73).  We could also
> support a set of shorter addresses, but given the lack of entropy in such
> short addresses, it is hard to believe that such witness programs could be
> used to secure anything.  I'm not sure what the motivation for allowing
> such short witness programs was, but I'm somewhat inclined to exclude them
> from the segwit address format.
>
> Given that we would only be able to support one of 39 or 40 byte witness
> programs, it is sensible to choose to allow 40 byte witness programs to be
> addressable.  This is the maximum witness program size allowed by BIP 141.
>
> So my proposal would be to amend BIP173 in such a way to restrict "bc" and
> "tb" segwit address formats to require witness programs be of size *20*,
> 23, 26, 29, *32*, 36, or 40.  Witness programs of other sizes (between 2
> and 40) would, of course, still be legal in accordance with BIP 141;
> however they would be unaddressable by using this "bc" and "tb" prefix.
> Another address format would be needed to support other witness sizes,
> should the need ever arise.
>
> --
> Russell O'Connor
> ___
> 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] Tainting, CoinJoin, PayJoin, CoinSwap

[Greg Sanders via bitcoin-dev]

A major point of defeating the common input heuristic and others is to make
"super-clusters". A small number of users that "don't care" about possibly
touching tainted coins can render many chain analysis techniques unworkable
in practice for enforcement. You don't need 100% coverage to defeat the
heuristic.

On Wed, Jun 10, 2020 at 9:40 AM nopara73 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The problem with CoinJoins is that desire for privacy is explicitly
> signalled by them, so adversaries can consider them "suspicious." PayJoin
> and CoinSwap solve this problem, because they are unnoticeable. I think
> this logic doesn't stand for scrutiny.
>
> From here on let's use the terminology of a typical adversary: there are 3
> kinds of coin histories: "clean", "dirty" and "suspicious".
> The aftermath of you using a "dirty" coin is knocks on your door. You
> using a "suspicious" coin is uncomfortable questions and you using a
> "clean" coin is seamless transfer.
>
> In scenario 1, you start out with a "clean" history. By using CoinJoins
> you make your new coin's history "suspicious" so you have no incentive to
> CoinJoin. By using CoinSwap/PayJoin your new coin can be either "clean" or
> "dirty". What would a "clean" coin owner prefer more? Take the risk of
> knocking on the door or answering uncomfortable questions?
>
> In scenario 2, you start out with a "dirty" history. By using CoinJoins
> you make your new coin's history "suspicious" so you have an incentive to
> CoinJoin. By using CoinSwap/PayJoin your new coin can either be "clean" or
> "dirty". What would a "dirty" coin owner prefer more? And here's an
> insight: you may get knocks on your door for a dirty coin that you have
> nothing to do with. And you can prove this fact to the adversary, but by
> doing so, you'll also expose that you started out with a "dirty" coin to
> begin with and now the adversary becomes interested in you for a different
> reason.
>
> You can also examine things assuming full adoption of PJ/CS vs full
> adoption of CJ, but you'll see that full adoption of any of these solves
> the tainting issue.
>
> So my current conclusion is that PJ/CS does not only not solve the taint
> problem, it just alters it and ultimately very similar problems arise for
> the users. Maybe the goal of unobservable privacy is a fallacy in this
> context as it is based on the assumption that desiring privacy is
> suspicious, so you want to hide the fact that you desire privacy. And the
> solution to the taint issue is either protocol change or social change
> (decent adoption.)
>
> PS.: Please try to keep the conversation to the Taint Issue as this email
> of mine isn't supposed to be discussing general pros and cons of various
> privacy techniques.
>
> Any thoughts?
>
> --
> Best,
> Ádám
> ___
> 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] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN

[Greg Sanders via bitcoin-dev]

So I think the question to ask would be "why can't we just make sure it's
not 64?"

On Sat, May 23, 2020 at 11:24 AM Greg Sanders  wrote:

> AFAIU the number was picked to protect against CVE-2017-12842 covertly.
> See: https://github.com/bitcoin/bitcoin/pull/16885
>  which updated the
> text to explicitly mention this fact.
>
> On Sat, May 23, 2020 at 11:20 AM Thomas Voegtlin via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hello list,
>>
>> I have been trying to CPFP a transaction using OP_RETURN, because the
>> remaining output value would have been lower than the dust threshold.
>>
>> The scriptPubkey of the output was OP_RETURN + OP_0, and there was a
>> single p2wsh input.
>>
>> The result is a 60 bytes transaction (without witness), that gets
>> rejected because it is lower than MIN_STANDARD_TX_NONWITNESS_SIZE, which
>> is equal to 82 bytes.
>>
>> Why is that value so high? Would it make sense to lower it to 60?
>>
>>
>> Thomas
>> ___
>> 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] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN

[Greg Sanders via bitcoin-dev]

AFAIU the number was picked to protect against CVE-2017-12842 covertly.
See: https://github.com/bitcoin/bitcoin/pull/16885
 which updated the
text to explicitly mention this fact.

On Sat, May 23, 2020 at 11:20 AM Thomas Voegtlin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello list,
>
> I have been trying to CPFP a transaction using OP_RETURN, because the
> remaining output value would have been lower than the dust threshold.
>
> The scriptPubkey of the output was OP_RETURN + OP_0, and there was a
> single p2wsh input.
>
> The result is a 60 bytes transaction (without witness), that gets
> rejected because it is lower than MIN_STANDARD_TX_NONWITNESS_SIZE, which
> is equal to 82 bytes.
>
> Why is that value so high? Would it make sense to lower it to 60?
>
>
> Thomas
> ___
> 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] BIP-341: Committing to all scriptPubKeys in the signature message

[Greg Sanders via bitcoin-dev]

For what it's worth this measure had been discussed as a lightweight way of
informing offline signers if inputs were segwit or not for malleability
analysis reasons. So there's at least a couple direct use-cases it seems.

On Fri, May 1, 2020, 8:23 AM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> While I'm not entirely convinced yet that accertaining non-ownership of an
> input is a robust method of solving the problem here, I also see little
> reason not to amend BIP-341 as proposed. The ScriptPubKeys in question is
> already indirectly covered through the outpoints, so it is just a matter of
> optimization.  Furthermore in the consensus code, the ScriptPubKeys are
> part of the UTXO data set, and it is already being retrieved as part of the
> transaction checking process, so it is readily available.
>
> I'm not sure how much my opinion on the topic matters, but I did include
> this kind of functionality in my design for Simplicity on Elements, and I
> have been leaning towards adding this kind of functionality in my Bitcoin
> demo application of Simplicity.
>
> Regarding specifics, I personally think it would be better to keep the
> hashes of the ScriptPubKeys separate from the hashes of the input values.
> This way anyone only interested in input values does not need to wade
> through what are, in principle, arbitrarily long ScriptPubKeys in order to
> check the input values (which each fixed size).  To that end, I would also
> (and independently) propose separating the hashing of the output values
> from the output ScriptPubKeys in `sha_outputs` so again, applications
> interested only in summing the values of the outputs (for instance to
> compute fees) do not have to wade through those arbitrarily long
> ScriptPubKeys in the outputs.
>
> On Thu, Apr 30, 2020 at 4:22 AM Andrew Kozlik via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi everyone,
>>
>> In the current draft of BIP-0341 [1] the signature message commits to the
>> scriptPubKey of the output being spent by the input. I propose that the
>> signature message should commit to the scriptPubKeys of *all* transaction
>> inputs.
>>
>> In certain applications like CoinJoin, a wallet has to deal with
>> transactions containing external inputs. To calculate the actual amount
>> that the user is spending, the wallet needs to reliably determine for each
>> input whether it belongs to the wallet or not. Without such a mechanism an
>> adversary can fool the wallet into displaying incorrect information about
>> the amount being spent, which can result in theft of user funds [2].
>>
>> In order to ascertain non-ownership of an input which is claimed to be
>> external, the wallet needs the scriptPubKey of the previous output spent by
>> this input. It must acquire the full transaction being spent and verify its
>> hash against that which is given in the outpoint. This is an obstacle in
>> the implementation of lightweight air-gapped wallets and hardware wallets
>> in general. If the signature message would commit to the scriptPubKeys of
>> all transaction inputs, then the wallet would only need to acquire the
>> scriptPubKey of the output being spent without having to acquire and verify
>> the hash of the entire previous transaction. If an attacker would provide
>> an incorrect scriptPubKey, then that would cause the wallet to generate an
>> invalid signature message.
>>
>> Note that committing only to the scriptPubKey of the output being spent
>> is insufficient for this application, because the scriptPubKeys which are
>> needed to ascertain non-ownership of external inputs are precisely the ones
>> that would not be included in any of the signature messages produced by the
>> wallet.
>>
>> The obvious way to implement this is to add another hash to the signature
>> message:
>> sha_scriptPubKeys (32): the SHA256 of the serialization of all
>> scriptPubKeys of the previous outputs spent by this transaction.
>>
>> Cheers,
>> Andrew Kozlik
>>
>> [1]
>> https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message
>> [2]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014843.html
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Statechain implementations

[Greg Sanders via bitcoin-dev]

> Wouldn't that result in a changing pubkey at each update, and thus
require an onchain move to be committed?

Suggestion was in line with original proposal where no keys are changing
ever, just not presupposing existence of MuSig.

On Thu, Mar 26, 2020 at 1:15 PM Christian Decker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Ruben Somsen via bitcoin-dev 
> writes:
> > Regarding modification 1, I agree with ZmnSCPxj that
> > Decker-Wattenhofer is your next best option, given that eltoo is not
> > yet available. But if you are going to use a kickoff transaction, keep
> > in mind that every previous owner will have a copy of it. Because of
> > this, you can't include a fee, and will instead need to have a second
> > output for CPFP. This way a previous owner will at least have to pay
> > the fee if they want to publish it. Note that it's still an
> > improvement, because even if the kickoff transaction gets posted, it
> > basically becomes no different than what it would have been, had you
> > not used a kickoff transaction at all.
>
> It might be worth adopting the late fee binding we have in eltoo by
> having the kickoff transaction input spending the funding tx signed with
> sighash_single. This works because we only have 1 input and 1 output
> that we really care about, and can allow others to attach fees at
> will. That'd at least remove the need to guess the feerate days or
> months in advance and thus having to overestimate.
>
> > Regarding modification 2, I like it a lot conceptually. It hadn't
> > occurred to me before, and it's a clear security improvement. The only
> > question is something Greg Sanders mentioned: whether it's enough to
> > justify the added complexity of using 2P ECDSA. The alternative would
> > be to simply use a regular 2-of-2 multisig (until Schnorr arrives,
> > possibly).
>
> Wouldn't that result in a changing pubkey at each update, and thus
> require an onchain move to be committed?
>
> > I'm looking forward to seeing statechains become a reality.
>
> That'd indeed be great :-)
>
> Cheers,
> Christian
> ___
> 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] Taproot proposal

[Greg Sanders via bitcoin-dev]

> I'd prefer to not support P2SH-nested TR. P2SH wrapping was useful for
segwit
v0 for compatibility reasons. Most wallets/exchanges/services now support
sending
to native segwit addresses (https://en.bitcoin.it/wiki/Bech32_adoption) and
that
will be even more true if Schnorr/Taproot activate in 12+ months time.

Apologies for necroing an ancient thread, but I'm echoing my agreement with
John here.
We still have plenty of time to have ecosystem upgrade by the time taproot
is likely to activate.



On Wed, May 22, 2019 at 10:30 AM John Newbery via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> > A Taproot output is a SegWit output [...]  with
> > version number 1, and a 33-byte witness program whose first byte is 0 or
> 1.
>
> Given a secret key k and public key P=(x,y), a signer with the knowledge
> of k
> can sign for -P=(x,p-y) since -k is the secret key for that point.
> Encoding the
> y value of the public key therefore adds no security. As an alternative to
> providing the y value of the taproot output key Q when constructing the
> taproot
> output, the signer can provide it when signing. We can also restrict the y
> value
> of the internal key P to be even (or high, or a quadratic residue). That
> gives
> us 4 options for how to set the y signs for P and Q.
>
> 1. Q sign is explictly set in the witness program, P sign is explicitly
> set in the control block
> => witness program is 33 bytes, 32 possible leaf versions (one for
> each pair of 0xc0..0xff)
> 2. Q sign is explictly set in the witness program, P sign is implicitly
> even
> => witness program is 33 bytes, 64 possible leaf versions (one for
> each 0xc0..0xff)
> 3. Q sign is explictly set in the control block, P sign is explicitly set
> in the control block
> => witness program is 32 bytes, 16 possible leaf versions (one for
> each 4-tuple of 0xc0..0xff)
> 4. Q sign is explictly set in the control block, P sign is implicitly even
> => witness program is 32 bytes, 32 possible leaf versions (one for
> pair of 0xc0..0xff)
>
> The current proposal uses (1). Using (3) or (4) would reduce the size of a
> taproot output by one byte to be the same size as a P2WSH output. That
> means
> that it's not more expensive for senders compared to sending to P2WSH.
>
> (Credit to James Chiang for suggesting omitting the y sign from the public
> key and
> to sipa for pointing out the 4 options above)
>
> > (native or P2SH-nested, see BIP141)
>
> I'd prefer to not support P2SH-nested TR. P2SH wrapping was useful for
> segwit
> v0 for compatibility reasons. Most wallets/exchanges/services now support
> sending
> to native segwit addresses (https://en.bitcoin.it/wiki/Bech32_adoption)
> and that
> will be even more true if Schnorr/Taproot activate in 12+ months time.
>
> On Mon, May 6, 2019 at 2:36 PM Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hello everyone,
>>
>> Here are two BIP drafts that specify a proposal for a Taproot
>> softfork. A number of ideas are included:
>>
>> * Taproot to make all outputs and cooperative spends indistinguishable
>> from eachother.
>> * Merkle branches to hide the unexecuted branches in scripts.
>> * Schnorr signatures enable wallet software to use key
>> aggregation/thresholds within one input.
>> * Improvements to the signature hashing algorithm (including signing
>> all input amounts).
>> * Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support
>> batch validation.
>> * Tagged hashing for domain separation (avoiding issues like
>> CVE-2012-2459 in Merkle trees).
>> * Extensibility through leaf versions, OP_SUCCESS opcodes, and
>> upgradable pubkey types.
>>
>> The BIP drafts can be found here:
>> * https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki
>> specifies the transaction input spending rules.
>> * https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki
>> specifies the changes to Script inside such spends.
>> * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
>> is the Schnorr signature proposal that was discussed earlier on this
>> list (See
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html
>> )
>>
>> An initial reference implementation of the consensus changes, plus
>> preliminary construction/signing tests in the Python framework can be
>> found on https://github.com/sipa/bitcoin/commits/taproot. All
>> together, excluding the Schnorr signature module in libsecp256k1, the
>> consensus changes are around 520 LoC.
>>
>> While many other ideas exist, not everything is incorporated. This
>> includes several ideas that can be implemented separately without loss
>> of effectiveness. One such idea is a way to integrate SIGHASH_NOINPUT,
>> which we're working on as an independent proposal.
>>
>> The document explains basic wallet operations, such as constructing
>> outputs and signing. However, a wide variety of more complex
>> constructions exist. 

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

[Greg Sanders via bitcoin-dev]

People are allowed the choice, it's a change of default only.

On Mon, Jul 22, 2019 at 4:41 PM Peter via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> I believe two wallets. Andreas' Android Bitcoin wallet and BRD are
> significant users of node_bloom.
>
> Privacy is a matter of individual choice in the current protocol. Why not
> let people provide this network service? I don't see why it should be
> end-of-life if it provides value.
>
> I believe there's a network security obtained by having a large quantity
> of people following the Bitcoin headers based on longest weighted chain. As
> a means of nullifying potential miner initiated hard forks (like S2X).
>
> Respectfully,
> Peter
> ___
> 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] BIP 174 thoughts

[Greg Sanders via bitcoin-dev]

>Hmm, upon further reflection, maybe it's not even worth including *any*
per-output data, aside from what the original transaction contains.

>The output redeem script is either:
- unknown, because we have received only an address from the receiver
- or it is known, because it is ours and in that case it doesn’t make
sense to include it in PSBT

Signers are an extremely heterogeneous bunch. A signer may need to
introspect on the script, such as "this is a 2-of-3,
and I'm one of the keys". Even in basic p2pkh settings not adding any
output information rules out things like change
detection on any conceivable hardware wallet, or even simple software
wallets that don't carry significant state.

On Thu, Jun 21, 2018 at 10:35 AM Tomas Susanka via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello,
>
> First of all, let me thank you for all the hard work you and others have
> put into this.
>
>
> On 21.6.2018 02:39, Achow101 via bitcoin-dev wrote:
> > While I agree that the BIP itself should be revised to reflect these
> suggestions, I fear that it may be too late. I know of a few other
> developers who have implemented BIP 174 already but have not yet responded
> to this email.
>
> We do realize that this discussion should have happened earlier, however
> agreeing on a good standard should be the number one priority for all
> the parties involved.
>
> The fact that someone already implemented this is indeed unfortunate,
> but I don't think we should lower our demands on the standard just
> because of a bad timing.
>
> >> A question to consider is,
> >> will there be more per-output data? If yes, it might make sense to have
> >> an output section.
> > I think it is unlikely that there would be anymore per-output data.
>
> Hmm, upon further reflection, maybe it's not even worth including *any*
> per-output data, aside from what the original transaction contains.
>
> The output redeem script is either:
> - unknown, because we have received only an address from the receiver
> - or it is known, because it is ours and in that case it doesn’t make
> sense to include it in PSBT
>
> We got stuck on the idea of the Creator providing future (output)
> redeem/witness scripts. But that seems to be a minority use case and can
> be solved efficiently via the same channels that coordinate the PSBT
> creation. Sorry to change opinions so quickly on this one.
>
> >
> >> 3) The sighash type 0x03 says the sighash is only a recommendation. That
> >> seems rather ambiguous. If the field is specified shouldn't it be
> binding?
> > I disagree. It is up to the signer to decide what they wish to sign, not
> for the creator to specify what to sign. The creator can ask the signer to
> sign something in a particular way, but it is ultimately up to the signer
> to decide.
>
> This seems very ambiguous. The Signer always has the option of not
> signing. *What* to sign is a matter of coordination between the parties;
> otherwise, you could make all the fields advisory and let anyone sign
> anything they like?
>
> We don't understand the usecase for a field that is advisory but not
> binding. On what basis would you choose to respect or disregard the
> advisory field? Either one party has a preference, in which case they
> have to coordinate with the other anyway - or they don't, in which case
> they simply leave the field out.
>
> > Size is not really a constraint, but we do not want to be unnecessarily
> large. The PSBT still has to be transmitted to other people. It will likely
> be used by copy and pasting the string into a text box. Copying and pasting
> very long strings of text can be annoying and cumbersome. So the goal is to
> keep the format still relatively clear while avoiding the duplication of
> data.
>
> I agree. Just to put some numbers on this: if we expect a 5-part
> derivation path, and add the master key fingerprint, that is 4 + 5*4 =
> 24 bytes (~32 base64 letters) per input and signer. I'd argue this is
> not significant.
> If we used full xpub, per Pieter's suggestion, that would grow to 32 +
> 32 + 5*4 = 84 bytes (~112 letters) per input/signer, which is quite a lot.
>
> On the other hand, keeping the BIP32 paths per-input means that we don't
> need to include the public key (as in the lookup key), so that's 32
> bytes down per path. In general, all the keys can be fully reconstructed
> from their values:
>
> redeem script key = hash160(value)
> witness script key = sha256(value)
> bip32 key = derive(value)
>
> The one exception is a partial signature. But even in that case we
> expect that a given public key will always correspond to the same
> signature, so we can act as if the public key is not part of the "key".
> In other words, we can move the public key to the value part of the record.
>
> This holds true unless there's some non-deterministic signing scheme,
> *and* multiple Signers sign with the same public key, which is what
> Pieter was alluding to on Twitter
> 

Re: [bitcoin-dev] {sign|verify}message replacement

[Greg Sanders via bitcoin-dev]

Sorry if I missed the rationale earlier, but why not just do a transaction,
with a FORKID specifically for this? Then a node can have a mempool
acceptance test that returns true even if the signature is not valid as per
Bitcoin consensus, but only due to the FORKID?

This way basically any wallet can support this provided generic FORKID
support.

On Thu, Mar 15, 2018 at 8:38 PM, Karl Johan Alm via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Mar 15, 2018 at 2:14 PM, Luke Dashjr  wrote:
> > Not necessarily specific UTXOs (that would contradict fungibility, as
> well as
> > be impossible for hot/cold wallet separation), but just to prove funds
> are
> > available. The current sign message cannot be used to prove present
> possession
> > of funds, only that you receive funds.
>
> By saying "not necessarily specific UTXOs", are you saying it may be
> spent outputs? I'm a little confused I think.
>
> On Thu, Mar 15, 2018 at 8:53 PM, Jim Posen  wrote:
> > In this general signing-a-script context, I think a verifier might want
> to
> > see the time conditions under which it may be spent. The proof container
> > could include an optional nLockTime which defaults to 0 and nSequence
> which
> > defaults to 0x...
>
> Good point!
>
> >> I think it would just use the default (SIGHASH_ALL?) for simplicity.
> >> Is there a good reason to tweak it?
> >
> > I took another look and there should definitely be a byte appended to the
> > end of the sig so that the encoding checks pass, but I think it might as
> > well be a 0x00 byte since it's not actually a sighash flag.
>
> I think the sighash flag affects the outcome of the actual
> verification, but I could be mistaken.
>
> -Kalle.
> ___
> 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] Revisiting BIP 125 RBF policy.

[Greg Sanders via bitcoin-dev]

Yes.

On Wed, Feb 14, 2018 at 9:08 AM, Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd  wrote:
>
>> On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote:
>> > Surely CPFP is already computing the package-fee rates of mempool
>> > transactions.  That is the value we need to compute.
>>
>> True, maybe we can just reuse the CPFP calculation now. That said, AFAIK
>> that's
>> only done in the miner code, not the mempool, so that may not be trivial
>> to
>> actually do.
>>
>
> Do you (or anyone else) know if the package fee rate is considered when
> ejecting transactions from the bottom of the mempool when the mempool gets
> too large?
>
> ___
> 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] Taproot: Privacy preserving switchable scripting

[Greg Sanders via bitcoin-dev]

Interesting parallels to current Elements sidechain peg-in functionality.
User tweaks the watchmen(BTC holder) pubkey using P2CH, committing to a
script that is used on the *sidechain side* as spending authorization for
that bitcoin output rather than mainnet.

I think composing the two can be done as:

P = C' + H(C'||S')G + H(C||S)G

where C is redefined as `C' + H(C'||S')G`, which for Bitcoin consensus
purposes is just a single pubkey.



On Mon, Jan 22, 2018 at 7:30 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Interest in merkelized scriptPubKeys (e.g. MAST) is driven by two main
> areas: efficiency and privacy. Efficiency because unexecuted forks of
> a script can avoid ever hitting the chain, and privacy because hiding
> unexecuted code leaves scripts indistinguishable to the extent that
> their only differences are in the unexecuted parts.
>
> As Mark Friedenbach and others have pointed out before it is almost
> always the case that interesting scripts have a logical top level
> branch which allows satisfaction of the contract with nothing other
> than a signature by all parties.  Other branches would only be used
> where some participant is failing to cooperate. More strongly stated,
> I believe that _any_ contract with a fixed finite participant set
> upfront can be and should be represented as an OR between an N-of-N
> and whatever more complex contract you might want to represent.
>
> One point that comes up while talking about merkelized scripts is can
> we go about making fancier contract use cases as indistinguishable as
> possible from the most common and boring payments. Otherwise, if the
> anonymity set of fancy usage is only other fancy usage it may not be
> very large in practice. One suggestion has been that ordinary
> checksig-only scripts should include a dummy branch for the rest of
> the tree (e.g. a random value hash), making it look like there are
> potentially alternative rules when there aren't really.  The negative
> side of this is an additional 32-byte overhead for the overwhelmingly
> common case which doesn't need it.  I think the privacy gains are
> worth doing such a thing, but different people reason differently
> about these trade-offs.
>
> It turns out, however, that there is no need to make a trade-off.  The
> special case of a top level "threshold-signature OR
> arbitrary-conditions" can be made indistinguishable from a normal
> one-party signature, with no overhead at all, with a special
> delegating CHECKSIG which I call Taproot.
>
> Let's say we want to create a coin that can be redeemed by either
> Alice && Bob   or by CSV-timelock && Bob.
>
> Alice has public A, Bob has pubkey B.
>
> We compute the 2-of-2 aggregate key C = A + B.  (Simplified; to
> protect against rogue key attacks you may want to use the MuSig key
> aggregation function [1])
>
> We form our timelock script S =  " OP_CSV OP_DROP B
> OP_CHECKSIGVERIFY"
>
> Now we tweak C to produce P which is the key we'll publish: P = C +
> H(C||S)G.
>
> (This is the attack hardened pay-to-contract construction described in [2])
>
> Then we pay to a scriptPubKey of [Taproot supporting version] [EC point P].
>
> Now Alice and Bob-- assuming they are both online and agree about the
> resolution of their contract-- can jointly form a 2 of 2 signature for
> P, and spend as if it were a payment to a single party (one of them
> just needs to add H(C||S) to their private key).
>
> Alternatively, the Taproot consensus rules would allow this script to
> be satisfied by someone who provides the network with C (the original
> combined pubkey), S, and does whatever S requires-- e.g. passes the
> CSV check and provides Bob's signature. With this information the
> network can verify that C + H(C||S) == P.
>
> So in the all-sign case there is zero overhead; and no one can tell
> that the contract alternative exists. In the alternative redemption
> branch the only overhead is revealing the original combined pubkey
> and, of course, the existence of the contract is made public.
>
> This composes just fine with whatever other merkelized script system
> we might care to use, as the S can be whatever kind of data we want,
> including the root of some tree.
>
> My example shows 2-of-2 but it works the same for any number of
> participants (and with setup interaction any threshold of
> participants, so long as you don't mind an inability to tell which
> members signed off).
>
> The verification computational complexity of signature path is
> obviously the same as any other plain signature (since its
> indistinguishable). Verification of the branch redemption requires a
> hash and a multiplication with a constant point which is strictly more
> efficient than a signature verification and could be efficiently fused
> into batch signature validation.
>
> The nearest competitor to this idea that I can come up with would
> supporting a simple delegation where the output can be spent by the
> named 

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Greg Sanders via bitcoin-dev]

>I'm shocked that so many people are resisting the idea that just *maybe* there
could be people in other parts of the world who do not want to use or
cannot use the strict set of latin characters and words from the English
language.


You're mistaking concern for users potentially losing money with disdain
for them. I can read a few languages, yet I would not advise users to use a
wordlist that might not have support across multiple wallet
implementations, resulting in lock-in or worse.

If I'm wrong, great, more people can use software strictly in their native
language in a safe manner!

On Mon, Jan 8, 2018 at 10:26 AM, AJ West <ajw...@gmail.com> wrote:

> Greg yes, there were already examples in this very thread of people
> explaining how they use languages other than English. I'm shocked that so
> many people are resisting the idea that just *maybe* there could be
> people in other parts of the world who do not want to use or cannot use the
> strict set of latin characters and words from the English language.
>
> I agree with Sjors and maybe I'm simplifying too much, but can't we just
> map an existing ISO/UTF language character standard to the seeds? Why is
> there a word list at all? Choose a flexible encoding standard, create a
> clever map to the bytes, make sure to include a checksum.
>
> As an aside, I know there are some conventions which add space for error
> correction but I personally don't love the idea of somebody inputting what
> they think is the proper seed, only to have it auto-corrected and thus
> reinforcing their erroneously saved/written seed backup.
>
> Pavol, why do you say "I learned that it was something I should've been
> more persistently against?" I still can't see any good arguments as to why
> we should limit this to English other than "It's easier to support a single
> language" which comes at the cost of "It's hard for me to backup my seed"
> for those who don't speak English.
>
> On Mon, Jan 8, 2018 at 10:23 AM, Matias Alejo Garcia via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> > Let me re-phrase: Is it a known thing for users to actually use it?
>>
>> yes. Based on language stats from the app stores, roughly 30% to 40% of
>> Copay users have their backup on a language
>> other than English, and we constantly get requests to support new
>> languages in BIP39.
>>
>> On Mon, Jan 8, 2018 at 11:54 AM, Greg Sanders <gsander...@gmail.com>
>> wrote:
>>
>>> Let me re-phrase: Is it a known thing for users to actually use it?
>>>
>>> On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia <ema...@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>>> Has anyone actually used the multilingual support in bip39?
>>>>>
>>>>
>>>>
>>>> Copay (and all its clones) use it.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> If a feature of the standard has not been(widely?) used in years, and
>>>>> isn't supported in any major wallet(?), it seems indicative it was a
>>>>> mistake to add it in the first place, since it's a footgun in the making
>>>>> for some poor sap who can't even read English letters when almost all
>>>>> documentation is written in English.
>>>>>
>>>>> On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
>>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>>
>>>>>> On 2018-01-08 at 07:35:52 +, 木ノ下じょな <kinoshitaj...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> This is very sad.
>>>>>>>
>>>>>>> The number one problem in Japan with BIP39 seeds is with English
>>>>>>> words.
>>>>>>>
>>>>>>> I have seen a 60 year old Japanese man writing down his phrase
>>>>>>> (because he kept on failing recovery), and watched him write down 
>>>>>>> "aneter"
>>>>>>> for "amateur"...
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>> If you understand English and can spell, you read a word, your brain
>>>>>>> processes the word, and you can spell it on your own when writing down.
>>>>>>> Not many Japanese people ca

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Greg Sanders via bitcoin-dev]

Let me re-phrase: Is it a known thing for users to actually use it?

On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia <ema...@gmail.com>
wrote:

>
>
> On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Has anyone actually used the multilingual support in bip39?
>>
>
>
> Copay (and all its clones) use it.
>
>
>
>
>
>>
>> If a feature of the standard has not been(widely?) used in years, and
>> isn't supported in any major wallet(?), it seems indicative it was a
>> mistake to add it in the first place, since it's a footgun in the making
>> for some poor sap who can't even read English letters when almost all
>> documentation is written in English.
>>
>> On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On 2018-01-08 at 07:35:52 +, 木ノ下じょな <kinoshitaj...@gmail.com> wrote:
>>>
>>>> This is very sad.
>>>>
>>>> The number one problem in Japan with BIP39 seeds is with English words.
>>>>
>>>> I have seen a 60 year old Japanese man writing down his phrase (because
>>>> he kept on failing recovery), and watched him write down "aneter" for
>>>> "amateur"...
>>>>
>>>> [...]
>>>>
>>>> If you understand English and can spell, you read a word, your brain
>>>> processes the word, and you can spell it on your own when writing down.
>>>> Not many Japanese people can do that, so they need to copy letter for
>>>> letter, taking a long time, and still messing up on occasion.
>>>>
>>>> [...]
>>>>
>>>> Defining "everyone should only use English, because ASCII is easier to
>>>> plan for" is not a good way to move forward as a currency.
>>>>
>>>
>>> Well said.  Thank you for telling of these experiences.  Now please,
>>> let’s put the shoe on the other foot.
>>>
>>> I ask everybody who wants an English-only mnemonic standard to entrust
>>> *their own money* to their abilities to very, very carefully write this
>>> down—then later, type it back in:
>>>
>>> すさん たんろ りゆう しもん ていおん しとう
>>> とこや はやい おうさま ほくろ けちゃっふ たもつ
>>>
>>> (Approximate translation:  “Whatever would you do if Bitcoin had been
>>> invented by somebody named Satoshi Nakamoto?”)
>>>
>>> No, wait:  That is only a 12-word mnemonic.  We are probably talking
>>> about a Trezor; so now, hey you there, stake the backup of your life’s
>>> savings on your ability to handwrite *this*:
>>>
>>> にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
>>> とうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
>>> へこむ すひょう おやゆひ ふせく けさき めいきょく こんまけ
>>>
>>> Ready to bet your money on *that* as a backup phrase in your own hands?
>>> No?  Then please, stop demanding that others risk *their* money on the
>>> inverse case.
>>>
>>> 
>>>
>>> If you cheat here by having studied Japanese, then remember that many
>>> Japanese people know English and other European languages, too.  Then think
>>> of how much money would be lost by your non-Japanese-literate family and
>>> friends—if BIP 39 had only Japanese wordlists, and your folks needed to
>>> wrestle with the above phrases as their “mnemonics”.
>>>
>>> In such cases, the phrases cannot be called “mnemonics” at all.  A
>>> “mnemonic” implies aid to memory.  Gibberish in a wholly alien writing
>>> system is much worse even than transcribing pseudorandom hex strings.  The
>>> Japanese man in the quoted story, who wrote “aneter” for “amateur”, was not
>>> dealing with a *mnemonic*:  He was using the world’s most inefficient means
>>> of making cryptic bitstrings *less* userfriendly.
>>>
>>> 
>>>
>>> I began this thread with a quite simple request:  Is “日本語” an
>>> appropriate string for identifying the Japanese language to Japanese
>>> users?  And what of the other strings I posted for other languages?
>>>
>>> I asked this as an implementer working on my own instance of the
>>> greatest guard against vendor lock-in and stale software:  Independent
>>> implementations.  —  I asked, because obviously, I myself do not speak all
>>> these different languages; and I want to implement them all.  *All.*
>>>
>>> Some replies have been interesting in their own r

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Greg Sanders via bitcoin-dev]

Has anyone actually used the multilingual support in bip39?

If a feature of the standard has not been(widely?) used in years, and isn't
supported in any major wallet(?), it seems indicative it was a mistake to
add it in the first place, since it's a footgun in the making for some poor
sap who can't even read English letters when almost all documentation is
written in English.

On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2018-01-08 at 07:35:52 +, 木ノ下じょな  wrote:
>
>> This is very sad.
>>
>> The number one problem in Japan with BIP39 seeds is with English words.
>>
>> I have seen a 60 year old Japanese man writing down his phrase (because
>> he kept on failing recovery), and watched him write down "aneter" for
>> "amateur"...
>>
>> [...]
>>
>> If you understand English and can spell, you read a word, your brain
>> processes the word, and you can spell it on your own when writing down.
>> Not many Japanese people can do that, so they need to copy letter for
>> letter, taking a long time, and still messing up on occasion.
>>
>> [...]
>>
>> Defining "everyone should only use English, because ASCII is easier to
>> plan for" is not a good way to move forward as a currency.
>>
>
> Well said.  Thank you for telling of these experiences.  Now please, let’s
> put the shoe on the other foot.
>
> I ask everybody who wants an English-only mnemonic standard to entrust
> *their own money* to their abilities to very, very carefully write this
> down—then later, type it back in:
>
> すさん たんろ りゆう しもん ていおん しとう
> とこや はやい おうさま ほくろ けちゃっふ たもつ
>
> (Approximate translation:  “Whatever would you do if Bitcoin had been
> invented by somebody named Satoshi Nakamoto?”)
>
> No, wait:  That is only a 12-word mnemonic.  We are probably talking about
> a Trezor; so now, hey you there, stake the backup of your life’s savings on
> your ability to handwrite *this*:
>
> にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
> とうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
> へこむ すひょう おやゆひ ふせく けさき めいきょく こんまけ
>
> Ready to bet your money on *that* as a backup phrase in your own hands?
> No?  Then please, stop demanding that others risk *their* money on the
> inverse case.
>
> 
>
> If you cheat here by having studied Japanese, then remember that many
> Japanese people know English and other European languages, too.  Then think
> of how much money would be lost by your non-Japanese-literate family and
> friends—if BIP 39 had only Japanese wordlists, and your folks needed to
> wrestle with the above phrases as their “mnemonics”.
>
> In such cases, the phrases cannot be called “mnemonics” at all.  A
> “mnemonic” implies aid to memory.  Gibberish in a wholly alien writing
> system is much worse even than transcribing pseudorandom hex strings.  The
> Japanese man in the quoted story, who wrote “aneter” for “amateur”, was not
> dealing with a *mnemonic*:  He was using the world’s most inefficient means
> of making cryptic bitstrings *less* userfriendly.
>
> 
>
> I began this thread with a quite simple request:  Is “日本語” an appropriate
> string for identifying the Japanese language to Japanese users?  And what
> of the other strings I posted for other languages?
>
> I asked this as an implementer working on my own instance of the greatest
> guard against vendor lock-in and stale software:  Independent
> implementations.  —  I asked, because obviously, I myself do not speak all
> these different languages; and I want to implement them all.  *All.*
>
> Some replies have been interesting in their own right; but thus far,
> nobody has squarely addressed the substance of my question.
>
> Most worrisome is that much of the discussion has veered into criticism of
> multi-language support.  I opened with a question about other languages,
> and I am getting replies which raise a hue and cry of “English only!”
>
> Though I am fluent and literate in English, I am uninterested in ever
> implementing any standard of this nature which is artificially restricted
> to English.  I am fortunate; for as of this moment, we have a standard
> called “BIP 39” which has seven non-English wordlists, and four more
> pending in open pull requests (#432, #442, #493, #621).
>
> I request discussion of language identification strings appropriate for
> use with that standard.
>
> (P.S., I hope that my system did not mangle anything in the foregoing.  I
> have seen weird copypaste behaviour mess up decomposed characters.  I
> thought of this after I searched for and collected some visually
> fascinating phrases; so I tried to normalize these to NFC...  It should go
> without saying, easyseed output the Japanese perfectly!)
>
>
> --
> null...@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
> Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
> 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG)  (PGP RSA: 0x36EBB4AB699A10EE)
> “‘If you’re not doing anything wrong, you have nothing to hide.’