Nostr notes by

📅 Original date posted:2023-10-17 🗒️ Summary of this ...

2023-10-18T15:02:10+02:00

In reply to nevent1q…zlfw
_________________________

📅 Original date posted:2023-10-17
🗒️ Summary of this message: Batched splicing is risky because if an old state is broadcasted and confirmed before the splice, it can disrupt the process. It is important for batched splicing mechanisms to have a backout option.
📝 Original message:
> 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231017/831a1dfc/attachment-0001.html>;

📅 Original date posted:2023-07-19 🗒️ Summary of this ...

2023-07-20T11:54:05+02:00

In reply to nevent1q…0anh
_________________________

📅 Original date posted:2023-07-19
🗒️ Summary of this message: The complexity of the Lightning Network (LN) cannot be resolved with covenants alone. More than CTV is needed for significant gains, and there are other BOLTs to consider. Finding interesting primitives and working backwards from there may be a more productive approach. Covenants can contribute to LN's maturity, but the prioritization is unclear.
📝 Original message:
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 at 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 at 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 [3].
>>
>> About the Bitcoin Contracting Primitives WG, a Github repository was
>> started and maintained to archive and document all the primitives (apo,
>> tluv, ctv, the taproot annex, sighash_group, CSFS, cat, txhash, evict,
>> check_output_covenant_verify, inherited ids, anyamount, singletons,
>> op_vault) and the corresponding protocols (payment pools, vaults,
>> drivechains, trust-minimized mining pools payouts). We had a total of 6
>> monthly meetings on the Libera chat #bitcoin-contracting-primitives-wg for
>> a number of more than 20 individual attendees representing most of the
>> parts of the community. I think (missing march logs). Numerous in-depth
>> discussions did happen on the repository and on the channel on things like
>> "merkelized all the things" or "payment pools for miners payoffs".
>>
>> As I've been busy on the Lightning-side and other Bitcoin projects, I've
>> not run an online meeting since the month of April, while still having a
>> bunch of fruitful technical discussions with folks involved in the effort
>> at conferences and elsewhere. I launched the effort as an experiment with
>> the soft commitment to dedicate 20% of my time on it, after few successful
>> sessions I think such a process has an interest of its own, however it
>> comes with direct competition of my time to work on Lightning robustness.
>> Getting my hands dirty on low-level LDK development recently made me
>> realize we still have years of titan work to get a secure and reliable
>> Lightning Network.
>>
>> As such, between extended covenant capabilities for advanced contracts
>> coming as a reality for Bitcoin _or_ LN working smoothly at scale with
>> 50-100M UTXO-sharing users on it during the next 5-7 years cycle, I think
>> the latter goal is more critical for Bitcoin existential survival, and
>> where on a personal title I'll allocate the best of my time and energy (and
>> somehow it match the "slow" technical activity on bitcoin-inquisition
>> mostly done by Lightning hands).
>>
>> This is my personal conclusion only on the state of Bitcoin technological
>> momentum, and this is quite tainted by my deep background in Lightning
>> development. If you've been working on covenant changes proposals, please
>> don't take it as a discouragement, I think Taproot (privacy-preserving
>> script policies behind the taproot tree branches) and Schnorr (for native
>> multi-sig) soft forks have shown how it can improve the building of
>> self-custody solutions by one or two order of magnitude, and small
>> incremental changes might be good enough to have a lower technical
>> consensus bar.
>>
>> On my side, I'll pursue pure R&D works on CoinPool, notably coming with
>> better solutions with the interactivity issue and mass-compression of
>> withdrawal and design exotic advanced Bitcoin contracts based on the
>> taproot annex, though more in a "l'art pour l'art" approach for the time
>> being [4]. Additionally, I might start to submit an in-depth security
>> review of consensus changes under pseudonyms, it has already been done in
>> the past and somehow it's good practice in terms of "message neutrality"
>> [5]. If folks wanna experiment in terms of payment pools deployment, Greg
>> Maxwell's old joinpool can be used today (and somehow it's worthy of its
>> own as a net advance for coinjoins).
>>
>> I'll honestly acknowledge towards the community, I might have
>> overpromised with the kickstart of this new process aiming to move the
>> frontlines in matters of Bitcoin consensus changes development process. On
>> the other hand, I think enough sessions of the working group have been
>> runned and enough marks of technical interests have been collected to
>> demonstrate the minimal value of such a process, so I would estimate my
>> open-source balance sheet towards the community to be in good standing ?
>> (open-minded question).
>>
>> I don't think Bitcoin fundamentally lacks compelling technical proposals
>> to advance the capabilities of Bitcoin Script today, nor the crowd of
>> seasoned and smart protocol developers to evaluate mature proposals
>> end-to-end and on multiple dimensions with a spirit of independence.
>> Rather, I believe what Bitcoin is lacking is a small crowd of technical
>> historians and archivist doing the work of assessing, collecting and
>> preserving consensus changes proposals and QA devs to ensure any consensus
>> change proposals has world-class battle-ground testing before to be
>> considered for deployment, ideally with the best standards of Bitcoin
>> decentralization and FOSS neutrality [6].
>>
>> If you would like to pursue the maintenance and nurturing of the Bitcoin
>> Contracting Primitives WG (or the bitcoin-inquisition fork or collaborate
>> with Optech to organize industry-wise workshop on covenants at the image of
>> what has been done in 2019 for Taproot), that you're willing to show
>> proof-of-work and you estimate that operational ground, legal information
>> or financial resources will anchor your individual work on the long-term,
>> don't hesitate to reach out, I'll see what I can do with a disinterested
>> mind [7].
>>
>> With humility,
>> Antoine
>>
>> [0]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.html
>> [1]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020233.html
>> [2]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
>> [3] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
>> [4] Version 0.2 of the CoinPool whitepaper addressing most of the
>> remaining "Big Problems" is still pending on my visit to co-author Gleb
>> Naumenko in Ukraine, which has been postponed few times in light of the
>> conflict operational evolutions.
>> [5] See
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017614.html.
>> For the philosophical reasons of doing so, I invite you to read Foucault's
>> famous essay "Le philosophe masque".
>> [6] Somehow I come to share Jeremy's thesis's "Product management is not
>> "my Job" it's yours" in matters of consensus changes. I believe we might be
>> past the technical complexity threshold where even simple consensus changes
>> can be conducted from A to Z as a one man job or even by a group of 2/3
>> elite devs.
>> [7] I've been reached out multiple times and consistently by R&D
>> non-profits, plebs whales and VC firms who were interested to commit
>> resources to advance softforks and covenants in the Bitcoin space, no doubt
>> when you're reliable and with a track record, folks are ready to offer you
>> opportunities to work full-time on consensus changes.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230719/3995d4a3/attachment-0001.html>;

📅 Original date posted:2023-06-03 🗒️ Summary of this ...

2023-06-19T20:19:53+02:00

In reply to nevent1q…shdc
_________________________

📅 Original date posted:2023-06-03
🗒️ Summary of this message: The issue of annex malleability in Bitcoin transactions could mislead developers into thinking their transactions are immune to replacement, warns a developer. The problem arises when a transaction is denied entry into the mempool because a counter-party has put in a strictly worse transaction for miners by bloating its weight, not adding fees.
📝 Original message:
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 <joost.jager at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230603/49e83857/attachment.html>;

📅 Original date posted:2023-06-03 🗒️ Summary of this ...

2023-06-19T20:19:52+02:00

In reply to nevent1q…nktn
_________________________

📅 Original date posted:2023-06-03
🗒️ Summary of this message: The annex trick is used to publish the missing piece of the control block for the new taproot output, maintaining the node's O(1) state. However, it could mislead developers into believing their transactions are immune to replacement. Mempool policy should bridge the gap between node anti-DoS and an entity's ability to pay miners more via feerate-ordered queue.
📝 Original message:
> 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 at lists.linuxfoundation.org> wrote:

> On Sat, Jun 3, 2023 at 9:49 AM Joost Jager <joost.jager at gmail.com> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230603/00985f2b/attachment.html>;

📅 Original date posted:2023-06-02 🗒️ Summary of this ...

2023-06-19T20:19:50+02:00

In reply to nevent1q…u8yq
_________________________

📅 Original date posted:2023-06-02
🗒️ Summary of this message: Greg Sanders is interested in using the annex data with LN-Symmetry, but there are concerns about the fact that BIP341/342 signature hashes do not cover other inputs' annex fields, which could lead to griefing. Possible solutions include limiting annex usage to opt-in inputs or having a field that limits the total transaction weight.
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230602/7ff6b96e/attachment-0001.html>;

📅 Original date posted:2022-12-08 📝 Original message: ...

2023-06-09T15:07:38+02:00

In reply to nevent1q…lz7s
_________________________

📅 Original date posted:2022-12-08
📝 Original message:
Antoine,

> While the 2*to_self_delay sounds the maximum time delay in the state
publication scenario where the cheating counterparty publishes a old state
then the honest counterparty publishes the latest one, there could be the
case where the cheating counterparty broadcast chain of old states, up to
mempool's `limitancestorcount`. However, this chain of eltoo transactions
could be replaced by the honest party paying a higher-feerate (assuming
something like nversion=3). I think there might still be an attack
triggerable under certain economic conditions, where the attacker overbids
with the higher-feerate transaction until the HTLC cltv expires. If this
attack is plausible, it could be even opportun if you're batching against
multiple channels, where the victims are not able to coordinate response.

Feel free to assume that we've worked around mempool pinning for all of
these discussions, otherwise we're pretty hosed regardless. I'm implicitly
assuming V3+ephemeral anchors, which disallows batched bumps, for example.
You'll need to give some room for "slippage", but I think
shared_delay/2*shared_delay is going to end up dominating UX in any
non-layered scheme.

> I wonder if the introduction of watchtower specific transactions doesn't
break the 2*to_self_delay assumption

This architecture doesn't suffer from 2*self_delay, and each transition
aside from Slow/Settle/SX.y has no relative timelock so that relative
timelock is all that matters. It does introduce a watchtower cycle, so it's
not longer a one-shot architecture, or even k-shot exactly, it ends up
looking like vanilla eltoo for that single path.

Cheers,
Greg

On Thu, Dec 8, 2022 at 2:14 PM Antoine Riard <antoine.riard at gmail.com>
wrote:

> Hi AJ,
>
> The eltoo irc channel is ##eltoo on Libera chat.
>
> > - 2022-10-21, eltoo/chia:
> https://twitter.com/bramcohen/status/1583122833932099585
>
> On the eltoo/chia variant, from my (quick) understanding, the main
> innovation aimed for is the limitation of the publication of eltoo states
> more than once by a counterparty, by introducing a cryptographic puzzle,
> where the witness can be produced once and only once ? I would say you
> might need the inheritance of the updated scriptpubkey across the chain of
> eltoo states, with a TLUV-like mechanism.
>
> > The basic idea is "if it's a two party channel with just Alice and Bob,
> > then if Alice starts a unilateral close, then she's already had her say,
> > so it's only Bob's opinion that matters from now on, and he should be
> > able to act immediately", and once it's only Bob's opinion that matters,
> > you can simplify a bunch of things.
>
> From my understanding, assuming Eltoo paper terminology, Alice can publish
> an update K transaction, and then after Bob can publish an update
> transaction K<N or Alice can publish the settlement transaction N, or Bob
> can publish an update transaction N. The main advantage of this
> construction I can see is a strict bound on the shared_delay encumbered in
> the on-chain publication of the channel ?
>
> > fast forwards: we might want to allow our channel partner
> > to immediately rely on a new state we propose without needing a
> > round-trip delay -- this potentially makes forwarding payments much
> > faster (though with some risk of locking the funds up, if you do a
> > fast forward to someone who's gone offline)
>
> IIRC, there has already been a "fast-forward" protocol upgrade proposal
> based on update-turn in the LN-penalty paradigm [0]. I think reducing the
> latency of HTLC propagation across payment paths would constitute a UX
> improvement, especially a link-level update mechanism upgrade deployment
> might be incentivized by routing algorithms starting to penalize routing
> hops HTLC relay latency. What is unclear is the additional risk of locking
> the funds up. If you don't receive acknowledgement the fast forward state
> has been received, you should still be able to exit with the state N-1 ?
> However, the fast-forward trade-off might sound acceptable, with time you
> might expect reliable routing hops in the core of the graph, and flappy
> spokes at the edge.
>
> > doubled delays: once we publish the latest state we can, we want to
> > be able to claim the funds immediately after to_self_delay expires;
> > however if our counterparty has signatures for a newer state than we
> > do (which will happen if it was fast forwarded), they could post that
> > state shortly before to_self_delay expires, potentially increasing
> > the total delay to 2*to_self_delay.
>
> While the 2*to_self_delay sounds the maximum time delay in the state
> publication scenario where the cheating counterparty publishes a old state
> then the honest counterparty publishes the latest one, there could be the
> case where the cheating counterparty broadcast chain of old states, up to
> mempool's `limitancestorcount`. However, this chain of eltoo transactions
> could be replaced by the honest party paying a higher-feerate (assuming
> something like nversion=3). I think there might still be an attack
> triggerable under certain economic conditions, where the attacker overbids
> with the higher-feerate transaction until the HTLC cltv expires. If this
> attack is plausible, it could be even opportun if you're batching against
> multiple channels, where the victims are not able to coordinate response.
>
> > penalties: when you do a unilateral close, attempting to cheat comes
> > with no cost to you and a possible benefit if you succeed, but
> > potentially does cost your channel partner (either in forcing them
> > to spend on-chain fees to update to the correct state, or in the risk
> > of loss if their node malfunctions occassionally) -- a penalty could
> > reduce this incentive to cheat
>
> I think there has been a proposal in the past to enable penalties on top
> of symmetric states by leveraging asymmetric witnesses [1]. Further, I
> wonder if there is a game-theory interest for penalty-on-top-eltoo, it
> could be an incentive against laziness, where a dysfunctional trusted
> watchtower broadcasts an old state. On the qualification of the game-theory
> soundness, I think one would have to run the empirical case study: select
> channel counterparties randomly (no out-of-band assumptions), one set with
> eltoo+penalty and the other with vanilla eltoo, observe the broadcast of
> revoked states over some period.
>
> > trustless watchtowers: we may want to consider the possibility of a
> > watchtower holding onto obsolete states and colluding with an
> > attacker to attempt to cheat us
>
> In terms of pinning and other mempool games, I think honest participant
> own states leveraged by a colluding watchtower might increase the attack
> surface, especially post-anchor with the SIGHASH_SINGLE malleability on
> second-stage HTLC transactions.
>
> > (I think for initial eltoo experimentation it doesn't make sense to try
> to
> > deal with all (or perhaps any) of those constraints; simple and working
> > is better than complex and theoretical. But having them written down so
> > the ideas can be thought about and looked up later still seems useful)
>
> I share the belief -- "simple and working" enable shorter iteration cycles
> and hopefully fasten the protocol design learning curve. Beyond, I think
> it's also realistic in face of the state of the LN ecosystem, especially on
> the watchtower issue. AFAICT, there is no even multi trusted watchtower
> design covering the full execution of the protocol (i.e including
> HTLC-preimage/ HTLC-timeout claim), and such implementation is far from
> simple, as from now on you LN's chain backend might have asynchronicity
> issue to solve between your on-chain monitoring state machine (at least
> speaking in knowledge of the LDK-architecture).
>
> > * WA.n, WB.n : watchtower update to state n
> > - this is for an untrusted watchtower to correct attempted cheating
> > by Bob on behalf of Alice (or vice-versa). Spends UB.k or WA.k
> > (or UA.k/WB.k) respectively, provided k < n.
>
> I wonder if the introduction of watchtower specific transactions doesn't
> break the 2*to_self_delay assumption (iiuc it's a design goal of current
> protocol) and what is the design rationale. Beyond that, there is a concern
> with watchtower-specific transactions, it might leak your towers topology
> (i.e the number of them and the distribution in the p2p network) to an
> adversary.
>
> > * SA.n, SB.n : slowly claim funds according to state n
> > - this is for Alice to claim her funds if Bob is completely offline
> > (or vice-versa). Spends UA.n, UB.n, WA.n or WB.n with relative
> > timelock of to_self_delay.
>
> If I'm following correctly the description, this is logically equivalent
> to the sweep of a `to_local`/`to_remote` output on a commitment transaction
> though instead the waiting delay is eltoo shared_delay. There is no
> to_self_delay, at the punishment seems only to happen on the update-level,
> or maybe one should be also able to punish slow fund exit, and another
> relative locktime should exist on the S* transactions.
>
> > * Alice and Bob's watchtower collude, but Bob has many watchtowers:
> >
> > F -> UA.k1 -> WB.k2 -> WB.n -> (to_self_delay) -> SA.n -> money
>
> Could the punishment transactions R* be also delegated to watchtowers,
> assuming they have been pre-signed to lockdown the exit scriptpubkeys ?
>
> > In order to allow fast-forwards, when Alice proposes a new state,
> > she needs to send her partial signatures to allow Bob to unilaterally
> > accept the new state, ie sigs for: UB.n, CB.n, SB.n, RB.n. But she
> > also needs to be able to claim the funds if Bob proposes the new state
> > and broadcasts UB.n, she needs to be able broadcast CA.n. This can be
> > achieved with an adaptor signature approach (spelt out a bit more fully
> > in the gist) or a CTV-like approach, provided that UB.n reveals the
> > state needed to calculate the the CTV commitment (see "EXPR_SETTLE" in
> >
> https://github.com/instagibbs/bolts/blob/29fe6d36cbad4101d5ec76c2b19c83c1494ac2fc/XX-eltoo-transactions.md
> ).
>
> If you would like to have fast forward of chain of transactions, I wonder
> if there could be also the "sig-in-the-script" trick, where UB.n
> scriptpubkey (or one of its tapscripts) contains the signature for CB.n,
> SB.n, RB.n. Though you might have an issue of re-generating the
> witnessscript in case of state loss.
>
> > * how to add fees -- the U/W transactions are 1-in/1-out transactions
> > that can't be trivially CPFPed by the proposer and need to have
> > fees added (either SINGLE/ANYONECANPAY signatures or having a 0-sat
> > ephemeral output and package relay might be workable); the C/S/R
> > transactions are 1-in/many-out transactions, but have balance outputs
> > that can be immediately spent to pay for fees via CPFP if package
> > relay is available.
>
> Assuming something like nversion=3, the SINGLE/ANYONCANPAY could be a
> viable fee-bumping mechanism, as ancestor-based pinning should be less of a
> concern. Ephemeral anchor output could be a more efficient direction, if
> the output value can be cooperatively inflated from the channel value,
> rather than relying on external fee-bumping reserves. I think even more
> efficient fee-bumping primitives can be introduced later.
>
> > * how to pay watchtowers -- when a watchtower broadcasts a W
> > transaction, it needs to add fees, and it's not clear (to me) how it
> > could fairly and reliably ensure it's compensated for those costs,
> > particularly if multiple W transactions are broadcast for a single
> > unilateral close attempt, due to one or more watchtowers colluding
> > with an attacker, or simply having out of date information.
>
> I wonder if paying a watchtower, or getting paid as a watchtower isn't a
> "counterparty risk" similar to what is happening with jamming due to
> non-covered HTLC forward risk. The watchtower has the risk of not being
> paid a posteriori and the user has the risk of the tower not acting. There
> is even a trade-off between tower costs and safety, as the more towers you
> have, more robust if your Lightning channel (in theory, as you also have a
> duplication of the key material).
>
> > * lack of layered transactions -- while this prevents you having to
> > wait longer than to_self_delay before you can claim channel funds,
> > it still means that any htlc that is going to timeout sooner than that
> > may not be claimable on-chain, meaning you need to set
> > cltv_expiry_delta >= to_self_delay.
>
> From a security perspective, offsetting the cltv_expiry_delta to a value
> superior to to_self_delay can be considered as an improvement, especially
> if it gradually does it network-wide. On the other hand, if routing
> algorithms start to penalize long-cltv-delta payment paths as the timevalue
> of liquidity is priced in routing fees, this design rationale might not be
> aligned with long-term LN network incentives (as of today even more
> loosely-defined than miner incentives).
>
> > * extending to multiparty channels -- penalising is hard if there's
> > more than two parties, fast forwards are probably impossible since
> > you need multiple round-trips to coordinate signatures anyway, and if
> > you're doing channels-within-channels to reduce your n-party channel
> > to an easier to update 2-party channel you're probably forced to have
> > to_self_delay for each layer of channels. Also, just figuring out how
> > to coordinate multiparty state updates and even keeping everyone in
> > a multiparty channel online consistently to generate new signatures
> > seems potentially hard?
>
> I don't know if penalising has been a solved issue for mulit-party, at
> least in a trustless fashion in the same way we have with 2-party
> LN-penalty (you could devise weird scheme based on timelock, taproot tree
> and threshold signatures incentivizing towards the convergence of a
> "consensus" punishment, still...) Figuring out coordinating multi-party
> states updates sounds workable with modern consensus algorithms (e.g Raft),
> though still conserving the fast forward effect is a high bar, it might be
> better deferred to an uplifted layer of 2-of-2 LN channels. The only reason
> you might have payments at the multi-party level (with the signature of the
> N-of-N participants requested) only for privacy or liquidity allocation
> reason. Though effectively, it sounds like your multiparty
> channel coordination mechanism should encompass party eviction or
> partitioning the offline parties. One or two orders of magnitude of
> complexity beyond the 2-party eltoo channel case, I think.
>
> Antoine
>
> [0] https://github.com/lightning/bolts/pull/867
> [1] https://github.com/LLFourn/witness-asymmetric-channel
>
> Le mer. 7 déc. 2022 à 00:36, Anthony Towns <aj at erisian.com.au> a écrit :
>
>> Hi all,
>>
>> On the eltoo irc channel we discussed optimising eltoo for the 2-party
>> scenario; figured it was probably worth repeating that here.
>>
>> This is similar to:
>>
>> - 2018-07-18, simplified eltoo:
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/001363.html
>> - 2021-09-17, IID 2Stage,
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019470.html
>> - 2022-09-29, Daric: https://eprint.iacr.org/2022/1295
>> - 2022-10-21, eltoo/chia:
>> https://twitter.com/bramcohen/status/1583122833932099585
>>
>> The basic idea is "if it's a two party channel with just Alice and Bob,
>> then if Alice starts a unilateral close, then she's already had her say,
>> so it's only Bob's opinion that matters from now on, and he should be
>> able to act immediately", and once it's only Bob's opinion that matters,
>> you can simplify a bunch of things.
>>
>> A "gist" for this idea is
>> https://gist.github.com/ajtowns/53e0f735f4d5c06a681429d937200aa5 (it
>> goes into a little more detail in places, though doesn't cover trustless
>> watchtowers at all).
>>
>>
>>
>> In particular, there are a few practical constraints that we might like
>> to consider for 2-party channels with eltoo:
>>
>> - fast forwards: we might want to allow our channel partner
>> to immediately rely on a new state we propose without needing a
>> round-trip delay -- this potentially makes forwarding payments much
>> faster (though with some risk of locking the funds up, if you do a
>> fast forward to someone who's gone offline)
>>
>> - doubled delays: once we publish the latest state we can, we want to
>> be able to claim the funds immediately after to_self_delay expires;
>> however if our counterparty has signatures for a newer state than we
>> do (which will happen if it was fast forwarded), they could post that
>> state shortly before to_self_delay expires, potentially increasing
>> the total delay to 2*to_self_delay.
>>
>> - penalties: when you do a unilateral close, attempting to cheat comes
>> with no cost to you and a possible benefit if you succeed, but
>> potentially does cost your channel partner (either in forcing them
>> to spend on-chain fees to update to the correct state, or in the risk
>> of loss if their node malfunctions occassionally) -- a penalty could
>> reduce this incentive to cheat
>>
>> - trustless watchtowers: we may want to consider the possibility of a
>> watchtower holding onto obsolete states and colluding with an
>> attacker to attempt to cheat us
>>
>> What follows is a rough approach for dealing with all those issues for
>> two-party channels. It's spelled out in a little more detail in the gist.
>>
>> (I think for initial eltoo experimentation it doesn't make sense to try to
>> deal with all (or perhaps any) of those constraints; simple and working
>> is better than complex and theoretical. But having them written down so
>> the ideas can be thought about and looked up later still seems useful)
>>
>> In more detail: unilateral closes are handled by each channel participant
>> maintaining five transactions, which we'll call:
>>
>> * UA.n, UB.n : unilaterally propose closing at state n
>> - this is for Alice or Bob to spend the funding tx for a unilater
>> close to state n. Spends the funding transaction.
>>
>> * WA.n, WB.n : watchtower update to state n
>> - this is for an untrusted watchtower to correct attempted cheating
>> by Bob on behalf of Alice (or vice-versa). Spends UB.k or WA.k
>> (or UA.k/WB.k) respectively, provided k < n.
>>
>> * CA.n, CB.n : cooperatively claim funds according to state n
>> - this is for Alice to confirm Bob's unilateral close (or vice-versa).
>> Spends UB.k, WA.k (or UA.k/WB.k respectively), provided k <= n
>>
>> * SA.n, SB.n : slowly claim funds according to state n
>> - this is for Alice to claim her funds if Bob is completely offline
>> (or vice-versa). Spends UA.n, UB.n, WA.n or WB.n with relative
>> timelock of to_self_delay.
>>
>> * RA.n, RB.n : claim funds with penalty after unilateral close to
>> revoked state
>> - this is for Alice to update the state if Bob attempted to cheat
>> (or vice-versa). Spends UB.k or WA.k (or UA.k/WB.k respectively)
>> conditional on k < n - 1; outputs are adjusted to transfer a fixed
>> penalty of penalty_msat from Bob's balance to Alice's (or vice-versa)
>>
>> Each of these "transactions" requires a pre-signed signature; however
>> the actual transaction/txid will vary in cases where a transaction has
>> the possibility of spending different inputs (eg "Spends UB.k or WA.k").
>> In particular UA.n/UB.n can be constructed with known txids and non-APO
>> signatures but WA.n/WB.n/CA.n/CB.n/SA.n/SB.n/RA.n/RB.n all require
>> APO signatures.
>>
>> They're named such that Alice can immediately broadcast all the *A.n
>> transactions (provided a tx that it can spend has been broadcast) and
>> Bob can likewise immediately broadcast all the *B.n transactions.
>>
>> Scenarios where Alice decides to unilaterally close the channel might
>> look like:
>>
>> * if Alice/Bob can't communicate directly, but both are online:
>>
>> F -> UA.n -> CB.n -> money
>>
>> (balances and htlcs claimed, no delay)
>>
>> * if Bob has gone offline entirely:
>>
>> F -> UA.n -> (to_self_delay) -> SA.n -> money
>>
>> * Alice cheats, Bob punishes:
>>
>> F -> UA.k -> RB.n -> money[Alice pays Bob penalty]
>>
>> * Bob is offline, Alice cheats, but Bob has a watchtower:
>>
>> F -> UA.k -> WB.n -> (to_self_delay) -> SA.n -> money
>>
>> * Alice and Bob's watchtower collude, but Bob's not offline:
>>
>> F -> UA.k1 -> WB.k2 -> RB.n -> money[Alice pays Bob penalty]
>>
>> * Alice and Bob's watchtower collude, but Bob has many watchtowers:
>>
>> F -> UA.k1 -> WB.k2 -> WB.n -> (to_self_delay) -> SA.n -> money
>>
>> For Alice to successfully cheat, she needs Bob to be offline for at least
>> to_self_delay, and for all Bob's watchtowers to either also be offline,
>> or colluding.
>>
>> This can be simplified somewhat, if you don't care about all the features:
>>
>> * If you don't care about trustless watchtowers you can drop WA.n/WB.n
>> (and simplify SA.n/SB.n to not require an APO signature)
>>
>> * If you don't care about penalties you can set penalty_msat to 0 and
>> allow RA.n/RB.n to spend k<=n. In this case, you can either drop
>> CA.n/CB.n entirely, or you can have CA.n/CB.n only be used for directly
>> spending of UB.n/UA.n and thus not require APO signatures
>>
>> In order to allow fast-forwards, when Alice proposes a new state,
>> she needs to send her partial signatures to allow Bob to unilaterally
>> accept the new state, ie sigs for: UB.n, CB.n, SB.n, RB.n. But she
>> also needs to be able to claim the funds if Bob proposes the new state
>> and broadcasts UB.n, she needs to be able broadcast CA.n. This can be
>> achieved with an adaptor signature approach (spelt out a bit more fully
>> in the gist) or a CTV-like approach, provided that UB.n reveals the
>> state needed to calculate the the CTV commitment (see "EXPR_SETTLE" in
>>
>> https://github.com/instagibbs/bolts/blob/29fe6d36cbad4101d5ec76c2b19c83c1494ac2fc/XX-eltoo-transactions.md
>> ).
>>
>> Note that in this scenario Alice doesn't provide WB.n to Bob
>> immediately. This is okay, as if Alice proposes UA.(n-1) (her most
>> recent state), Bob can still immediately claim via CA.n. If Bob did have
>> WB.n; then if Alice proposed UA.(n-1) Bob could wait for an initial
>> to_self_delay period and broadcast WB.n, forcing Alice to wait for an
>> additional to_self_delay before being able to claim her funds via SA.n.
>>
>> Note also that this is why RA.n/RB.n require "k < n - 1" -- otherwise
>> Alice would only be able to broadcast UA.(n-1) and Bob would immediately
>> be able to penalise by broadcasting RB.n.
>>
>> Note that if you're using a watchtower and wish to punish your
>> counterparty if it attempts to cheat, you should only pass WA.(n-2)
>> to your watchtowers, not WA.(n-1) or WA.n.
>>
>>
>>
>> This doesn't address any potential issues from:
>>
>> * how to add fees -- the U/W transactions are 1-in/1-out transactions
>> that can't be trivially CPFPed by the proposer and need to have
>> fees added (either SINGLE/ANYONECANPAY signatures or having a 0-sat
>> ephemeral output and package relay might be workable); the C/S/R
>> transactions are 1-in/many-out transactions, but have balance outputs
>> that can be immediately spent to pay for fees via CPFP if package
>> relay is available.
>>
>> * how to pay watchtowers -- when a watchtower broadcasts a W
>> transaction, it needs to add fees, and it's not clear (to me) how it
>> could fairly and reliably ensure it's compensated for those costs,
>> particularly if multiple W transactions are broadcast for a single
>> unilateral close attempt, due to one or more watchtowers colluding
>> with an attacker, or simply having out of date information.
>>
>> * lack of layered transactions -- while this prevents you having to
>> wait longer than to_self_delay before you can claim channel funds,
>> it still means that any htlc that is going to timeout sooner than that
>> may not be claimable on-chain, meaning you need to set
>> cltv_expiry_delta >= to_self_delay.
>>
>> * extending to multiparty channels -- penalising is hard if there's
>> more than two parties, fast forwards are probably impossible since
>> you need multiple round-trips to coordinate signatures anyway, and if
>> you're doing channels-within-channels to reduce your n-party channel
>> to an easier to update 2-party channel you're probably forced to have
>> to_self_delay for each layer of channels. Also, just figuring out how
>> to coordinate multiparty state updates and even keeping everyone in
>> a multiparty channel online consistently to generate new signatures
>> seems potentially hard?
>>
>> Cheers,
>> aj
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221208/78e37af8/attachment-0001.html>;

📅 Original date posted:2022-08-10 📝 Original message: In ...

2023-06-09T15:06:41+02:00

In reply to nevent1q…qxnx
_________________________

📅 Original date posted:2022-08-10
📝 Original message:
In this vector, I'm pretty sure feerate/total fee pinning is the same
issue. Even if you don't have to increase feerate, you have to pay for
100*1000=100,000 sats due to rule#3.

There's been some work trying to document the exact replacement behavior
implemented in core since it has drifted so much, and the feerate one would
be "rule#6" in the doc:
https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md

Making sure inputs are confirmed completely mitigates this, so I'm guessing
it's not much of an issue.

On Wed, Aug 10, 2022 at 2:03 PM Eugene Siegel <elzeigel at gmail.com> wrote:

> I quickly looked it up and it seems that bitcoind has a function
> PaysMoreThanConflicts which checks that the tx pays a higher feerate than
> the replaced tx. This isn't a BIP125 rule AFAICT so I think that's what
> tripped me up. That means I'm wrong about the ancestor bulking variant as a
> malicious counterparty can put a high feerate splice tx at the bottom of
> the mempool, requiring a higher feerate to replace it.
>
> On Wed, Aug 10, 2022 at 12:31 PM Greg Sanders <gsanders87 at gmail.com>
> wrote:
>
>> Your reading is correct.
>>
>> My example was that if TxB, size 100vB with feerate 1000 sat/vbyte, has
>> an 100kvB ancestor paying 1 sat/vbyte. The effective package rate for those
>> two transactions will be (100*1,000 + 100,000*1)/(100,000 + 100) = ~2
>> sat/vybte
>>
>> This means TxB will not be picked up if the prevailing rate is > 2
>> sat/byte. Let's say it's 4 sat/vbyte prevailing rate. To replace it with
>> TxB', one still has to pay to evict TxB, at roughly 1000/4=250 times the
>> normal feerate.
>>
>> Sorry if I got the math wrong here, but at least trying to get the idea
>> across.
>>
>> On Wed, Aug 10, 2022 at 12:20 PM Eugene Siegel <elzeigel at gmail.com>
>> wrote:
>>
>>> Looking it up, rule 3 is "The replacement transaction pays an absolute
>>> fee of at least the sum paid by the original transactions." but here the
>>> ancestors aren't getting replaced so I don't think the replacement has to
>>> pay for them? Or maybe your comment was just generally about how it can
>>> matter in certain cases
>>>
>>> On Wed, Aug 10, 2022 at 12:06 PM Greg Sanders <gsanders87 at gmail.com>
>>> wrote:
>>>
>>>> > I think the ancestor bulking variant of pinning only matters if you
>>>> are trying to add a new descendant and can't due to the ancestor/descendant
>>>> limits.
>>>>
>>>> Not quite. It also matters if you want to RBF that transaction, since
>>>> low feerate ancestor junk puts the transaction at the bottom of the
>>>> mempool, so to speak, even if it has a high feerate itself. You are forced
>>>> to pay "full freight" to replace it via bip125 rule#3 even though it's not
>>>> going to be mined.
>>>>
>>>> (I don't know if that applies here, just noting the wrinkle)
>>>>
>>>> On Wed, Aug 10, 2022 at 11:37 AM Eugene Siegel <elzeigel at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I think the ancestor bulking variant of pinning only matters if you
>>>>> are trying to add a new descendant and can't due to the ancestor/descendant
>>>>> limits. In this example, since all of the outputs are locked with `1
>>>>> OP_CSV`, you can't add a descendant to the splice tx. The ancestor bulking
>>>>> also shouldn't matter for RBF since you wouldn't be replacing any of the
>>>>> ancestors, only the splice tx. I think it might matter if the new funding
>>>>> output isn't encumbered.
>>>>>
>>>>> The new funding output can't have `1 OP_CSV` unless we also change the
>>>>> commit tx format, and I'm not sure if it would work. The commit tx has the
>>>>> disable bit set in nSequence so it isn't compatible with the sequence lock.
>>>>> Enabling the bit might be tricky since then the commit tx may have a
>>>>> time-based or block-based locktime based on the lower bits of the obscured
>>>>> commitment number, and it must be block-based (and non-zero) for the
>>>>> sequence lock to work. That means if it's not encumbered, pinning exists
>>>>> since an attacker can make a junk tree using the anchor output. It is
>>>>> replaceable using RBF since you have your own commit tx (with anchor) to
>>>>> broadcast.
>>>>>
>>>>> Eugene
>>>>> _______________________________________________
>>>>> Lightning-dev mailing list
>>>>> Lightning-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220810/ab81a7c1/attachment-0001.html>;

📅 Original date posted:2022-08-10 📝 Original message: Your ...

2023-06-09T15:06:40+02:00

In reply to nevent1q…60zn
_________________________

📅 Original date posted:2022-08-10
📝 Original message:
Your reading is correct.

My example was that if TxB, size 100vB with feerate 1000 sat/vbyte, has an
100kvB ancestor paying 1 sat/vbyte. The effective package rate for those
two transactions will be (100*1,000 + 100,000*1)/(100,000 + 100) = ~2
sat/vybte

This means TxB will not be picked up if the prevailing rate is > 2
sat/byte. Let's say it's 4 sat/vbyte prevailing rate. To replace it with
TxB', one still has to pay to evict TxB, at roughly 1000/4=250 times the
normal feerate.

Sorry if I got the math wrong here, but at least trying to get the idea
across.

On Wed, Aug 10, 2022 at 12:20 PM Eugene Siegel <elzeigel at gmail.com> wrote:

> Looking it up, rule 3 is "The replacement transaction pays an absolute fee
> of at least the sum paid by the original transactions." but here the
> ancestors aren't getting replaced so I don't think the replacement has to
> pay for them? Or maybe your comment was just generally about how it can
> matter in certain cases
>
> On Wed, Aug 10, 2022 at 12:06 PM Greg Sanders <gsanders87 at gmail.com>
> wrote:
>
>> > I think the ancestor bulking variant of pinning only matters if you are
>> trying to add a new descendant and can't due to the ancestor/descendant
>> limits.
>>
>> Not quite. It also matters if you want to RBF that transaction, since low
>> feerate ancestor junk puts the transaction at the bottom of the mempool, so
>> to speak, even if it has a high feerate itself. You are forced to pay "full
>> freight" to replace it via bip125 rule#3 even though it's not going to be
>> mined.
>>
>> (I don't know if that applies here, just noting the wrinkle)
>>
>> On Wed, Aug 10, 2022 at 11:37 AM Eugene Siegel <elzeigel at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I think the ancestor bulking variant of pinning only matters if you are
>>> trying to add a new descendant and can't due to the ancestor/descendant
>>> limits. In this example, since all of the outputs are locked with `1
>>> OP_CSV`, you can't add a descendant to the splice tx. The ancestor bulking
>>> also shouldn't matter for RBF since you wouldn't be replacing any of the
>>> ancestors, only the splice tx. I think it might matter if the new funding
>>> output isn't encumbered.
>>>
>>> The new funding output can't have `1 OP_CSV` unless we also change the
>>> commit tx format, and I'm not sure if it would work. The commit tx has the
>>> disable bit set in nSequence so it isn't compatible with the sequence lock.
>>> Enabling the bit might be tricky since then the commit tx may have a
>>> time-based or block-based locktime based on the lower bits of the obscured
>>> commitment number, and it must be block-based (and non-zero) for the
>>> sequence lock to work. That means if it's not encumbered, pinning exists
>>> since an attacker can make a junk tree using the anchor output. It is
>>> replaceable using RBF since you have your own commit tx (with anchor) to
>>> broadcast.
>>>
>>> Eugene
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220810/7ae290f0/attachment-0001.html>;

📅 Original date posted:2022-08-10 📝 Original message: > ...

2023-06-09T15:06:40+02:00

In reply to nevent1q…gwvw
_________________________

📅 Original date posted:2022-08-10
📝 Original message:
> I think the ancestor bulking variant of pinning only matters if you are
trying to add a new descendant and can't due to the ancestor/descendant
limits.

Not quite. It also matters if you want to RBF that transaction, since low
feerate ancestor junk puts the transaction at the bottom of the mempool, so
to speak, even if it has a high feerate itself. You are forced to pay "full
freight" to replace it via bip125 rule#3 even though it's not going to be
mined.

(I don't know if that applies here, just noting the wrinkle)

On Wed, Aug 10, 2022 at 11:37 AM Eugene Siegel <elzeigel at gmail.com> wrote:

> Hi,
>
> I think the ancestor bulking variant of pinning only matters if you are
> trying to add a new descendant and can't due to the ancestor/descendant
> limits. In this example, since all of the outputs are locked with `1
> OP_CSV`, you can't add a descendant to the splice tx. The ancestor bulking
> also shouldn't matter for RBF since you wouldn't be replacing any of the
> ancestors, only the splice tx. I think it might matter if the new funding
> output isn't encumbered.
>
> The new funding output can't have `1 OP_CSV` unless we also change the
> commit tx format, and I'm not sure if it would work. The commit tx has the
> disable bit set in nSequence so it isn't compatible with the sequence lock.
> Enabling the bit might be tricky since then the commit tx may have a
> time-based or block-based locktime based on the lower bits of the obscured
> commitment number, and it must be block-based (and non-zero) for the
> sequence lock to work. That means if it's not encumbered, pinning exists
> since an attacker can make a junk tree using the anchor output. It is
> replaceable using RBF since you have your own commit tx (with anchor) to
> broadcast.
>
> Eugene
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220810/cedb54f6/attachment.html>;

📅 Original date posted:2022-04-21 📝 Original message: I ...

2023-06-09T15:05:53+02:00

In reply to nevent1q…70ng
_________________________

📅 Original date posted:2022-04-21
📝 Original message:
I think I mentioned this out of band to Alex, but (b) is what Erlay's
proposal is for Bitcoin gossip, so it's worth studying up.

On Thu, Apr 21, 2022 at 9:18 AM Matt Corallo <lf-lists at mattcorallo.com>
wrote:

> Instead of trying to make sure everyone’s gossip acceptance matches
> exactly, which as you point it seems like a quagmire, why not (a) do a sync
> on startup and (b) do syncs of the *new* things. This way you aren’t stuck
> staring at the same channels every time you do a sync. Sure, if you’re
> rejecting a large % of channel updates in total you’re gonna end up hitting
> degenerate cases, but we can consider tuning the sync frequency if that
> becomes an issue.
>
> Like eclair, we don’t bother to rate limit and don’t see any issues with
> it, though we will skip relaying outbound updates if we’re saturating
> outbound connections.
>
> On Apr 14, 2022, at 17:06, Alex Myers <alex at endothermic.dev> wrote:
>
>
>
> Hello lightning developers,
>
>
> I’ve been investigating set reconciliation as a means to reduce bandwidth
> and redundancy of gossip message propagation. This builds on some earlier work
> from Rusty using the minisketch library [1]. The idea is that each node
> will build a sketch representing it’s own gossip set. Alice’s node will
> encode and transmit this sketch to Bob’s node, where it will be merged with
> his own sketch, and the differences produced. These differences should
> ideally be exactly the latest missing gossip of both nodes. Due to size
> constraints, the set differences will necessarily be encoded, but Bob’s
> node will be able to identify which gossip Alice is missing, and may then
> transmit exactly those messages.
>
>
> This process is relatively straightforward, with the caveat that the sets
> must otherwise match very closely (each sketch has a maximum capacity for
> differences.) The difficulty here is that each node and lightning
> implementation may have its own rules for gossip acceptance and
> propagation. Depending on their gossip partners, not all gossip may
> propagate to the entire network.
>
>
> Core-lightning implements rate limiting for incoming channel updates and
> node announcements. The default rate limit is 1 per day, with a burst of
> 4. I analyzed my node’s gossip over a 14 day period, and found that, of
> all publicly broadcasting half-channels, 18% of them fell afoul of our
> spam-limiting rules at least once. [2]
>
>
> Picking several offending channel ids, and digging further, the majority
> of these appear to be flapping due to Tor or otherwise intermittent
> connections. Well connected nodes may be more susceptible to this due to more
> frequent routing attempts, and failures resulting in a returned channel
> update (which otherwise might not have been broadcast.) A slight
> relaxation of the rate limit resolves the majority of these cases.
>
>
> A smaller subset of channels broadcast frequent channel updates with minor
> adjustments to htlc_maximum_msat and fee_proportional_millionths
> parameters. These nodes appear to be power users, with many channels and
> large balances. I assume this is automated channel management at work.
>
>
> Core-Lightning has updated rate-limiting in the upcoming release to
> achieve a higher acceptance of incoming gossip, however, it seems that a
> broader discussion of rate limits may now be worthwhile. A few immediate
> ideas:
>
> - A common listing of current default rate limits across lightning
> network implementations.
>
> - Internal checks of RPC input to limit or warn of network propagation
> issues if certain rates are exceeded.
>
> - A commonly adopted rate-limit standard.
>
>
> My aim is a set reconciliation gossip type, which will use a common,
> simple heuristic to accept or reject a gossip message. (Think one channel
> update per block, or perhaps one per block_height << 5.) See my github
> for my current draft. [3] This solution allows tighter consensus, yet suffers
> from the same problem as original anti-spam measures – it remains
> somewhat arbitrary. I would like to start a conversation regarding gossip
> propagation, channel_update and node_announcement usage, and perhaps even
> bandwidth goals for syncing gossip in the future (how about a million
> channels?) This would aid in the development of gossip set
> reconciliation, but could also benefit current node connection and
> routing reliability more generally.
>
>
> Thanks,
>
> Alex
>
>
> [1] https://github.com/sipa/minisketch
>
> [2]
> https://github.com/endothermicdev/lnspammityspam/blob/main/sampleoutput.txt
>
> [3]
> https://github.com/endothermicdev/lightning-rfc/blob/gossip-minisketch/07-routing-gossip.md#set-reconciliation
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220421/ba5e3e5e/attachment-0001.html>;

📅 Original date posted:2018-05-08 📝 Original message: ...

2023-06-09T14:50:40+02:00

In reply to nevent1q…se0g
_________________________

📅 Original date posted:2018-05-08
📝 Original message:
>From what I understand talking to folks, the linear properties of these
signature tricks are maintained under a number of post-quantum schemes.

On Tue, May 8, 2018 at 8:44 AM, Benjamin Mord <ben at mord.family> wrote:

>
> If I'm not mistaken, the scriptless scripts concept (as currently
> formulated) falls to Schor's algorithm, and at present there is no
> alternative implementation of the concept to fall back on. Correct? Lest we
> build a house of cards, I'd strongly urge everyone to not depend on
> functional concepts whose underlying cryptographic primitives cannot be
> swapped in an emergency.
>
> Sure, we use ecdsa for example (which is also vulnerable to Schor's
> algorithm), but in contrast to scriptless scripts we have a variety of
> backup primitives at our disposal that fulfill the same functional
> objective.
>
> If scriptless scripts are found possible under lattice-based cryptography
> for example, that would be something I suppose. The functional concept of
> scriptless scripts is indeed very awesome - we just need to add some
> cryptographic conservatism before we build on it.
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180508/5b5bfa6b/attachment.html>;

📅 Original date posted:2015-11-19 📝 Original message: The ...

2023-06-09T14:45:08+02:00

In reply to nevent1q…40pd
_________________________

📅 Original date posted:2015-11-19
📝 Original message:
The hardfork variant is quite simple, if I understood it correctly. You
just stick the signatures in another parallel merkle tree. So if you don't
want to validate signatures, just don't download them, and validate
everything else. TXIDs don't use the signature at all. Nothing to malleate,
AFAIK. Not sure what the softfork plan is, but it will be a talk at Scaling
Bitcoin HK.

On Thu, Nov 19, 2015 at 10:28 AM, Glenn Tarbox, PhD <glenn at tarbox.org>
wrote:

>
> On Thu, Nov 19, 2015 at 4:33 AM, sickpig at gmail.com <sickpig at gmail.com>
> wrote:
>
>> Hi Pierre
>>
>> you could start here
>>
>>
>> https://github.com/ElementsProject/elementsproject.github.io#segregated-witness
>>
>> https://people.xiph.org/~greg/blockstream.gmaxwell.elements.talk.060815.pdf
>> https://github.com/ElementsProject/elements
>
>
> There was a brief blip on Reddit:
>
>
> https://www.reddit.com/r/Bitcoin/comments/3ngtx5/could_the_segregated_witness_part_of_the/cwnthlh
>
> Its weird how little information there is on Segregated Witness. I'm
> guessing its a simple concept and those working on it (sipa / gmaxwell)
> haven't felt the need to write it up.
>
> That it "apparently" can be done with a soft fork similar to P2SH is good
> news... I guess...
>
>
> --
> Glenn H. Tarbox, PhD
> =]|[=
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151119/630dbc4e/attachment-0001.html>;

📅 Original date posted:2023-03-14 🗒️ Summary of this ...

2023-06-08T01:20:08+02:00

In reply to nevent1q…0plc
_________________________

📅 Original date posted:2023-03-14
🗒️ Summary of this message: Discussion on privacy and efficiency in Bitcoin vaults, including rotating trigger authorization keys and batching multiple inputs with different internal keys.
📝 Original message: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 <freedom at reardencode.com>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230314/b2e848e8/attachment.html>;

📅 Original date posted:2023-03-09 🗒️ Summary of this ...

2023-06-08T01:20:00+02:00

In reply to nevent1q…xn56
_________________________

📅 Original date posted:2023-03-09
🗒️ Summary of this message: New opcodes proposed for Bitcoin's OP_VAULT concept allow rate-limiting of two-step unvaulting and single-step vaulting, reducing theft risk during watchtower outages.
📝 Original message: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 = <deposit-delay> OP_CSV OP_DROP <pubkey> OP_CHECKSIG OP_DUP
<V> OP_LESSTHANOREQUAL OP_VERIFY OP_FORWARD_PARTIAL OP_FORWARD_TARGET
OP_FORWARD_SELF

$withdrawal is spent by:

<self-idx> <target-idx> <spk> <0<=v<=V> <signature>

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 <aj at erisian.com.au> 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 =
> > <trigger> <auth> <script> <spend-delay> OP_VAULT
>
> With the opcodes above, the trigger_leaf (for spending some of the
> vaulted funds via your hot wallet) script might look like:
>
> OP_FORWARD_PARTIAL OP_FORWARD_SELF
> 1 "288 OP_CSV OP_DROP OP_CTV" OP_FORWARD_LEAF_UPDATE
> key CHECKSIG
>
> So if you have 2.0 BTC in a vault utxo, you might spend 0.4 BTC by
> supplying the witness data:
>
> 160000000 (1.6BTC in sats)
> 0 (output 0 puts 1.6BTC goes back into the vault)
> <ctvhash> (the outputs where you want the remaining 0.4 BTC to end up)
> 1 (the output idx that will be spend via the CTV path once the CSV
> delay is done)
> <sig> (a signature of this transaction via the hot wallet "key")
>
> That is, the script becomes:
>
> 160000000 FORWARD_PARTIAL
> 0 FORWARD_SELF
> 1 <ctvhash> 1 "288 CSV DROP CTV" FORWARD_LEAF_UPDATE
> sig key CHECKSIG
>
> Output 1 would then have a tapscript of "<ctvhash> 288 OP_CSV OP_DROP
> OP_CTV", satisfied with an empty witness stack (along with the recovery
> path, etc).
>
> Output 0 is just 1.6BTC back in your vault, and immediately available
> for use.
>
> Other inputs/outputs (for fees etc) would still be committed to by <sig>,
> so nothing here is malleable. The script here is about 45 bytes (compared
> to 34 for a simple "key CHECKSIG") and the witness data is about 105 bytes
> (compared to 65 bytes for just a signature), which seems pretty nice.
>
> > ... =
> > other (optional) leaves in the taptree
>
> This would allow you to have multiple hot wallets (if any of them are
> compromised you can still use the recovery path to avoid loss of funds;
> but if some hot wallet becomes temporarily *inaccessible* you can still
> easily spend the funds via one of the alternative hot wallets), or,
> if you have multiple watchtowers validating your spends and recovering
> funds to your cold wallet on a violation, you could have multiple recovery
> paths to provide some auditability for who triggered the recovery.
>
> > Happens via script-path spend to $expr_withdraw, i.e. a timelocked
> > OP_CTV.
>
> Note that if you calculated the OP_CTV incorrectly (eg, you don't set a
> correct nSequence timelock, so that any tx that passes OP_CTV won't pass
> the OP_CSV check, and vice-versa) then this spend path becomes invalid,
> and the funds can only be reclaimed via some other path (key path spend,
> recovery tapscript, potentially an alternative hotwallet script path).
>
> OP_FORWARD_LEAF_UPDATE is equivalent to a very specific form of TLUV,
> namely "FALSE <h> 2 TLUV", where "<h>" is calculated by building the
> script, prefixing the pushes, then doing the Hash_TapLeaf calculation.
>
> Not being able to tweak the internal public key ("FALSE" rather than
> "<x>") means this can't be used to build a coinpool with unilateral
> exit -- you can't remove your key from the key path, which screws over
> everyone who's still in the coinpool.
>
> On the other hand, not tweaking the internal public key avoids introducing
> all the x-only pubkey complications, and keeps it relatively simple,
> which is nice, and keeping things simple and targeted now means there's
> still plenty of OP_SUCCESS opcodes available later for something more
> general, if that turns out to be desirable.
>
> Cheers,
> aj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230309/7c5a5e29/attachment.html>;

📅 Original date posted:2023-03-06 🗒️ Summary of this ...

2023-06-08T01:19:59+02:00

In reply to nevent1q…qqrn
_________________________

📅 Original date posted:2023-03-06
🗒️ Summary of this message: Greg proposes to TLUV-ify the proposal for withdrawal authorization, using OP_FORWARD_LEAF_UPDATE to avoid recursive script execution and ensure secure spending.
📝 Original message: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 <james.obeirne at gmail.com>
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. <trigger-sPK-hash> + 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, {$recovery_leaf, $trigger_leaf, ...})
>
> where
>
> internal_key =
> unchanged from original proposal (some very safe recovery key)
>
> $recovery_leaf =
> [<opt.> <recovery> <auth>] <recovery sPK hash> OP_VAULT_RECOVER
>
> $trigger_leaf =
> <trigger> <auth> <script> <spend-delay> OP_VAULT
>
> ... =
> other (optional) leaves in the taptree
>
>
> Triggering a withdrawal request
> -------------------------------
>
> To trigger the start of the withdrawal process, an output of the above
> form is spent with a witness that contains
>
> - Taproot control block pointing to $trigger_leaf.
> - <trigger-vout-idx>, indicating the trigger output which must abide
> by the rules given below.
>
>
> ## Output structure
>
> taproot(internal_key, {$recovery_leaf, $expr_withdraw, ...})
>
> where
>
> $recovery_leaf is preserved exactly
> $expr_withdraw =
> <spend-delay> OP_CSV OP_DROP <target-ctv-hash> OP_CTV
> ... is preserved exactly
>
>
> (Spoiler: note here that the only thing that is changing is
> s/expr_trigger/expr_withdrawl/ from the initial vault ouput.)
>
> Of course $expr_withdraw *could* be prefixed by an optional "withdrawal
> authorization" script, if some sensible use for that is found.
>
> The validation rules are essentially unchanged from the existing
> proposal:
>
> - The total amount of all OP_VAULT inputs with matching $recovery_leaf
> values must be reflected in output <trigger-vout-idx>
>
> - <trigger-vout-idx> must correspond to an output that is identical to
> the input taptree but with the spent tapleaf (OP_VAULT) swapped out
> for the timelocked CTV constructed using <target-ctv-hash> and
> <spend-delay> as extracted from the spent tapleaf
> - internal_key is preserved
> - the whole rest of the taptree is preserved
> - (this is what ensures the parameters of the vault are forwarded)
>
> All batching, fee management characteristics are the same.
>
>
> Finalizing withdrawal
> ---------------------
>
> Happens via script-path spend to $expr_withdraw, i.e. a timelocked
> OP_CTV.
>
>
> Recovery
> --------
>
> Can happen from any of the above outputs using the $recovery_leaf
> script path in a way very similar to the existing OP_VAULT proposal.
>
>
> ---
>
> To reiterate, all aspects of the existing OP_VAULT proposal are either
> preserved or improved upon in terms of malleability reduction,
> composability, and flexibility. So big thanks to AJ and Greg.
>
> I'll undertake implementing these changes in the coming days to verify
> that they are, as expected, workable.
>
> James
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230306/3e92a245/attachment-0001.html>;

📅 Original date posted:2023-03-02 🗒️ Summary of this ...

2023-06-08T01:19:56+02:00

In reply to nevent1q…7ve4
_________________________

📅 Original date posted:2023-03-02
🗒️ Summary of this message: Greg proposes a new script for the EXPR_TRIGGER opcode, allowing for withdrawal authorization and introducing a refund path.
📝 Original message: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:

<trigger> <auth> <stuff> <spend-delay> <2> <OP_CSV OP_DROP
OP_FORWARD_OUTPUTS> OP_FORWARD_LEAF_UPDATE

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

To be clear, <spend-delay> could be embedded in the <script> too, right,
making <2> a <1> in the above? Any reason for one or the other?

Another bonus from this is that you can introduce withdrawal authorization
as well as part of the <script>. Current proposal has no withdrawal
authorization, from what I understand. So each transition in a vault
construct can have authorization, if it desires it.

> I do recognise that it makes it take a variable number of stack elements
though :)

Just when I thought I was out, they pulled me back in.

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

> Having OP_FORWARD_OUTPUTS not leave its input on the stack would let
you move the OP_CSV to the end and drop the OP_DROP too, saving 1 WU.

Previously setting CSV timeout to 0 would result in it not being
satisfiable, if I'm understanding the suggestion correctly. I suppose this
was a side-effect of having OP_UNVAULT take this value directly. Indeed
with `OP_FORWARD_OUTPUTS` being split out there's not really a reason to
use a 0 value?

> I think the existing OP_VAULT cleverness would work here, allowing you
to spend two inputs to the same output, accumulating their values.

Yes I think batching story should be same hopefully. I am assuming all the
accounting OP_VAULT is doing is being done here. We match against the hash
passed in, and fits into the "deferred checks" IIUC.

> OP_FORWARD_REFUND

Again, to be pedantic EXPR_TRIGGER becomes:

<trigger> <auth> <stuff> <spend-delay> <2> <OP_CSV OP_DROP
OP_FORWARD_OUTPUTS> OP_FORWARD_LEAF_UPDATE OP_FORWARD_REFUND

Resulting in 2 more WU at spend time(for small idx). So *up front*
committing to a refund path, perhaps with value explicitly passed in.

Totally forgot about the refund path; will need to mull the issue over, see
how it interacts with BYOF schemes, etc.

Cheers,
Greg

On Wed, Mar 1, 2023 at 11:46 PM Anthony Towns <aj at erisian.com.au> wrote:

> On Wed, Mar 01, 2023 at 10:05:47AM -0500, Greg Sanders via bitcoin-dev
> wrote:
> > Below is a sketch of a replacement for the two opcodes.
>
> I like this! I tried to come up with something along similar lines for
> similar reasons, but I think I tried too hard to reduce it to two opcodes
> or something and got myself confused.
>
> > `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)
>
> I think you could generalise this as follows:
>
> idx .. npush script OP_FORWARD_LEAF_UPDATE
>
> (OP_FLU :) with the behaviour being:
>
> pop script from the stack
> pop npush from the stack (error if non-minimal or <0)
> pop npush entries from the stack,
> prefix script with a minimal push of that entry
> pop idx off the stack (error if idx is not a valid output)
> calculate the spk corresponding to taking the current
> input's spk and replacing the current leaf with the
> given script
> check the output at idx matches this spk, and the
> value from this input accumulates to that output
>
> 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`
>
> That's an additional 5 witness bytes, but a much more generic/composable
> opcode.
>
> Being able to prefix a script with push opcodes avoids the possibility
> of being able to add OP_SUCCESS instructions, so I think this is a fairly
> safe way of allowing a TLUV-ish script to be modified, especially compared
> to OP_CAT.
>
> I do recognise that it makes it take a variable number of stack elements
> though :)
>
> > 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.
>
> 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.
>
> > Could save 2 WU having OP_FORWARD_OUTPUTS take the <spend-delay> directly
> > as an argument, or keep it more general as I did.
>
> Having OP_FORWARD_OUTPUTS not leave its input on the stack would let
> you move the OP_CSV to the end and drop the OP_DROP too, saving 1 WU.
>
> > 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!
>
> I think the existing OP_VAULT cleverness would work here, allowing you
> to spend two inputs to the same output, accumulating their values.
>
> I don't think it quite gives you a way to "refund" values though -- so
> that you can take a vault with 3 BTC, start the <delay> wait to spend
> 1.4 BTC, and then immediately decide to spend an additional 0.8 BTC on
> something else, without the 0.8 BTC effectively having a doubled delay.
>
> I think you could fix that with something as simple as an additional
> "idx OP_FORWARD_REFUND" opcode, though -- then the restriction is just
> that the output at the refund idx has the same sPK as this input, and
> the total value of this input is accumulated amongst all the outputs
> specified by OP_FORWARD opcodes. (Maybe you need to specify the refund
> amount explicitly as well, to keep verification easy)
>
> That would make maybe three new opcodes to cover the "accumulate value
> from one or more inputs into specified outputs":
>
> - OP_FORWARD_LEAF_UPDATE --> forward input value to modified spk
> - OP_FORWARD_DESTINATION --> forward input value to given spk
> - OP_FORWARD_REFUND --> forward part of input value to same spk
>
> along with OP_CTV:
>
> - OP_FORWARD_OUTPUTS --> pay to specific outputs
>
> OP_VAULT's "accumulate value" behaviour here makes the OP_IN_OUT_AMOUNT
> things from TLUV more implicit and automatic, which is nice. I think
> doing TLUV payment pools wouldn't require much more than the ability to
> combine OP_FLU and OP_FDEST in a single script, explicitly specifying
> how much value is extracted via OP_FDEST with the rest assigned to OP_FLU.
>
> Cheers,
> aj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230302/59e4f0f8/attachment.html>;

📅 Original date posted:2023-03-01 🗒️ Summary of this ...

2023-06-08T01:19:55+02:00

In reply to nevent1q…eype
_________________________

📅 Original date posted:2023-03-01
🗒️ Summary of this message: A proposal to decouple the functionalities of `OP_VAULT` and `OP_UNVAULT` into their constituent functions with names, to improve legibility and remove recursive evaluation functionality. The proposal aims to be a drop-in replacement for the existing opcodes.
📝 Original message: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: <spend-delay> OP_CHECKSEQUENCEVERIFY OP_DROP
<target-outputs-hash> 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) <recovery sPK tagged hash (32 bytes)>: 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: <recovery> <auth> <stuff> <recovery sPK tagged hash (32
bytes)> OP_FORWARD_DESTINATION
EXPR_TRIGGER: <trigger> <auth> <stuff> <spend-delay> OP_TRIGGER_FORWARD

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

```
EXPR_WITHDRAW: <spend-delay> OP_CHECKSEQUENCEVERIFY OP_DROP
<target-outputs-hash> 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 <spend-delay> 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 at 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 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230301/067e5b0d/attachment.html>;

📅 Original date posted:2023-02-02 🗒️ Summary of this ...

2023-06-08T01:19:17+02:00

In reply to nevent1q…wcht
_________________________

📅 Original date posted:2023-02-02
🗒️ Summary of this message: OP_2 fails standardness tests in Bitcoin Core unit/functional tests. It was Luke Jr's idea in 2017, and changing test vectors is a concern.
📝 Original message: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 <pete at petertodd.org> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230202/48dcb48f/attachment-0001.html>;

📅 Original date posted:2023-02-02 🗒️ Summary of this ...

2023-06-08T01:19:17+02:00

In reply to nevent1q…66tr
_________________________

📅 Original date posted:2023-02-02
🗒️ Summary of this message: Greg Sanders proposes the Ephemeral Anchors idea in a short draft BIP, with a refreshed pull request, and suggests using OP_2 instead of OP_TRUE in test vectors.
📝 Original message: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 <pete at petertodd.org> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230202/d53025db/attachment.html>;

📅 Original date posted:2023-01-31 🗒️ Summary of this ...

2023-06-08T01:18:51+02:00

In reply to nevent1q…h6r0
_________________________

📅 Original date posted:2023-01-31
🗒️ Summary of this message: Sending funds to future segwit versions is risky, so most exchanges won't enable it. Updating to new versions should be straightforward, and popular open source libraries should support it.
📝 Original message: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 at 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: 0x0000. 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230131/28cd677c/attachment.html>;

📅 Original date posted:2023-01-09 🗒️ Summary of this ...

2023-06-08T01:18:17+02:00

In reply to nevent1q…njap
_________________________

📅 Original date posted:2023-01-09
🗒️ Summary of this message: Proposal for a fix to make OP_UNVAULT compatible with scripthashes by requiring an additional witness data item during OP_VAULT spend.
📝 Original message: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
<target-outputs-hash> 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 at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230109/7ca41bc5/attachment-0001.html>;

📅 Original date posted:2022-12-05 📝 Original message:This ...

2023-06-08T01:17:19+02:00

In reply to nevent1q…uuxa
_________________________

📅 Original date posted:2022-12-05
📝 Original message: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 at 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 at 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/0000000000000000000436aba59d8430061e0e50592215f7f263bfb1073ccac7
>> >
>> https://miningpool.observer/template-and-block/00000000000000000005600404792bacfd8a164d2fe9843766afb2bfbd937309
>> >
>> https://miningpool.observer/template-and-block/00000000000000000004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1
>> >
>> > That presumably means those pools (AntPool twice and "unknown") are
>> > running with large mempools that didn't kept the earlier 1.2sat/vb txs.
>>
>> To be clear, you think that AntPool and that other exchange is running
>> with a
>> larger than normal max mempool size limit? You mean those miners *did*
>> keep the
>> earlier 1.2sat/vb tx?
>>
>> > The txs were mined by Foundry:
>> >
>> >
>> https://miningpool.observer/template-and-block/00000000000000000001382a226aedac822de80309cca2bf1253b35d4f8144f5
>> >
>> > This seems to be pretty good evidence that we currently don't have any
>> > significant hashrate mining with fullrbf policies (<0.5% if there was a
>> > high fee replacement available prior to every block having been mined),
>> > despite the bounty having been collected.
>>
>> Oh, we can put much lower bounds on that. I've been running OTS calendars
>> with
>> full-rbf replacements for a few months without clear evidence of a
>> full-rbf
>> replacement. While there was good reason to think some miners were mining
>> full-rbf before a few years back, they probably didn't bother to reapply
>> their
>> patches each upgrade. `mempoolfullrbf=1` is much simpler to use.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221205/ce59b2c5/attachment.html>;

📅 Original date posted:2022-11-02 📝 Original message:> I ...

2023-06-08T01:16:15+02:00

In reply to nevent1q…947r
_________________________

📅 Original date posted:2022-11-02
📝 Original message:> 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 <aj at erisian.com.au> 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) 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.
>
> As you already acknowledged, any miner that wants this behaviour can just
> pick up the patch (or could run Knots, which already has the feature
> enabled by default). It's simply false to say miners are being forced
> to do anything, no matter what we do here.
>
> If the direction you're facing is one where you're moving towards making
> life easier for people to commit fraud, and driving away businesses
> that aren't doing anyone harm, without achieving anything much else;
> then taking a step backwards seems like a sensible thing to do to me.
>
> (I remain optimistic about coming up with better RBF policy, and willing
> to be gung ho about everyone switching over to it even if it does kill
> off zeroconf, provided it actually does some good and we give people 6
> months or more notice that it's definitely happening and what exactly
> the new rules will be, though)
>
> Cheers,
> aj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221102/a1614798/attachment.html>;

📅 Original date posted:2022-11-02 📝 Original message:My ...

2023-06-08T01:16:11+02:00

In reply to nevent1q…wyzz
_________________________

📅 Original date posted:2022-11-02
📝 Original message: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 at 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 usage in the optimistic case (e.g in Lightning no commitment
> + HTLC transactions broadcast).
>
> For the zeroconf operators, assuming they have access to the UTXO set,
> they can inspect the receiving transactions ancestors nVersion fields, and
> sort those transactions in the wider set of the replaceable ones, as
> they're currently doing for BIP125 opt-in ones.
>
> Long-term, the annoying privacy issue and the assumption that any wallet
> will be a Lightning one could lead to the majority of wallets signaling RBF
> for their spends. Therefore making those wallets incompatible with zeroconf
> services, slowly economically outlawing them. From my perspective, though
> it might be a simplification, it sounds an alternative full rbf way
> forward, where rather than having miners deciding on the policy
> enforcement, we let the users decide with their coins. However, this new
> policy enforcement efficiency is still dependent on the existence of relay
> paths and support at the endpoints that matter, the miner mempools. So in
> fine we might have to realize incentive alignment with hashrate is what
> matters in terms of transaction-relay rules ?
>
> Credit to Greg Maxwell for this idea.
>
> Cheers,
> Antoine
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221102/70b6a272/attachment.html>;

📅 Original date posted:2022-10-27 📝 Original message:To add ...

2023-06-08T01:15:57+02:00

In reply to nevent1q…k3e4
_________________________

📅 Original date posted:2022-10-27
📝 Original message: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 at 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
>
> And other plausible options aren't configurable even at compile time
> -- eg, core doesn't implement BIP 125's inherited signalling rule so
> there's no way to enable it; core doesn't allow opting out of BIP 125
> rule 3 ratchet on absolute fee; core doesn't allow CPFP carveout with
> more than 1 ancestor; core doesn't allow opting out of LOW_S checks
> (even via -acceptnonstdtxn); etc.
>
> We also naturally have different mempool policies between different
> releases: eg, expansions of policy, such as allowing OP_RETURN or
> expanding it from 40 to 80 bytes or new soft forks where old nodes won't
> relay transactions that use the new; and also occassional restrictions
> in policy, such as the LOW_S requirement.
>
>
> While supporting and encouraging different mempool polices might be new
> for core, it's not new for knots: knots changes some of these defaults
> (-permitbaremultisig defaults to false, -datacarriersize is reduced to
> 42), allows the use of -acceptnonstdtxn on mainnet, and introduces new
> options including -spkreuse and -mempoolreplacement (giving the latter
> full rbf behaviour by default). Knots also includes a `-corepolicy`
> option to make it easy to get a configuration matching core's defaults.
>
>
> I think gmaxwell's take from Feb 2015 (in the context of how restrictive
> policy on OP_RETURN data should be) was a reasonable description for
> core's approach up until now:
>
> There is also a matter of driving competent design rather than lazy
> first thing that works. E.g. In stealth addresses the early proposals
> use highly inefficient single ECDH point per output instead of simply
> pooling them. Network behavior is one of the few bits of friction
> driving good technical design rather than "move fast, break things, and
> force everyone else onto my way of doing thing rather than discussing
> the design in public". No one wants to be an outright gatekeeper,
> but the network is a shared resource and it's perfectly reasonable
> node behavior to be stingy about the perpetual storage impact of the
> transactions they're willing to process, especially when it comes to
> neutral technical criteria like the amount of network irrelevant data
> stuffed in transactions.
>
> There is also a very clear pattern we've seen in the past where
> people take anything the system lets them do as strong evidence that
> they have a irrevocable right to use the system in that way, and that
> their only responsibility-- and if their usage harms the system it's
> the responsibility of the system to not permit it. [...
> ...] For mitigating these risks it's optimal if transactions
> seem as uniform and indistinguishable as reasonably possible.
>
> - https://github.com/bitcoin/bitcoin/pull/5286#issuecomment-72564175
>
> Perhaps see also sdaftuar in Nov 2015,
>
> To me the most important question is, is priority something that miners
> want to use?
>
> If a non-negligible amount of hashpower intends to use it in their
> transaction selection, then I think it makes sense for nodes to use it
> too, because it's generally helpful to have your mempool predict the
> UTXO as much as possible, and for nodes to be able to have reasonable
> fee and priority estimates (which won't happen unless they track the
> priority transactions somehow -- I'm presuming that miners run with
> much bigger mempools than regular nodes).
>
> If the answer is no, then that's fine and I don't see a reason to push
> in this direction. I sort of assumed there was enough hashpower mining
> with priority, since last time I checked estimatepriority was still
> giving meaningful results for low-ish blockheights, but I haven't done
> any kind of real analysis.
>
> - https://github.com/bitcoin/bitcoin/pull/6992#issuecomment-155969455
>
> or in June 2019,
>
> What this PR is proposing is to get rid of a command-line option that is
> (a) a footgun for users and (b) does not reflect what I believe to be
> the understanding most users have, which is that [X txs] are expected
> to propagate well on the network.
>
> ..
>
> I don't think this rises to the level that Luke is concerned about,
> namely a prelude to forcing a common relay policy on all nodes. In
> particular I do agree it makes sense that we offer some ways of
> customizing policy parameters (eg the mempool size, min relay fee,
> etc). Instead, I think the justification for this change is that we
> should not support behaviors we think are harmful to the ecosystem
> overall and have no legitimate use-case, and we should eliminate ways
> that users might inadvertently shoot themselves in the foot.
>
> - https://github.com/bitcoin/bitcoin/pull/16171#issuecomment-500393271
>
> (or see discussion in https://github.com/bitcoin/bitcoin/pull/7219)
>
> I don't mean to imply the above are saying "there's one way to do
> things and it's this way", or that the old way of doing things should
> necessarily be the way we keep doing things. Just that previously core
> has tended towards designing a single policy that works as well as it
> can for everyone and the ecosystem as a whole. (I'm also not saying that
> fullrbf can't work well for everyone or the ecosystem as a whole)
>
>
> By contrast, I think the most common response to pushback against the
> full rbf option has been along the lines of "it's just an option, we
> don't want to force people", eg:
>
> Blaming the default false -mempoolfullrbf option for a full RBF network
> would be holding Bitcoin Core developers responsible for the decisions
> of individual node operators and miners. I don't think having the
> option (again, default false) can directly cause a full RBF network,
> and likewise, I don't think removing this option removes the "risk"
> of a full RBF network.
> - glozow
> https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1274949400
>
> NACK. This is a default false option.
> - achow101
> https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1274953204
>
> Erecting artificial barriers to prevent or make it difficult for users
> to do what they want to do, is not appropriate behaviour.
> - luke-jr
> https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1290721905
>
> I'm in general against removing options.
> - instagibbs
> https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1292030700
>
> I think this differs from what core has done in the past, in that
> previously we've tried to ensure a new policy is good for everyone (or as
> nearly as it can be), and then enabled it as soon as it's implemented.
> Any options that have been added have either been to control resource
> usage in ways that don't significantly effect tx propagation, to
> allow people to revert to the old behaviour when the new behaviour is
> controversial (eg the -mempoolreplacement=0 option from 0.12 to 0.18),
> and to make it easier to test/debug the implementation.
>
> Giving people a new relay behaviour they can opt-in to when we aren't
> confident enough to turn on by default doesn't match the approach I've
> seen core take in the past.
>
>
> If this is going to be an ongoing shift in how core sees relay/mempool
> policy, I think that's significant and worth paying attention to.
>
> I don't think it's necessary to have that shift to roll out full rbf.
> The other approach would be either:
>
> * set -mempoolfullrbf=true as the default for 24.0, and just have the
> command line param there in case people want to do a
> "UserRejectedMempoolPolicy" campaign to get everyone to opt-out
>
> * revert it for now because we don't think mainnet is ready for fullrbf
> yet, and introduce it as default true for 25.0 or 26.0 or 27.0 or
> to activate at some scheduled date in that timeframe (potentially
> backporting it to previous releases to help with adoption too,
> whatever). same effect as the previous option, just with a bit more
> advanced notice and time to prepare
>
> I don't think anyone's proposed the first (which I interpret as "most of
> us don't think mainnet is ready for fullrbf today"), but the comments
> above are all pushback by people arguing against (the first step of)
> the second approach, and they seem to be winning the day.
>
> It's also possible that this is something of a one time thing: full rbf
> has been controversial for ages, but widely liked by devs, and other
> attempts (eg making it available in knots) haven't actually achieved
> much of a result in practice. So maybe this is just a special case and
> not a precedent, and when people propose other default false options,
> there will be substantially more resistance to them being merged,
> despite all the talk about users having options that's going on right now.
>
>
> Assuming it is the change of direction it appears to be -- and all of
> the above is really just justification for that assumption -- then like
> I said, I think it's worth seriously considering what it means for people
> to choose their own relay/mempool policies and for you to expect to have
> different mempool policies to many or most of your potential peers.
>
>
> One thing maybe worth noting is that is that you can still only choose
> your policy from options that people write code for -- if it wasn't
> something you could get by running knots or compiling a rejected PR
> yourself, it won't magically become more possible now. Presumably it
> would mean that once a PR is written, it might get better review (rather
> than being dismissed as not suitable for everyone), and there would be
> less maintenance burden than if it had to be manually rebased every
> release, though (or at least the maintenance burden would be shared
> across everyone working on the codebase).
>
>
> The second thing is that whatever your relay policy is, you still
> need a path all the way to miners through nodes that will accept your
> transaction at every step. If you're making your mempool more restrictive
> (eg -permitbaremultisig=0, -datacarrier=0), that's easy for you (though
> you're making life more difficult for people who do create those sorts
> of txs); but if you want a more permissive policy (package relay,
> version-3-rbf, full-rbf), you might need to do some work.
>
> The cutoff for that is probably something like "do 30% of listening
> nodes have a compatible policy"? If they do, then you'll have about a
> 95% chance of having at least one of your outbound peers accept your tx,
> just by random chance. If erlay allows increasing your outbound count to
> 12 connections instead of 8; that might reduce down to needing just 20%
> of listening nodes (~93%).
>
> But for cases where less than 30% (20%) of network supports your preferred
> policy, you probably need to do something cleverer.
>
> One approach is to set a service bit and preferentially peer with other
> nodes that advertise that service bit; knots does the first half of this
> for fullrbf, and both halves have been proposed for core in #25600.
> Preferential peering was previously done for the segwit deployment,
> though in that case it was necessary not just for tx propogation but
> also for ensuring block propogation, making it effectively a consensus
> critical issue.
>
> Another approach is having a separate relay network -- eg, lightning nodes
> already have a gossip network, and might want to help their own ecosystem
> by ensuring unilateral channel closes and justice transactions are quickly
> relayed. Using their own gossip network to relay the transaction around,
> and each lightning node adding it to their local bitcoind's mempool and
> allowing it to propogate (or not) from there as normal, would also be a
> way of allowing transactions to propogate well. It does mean that miners
> would either need to also participate in lightning gossip directly, or
> that miners would need to connect to *many* peers to be confident of
> seeing those transactions (eg, if only 2% of the network would see a
> tx, you'd need to make 228 connections to have a 99% chance of seeing
> the tx). You can't currently do something like this, because all the
> relay policies are also applied when adding txs to the mempool via RPC,
> and there's no convenient way to remove txs from the mempool.
>
> A case where something like that might occur is in preventing L2
> transactions from pinning attacks -- so you might have a high-fee,
> low-feerate transaction that's been widely propogated, sitting in the
> bottom of people's mempools, and you want to replace it with a smaller,
> higher-feerate transaction, but don't want to pay a higher absolute fee,
> and are thus blocked by BIP 125 rule 3. Perhaps 98% of the network is
> unwilling to deviate from BIP 125 rule 3 for you; because that would
> make it easy for random griefers to spam their mempool with large txs
> then delete them while only paying a small fee; but your L2 peers may be
> able to decode your replacement transaction and be sure that you aren't
> going to spam them, and thus will happily relay it.
>
> From a technical point-of-view, that's largely fine; the downside is it
> increases the centralisation pressure on mining: whether that's by having
> to connect to substantially more nodes, or having to parse through more
> spam, you can't just run your mining operation off a standard install
> of bitcoin core anymore, but need to actively opt-in to find all the
> weird unusual ways people are sending transactions around in order to
> actually collect as much in fees as your competitors are.
>
> That's probably moderately bad for privacy as well -- if lightning or
> coinjoins need special relay rules that most nodes haven't opted into,
> it's potentially easy to use that to find the bitcoin nodes on the
> network that are participating in those protocols, and from there to
> either identify the operator, or run a DoS attack to make it hard for you
> to keep doing what you want. Obviously if you're setting a service bit to
> get better routing, you've given up that privacy already. Likewise if the
> government or random vandals are opposed to bitcoin mining, and miners
> have to have special configuration on their nodes that distinguish them
> from regular users, then perhaps that makes it easier to find or shut
> down their operations.
>
> There are a few efficiencies to be gained from similar mempool policies as
> well: more reliable compact block reconstruction (if you're not missing
> any transactions, you avoid a round-trip) and presumably more efficient
> set reconstruction with erlay. You'll also waste less bandwidth sending
> transactions that the other node is only going to reject. Both those
> depend on how many transactions are going to rely on unusual mempool
> policies in the first place though.
>
> ariard wrote:
>
> I know I've advocated in the past to turn RBF support by default in
> the past. Though after gathering a lot of feedbacks, this approach
> of offering the policy flexiblity to the interested users only and
> favoring a full-rbf gradual deployment sounds better to me.
>
> - https://github.com/bitcoin/bitcoin/pull/25353#issuecomment-1157137026
>
> I guess all the above leads me to think that gradual deployments of
> mempool policies are likely the worse approach: even when they're not
> hurting anyone, it makes them hard to use during the gradual phase,
> and getting around that comes with worrying compromises on privacy and
> centralisation; and when they are problematic for some, the indeterminate
> nature of a gradual deployment means it's hard to plan for when that
> risk is going to eventuate.
>
>
> Theoretically, one way to recover the good parts of core deciding on
> what's good for the network might be for people outside of core to
> recommend a mempool configuration; then core can just have an option
> to make that easy, similar to "-std=c++17" for a C++ compiler, and much
> the same as knots' "-corepolicy" option.
>
> Presuming anyone actually wants to take on that job, and listen to the
> concerns of zeroconf businesses, lightning and coinjoin devs, miners, etc;
> and can come up with something that keeps most of them happy, and that
> 70% or 90% of the network ends up just following those recommendations
> because it's easy, it works, and it's recommended by all the apps they
> want to use, then that could work great:
>
> * miners don't need to do anything special, so there's no new
> mining centralisation pressure
> * miners and users don't reveal what they're doing with bitcoin by the way
> they configure their nodes, so there's no privacy problems
> * devs can be fairly confident in how they have to design their apps
> in order to get their transactions to most hashpower
> * devs don't have to add new p2p layers to make it happen
> * at least there's someone to talk to when you're trying to figure out
> how to make some new project possible when it's inhibited by current
> relay policies and you don't have to try to convince everyone to
> upgrade on your own
> * core devs just provide options, and don't have to worry about being
> seen as gatekeepers
>
> The "downside" in that scenario is that users/dev aren't making much
> actual use of all the choices core is offering by making different
> options available; but the upside is that that choice is at least readily
> available should whoever is coming up with these policy become out of
> step with what people actually want.
>
> One thing that might make an approach like that difficult is that core
> has historically been happy to remove options that don't seem useful
> anymore: eg the ability to turn of BIP 125 support (#16171), and priority
> transactions (#9602). Perhaps that's fine if you're trying to actively
> craft a single mempool/relay policy that's good enough for almost everyone
> (after all, it makes the code simpler and more efficient, and reduces
> the number of footguns); all you're doing is leaving a minority of people
> who want weird things to run a fork, and that's going to happen anyway.
>
> But if people are following policy developed outside of core, core
> might well disagree with them and decide "no that's a stupid policy,
> no one should do that" and remove some feature that others thing should
> continue to be normal. Beyond the examples above, there's already talk of
> removing the ability to disable fullrbf support in #26305, for instance.
> If that happens, then the people maintaining the policy will instead
> end up maintaining an entire fork of bitcoin core, and all we've done
> is transition to people running software from a different repo, and a
> different set of maintainers.
>
> If we're really going to a world where core's eager to add new options,
> and reluctant to remove them, at least if anyone at all finds them
> interesting, that's presumably a non-issue, though.
>
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221027/e73c3002/attachment-0001.html>;

📅 Original date posted:2022-10-27 📝 Original message:During ...

2023-06-08T01:15:54+02:00

In reply to nevent1q…mfmy
_________________________

📅 Original date posted:2022-10-27
📝 Original message: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 <gsanders87 at gmail.com> 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 at 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221027/bd6fd919/attachment-0001.html>;

📅 Original date posted:2022-10-27 📝 Original message:> ...

2023-06-08T01:15:53+02:00

In reply to nevent1q…999g
_________________________

📅 Original date posted:2022-10-27
📝 Original message:> 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 at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221027/2af6e755/attachment.html>;

📅 Original date posted:2022-10-18 📝 Original message:> ...

2023-06-08T01:15:30+02:00

In reply to nevent1q…cefw
_________________________

📅 Original date posted:2022-10-18
📝 Original message:> 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 at 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 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 outputs, does this open up a
> MEV we are worried about? Wallets should toss all the value directly to
> fees, and add their own additional fees on top, otherwise miners have
> incentive to make the smallest utxo burn transaction to claim those funds.
> They just confirmed your parent transaction anyways, so do we care?
> 2.
>
> SIGHASH_GROUP like constructs would allow uncommitted ephemeral
> anchors to be added at spend time, depending on spending requirements.
> SIGHASH_SINGLE already allows this.
>
>
>
>
> Hopefully this gives people something to consider as we move forward in
> thinking about mempool design within the constraints we have today.
>
>
> Greg
>
> 0: With V3 transactions where you have "veto power" over all the inputs in
> that transaction. Therefore something like ANYONECANPAY is still broken. We
> need a more complex solution, which I’m punting for the sake of progress.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221018/37eafd3d/attachment-0001.html>;

📅 Original date posted:2022-10-19 📝 Original ...

2023-06-08T01:14:41+02:00

In reply to nevent1q…ytud
_________________________

📅 Original date posted:2022-10-19
📝 Original message: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 at 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 <jeremy.l.rubin at gmail.com>
> 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 at 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 of thing is clunky, and
>>> requires a certain level of scale to be able to do, we certainly wouldn't
>>> have had the manpower for that when we were starting out. This why I'm
>>> cautious about introducing more such clunkiness vectors as they are
>>> centralizing factors.
>>>
>>> I'm well aware of the reason for this policy being suggested and the
>>> potential pinning attack vector for LN and other smart contracts, but I
>>> think these two risks/costs need to be weighed against eachother first and
>>> thoroughly discussed because the costs are non-trivial on both sides.
>>>
>>> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
>>> After interacting with users during high-fee periods I've come to not
>>> appreciate RBF as a solution to that issue. Most users (80% or so) simply
>>> don't have access to that functionality, because their wallet doesn't
>>> support it, or they use a custodial (exchange) wallet etc. Of those that
>>> have the feature - only the power users understand how RBF works, and
>>> explaining how to do RBF to a non-power-user is just too complex, for the
>>> same reason why it's complex for wallets to make sensible non-power-user UI
>>> around it. Current equilibrium is that mostly only power users have access
>>> to RBF and they know how to handle it, so things are somewhat working. But
>>> rolling this out to the broad market is something else and would likely
>>> cause more confusion.
>>> CPFP is somewhat more viable but also not perfect as it would require
>>> lots of edge case code to handle abuse vectors: What if users abuse a
>>> generous CPFP policy to unstuck past transactions or consolidate large
>>> wallets. Best is for CPFP to be done on the wallet side, not the merchant
>>> side, but there too are the same UX issues as with RBF.
>>> In the end a risk-based approach to decide on which payments are
>>> non-trivial to reverse is the easiest, taking account user experience and
>>> such. Remember that in the fiat world card payments have up to 5%
>>> chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
>>> 1 in a million" accepted transactions successfully reversed. These days we
>>> have very few support issues related to bitcoin payments. The few that do
>>> come in are due to accidental RBF users venting frustration about waiting
>>> for their tx to confirm.
>>> "In theory, theory and practice are the same. In practice, they are not"
>>>
>>> All the best,
>>> Sergej Kotliar
>>> CEO Bitrefill.com
>>>
>>>
>>> --
>>>
>>> Sergej Kotliar
>>>
>>> CEO
>>>
>>>
>>> Twitter: @ziggamon <https://twitter.com/ziggamon>;
>>>
>>>
>>> www.bitrefill.com
>>>
>>> Twitter <https://www.twitter.com/bitrefill>; | Blog
>>> <https://www.bitrefill.com/blog/>; | Angellist
>>> <https://angel.co/bitrefill>;
>>>
>>>
>>> --
>>>
>>> Sergej Kotliar
>>>
>>> CEO
>>>
>>>
>>> Twitter: @ziggamon <https://twitter.com/ziggamon>;
>>>
>>>
>>> www.bitrefill.com
>>>
>>> Twitter <https://www.twitter.com/bitrefill>; | Blog
>>> <https://www.bitrefill.com/blog/>; | Angellist
>>> <https://angel.co/bitrefill>;
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>
> --
>
> Sergej Kotliar
>
> CEO
>
>
> Twitter: @ziggamon <https://twitter.com/ziggamon>;
>
>
> www.bitrefill.com
>
> Twitter <https://www.twitter.com/bitrefill>; | Blog
> <https://www.bitrefill.com/blog/>; | Angellist <https://angel.co/bitrefill>;
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221019/f0fed178/attachment-0001.html>;

📅 Original date posted:2022-10-19 📝 Original ...

2023-06-08T01:14:39+02:00

In reply to nevent1q…fnhf
_________________________

📅 Original date posted:2022-10-19
📝 Original message: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 at 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 at 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 of thing is clunky, and
>> requires a certain level of scale to be able to do, we certainly wouldn't
>> have had the manpower for that when we were starting out. This why I'm
>> cautious about introducing more such clunkiness vectors as they are
>> centralizing factors.
>>
>> I'm well aware of the reason for this policy being suggested and the
>> potential pinning attack vector for LN and other smart contracts, but I
>> think these two risks/costs need to be weighed against eachother first and
>> thoroughly discussed because the costs are non-trivial on both sides.
>>
>> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
>> After interacting with users during high-fee periods I've come to not
>> appreciate RBF as a solution to that issue. Most users (80% or so) simply
>> don't have access to that functionality, because their wallet doesn't
>> support it, or they use a custodial (exchange) wallet etc. Of those that
>> have the feature - only the power users understand how RBF works, and
>> explaining how to do RBF to a non-power-user is just too complex, for the
>> same reason why it's complex for wallets to make sensible non-power-user UI
>> around it. Current equilibrium is that mostly only power users have access
>> to RBF and they know how to handle it, so things are somewhat working. But
>> rolling this out to the broad market is something else and would likely
>> cause more confusion.
>> CPFP is somewhat more viable but also not perfect as it would require
>> lots of edge case code to handle abuse vectors: What if users abuse a
>> generous CPFP policy to unstuck past transactions or consolidate large
>> wallets. Best is for CPFP to be done on the wallet side, not the merchant
>> side, but there too are the same UX issues as with RBF.
>> In the end a risk-based approach to decide on which payments are
>> non-trivial to reverse is the easiest, taking account user experience and
>> such. Remember that in the fiat world card payments have up to 5%
>> chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
>> 1 in a million" accepted transactions successfully reversed. These days we
>> have very few support issues related to bitcoin payments. The few that do
>> come in are due to accidental RBF users venting frustration about waiting
>> for their tx to confirm.
>> "In theory, theory and practice are the same. In practice, they are not"
>>
>> All the best,
>> Sergej Kotliar
>> CEO Bitrefill.com
>>
>>
>> --
>>
>> Sergej Kotliar
>>
>> CEO
>>
>>
>> Twitter: @ziggamon <https://twitter.com/ziggamon>;
>>
>>
>> www.bitrefill.com
>>
>> Twitter <https://www.twitter.com/bitrefill>; | Blog
>> <https://www.bitrefill.com/blog/>; | Angellist
>> <https://angel.co/bitrefill>;
>>
>>
>> --
>>
>> Sergej Kotliar
>>
>> CEO
>>
>>
>> Twitter: @ziggamon <https://twitter.com/ziggamon>;
>>
>>
>> www.bitrefill.com
>>
>> Twitter <https://www.twitter.com/bitrefill>; | Blog
>> <https://www.bitrefill.com/blog/>; | Angellist
>> <https://angel.co/bitrefill>;
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221019/b5acb142/attachment-0001.html>;

📅 Original date posted:2022-10-17 📝 Original message:AJ, ...

2023-06-08T01:14:21+02:00

In reply to nevent1q…udd6
_________________________

📅 Original date posted:2022-10-17
📝 Original message: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 at 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 +0000, 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) is the goal people are actually working towards.
>
> [7] https://github.com/bitcoin/bitcoin/pull/26305
>
> But if (3) *is* what we're really trying to do, I think it's a bit
> disingenuous to assume that that effort will fail, and tell people that
> nothing's going to change on mainnet in the near future [8] [9] [10]
> [11]. If pools are starting to allow replacements of txs that didn't
> signal according to BIP 125 and mine blocks including those replacements,
> then it's true that zero-conf apps are in much more immediate danger
> than they were a month ago, and as far as I can see, we shouldn't be
> pretending otherwise.
>
> [8] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1274953204
> [9] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1276682043
> [10]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020981.html
> [11]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021006.html
>
> Personally, I prefer an approach like (2) -- commit to doing something
> first, give people time to prepare for it, and then do it, and outside
> of Knots, I don't think there's been any clear commitment to deprecating
> zeroconf txs up until now. But what we're currently doing is suboptimal
> for that in two ways:
>
> - there's no real commitment that the change will actually happen
> - even if it does, there's no indication when that will be
> - it's not easy to test your apps against the new world order, because
> it's not well supported on either testnet or signet, being disabled
> by default on both those networks
>
> Dario suggested an approach [12] that seems like it would resolve all
> these issues:
>
> ] This could be one such proposal:
> ] 1. We activate [..] full-RBF on testnet now.
> ] 2. We commit now (in the code) to a block height in the future at
> ] which [..] full-RBF will activate on mainnet.
>
> (I've delted the words "opt-in" and "opt-out" from the quote above,
> because they didn't make sense to me)
>
> [12]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021007.html
>
> I've made up a patch along these lines [13]; it's easy to use a timestamp
> rather than a block height, so I've arbitrarily picked 1st May (slightly
> over 6 months away) as the changeover time. If people are willing to
> give zeroconf businesses some time to adapt, including something along
> those lines in 24.0 seems a better approach to me:
>
> * it gives a clear deadline for businesses to adapt, so that they don't
> defer it and suddenly complain "oh no, we didn't think you were
> serious, please give us more time" later
>
> * it gives plenty(?) of time to update your code and test it, as well
> as teach customers and customer support about the new behaviour
>
> * when the deadline hits, presumably plenty of nodes and miners will
> immediately start supporting the new behaviour on mainnet, so that
> protocols can quickly start relying on that method of tx pinning no
> longer being applicable
>
> * nodes on signet and testnet will quickly adopt the new behaviour,
> well before it's available on mainnet, making testing easier
>
> [13] https://github.com/bitcoin/bitcoin/pull/26323
>
> To me, this seems like a good way of achieving what I said previously:
>
> > If we're trying to socialise the idea that zeroconf deprecation is
> > happening and that your business now has a real deadline for migrating
> > away from accepting unconfirmed txs if the risk of being defrauded
> > concerns you, then enabling experimentation on test nets and not touching
> > mainnet until a later release seems fairly fine to me -- similar to
> > activating soft forks on test nets prior to activating it on mainnet.
>
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221017/b9415d4b/attachment.html>;

📅 Original date posted:2022-10-07 📝 Original message:David, ...

2023-06-08T01:14:17+02:00

In reply to nevent1q…eq7x
_________________________

📅 Original date posted:2022-10-07
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221007/631f5053/attachment-0001.html>;

📅 Original date posted:2022-09-29 📝 Original message:> ...

2023-06-08T01:13:48+02:00

In reply to nevent1q…5ggm
_________________________

📅 Original date posted:2022-09-29
📝 Original message:> Right, good catch, this does require new logic to handle this case.
As Gloria points out, this should be doable, and is definitely worth
adding (those CSV 1 on every other output are really hacky, glad to
find a way to get rid of them).

For the record, it turns out ephemeral anchors + v3 solves this already, as
the anchor must be spent, and the parent tx may only have one child.
Somehow I missed this implication for a few months. It's great news if we
can directly source fees from any output claimable, including HTLCs!

On Thu, Sep 29, 2022 at 5:15 AM Bastien TEINTURIER <bastien at acinq.fr> wrote:

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

📅 Original date posted:2022-09-26 📝 Original ...

2023-06-08T01:13:46+02:00

In reply to nevent1q…904d
_________________________

📅 Original date posted:2022-09-26
📝 Original message:Bastien,

> This may be already covered by the current package RBF logic, in that
scenario we are simply replacing [ParentTx, ChildTx1] with
[ParentTx, ChildTx2] that pays more fees, right?

For clarification, package RBF is ParentTx*s*(plural), and
ChildTx(singular), so it might be a bit more complicated than we're
thinking, and currently the V3 proposal would first de-duplicate the
ParentTx based on what is in the mempool, then look at the "rest" of the
transactions as a package, then individually. Not the same, not sure how
different. I'll defer to experts.

Best,
Greg

On Mon, Sep 26, 2022 at 11:48 AM Bastien TEINTURIER via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Thanks Gloria for this great post.
>
> This is very valuable work for L2 contracts, and will greatly improve
> their security model.
>
> > "Only 1 anchor output? What if I need to bump counterparty's commitment
> tx in mempool?"
> > You won't need to fee-bump a counterparty's commitment tx using CPFP.
> > You would just package RBF it by attaching a high-feerate child to
> > your commitment tx.
>
> Note that we can also very easily make that single anchor spendable by
> both participants (or even anyone), so if you see your counterparty's
> commitment in your mempool, you can bump it without publishing your
> own commitment, which is quite desirable (your own commitment tx has
> CSV delays on your outputs, whereas your counterparty's commitment tx
> doesn't).
>
> > "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN
> transactions based on nVersion?"
>
> I agree with you, this isn't worse than today, unilateral closes will
> probably always be identifiable on-chain.
>
> > Would kind of be nice if package RBF would detect a "sibling output
> spend"
> > conflict, and knock it out of the mempool via the other replacement
> rules?
> > Getting rid of the requirement to 1 block csv lock every output would be
> > quite nice from a smart contracting composability point of view.
>
> +1, that would be very neat!
>
> This may be already covered by the current package RBF logic, in that
> scenario we are simply replacing [ParentTx, ChildTx1] with
> [ParentTx, ChildTx2] that pays more fees, right?
>
> > 1) I do think that we should seriously consider allowing OP_TRUE to
> become
> > a standard script type as part of this policy update. If pinning is
> solved,
> > then there's no reason to require all those extra bytes for "binding" an
> > anchor to a specific wallet/user. We can save quite a few bytes by having
> > the input be empty of witness data.
> > 2) If we allow for a single dust-value(0 on up) output which is
> immediately
> > spent by the package, anchors become even easier to to design. No value
> has
> > to be "sapped" from contract participants to make an anchor output.
> There's
> > more complications for this, such as making sure the parent transaction
> is
> > dropped if the child spend is dropped, but maybe it's worth the squeeze.
>
> I also think both of these could be quite useful. This would probably
> always
> be used in combination with a parent transaction that pays 0 fees, so the
> 0-value output would always be spent in the same block.
>
> But this means we could end up with 0-value outputs in the utxo set, if for
> some reason the parent tx is CPFP-ed via another output than the 0-value
> one,
> which would be a utxo set bloat issue. But I'd argue that we're probably
> already creating utxo set bloat with the 330 sat anchor outputs (especially
> since we use two of them, but only one is usually spent), so it would
> probably be *better* than what we're doing today.
>
> Thanks,
> Bastien
>
> Le lun. 26 sept. 2022 à 03:22, Antoine Riard via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> a écrit :
>
>> Hi Gloria,
>>
>> Thanks for the progress on package RBF, few early questions.
>>
>> > 2. Any descendant of an unconfirmed V3 transaction must also be V3.
>>
>> > 3. An unconfirmed V3 transaction cannot have more than 1 descendant.
>>
>> If you're a miner and you receive a non-V3, second descendant of an
>> unconfirmed V3 transaction, if the offered fee is in the top mempool
>> backlog, I think you would have an interest to accept such a transaction.
>>
>> So I'm not sure if those two rules are compatible with miners
>> incentives...
>>
>> > 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be
>> > larger than 1000 virtual bytes.
>>
>> If I understand correctly the 1000 vb upper bound rational, it would be
>> to constraint the pinning counterparty to attach a high fee to a child due
>> to the limited size, if they would like this transaction to be stuck in the
>> network mempools. By doing so this child has high odds to confirm.
>>
>> I still wonder if this compatible with miner incentives in period of
>> empty mempools, in the sense that if you've already a V3 transaction of
>> size 100Kvb offering 2 sat/vb, it's more interesting than a V3 replacement
>> candidate of size 1000 vb offering 10 sat/vb. It could be argued the former
>> should be conserved.
>>
>> (That said, the hard thing with any replacement strategy we might evict a
>> parent transaction *now* to which is attached a high-feerate child *latter*
>> making for a utxo considered the best ancestor set. Maybe in the long-term
>> miners should keep every transaction ever accepted...)
>>
>> > (Lower bound) the smaller this limit, the fewer UTXOs a child may use
>> > to fund this fee-bump. For example, only allowing the V3 child to have
>> > 2 inputs would require L2 protocols to manage a wallet with high-value
>> > UTXOs and make batched fee-bumping impossible. However, as the
>> > fee-bumping child only needs to fund fees (as opposed to payments),
>> > just a few UTXOs should suffice.
>>
>> Reminder for L2 devs, batched fee-bumping of time-sensitive confirmations
>> of commitment transactions is unsafe, as the counterparty could enter in a
>> "cat-and-mouse" game to replace one of the batch element at each block to
>> delay confirmation of the remaining elements in the batch, I think.
>>
>> On the other hand, I wonder if we wouldn't want a higher bound. LN
>> wallets are likely to have one big UTXO in their fee-bumping reserve pool,
>> as the cost of acquiring UTXO is non-null and in the optimistic case, you
>> don't need to do unilateral closure. Let's say you close dozens of channels
>> at the same time, a UTXO pool management strategy might be to fan-out the
>> first spends UTXOs in N fan-out outputs ready to feed the remaining
>> in-flight channels.
>>
>> > 1. The rule around unconfirmed inputs was
>> > originally "A package may include new unconfirmed inputs, but the
>> > ancestor feerate of the child must be at least as high as the ancestor
>> > feerates of every transaction being replaced."
>>
>> Note, I think we would like this new RBF rule to also apply to single
>> transaction package, e.g second-stage HTLC transactions, where a
>> counterparty pins a HTLC-preimage by abusing rule 3. In that case, the
>> honest LN node should be able to broadcast a "at least as high ancestor
>> feerate" HTLC-timeout transaction. With `option_anchor_outputs" there is no
>> unconfirmed ancestor to replace, as the commitment transaction, whatever
>> the party it is originating from, should already be confirmed.
>>
>> > "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN
>> transactions based on nVersion?"
>>
>> As of today, I think yes you can already fingerprint LN transactions on
>> the spec-defined amount value of the anchor outputs, 330 sats. There is
>> always one of them on post-anchor commitment transactions. And sadly I
>> would say we'll always have tricky fingerprints leaking from unilateral LN
>> closures such as HTLC/PTLC timelocks...
>>
>> > "Can a V2 transaction replace a V3 transaction and vice versa?"
>>
>> IIUC, a V3 package could replace a V2 package, with the benefit of the
>> new package RBF rules applied. I think this would be a significant
>> advantage for LN, as for the current ~85k of opened channels, the old V2
>> states shouldn't be pinning vectors. Currently, commitment transactions
>> signal replaceability.
>>
>> Le ven. 23 sept. 2022 à 11:26, Gloria Zhao via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> a écrit :
>>
>>> Hi everyone,
>>>
>>> I'm writing to propose a very simple set of mempool/transaction relay
>>> policies intended to aid L2/contract protocols. I realized that
>>> the previously proposed Package Mempool Accept package RBF [1]
>>> had a few remaining problems after digging into the RBF logic more [2].
>>> This additional set of policies solves them without requiring a huge RBF
>>> overhaul.
>>>
>>> I've written an implementation (and docs) for Bitcoin Core:
>>> https://github.com/bitcoin/bitcoin/pull/25038
>>>
>>> (You may notice that this proposal incorporates feedback on the PR -
>>> thanks Suhas Daftuar, Gregory Sanders, Bastien Teinturier, Anthony Towns,
>>> and others.)
>>>
>>> If you are interested in using package RBF/relay to bump presigned
>>> transactions, I think you may be interested in reviewing this proposal.
>>> This should solve Rule 3 pinning and perhaps allow us
>>> to get rid of CPFP carve-out (yay!). I'm keen to hear if people find
>>> the 1-anchor-output, 1000vB child limit too restrictive. Also, if you
>>> find a
>>> pinning attack or something that makes it unusable for you, I would
>>> really really like to know.
>>>
>>> Note that transactions with nVersion=3 ("V3 transactions") are
>>> currently non-standard in Bitcoin Core. That means **anything that was
>>> standard before this policy change would still be standard
>>> afterwards.** If you don't want your transactions to be subject to
>>> these rules, just continue whatever you're doing and don't use
>>> nVersion=3. AFAICT this shouldn't break anything, but let me know if
>>> this would be disruptive for you?
>>>
>>> **New Policies:**
>>>
>>> This includes:
>>> - a set of additional policy rules applying to V3 transactions
>>> - modifications to package RBF rules
>>>
>>> **V3 transactions:**
>>>
>>> Existing standardness rules apply to V3 (e.g. min/max tx weight,
>>> standard output types, cleanstack, etc.). The following additional
>>> rules apply to V3:
>>>
>>> 1. A V3 transaction can be replaced, even if it does not signal BIP125
>>> replaceability. (It must also meet the other RBF rules around fees,
>>> etc. for replacement to happen).
>>>
>>> 2. Any descendant of an unconfirmed V3 transaction must also be V3.
>>>
>>> *Rationale*: Combined with Rule 1, this gives us the property of
>>> "inherited" replaceability signaling when descendants of unconfirmed
>>> transactions are created. Additionally, checking whether a transaction
>>> signals replaceability this way does not require mempool traversal,
>>> and does not change based on what transactions are mined. It also
>>> makes subsequent rules about descendant limits much easier to check.
>>>
>>> *Note*: The descendant of a *confirmed* V3 transaction does not need to
>>> be V3.
>>>
>>> 3. An unconfirmed V3 transaction cannot have more than 1 descendant.
>>>
>>> *Rationale*: (Upper bound) the larger the descendant limit, the more
>>> transactions may need to be replaced. This is a problematic pinning
>>> attack, i.e., a malicious counterparty prevents the transaction from
>>> being replaced by adding many descendant transactions that aren't
>>> fee-bumping.
>>>
>>> (Lower bound) at least 1 descendant is required to allow CPFP of the
>>> presigned transaction. The contract protocol can create presigned
>>> transactions paying 0 fees and 1 output for attaching a CPFP at
>>> broadcast time ("anchor output"). Without package RBF, multiple anchor
>>> outputs would be required to allow each counterparty to fee-bump any
>>> presigned transaction. With package RBF, since the presigned
>>> transactions can replace each other, 1 anchor output is sufficient.
>>>
>>> 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be
>>> larger than 1000 virtual bytes.
>>>
>>> *Rationale*: (Upper bound) the larger the descendant size limit, the
>>> more vbytes may need to be replaced. With default limits, if the child
>>> is e.g. 100,000vB, that might be an additional 100,000sats (at
>>> 1sat/vbyte) or more, depending on the feerate.
>>>
>>> (Lower bound) the smaller this limit, the fewer UTXOs a child may use
>>> to fund this fee-bump. For example, only allowing the V3 child to have
>>> 2 inputs would require L2 protocols to manage a wallet with high-value
>>> UTXOs and make batched fee-bumping impossible. However, as the
>>> fee-bumping child only needs to fund fees (as opposed to payments),
>>> just a few UTXOs should suffice.
>>>
>>> With a limit of 1000 virtual bytes, depending on the output types, the
>>> child can have 6-15 UTXOs, which should be enough to fund a fee-bump
>>> without requiring a carefully-managed UTXO pool. With 1000 virtual
>>> bytes as the descendant limit, the cost to replace a V3 transaction
>>> has much lower variance.
>>>
>>> *Rationale*: This makes the rule very easily "tacked on" to existing
>>> logic for policy and wallets. A transaction may be up to 100KvB on its
>>> own (`MAX_STANDARD_TX_WEIGHT`) and 101KvB with descendants
>>> (`DEFAULT_DESCENDANT_SIZE_LIMIT_KVB`). If an existing V3 transaction
>>> in the mempool is 100KvB, its descendant can only be 1000vB, even if
>>> the policy is 10KvB.
>>>
>>> **Package RBF modifications:**
>>>
>>> 1. The rule around unconfirmed inputs was
>>> originally "A package may include new unconfirmed inputs, but the
>>> ancestor feerate of the child must be at least as high as the ancestor
>>> feerates of every transaction being replaced."
>>>
>>> The package may still include new unconfirmed inputs. However,
>>> the new rule is modified to be "The minimum between package feerate
>>> and ancestor feerate of the child is not lower than the individual
>>> feerates of all directly conflicting transactions and the ancestor
>>> feerates of all original transactions."
>>>
>>> *Rationale*: We are attempting to ensure that the replacement
>>> transactions are not less incentive-compatible to mine. However, a
>>> package/transaction's ancestor feerate is not perfectly representative
>>> of its incentive compatibility; it may overestimate (some subset of
>>> the ancestors could be included by itself if it has other high-feerate
>>> descendants or are themselves higher feerate than this
>>> package/transaction). Instead, we use the minimum between the package
>>> feerate and ancestor feerate of the child as a more conservative value
>>> than what was proposed originally.
>>>
>>> 2. A new rule is added, requiring that all package transactions with
>>> mempool conflicts to be V3. This also means the "sponsoring"
>>> child transaction must be V3.
>>>
>>> *Note*: Combined with the V3 rules, this means the package must be
>>> a child-with-parents package. Since package validation is only
>>> attempted if the transactions do not pay sufficient fees to be
>>> accepted on their own, this effectively means that only V3
>>> transactions can pay to replace their ancestors' conflicts, and only
>>> V3 transactions' replacements may be paid for by a descendant.
>>>
>>> *Rationale*: The fee-related rules are economically rational for
>>> ancestor packages, but not necessarily other types of packages.
>>> A child-with-parents package is a type of ancestor package. It
>>> may be fine to allow any ancestor package, but it's more difficult
>>> to account for all of the possibilities. For example, it gets much
>>> harder to see that we're applying the descendant limits correctly if
>>> the package has a gnarly, many-generation, non-tree shape. I'm also
>>> not sure if this policy is 100% incentive-compatible if the sponsor
>>> is not a direct descendant of the sponsee.
>>>
>>> Please see doc/policy/version3_transactions.md and
>>> doc/policy/packages.md in the PR for the full set of rules.
>>>
>>> **Intended usage for LN:**
>>>
>>> Commitment transactions should be V3 and have 1 anchor output. They
>>> can be signed with 0 fees (or 1sat/vbyte) once package relay is deployed
>>> on a significant portion of the network. If the commitment tx must
>>> be broadcast, determine the desired feerate at broadcast time and
>>> spend the anchor output in a high feerate transaction. I'm going to
>>> call the broadcasted commitment tx "the parent" and the attached
>>> fee-bumping tx "the child."
>>>
>>> - This child must be V3.
>>> - This child must be at most 1000vB. Note this restricts the
>>> number of inputs you can use to fund the fee bump. Depending
>>> on the output types, this is around 6-15.
>>> - One child may fund fees for multiple commitment tx ("batched
>>> fee-bumping").
>>> - To do a second fee-bump to add more fees, replace the
>>> *child* with a higher-feerate tx. Do not try to attach a grandchild.
>>>
>>> Otherwise, never try to spend from an unconfirmed V3 transaction. The
>>> descendant limits for V3 transactions are very restrictive.
>>>
>>> **Expected Questions:**
>>>
>>> "Does this fix Rule 3 Pinning?"
>>> Yes. The V3 descendant limit restricts both you and your counterparty.
>>> Assuming nodes adopted this policy, you may reasonably assume that you
>>> only need to replace the commitment transaction + up to 1000vB.
>>>
>>> "Only 1 anchor output? What if I need to bump counterparty's commitment
>>> tx in mempool?"
>>> You won't need to fee-bump a counterparty's commitment tx using CPFP.
>>> You would just package RBF it by attaching a high-feerate child to
>>> your commitment tx.
>>>
>>> "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN
>>> transactions based on nVersion?"
>>> Indeed it may be unrealistic to assume V3 transactions will be in
>>> widespread use outside of L2. IIUC, unilateral closes are already
>>> obvious LN transactions because of the HTLC inputs. For e.g.
>>> cooperative closes and opens, I think it makes sense to continue using
>>> V2. So, unless I'm missing something, this shouldn't make it worse.
>>>
>>> "So a V3 transaction that doesn't signal BIP125 replaceability is
>>> replaceable? Is that a backward compatibility issue?"
>>> Yes it's replaceable. It's not an issue AFAICT because,
>>> under previous policy, the V3 transaction wouldn't have been
>>> in the mempool in the first place.
>>>
>>> "Can a V2 transaction replace a V3 transaction and vice versa?"
>>> Yes, otherwise someone can use V3 transactions to censor V2
>>> transactions spending shared inputs. Note if the
>>> original V3 transaction has an unconfirmed V3 parent, this would
>>> violate the "inherited V3" rule and would be rejected.
>>>
>>> Thanks for reading! Feedback and review would be much appreciated.
>>>
>>> [1]:
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019464.html
>>> [2]:
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html
>>>
>>> Best,
>>> Gloria
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220926/7e18188a/attachment-0001.html>;

📅 Original date posted:2022-09-23 📝 Original message:Hello ...

2023-06-08T01:13:42+02:00

In reply to nevent1q…zcqq
_________________________

📅 Original date posted:2022-09-23
📝 Original message: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 at 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 or something that makes it unusable for you, I would
> really really like to know.
>
> Note that transactions with nVersion=3 ("V3 transactions") are
> currently non-standard in Bitcoin Core. That means **anything that was
> standard before this policy change would still be standard
> afterwards.** If you don't want your transactions to be subject to
> these rules, just continue whatever you're doing and don't use
> nVersion=3. AFAICT this shouldn't break anything, but let me know if
> this would be disruptive for you?
>
> **New Policies:**
>
> This includes:
> - a set of additional policy rules applying to V3 transactions
> - modifications to package RBF rules
>
> **V3 transactions:**
>
> Existing standardness rules apply to V3 (e.g. min/max tx weight,
> standard output types, cleanstack, etc.). The following additional
> rules apply to V3:
>
> 1. A V3 transaction can be replaced, even if it does not signal BIP125
> replaceability. (It must also meet the other RBF rules around fees,
> etc. for replacement to happen).
>
> 2. Any descendant of an unconfirmed V3 transaction must also be V3.
>
> *Rationale*: Combined with Rule 1, this gives us the property of
> "inherited" replaceability signaling when descendants of unconfirmed
> transactions are created. Additionally, checking whether a transaction
> signals replaceability this way does not require mempool traversal,
> and does not change based on what transactions are mined. It also
> makes subsequent rules about descendant limits much easier to check.
>
> *Note*: The descendant of a *confirmed* V3 transaction does not need to be
> V3.
>
> 3. An unconfirmed V3 transaction cannot have more than 1 descendant.
>
> *Rationale*: (Upper bound) the larger the descendant limit, the more
> transactions may need to be replaced. This is a problematic pinning
> attack, i.e., a malicious counterparty prevents the transaction from
> being replaced by adding many descendant transactions that aren't
> fee-bumping.
>
> (Lower bound) at least 1 descendant is required to allow CPFP of the
> presigned transaction. The contract protocol can create presigned
> transactions paying 0 fees and 1 output for attaching a CPFP at
> broadcast time ("anchor output"). Without package RBF, multiple anchor
> outputs would be required to allow each counterparty to fee-bump any
> presigned transaction. With package RBF, since the presigned
> transactions can replace each other, 1 anchor output is sufficient.
>
> 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be
> larger than 1000 virtual bytes.
>
> *Rationale*: (Upper bound) the larger the descendant size limit, the
> more vbytes may need to be replaced. With default limits, if the child
> is e.g. 100,000vB, that might be an additional 100,000sats (at
> 1sat/vbyte) or more, depending on the feerate.
>
> (Lower bound) the smaller this limit, the fewer UTXOs a child may use
> to fund this fee-bump. For example, only allowing the V3 child to have
> 2 inputs would require L2 protocols to manage a wallet with high-value
> UTXOs and make batched fee-bumping impossible. However, as the
> fee-bumping child only needs to fund fees (as opposed to payments),
> just a few UTXOs should suffice.
>
> With a limit of 1000 virtual bytes, depending on the output types, the
> child can have 6-15 UTXOs, which should be enough to fund a fee-bump
> without requiring a carefully-managed UTXO pool. With 1000 virtual
> bytes as the descendant limit, the cost to replace a V3 transaction
> has much lower variance.
>
> *Rationale*: This makes the rule very easily "tacked on" to existing
> logic for policy and wallets. A transaction may be up to 100KvB on its
> own (`MAX_STANDARD_TX_WEIGHT`) and 101KvB with descendants
> (`DEFAULT_DESCENDANT_SIZE_LIMIT_KVB`). If an existing V3 transaction
> in the mempool is 100KvB, its descendant can only be 1000vB, even if
> the policy is 10KvB.
>
> **Package RBF modifications:**
>
> 1. The rule around unconfirmed inputs was
> originally "A package may include new unconfirmed inputs, but the
> ancestor feerate of the child must be at least as high as the ancestor
> feerates of every transaction being replaced."
>
> The package may still include new unconfirmed inputs. However,
> the new rule is modified to be "The minimum between package feerate
> and ancestor feerate of the child is not lower than the individual
> feerates of all directly conflicting transactions and the ancestor
> feerates of all original transactions."
>
> *Rationale*: We are attempting to ensure that the replacement
> transactions are not less incentive-compatible to mine. However, a
> package/transaction's ancestor feerate is not perfectly representative
> of its incentive compatibility; it may overestimate (some subset of
> the ancestors could be included by itself if it has other high-feerate
> descendants or are themselves higher feerate than this
> package/transaction). Instead, we use the minimum between the package
> feerate and ancestor feerate of the child as a more conservative value
> than what was proposed originally.
>
> 2. A new rule is added, requiring that all package transactions with
> mempool conflicts to be V3. This also means the "sponsoring"
> child transaction must be V3.
>
> *Note*: Combined with the V3 rules, this means the package must be
> a child-with-parents package. Since package validation is only
> attempted if the transactions do not pay sufficient fees to be
> accepted on their own, this effectively means that only V3
> transactions can pay to replace their ancestors' conflicts, and only
> V3 transactions' replacements may be paid for by a descendant.
>
> *Rationale*: The fee-related rules are economically rational for
> ancestor packages, but not necessarily other types of packages.
> A child-with-parents package is a type of ancestor package. It
> may be fine to allow any ancestor package, but it's more difficult
> to account for all of the possibilities. For example, it gets much
> harder to see that we're applying the descendant limits correctly if
> the package has a gnarly, many-generation, non-tree shape. I'm also
> not sure if this policy is 100% incentive-compatible if the sponsor
> is not a direct descendant of the sponsee.
>
> Please see doc/policy/version3_transactions.md and
> doc/policy/packages.md in the PR for the full set of rules.
>
> **Intended usage for LN:**
>
> Commitment transactions should be V3 and have 1 anchor output. They
> can be signed with 0 fees (or 1sat/vbyte) once package relay is deployed
> on a significant portion of the network. If the commitment tx must
> be broadcast, determine the desired feerate at broadcast time and
> spend the anchor output in a high feerate transaction. I'm going to
> call the broadcasted commitment tx "the parent" and the attached
> fee-bumping tx "the child."
>
> - This child must be V3.
> - This child must be at most 1000vB. Note this restricts the
> number of inputs you can use to fund the fee bump. Depending
> on the output types, this is around 6-15.
> - One child may fund fees for multiple commitment tx ("batched
> fee-bumping").
> - To do a second fee-bump to add more fees, replace the
> *child* with a higher-feerate tx. Do not try to attach a grandchild.
>
> Otherwise, never try to spend from an unconfirmed V3 transaction. The
> descendant limits for V3 transactions are very restrictive.
>
> **Expected Questions:**
>
> "Does this fix Rule 3 Pinning?"
> Yes. The V3 descendant limit restricts both you and your counterparty.
> Assuming nodes adopted this policy, you may reasonably assume that you
> only need to replace the commitment transaction + up to 1000vB.
>
> "Only 1 anchor output? What if I need to bump counterparty's commitment tx
> in mempool?"
> You won't need to fee-bump a counterparty's commitment tx using CPFP.
> You would just package RBF it by attaching a high-feerate child to
> your commitment tx.
>
> "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN
> transactions based on nVersion?"
> Indeed it may be unrealistic to assume V3 transactions will be in
> widespread use outside of L2. IIUC, unilateral closes are already
> obvious LN transactions because of the HTLC inputs. For e.g.
> cooperative closes and opens, I think it makes sense to continue using
> V2. So, unless I'm missing something, this shouldn't make it worse.
>
> "So a V3 transaction that doesn't signal BIP125 replaceability is
> replaceable? Is that a backward compatibility issue?"
> Yes it's replaceable. It's not an issue AFAICT because,
> under previous policy, the V3 transaction wouldn't have been
> in the mempool in the first place.
>
> "Can a V2 transaction replace a V3 transaction and vice versa?"
> Yes, otherwise someone can use V3 transactions to censor V2
> transactions spending shared inputs. Note if the
> original V3 transaction has an unconfirmed V3 parent, this would
> violate the "inherited V3" rule and would be rejected.
>
> Thanks for reading! Feedback and review would be much appreciated.
>
> [1]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019464.html
> [2]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html
>
> Best,
> Gloria
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220923/43403b3a/attachment-0001.html>;

📅 Original date posted:2022-07-20 📝 Original message:Please ...

2023-06-08T01:11:58+02:00

In reply to nevent1q…ukr0
_________________________

📅 Original date posted:2022-07-20
📝 Original message: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 at 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 <https://www.ietf.org/rfc/rfc2440.txt>; 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 +0000, 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?
> >
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220720/917426c4/attachment.html>;

📅 Original date posted:2022-06-16 📝 Original message:> ...

2023-06-08T01:10:31+02:00

In reply to nevent1q…9dhv
_________________________

📅 Original date posted:2022-06-16
📝 Original message:> 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 <alicexbt at protonmail.com> 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 <https://proton.me/>; secure email.
>
> ------- Original Message -------
> On Thursday, June 16th, 2022 at 6:32 AM, Greg Sanders <
> gsanders87 at 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 at 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 <https://proton.me/>; secure email.
>>
>> ------- Original Message -------
>> On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Hi list,
>>
>> 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]. While it does not consist in a
>> direct loss of funds, if exploited well I think it's annoying enough to
>> inflict significant timevalue loss or fee-bumping waste
>> to the future providers or distributed swarm of users doing multi-party
>> funded transactions. Of course, it can be fixed one layer above by
>> introducing either fidelity bonds or a reliable centralized coordinator,
>> though at the price of an overhead per-participant ressources cost and loss
>> in system openness [1].
>>
>> For that reason, I believe it would be beneficial to the flourishing of
>> multi-party funded transactions to fix the Dos vector by seeing a subset of
>> the network running full-rbf and enabling propagation of honest multi-party
>> transactions to the interested miners, replacing potential non-signaling
>> double-spend from a malicious counterparty. Moving towards that direction,
>> I've submitted a small patch against Bitcoin Core enabling it to turn on
>> full-rbf as a policy, still under review [3]. The default setting stays
>> **false**, i.e keeping opt-in RBF as a default replacement policy. I've
>> started to run the patch on a public node at 146.190.224.15.
>>
>> If you're a node operator curious to play with full-rbf, feel free to
>> connect to this node or spawn up a toy, public node yourself. There is a
>> ##uafrbf libera chat if you would like information on the settings or
>> looking for full-rbf friends (though that step could be automated in the
>> future by setting up a dedicated network bit and reserving a few outbound
>> slots for them).
>>
>> If you're a mining operator looking to increase your income, you might be
>> interested to experiment with full-rbf as a policy. Indeed, in the future I
>> believe the multi-party transactions issuers who need full-rbf to secure
>> their funding flow should connect by default to full-rbf peers. One can
>> conjecture that their transactions are likely to be more compelling in
>> their feerate as their liquidity needs are higher than the simple
>> transaction. For today, I think we have really few standards and bitcoin
>> softwares relying on multi-party funded transactions [4].
>>
>> 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.
>>
>> Any mistakes or missing context is my own.
>>
>> Cheers,
>> Antoine
>>
>> [0] For more info about replace-by-fee, see
>> https://bitcoinops.org/en/topics/replace-by-fee/
>>
>> [1] For more details about the DoS vector, see
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>>
>> [2] E.g I think it does not affect the Lightning Pool service, as there
>> is a preliminary step where the participant funds are locked first in a
>> 2-of-2 with the coordinator before being committed in the multi-party batch
>> transaction.
>>
>> [3] https://github.com/bitcoin/bitcoin/pull/25353
>>
>> [4] E.g DLCs :
>> https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md
>> ; Lightning dual-funded channel :
>> https://github.com/lightning/bolts/pull/851
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220616/8af3abae/attachment-0001.html>;

📅 Original date posted:2022-06-15 📝 Original message:> ...

2023-06-08T01:10:29+02:00

In reply to nevent1q…5rg2
_________________________

📅 Original date posted:2022-06-15
📝 Original message:> 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 at 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 <https://proton.me/>; secure email.
>
> ------- Original Message -------
> On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi list,
>
> 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]. While it does not consist in a
> direct loss of funds, if exploited well I think it's annoying enough to
> inflict significant timevalue loss or fee-bumping waste
> to the future providers or distributed swarm of users doing multi-party
> funded transactions. Of course, it can be fixed one layer above by
> introducing either fidelity bonds or a reliable centralized coordinator,
> though at the price of an overhead per-participant ressources cost and loss
> in system openness [1].
>
> For that reason, I believe it would be beneficial to the flourishing of
> multi-party funded transactions to fix the Dos vector by seeing a subset of
> the network running full-rbf and enabling propagation of honest multi-party
> transactions to the interested miners, replacing potential non-signaling
> double-spend from a malicious counterparty. Moving towards that direction,
> I've submitted a small patch against Bitcoin Core enabling it to turn on
> full-rbf as a policy, still under review [3]. The default setting stays
> **false**, i.e keeping opt-in RBF as a default replacement policy. I've
> started to run the patch on a public node at 146.190.224.15.
>
> If you're a node operator curious to play with full-rbf, feel free to
> connect to this node or spawn up a toy, public node yourself. There is a
> ##uafrbf libera chat if you would like information on the settings or
> looking for full-rbf friends (though that step could be automated in the
> future by setting up a dedicated network bit and reserving a few outbound
> slots for them).
>
> If you're a mining operator looking to increase your income, you might be
> interested to experiment with full-rbf as a policy. Indeed, in the future I
> believe the multi-party transactions issuers who need full-rbf to secure
> their funding flow should connect by default to full-rbf peers. One can
> conjecture that their transactions are likely to be more compelling in
> their feerate as their liquidity needs are higher than the simple
> transaction. For today, I think we have really few standards and bitcoin
> softwares relying on multi-party funded transactions [4].
>
> 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.
>
> Any mistakes or missing context is my own.
>
> Cheers,
> Antoine
>
> [0] For more info about replace-by-fee, see
> https://bitcoinops.org/en/topics/replace-by-fee/
>
> [1] For more details about the DoS vector, see
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>
> [2] E.g I think it does not affect the Lightning Pool service, as there is
> a preliminary step where the participant funds are locked first in a 2-of-2
> with the coordinator before being committed in the multi-party batch
> transaction.
>
> [3] https://github.com/bitcoin/bitcoin/pull/25353
>
> [4] E.g DLCs :
> https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md
> ; Lightning dual-funded channel :
> https://github.com/lightning/bolts/pull/851
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220615/31d6050c/attachment-0001.html>;

📅 Original date posted:2022-05-17 📝 Original message:Hi ...

2023-06-08T01:09:42+02:00

In reply to nevent1q…5w72
_________________________

📅 Original date posted:2022-05-17
📝 Original message: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 at 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 market can change due to sudden
> spikes in traffic (e.g. huge 12sat/vB dump a few days ago [9]) or
> sustained, high volume of Bitcoin payments (e.g. April 2021 and
> December 2017).
>
> The best solution is to enable nodes to consider packages of
> transactions as a unit, e.g. one or more low-fee parent transactions
> with a high-fee child, instead of separately. A package-aware mempool
> policy can help determine if it would actually be economically
> rational to accept a transaction to the mempool if it doesn't meet fee
> requirements individually. Network-wide adoption of these policies
> would create a more purely-feerate-based market for block space and
> allow contracting protocols to adjust fees (and therefore mining
> priority) at broadcast time. Some support for packages has existed in
> Bitcoin Core for years. Since v0.13, Bitcoin Core has used ancestor
> packages instead of individual transactions to evaluate the incentive
> compatibility of transactions in the mempool [10] and select them for
> inclusion in blocks [11].
>
> Package Relay, the concept of {announcing, requesting, downloading}
> packages between nodes on the p2p network, has also been discussed for
> many years. The earliest public mention I can find is from 2015 [12].
> The two most common use cases for package relay are fee-bumping
> otherwise-too-low-fee transactions and reducing the amount of orphans.
> It seems uncontroversial to say that everybody desires package relay
> conceptually, with varying degrees of urgency. Lots of work has been
> done by others over the past few years, from which I've taken
> inspiration from [13][14][15][16].
>
> My approach has been to split the project into two components: (1) Package
> Mempool Accept, which includes validation logic and mempool policy.
> (3) Package Relay, which includes the p2p protocol changes.
>
> Progress so far:
> After discussions with various developers of contracting protocols
> (with heavier emphasis towards LN), it was determined that a
> package containing a child with all of its unconfirmed parents
> (child-with-unconfirmed-parents or 1-child-multi-parent package) would
> be sufficient for their use case, i.e. fee-bumping presigned
> transactions. A child-with-unconfirmed-parents package has several
> properties that make many things easier to reason about.
>
> A few months ago, I proposed a set of policies for safe package
> validation and fee assessment for packages of this restricted
> topology [17]. A series of PRs implementing this proposal have
> been merged into Bitcoin Core [18].
>
> Theoretically, developing a safe and incentive-compatible package
> mempool acceptance policy is sufficient to solve this issue. Nodes
> could opportunistically accept packages (e.g. by trying combinations
> of transactions rejected from their mempools), but this practice would
> likely be inefficient at best and open new Denial of Service attacks
> at worst. Additional p2p messages may enable nodes to request and
> share package validation-related information with one another in a
> more communication-efficient way.
>
> Given that only package RBF remains for package mempool accept, and we
> can make progress on p2p and mempool in parallel, I think it’s
> appropriate to put forward a package relay proposal.
>
> ==Proposal==
>
> This proposal contains 2 components: a “generic” package relay
> protocol and an extension of it, child-with-unconfirmed-parents
> packages, as version 1 package relay. Another version of packages,
> “tx-with-unconfirmed-ancestors” can be created to extend package relay
> for eliminating orphans.
>
> ===Generic Package Relay===
>
> Two main ideas are introduced:
>
> Download and validate packages of transactions together.
>
> Provide information to help peers decide whether to request and/or how
> to validate transactions which are part of a package.
>
> ====Intended Protocol Flow====
>
> Due to the asynchronous nature of a distributed transaction relay
> network, nodes may not receive all of the information needed to
> validate a transaction at once. For example, after a node completes
> Initial Block Download (IBD) and first starts participating in
> transaction relay with an empty mempool, it is common to receive
> orphans. In such scenarios where a node is aware that it is missing
> information, a ''receiver-initiated'' dialogue is appropriate:
>
> 1. Receiver requests package information.
>
> 2. The sender provides package information, including the wtxids of
> the transactions in the package and anything else that might be
> relevant (e.g. total fees and size).
>
> 3. The reciever uses the package information to decide how to request
> and validate the transactions.
>
> Sometimes, no matter what order transactions are received by a node,
> validating them individually is insufficient. When the sender is aware
> of additional information that the receiver needs to accept a package,
> a proactive ''sender-initiated'' dialogue should be enabled:
>
> 1. Sender announces they have package information pertaining to a
> transaction that might otherwise be undesired on its own.
>
> 2. The receiver requests package information.
>
> 3. The sender provides package information, including the wtxids of
> the transactions in the package and anything else that might be
> relevant (e.g. total fees and size).
>
> 4. The reciever uses the package information to decide how to request
> and validate the transactions.
>
> Package relay is negotiated between two peers during the version
> handshake. Package relay requires both peers to support wtxid-based
> relay because package transactions are referenced by their wtxid.
>
> ====New Messages====
>
> Three new protocol messages are added for use in any version of
> package relay. Additionally, each version of package relay must define
> its own inv type and "pckginfo" message version, referred to in this
> document as "MSG_PCKG" and "pckginfo" respectively. See
> BIP-v1-packages for a concrete example.
>
> =====sendpackages=====
>
> {|
> | Field Name || Type || Size || Purpose
> |-
> |version || uint32_t || 4 || Denotes a package version supported by the
> node.
> |-
> |max_count || uint32_t || 4 ||Specifies the maximum number of transactions
> per package this node is
> willing to accept.
> |-
> |max_weight || uint32_t || 4 ||Specifies the maximum total weight per
> package this node is willing
> to accept.
> |-
> |}
>
> 1. The "sendpackages" message has the structure defined above, with
> pchCommand == "sendpackages".
>
> 2. During version handshake, nodes should send a "sendpackages"
> message indicate they support package relay and may request
> packages.
>
> 3. The message should contain a version supported by the node. Nodes
> should send a "sendpackages" message for each version they support.
>
> 4. The "sendpackages" message MUST be sent before sending a "verack"
> message. If a "sendpackages" message is received afer "verack", the
> sender should be disconnected.
>
> 5. If 'fRelay==false' in a peer's version message, the node must not
> send "sendpackages" to them. If a "sendpackages" message is
> received by a peer after sending `fRelay==false` in their version
> message, the sender should be disconnected.
>
> 6.. Upon receipt of a "sendpackages" message with a version that is
> not supported, a node must treat the peer as if it never received the
> message.
>
> 7. If both peers send "wtxidrelay" and "sendpackages" with the same
> version, the peers should announce, request, and send package
> information to each other.
>
> =====getpckgtxns=====
>
> {|
> | Field Name || Type || Size || Purpose
> |-
> |txns_length||CompactSize||1 or 3 bytes|| The number of transactions
> requested.
> |-
> |txns||List of wtxids||txns_length * 32|| The wtxids of each transaction
> in the package.
> |}
>
> 1. The "getpckgtxns" message has the structure defined above, with
> pchCommand == "getpckgtxns".
>
> 2. A "getpckgtxns" message should be used to request all or some of
> the transactions previously announced in a "pckginfo" message,
> specified by witness transactiosome id.
>
> 3. Upon receipt of a "getpckgtxns" message, a node must respond with
> either a "pckgtxns" containing the requested transactions or a
> "notfound" message indicating one or more of the transactions is
> unavailable. This allows the receiver to avoid downloading and storing
> transactions that cannot be validated immediately.
>
> 4. A "getpckgtxns" message should only be sent if both peers agreed to
> send packages in the version handshake. If a "getpckgtxns" message
> is received from a peer with which package relay was not negotiated,
> the sender should be disconnected.
>
> =====pckgtxns=====
>
> {|
> | Field Name || Type || Size || Purpose
> |-
> |txns_length||CompactSize||1 or 3 bytes|| The number of transactions
> provided.
> |-
> |txns||List of transactions||variable|| The transactions in the package.
> |}
>
> 1. The "pckgtxns" message has the structure defined above, with
> pchCommand == "pckgtxns".
>
> 2. A "pckgtxns" message should contain the transaction data requested
> using "getpckgtxns".
>
> 3. A "pckgtxns" message should only be sent to a peer that requested
> the package using "getpckgtxns". If a node receives an unsolicited
> package, the sender should be disconnected.
>
> 4. A "pckgtxns" message should only be sent if both peers agreed to
> send packages in the version handshake. If a "pckgtxns" message is
> received from a peer with which package relay was not negotiated, the
> sender should be disconnected.
>
> ===Version 1 Packages: child-with-unconfirmed-parents===
>
> This extends package relay for packages consisting of one transaction
> and all of its unconfirmed parents,by defining version 1 packages, a
> pckginfo1 message, and a MSG_PCKG1 inv type. It enables the use case
> in which a child pays for its otherwise-too-low-fee parents and their
> mempool conflict(s).
>
> ====Intended Protocol Flow====
>
> When relaying a package of low-fee parent(s) and high-fee child, the
> sender and receiver do the following:
>
> 1. Sender announces they have a child-with-unconfirmed-parents package
> for a child that pays for otherwise-too-low-fee parent(s) using
> "inv(MSG_PCKG1)".
>
> 2. The receiver requests package information using
> "getdata(MSG_PCKG1)".
>
> 3. The sender provides package information using "pckginfo1",
> including the blockhash of the sender's best block, the wtxids of
> the transactions in the package, their total fees and total weight.
>
> 4. The reciever uses the package information to decide how to request
> the transactions. For example, if the receiver already has some of
> the transactions in their mempool, they only request the missing ones.
> They could also decide not to request the package at all based on the
> fee information provided.
>
> 5. Upon receiving a "pckgtxns", the receiver submits the transactions
> together as a package.
>
> ====New Messages====
>
> A new inv type, "MSG_PCKG1", and new protocol message, "PCKGINFO1",
> are added.
>
> =====pckginfo1=====
>
> {|
> | Field Name || Type || Size || Purpose
> |-
> |blockhash || uint256 || 32 || The chain tip at which this package is
> defined.
> |-
> |pckg_fee||CAmount||4|| The sum total fees paid by all transactions in the
> package.
> |-
> |pckg_weight||int64_t||8|| The sum total weight of all transactions in the
> package.
> |-
> |txns_length||CompactSize||1 or 3 bytes|| The number of transactions
> provided.
> |-
> |txns||List of wtxids||txns_length * 32|| The wtxids of each transaction
> in the package.
> |}
>
>
> 1. The "pckginfo1" message has the structure defined above, with
> pchCommand == "pckginfo1".
>
> 2. A "pckginfo1" message contains information about a version 1
> package (defined below), referenced by the wtxid of the transaction
> it pertains to and the current blockhash.
>
> 3. Upon receipt of a "pckginfo1" message, the node should decide if it
> wants to validate the package, request transaction data if
> necessary, etc.
>
> 4. Upon receipt of a malformed "pckginfo1" message or package that
> does not abide by the max_count, max_weight, or other rules
> specified by the version agreed upon in the initial negotiation, the
> sender should be disconnected. If a node receives a "pckginfo1"
> message for which the "pckg_fee" or "pckg_weight" do not reflect the
> true total fees and weight, respectively, or the transactions in the
> package, the message is malformed.
>
> 5. A node MUST NOT send a "pckginfo1" message that has not been
> requested by the recipient. Upon receipt of an unsolicited
> "pckginfo1", a node should disconnect the sender.
>
> 6. A "pckginfo1" message should only be sent if both peers agreed to
> send version 1 packages in the version handshake. If a "pckginfo1"
> message is received from a peer with which package relay was not
> negotiated, the sender should be disconnected.
>
> =====MSG_PCKG1=====
>
> 1. A new inv type (MSG_PCKG1 == 0x6) is added, for use in inv messages
> and getdata requests pertaining to version 1 packages.
>
> 2. As an inv type, it indicates that both transaction data and version
> 1 package information are available for the transaction. The
> transaction is referenced by its wtxid. As a getdata request type, it
> indicates that the sender wants package information for the
> transaction.
>
> 3. Upon receipt of a "getdata" request for "MSG_PCKG1", the node
> should respond with the version 1 package corresponding to the
> requested transaction and its current chain tip, or with NOTFOUND.
> The node should not assume that the sender is requesting the
> transaction data as well.
>
> ====Child With Parent Packages Rules====
>
> 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.
>
> A version 1 or ''child-with-unconfirmed-parents'' package can be
> defined for any transaction that spends unconfirmed inputs. The child
> can be thought of as the "representative" of the package. This package
> can be uniquely identified by the transaction's wtxid and the current
> chain tip block hash.
>
> A ''child-with-unconfirmed-parents'' package MUST be:
>
> 1. ''Sorted topologically.'' For every transaction t in the package,
> if any of t's parents are present in the package, the parent must
> appear somewhere in the list before t. In other words, the
> transactions must be sorted in ascending order of the number of
> ancestors present in the package.
>
> 2. ''Only 1 child with unconfirmed parents.'' The package must consist
> of one transaction and its unconfirmed parents. There must not be
> any other transactions in the package. Other dependency relationships
> may exist within the package (e.g. one parent may spend the output of
> another parent) provided that topological order is respected.
>
> 3. ''All unconfirmed parents.'' All of the child's unconfirmed parents
> must be present.
>
> 4. ''No conflicts.'' None of the transactions in the package may
> conflict with each other (i.e. spend the same prevout).
>
> 5. ''Total fees and weight.'' The 'total_fee' and 'total_weight'
> fields must accurately represent the sum total of all transactions'
> fees and weights as defined in BIP141, respectively.
>
> Not all of the child's parents must be present; the child transaction
> may also spend confirmed inputs. However, if the child has confirmed
> parents, they must not be in the package.
>
> While a child-with-unconfirmed-parents package is perhaps most
> relevant when the child has a higher feerate than its parents, this
> property is not required to construct a valid package.
>
> ====Clarifications====
>
> ''Q: Under what circumstances should a sender announce a
> child-with-unconfirmed-parents package?''
>
> A child-with-unconfirmed-parents package for a transaction should be
> announced when it meets the peer's fee filter but one or more of its
> parents don't; a "inv(MSG_PCKG1)" instead of "inv(WTX)" should be sent
> for the child. Each of the parents which meet the peer's fee filter
> should still be announced normally.
>
> ''Q: What if a new block arrives in between messages?''
>
> A child-with-unconfirmed-parents package is defined for a transaction
> based on the current chain state. As such, a new block extending the
> tip may decrease the number of transactions in the package (i.e. if
> any of the transaction's parents were included in the block). In a
> reorg, the number of transactions in the package may decrease or
> increase (i.e. if any of the transaction's parents were included in a
> block in the previous chain but not the new one).
>
> If the new block arrives before the "getdata" or "pckginfo1", nothing
> needs to change.
>
> If the new block arrives before "getpckgtxns" or before "pckgtxns",
> the receiver may need to re-request package information if the block
> contained a transaction in the package. If the block doesn't contain
> any transactions in the package, whether it extends the previous tip
> or causes a reorg, nothing needs to change.
>
> ''Q: Can "getpckgtxns" and "pckgtxns" messages contain only one
> transaction?''
>
> Yes.
>
> ===Further Protocol Extensions===
>
> When introducing a new type of package, assign it a version number "n"
> and use an additional "sendpackages" message during version handshake
> to negotiate support for it. An additional package information message
> "pckginfon" and inv type "MSG_PCKGn" should be defined for the type of
> package. However, "getpckgtxns" and "pckgtxns" do not need to be
> changed.
>
> Example proposal for tx-with-unconfirmed-ancestors package relay: [19]
>
> ===Compatibility===
>
> Older clients remain fully compatible and interoperable after this
> change. Clients implementing this protocol will only attempt to send
> and request packages if agreed upon during the version handshake.
>
> ===Package Erlay===
>
> Clients using BIP330 reconciliation-based transaction relay (Erlay)
> are able to use package relay without interference. In fact, a package
> of transactions may be announced using both Erlay and package relay.
> After reconciliation, if the initiator would have announced a
> transaction by wtxid but also has package information for it, they may
> send "inv(MSG_PCKG)" instead of "inv(WTX)".
>
> ===Rationale===
>
> ====P2P Message Design====
>
> These p2p messages are added for communication efficiency and, as
> such, one should measure alternative solutions based on the resources
> used to communicate (not necessarily trustworthy) information: We
> would like to minimize network bandwidth, avoid downloading a
> transaction more than once, avoid downloading transactions that are
> eventually rejected, and minimize storage allocated for
> not-yet-validated transactions.
>
> Consider these (plausible) scenarios in transaction relay:
>
> Alice (the "sender") is relaying transactions to Bob (the "receiver").
> Alice's mempool has a minimum feerate of 1sat/vB and Bob's has a
> minimum feerate of 3sat/vB. For simplicity, all transactions are
> 1600Wu in virtual size and 500 bytes in serialized size. Apart from
> the spending relationships specified, all other inputs are from
> confirmed UTXOs.
>
> 1. Package {A, B} where A pays 0 satoshis and B pays 8000 satoshis in
> fees.
>
> 2. Package {C, D} where C pays 0 satoshis and D pays 1200 satoshis in
> fees.
>
> 3. Package {E, F, G, H, J} that pays 4000, 8000, 0, 2000, and 4000
> satoshis in fees, respectively.
>
> ====Alternative Designs Considered====
>
> ''Package Information Only:'' Just having "pckginfo" gives enough
> information for the receiver to accept the package. Omit the
> "getpckgtxns" and "pckgtxns" messages. While this option is a good
> fallback if batched transaction download fails for some reason, it
> shouldn't be used as the default because it 'always' requires storage
> of unvalidated transactions.
>
> ''No Package Information Round:'' Instead of having a package
> information round, just use the child's wtxid to refer to the package
> and always send the entire package together. This would cause nodes to
> redownload duplicate transactions.
>
> I have also created a slidedeck exploring various alternative designs
> and some examples in which they fall flat [20]. Please feel free to
> suggest other alternatives.
>
> ====Versioning System====
>
> This protocol should be extensible to support multiple types of
> packages based on future desired use cases. Two "flavors" of
> versioning were considered:
>
> 1. When package mempool acceptance is upgraded to support more types
> of packages, increment the version number (similar to Erlay).
> During version handshake, peers negotiate which version of package
> relay they will use by each sending one "sendpackages" message.
>
> 2. When introducing another type of package, assign a version number
> to it and announce it as an additional supported version (similar
> to Compact Block Relay). During version handshake, peers send one
> "sendpackages" message for each version supported.
>
> The second option was favored because it allows different parameters
> for different versions. For example, it should be possible to support
> both "arbitrary topology but maximum 3-transaction" package as well as
> "child-with-unconfirmed-parents with default mempool ancestor limits"
> packages simultaneously.
>
> ==Acknowledgements==
>
> I hope to have made it abundantly clear that this proposal isn’t
> inventing the concept of package relay, and in fact builds upon years
> of work by many others, including Suhas Daftuar and Antoine Riard.
>
> Thank you to John Newbery and Martin Zumsande for input on the design.
>
> Thank you to Matt Corallo, Christian Decker, David Harding, Antoine
> Poinsot, Antoine Riard, Gregory Sanders, Chris Stewart, Bastien
> Teinturier, and others for input on the desired interface for
> contracting protocols.
>
> Looking forward to hearing your thoughts!
>
> Best,
> Gloria
>
> [0]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html
> [1]:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002639.html
> [2]:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html
> [3]:
> https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md
> [4]:
> https://github.com/revault/practical-revault/blob/master/transactions.md#cancel_tx
> [5]:
> https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md#refund-transaction
> [6]: https://gist.github.com/instagibbs/60264606e181451e977e439a49f69fe1
> [7]:
> https://btctranscripts.com/adopting-bitcoin/2021/2021-11-16-gloria-zhao-transaction-relay-policy/#lightning-attacks
> [8]: https://youtu.be/fbWSQvJjKFs?t=1438
> [9]:
> https://www.reddit.com/r/Bitcoin/comments/unew4e/looks_like_70_mvb_of_transactions_just_got_dumped/
> [10]: https://github.com/bitcoin/bitcoin/pull/7594
> [11]: https://github.com/bitcoin/bitcoin/pull/7600
> [12]: https://github.com/bitcoin/bitcoin/pull/6455#issuecomment-122716820
> [13]: https://gist.github.com/sdaftuar/8756699bfcad4d3806ba9f3396d4e66a
> [14]: https://github.com/bitcoin/bitcoin/issues/14895
> [15]: https://github.com/bitcoin/bitcoin/pull/16401
> [16]: https://github.com/bitcoin/bitcoin/pull/19621
> [17]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019464.html
> [18]: https://github.com/users/glozow/projects/5/views/4?layout=board
> [19]: https://gist.github.com/glozow/9b321cd3ef6505135c763112033ff2a7
> [20]:
> https://docs.google.com/presentation/d/1B__KlZO1VzxJGx-0DYChlWawaEmGJ9EGApEzrHqZpQc/edit?usp=sharing
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220517/06bd18af/attachment-0001.html>;

📅 Original date posted:2021-11-24 📝 Original message:I may ...

2023-06-08T01:00:39+02:00

In reply to nevent1q…uknf
_________________________

📅 Original date posted:2021-11-24
📝 Original message: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 at 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 at 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
> | <tt>PSBT_IN_TAP_BIP32_DERIVATION = 0x16</tt>
> | <tt><xonlypubkey></tt>
> | The 32 byte X-only public key
> | <tt><hashes len> <leaf hash>* <32-bit uint> <32-bit uint>*</tt>
> | 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
> | <tt>PSBT_OUT_TAP_BIP32_DERIVATION = 0x07</tt>
> | <tt><xonlypubkey></tt>
> | The 32 byte X-only public key
> | <tt><hashes len> <leaf hash>* <32-bit uint> <32-bit uint>*</tt>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211125/1b84c9b6/attachment.html>;

📅 Original date posted:2020-08-21 📝 Original message:No ...

2023-06-07T20:26:37+02:00

In reply to nevent1q…5jkl
_________________________

📅 Original date posted:2020-08-21
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200821/53f9cfde/attachment.html>;

📅 Original date posted:2020-05-01 📝 Original message:For ...

2023-06-07T20:24:12+02:00

In reply to nevent1q…tprf
_________________________

📅 Original date posted:2020-05-01
📝 Original message: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 at 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200501/5712467f/attachment.html>;

📅 Original date posted:2020-03-26 📝 Original message:> ...

2023-06-07T20:23:37+02:00

In reply to nevent1q…wtya
_________________________

📅 Original date posted:2020-03-26
📝 Original message:> 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 at lists.linuxfoundation.org> wrote:

> Ruben Somsen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200326/7b38acf0/attachment.html>;

📅 Original date posted:2020-03-04 📝 Original ...

2023-06-07T20:23:15+02:00

In reply to nevent1q…z7cz
_________________________

📅 Original date posted:2020-03-04
📝 Original message:OP_MESSAGEONLY would make "dumb" signers like HWW more difficult to
support. They'd have to do script interpretation to make sure they're not
signing something real with funds.

Just FYI.

On Wed, Mar 4, 2020 at 9:35 AM Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> In addition to starting with proof-of-funds instead of proof-of-receiver,
> it
> would be nice to integrate with Taproot somehow or another. Perhaps
> OP_MESSAGEONLY is the most straightforward way to do this? It might be a
> good
> idea to have a message type after the opcode too.
>
> On Wednesday 04 March 2020 06:23:53 Karl-Johan Alm via bitcoin-dev wrote:
> > Hello,
> >
> > I noticed recently that a PR to Bitcoin Core that pretty much touched
> > everything my BIP-322 pull request touches (around the same
> > complexity) was merged without a thought given to BIP-322
> > compatibility, despite the BIP-322 PR being open for 2x the time. I
> > can only conclude from this that people dislike BIP-322 in its current
> > form, which the 9 month old pull request stagnating can probably
> > attest to.
> >
> > There are several things that I can do to make this a bit more
> > appealing to people, which would hopefully kick the progress on this
> > forward. I have already put in a non-trivial amount of energy and
> > effort into maintaining the pull request as is, so I'd prefer if
> > people were harsh and unfiltered in their criticism rather than polite
> > and buffered, so I can beat this thing into shape (or abandon it, in
> > the worst case).
> >
> > =============
> > 1. People use signmessage as a way to prove funds. This is misleading
> > and should be discouraged; throw the sign message stuff out and
> > replace it entirely with a prove funds system.
> >
> > I know in particular luke-jr is of this opinion, and Greg Maxwell in
> > https://github.com/bitcoin/bitcoin/pull/16440#issuecomment-568194168
> > leans towards this opinion as well, it seems.
> >
> > =============
> > 2. Use a transaction rather than a new format; make the first input's
> > txid the message hash to ensure the tx cannot be broadcasted. This has
> > the benefit of being able to provide to an existing hardware wallet
> > without making any modifications to its firmware.
> >
> > I think Mark Friedenbach and Johnson Lau are of this opinion, except
> > Johnson Lau also suggests that the signature hash is modified, see
> > https://github.com/bitcoin/bips/pull/725#issuecomment-420040430 --
> > which defeats the benefit above since now hw wallets can no longer
> > sign.
> >
> > Prusnak (I think he works at Trezor; apologies if I am mistaken) is
> > against this idea, and proposes (3) below:
> > https://github.com/bitcoin/bips/pull/725#issuecomment-420210488
> >
> > =============
> > 3. Use Trezor style
> >
> > See https://github.com/trezor/trezor-mcu/issues/169
> >
> > This has the benefit of already being adopted (which clearly BIP-322
> > is failing hard at right now), but has the drawback that we can no
> > longer do *generic* signing; we are stuck with the exact same
> > limitations as in the legacy system, which we kinda wanted to fix in
> > the updated version.
> >
> > =============
> > 4. Introduce OP_MESSAGEONLY
> >
> > Quoting Johnson Lau at
> > https://github.com/bitcoin/bips/pull/725#issuecomment-420421058 :
> > """
> > OP_MESSAGEONLY means the script following the code would never be
> > valid. For example, a scriptPubKey:
> >
> > OP_IF OP_MESSAGEONLY <key_m> OP_ELSE <key_s> OP_ENDIF OP_CHECKSIG
> >
> > For messaging purpose, OP_MESSAGEONLY is considered as OP_NOP and is
> > ignored. A message could be signed with either key_m or key_s.
> >
> > For spending, only key_s is valid.
> >
> > I don't think it is a big problem to consume a op_code. If this is a
> > real concern, I could modify it as follow: in message system,
> > OP_RETURN will pop the top stack. If top stack is msg in hex, it is
> > ignored. Otherwise, the script fails.
> > """
> >
> > =============
> > 5. Some other solution
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200304/4a364551/attachment.html>;

📅 Original date posted:2019-11-07 📝 Original message:Could ...

2023-06-07T20:21:35+02:00

In reply to nevent1q…a639
_________________________

📅 Original date posted:2019-11-07
📝 Original message:Could the softer touch of just making them non-standard apply as a future
preparation for an accepted softfork? Relaxations could easily be done
later if desired.

On Thu, Nov 7, 2019, 5:37 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hello all,
>
> A while ago it was discovered that bech32 has a mutation weakness (see
> https://github.com/sipa/bech32/issues/51 for details). Specifically,
> when a bech32 string ends with a "p", inserting or erasing "q"s right
> before that "p" does not invalidate it. While insertion/erasure
> robustness was not an explicit goal (BCH codes in general only have
> guarantees about substitution errors), this is very much not by
> design, and this specific issue could have been made much less
> impactful with a slightly different approach. I'm sorry it wasn't
> caught earlier.
>
> This has little effect on the security of P2WPKH/P2WSH addresses, as
> those are only valid (per BIP173) for specific lengths (42 and 62
> characters respectively). Inserting 20 consecutive "p"s in a typo
> seems highly improbable.
>
> I'm making this post because this property may unfortunately influence
> design decisions around bip-taproot, as was brought up in the review
> session (
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-October/017427.html
> )
> past tuesday. In the current draft, witness v1 outputs of length other
> than 32 remain unencumbered, which means that for now such an
> insertion or erasure would result in an output that can be spent by
> anyone. If that is considered unacceptable, it could be prevented by
> for example outlawing v1 witness outputs of length 31 and 33.
>
> Thoughts?
>
> Cheers,
>
> --
> Pieter
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191107/ffd8acac/attachment.html>;

📅 Original date posted:2018-01-23 📝 Original ...

2023-06-07T20:10:11+02:00

In reply to nevent1q…jpkh
_________________________

📅 Original date posted:2018-01-23
📝 Original message: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 at 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 = "<timeout> 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 key, or a spending transaction could provide a script along with
> a signature of that script by the named key, delegating control to the
> signed script. Before paying into that escrow Alice/Bob would
> construct this signature. This idea is equally efficient in the common
> case, but larger and slower to verify in the alternative spend case.
> Setting up the signature requires additional interaction between
> participants and the resulting signature must be durably stored and
> couldn't just be recomputed using single-party information.
>
> I believe this construction will allow the largest possible anonymity
> set for fixed party smart contracts by making them look like the
> simplest possible payments. It accomplishes this without any overhead
> in the common case, invoking any sketchy or impractical techniques,
> requiring extra rounds of interaction between contract participants,
> and without requiring the durable storage of other data.
>
>
> [1] https://eprint.iacr.org/2018/068
> [2] https://blockstream.com/sidechains.pdf Appendix A
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180123/ded288f9/attachment.html>;

📅 Original date posted:2017-04-07 📝 Original ...

2023-06-07T19:59:38+02:00

In reply to nevent1q…pwug
_________________________

📅 Original date posted:2017-04-07
📝 Original message:Interesting work.

I was wondering if you could tell us what specs for the machine being used
as preliminary benchmark is here: https://bitcrust.org/results ?

I'd be interested to also see comparisons with 0.14 which has some
improvements for script validation with more cores.

On Fri, Apr 7, 2017 at 4:47 AM, Tomas via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Thank you Marcos,
>
> Though written in Rust, bitcrust-db is definitely usable as pluggable
> module as its interface will be roughly some queries, add_tx and
> add_block with blobs and flags. (Bitcrust internally uses a
> deserialize-only model, keeping references to the blobs with the parsed
> data).
>
> However, from Core's side I believe network and storage are currently
> rather tightly coupled, which will make this far from trivial.
>
> Regardless, I am also hoping (with funding & a team) to build a Bitcrust
> networking component as well to bring a strong competitor to the market.
>
> best,
> Tomas
>
>
>
> On Fri, Apr 7, 2017, at 09:55, Marcos mayorga wrote:
> > Hi Tomas,
> >
> > I've read it and think it is an excellent work, I'd like to see it
> > integrated into bitcoin-core as a 'kernel module'.
> >
> > I see there are a lot of proof of concepts out there, IMO every one
> > deserve a room in the bitcoin client as a selectable feature, to make the
> > software more flexible and less dictatorial, an user could easily select
> > which features she wants to run.
> >
> > Best regards,
> > Marcos
> >
> > > I have been working on a bitcoin implementation that uses a different
> > > approach to indexing for verifying the order of transactions. Instead
> of
> > > using an index of unspent outputs, double spends are verified by using
> a
> > > spend-tree where spends are scanned against spent outputs instead of
> > > unspent outputs.
> > >
> > > This allows for much better concurrency, as not only blocks, but also
> > > individual inputs can be verified fully in parallel.
> > >
> > > I explain the approach at https://bitcrust.org, source code is
> available
> > > at https://github.com/tomasvdw/bitcrust
> > >
> > > I am sharing this not only to ask for your feedback, but also to call
> > > for a clear separation of protocol and implementations: As this
> > > solution, reversing the costs of outputs and inputs, seems to have
> > > excellent performance characteristics (as shown in the test results),
> > > updates to the protocol addressing the UTXO growth, might not be worth
> > > considering *protocol improvements* and it might be best to address
> > > these concerns as implementation details.
> > >
> > > Kind regards,
> > > Tomas van der Wansem
> > > tomas at bitcrust.org
> > > Bitcrust
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
> >
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/7be2b4cf/attachment.html>;