Re: [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

[Nadav Ivgi via bitcoin-dev]

Could this be addressed with an OP_CSV_ALLINPUTS, a covenant opcode that
requires *all* inputs to have a matching nSequence, and using `1
OP_CSV_ALLINPUTS` in the HTLC preimage branch?

This would prevent using unconfirmed outputs in the HTLC-preimage-spending
transaction entirely, which IIUC should protect it against the replacement
cycling attack.

(If desirable, this could alternatively be OP_CSV_OTHERINPUTS to allow the
HTLC output itself to be spent immediately via the preimage branch, and
only require that the other inputs added for fees are confirmed.)


On Mon, Oct 16, 2023 at 8:03 PM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> (cross-posting mempool issues identified are exposing lightning chan to
> loss of funds risks, other multi-party bitcoin apps might be affected)
>
> Hi,
>
> End of last year (December 2022), amid technical discussions on eltoo
> payment channels and incentives compatibility of the mempool anti-DoS
> rules, a new transaction-relay jamming attack affecting lightning channels
> was discovered.
>
> After careful analysis, it turns out this attack is practical and
> immediately exposed lightning routing hops carrying HTLC traffic to loss of
> funds security risks, both legacy and anchor output channels. A potential
> exploitation plausibly happening even without network mempools congestion.
>
> Mitigations have been designed, implemented and deployed by all major
> lightning implementations during the last months.
>
> Please find attached the release numbers, where the mitigations should be
> present:
> - LDK: v0.0.118 - CVE-2023 -40231
> - Eclair: v0.9.0 - CVE-2023-40232
> - LND: v.0.17.0-beta - CVE-2023-40233
> - Core-Lightning: v.23.08.01 - CVE-2023-40234
>
> While neither replacement cycling attacks have been observed or reported
> in the wild since the last ~10 months or experimented in real-world
> conditions on bitcoin mainet, functional test is available exercising the
> affected lightning channel against bitcoin core mempool (26.0 release
> cycle).
>
> It is understood that a simple replacement cycling attack does not demand
> privileged capabilities from an attacker (e.g no low-hashrate power) and
> only access to basic bitcoin and lightning software. Yet I still think
> executing such an attack successfully requests a fair amount of bitcoin
> technical know-how and decent preparation.
>
> From my understanding of those issues, it is yet to be determined if the
> mitigations deployed are robust enough in face of advanced replacement
> cycling attackers, especially ones able to combine different classes of
> transaction-relay jamming such as pinnings or vetted with more privileged
> capabilities.
>
> Please find a list of potential affected bitcoin applications in this full
> disclosure report using bitcoin script timelocks or multi-party
> transactions, albeit no immediate security risk exposure as severe as the
> ones affecting lightning has been identified. Only cursory review of
> non-lightning applications has been conducted so far.
>
> There is a paper published summarizing replacement cycling attacks on the
> lightning network:
>
> https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pdf
>
>  ## Problem
>
> A lightning node allows HTLCs forwarding (in bolt3's parlance accepted
> HTLC on incoming link and offered HTLC on outgoing link) should settle the
> outgoing state with either a success or timeout before the incoming state
> timelock becomes final and an asymmetric defavorable settlement might
> happen (cf "Flood & Loot: A Systematic Attack on The Lightning Network"
> section 2.3 for a classical exposition of this lightning security property).
>
> Failure to satisfy this settlement requirement exposes a forwarding hop to
> a loss of fund risk where the offered HTLC is spent by the outgoing link
> counterparty's HTLC-preimage and the accepted HTLC is spent by the incoming
> link counterparty's HTLC-timeout.
>
> The specification mandates the incoming HTLC expiration timelock to be
> spaced out by an interval of `cltv_expiry_delta` from the outgoing HTLC
> expiration timelock, this exact interval value being an implementation and
> node policy setting. As a minimal value, the specification recommends 34
> blocks of interval. If the timelock expiration I of the inbound HTLC is
> equal to 100 from chain tip, the timelock expiration O of the outbound HTLC
> must be equal to 66 blocks from chain tip, giving a reasonable buffer of
> reaction to the lightning forwarding node.
>
> In the lack of cooperative off-chain settlement of the HTLC on the
> outgoing link negotiated with the counterparty (either
> `update_fulfill_htlc` or `update_fail_htlc`) when O is reached, the
> lightning node should broadcast its commitment transaction. Once the
> commitment is confirmed (if anchor and the 1 CSV encumbrance is present),
> the lightning node broadcasts and confirms its HTLC-timeout before I height

Re: [bitcoin-dev] Minimum fees

[Nadav Ivgi via bitcoin-dev]

Hi Giuseppe,

One side-effect this has is that until enough fees accumulate in the
mempool to satisfy min_fees, the rational behaviour for miners would be to
try and fork the chain tip, competing for the fees in the latest block
(+whatever got into the mempool in the meanwhile and can fit in). This
could lead to increased reorgs/orphan rates and chain instability. It could
also lead to miners preferring to set their low_fee to zero, to avoid other
miners from forking their blocks off.

I'm also not sure that this would actually change much. If humanity is
willing to spend X BTC/day on mining fees, it doesn't really matter if it's
spread out through fewer or more blocks.

shesek

On Wed, Mar 1, 2023 at 10:25 PM Giuseppe B via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello everyone,
>
> I'm relatively new here so what I'm proposing could have already been
> discussed, or may be flawed or inapplicable. I apologize for that.
>
> I was picturing a situation where block rewards are almost zero, and the
> base layer is mainly used as a settlement layer for relatively few large
> transactions, since the majority of smaller ones goes through LN.
>
> In such a case it may very well be that even if transaction amounts are
> very consistent, transaction fees end up being very small since there is
> enough space for everyone in a block. Users wouldn't mind paying higher
> fees as they know that that would increase the network security, however
> nobody wants to be the only one doing that. Miners would of course like
> being paid more. So everyone involved would prefer higher fees but they
> just stay low because that's the only rational individual choice.
>
> Therefore I was imagining the introduction of a new protocol rule,
> min_fees, that would work like this:
> - the miner that gets to mine a block appends a min_fee field to the
> block, specifying the minimum fees that need to be contained in the
> following block in order for it to be valid.
> - one can also mine an empty block and reset the min_fee, to avoid the
> chain getting stuck.
>
> min_fees could either represent the total fees of the following block, or
> the minimal fee for each single transaction, as a percentage of the value
> transacted. Both seem to have some merits and some potential drawbacks. Of
> course min_fees=0 would correspond to the current situation.
>
> It looks to me that this could have the potential to bring the equilibrium
> closer to a socially optimal one (as opposed to individually optimal), and
> to benefit the network security in the long term. Of course it's just a
> rough sketch and it would deserve a much deeper analysis. I was just
> interested in knowing if you think that the principle has some merit or if
> it's not even worth discussing it for some reason that I'm not considering.
>
> Cheers,
>
> Giuseppe.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Nadav Ivgi via bitcoin-dev]

> Since Taproot (more generally any kind of MAST) spends have variable size

Isn't this the case with any arbitrary script execution? Non-taproot
P2(W)SH can also have multiple (OP_IF-gated) script branches. For example
with ` CHECKSIG IF SHA256  EQUALVERIFY ENDIF`, Mallory can
initially demonstrate that she can spend with `FALSE `, then later
switch to spending with ` TRUE `. (or I guess
even `DROP  CHECKSIG`, then just switch from DROPing a 0 length item to
a larger one)

It seems that supporting arbitrary scripts would require analyzing them and
verifying that all spend paths are acceptable, with or without Taproot/MAST.

If the goal is to only allow registering simple singlesig-encumbered UTXOs
like P2(W)PKH, the participants could be asked to prove that their P2TR
output commits to an unspendable script path [0].

shesek

[0]
https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_ref-23-0

On Tue, Feb 7, 2023 at 4:59 AM Yuval Kogman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> ## Summary
>
> Since Taproot (more generally any kind of MAST) spends have variable size
> which
> depends on the path being used, the last such input to be signed in a
> multiparty
> transaction can always use a larger than estimated signature to unfairly
> extract
> a fee contribution from the other parties to the transaction (keeping the
> absolute fees the same and reducing the feerate for the transaction).
>
> ## Attack Scenario
>
> Alice et al wish to perform a multiparty transaction, such as a CoinJoin or
> lightning dual funding at a relatively high feerate.
>
> Mallory has a P2TR output with a large script spend path, e.g. an ordinal
> inscription commitment transaction output.
>
> Mallory registers this coin as an input into the multiparty transaction
> with a
> fee obligation calculated on the basis of a key spend. When all other
> participants have provided signatures, the script spend path can be used.
>
> Since the absolute fee amount is already committed to by the provided
> (`SIGHASH_ALL`) signatures but the total transaction weight is not,
> Mallory can
> broadcast any valid signatures up to the maximum standard weight and
> minimum
> relay fees, or in collusion with a miner, up to consensus limits.
>
> This effectively steals a fee from Alice et al, as their signatures do not
> commit to a feerate directly or indirectly.
>
> ## Mitigations
>
> ### RBF
>
> All parties could negotiate a (series of) transaction(s) ahead of time at a
> lower feerate, giving a lower bound minimum feerate that Mallory can force.
>
> ### Minimum Weight Before Signing
>
> Enforcing a minimal weight for all non-witness data in the transaction
> before
> the transaction is considered fully constructed can limit the
> effectiveness of
> this attack, since the difference between the predicted weight and the
> maximum
> weight decreases.
>
> ### Trusted Coordinator
>
> In the centralized setting if BIP-322 ownership proofs are required for
> participation and assuming the server can be trusted not to collude with
> Mallory, the server can reject signatures that do not exercise the same
> spend
> path as the ownership proof, which makes the ownership proof a commitment
> to the
> spend weight of the input.
>
> ### Reputation
>
> Multiparty protocols with publicly verifiable protocol transcripts can be
> provided as weak evidence of a history of honest participation in
> multiparty
> transactions.
>
> A ring signature from keys used in the transaction or its transcript
> committing
> to the new proposed transaction can provide weak evidence for the honesty
> of the
> peer.
>
> Such proofs are more compelling to an entity which has participated in
> (one of)
> the transcripts, or proximal transactions. Incentives are theoretically
> aligned
> if public coordinators publish these transcripts as a kind of server
> reputation.
>
> ### Increasing Costliness
>
> A minimum feerate for the previous transaction or a minimum confirmation
> age
> (coindays destroyed implies time value, analogous to fidelity bonds) can be
> required for inputs to be added, in order to make such attacks less
> lucrative
> (but there is still a positive payoff for the attacker).
>
> ### Signature Ordering
>
> Signatures from potentially exploitative inputs can be required ahead of
> legacy
> or SegWit v0 ones. The prescribed order can be determined based on
> reputation or
> costliness as described in the previous paragraphs.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

[Nadav Ivgi via bitcoin-dev]

On Sat, May 7, 2022 at 5:08 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> * Even ***with*** `OP_CAT`, the following will enable non-recursive
covenants without enabling recursive covenants:
>  * `OP_CTV`, ...
> * With `OP_CAT`, the following would enable recursive covenants:
>  * `OP_CHECKSIGFROMSTACK`, ...

Why does CTV+CAT not enable recursive covenants while CSFS+CAT does?

CTV+CAT lets you similarly assert against the outputs and verify that they
match some dynamically constructed script.

Is it because CTV does not let you have a verified copy of the input's
prevout scriptPubKey on the stack [0], while with OP_CSFS you can because
the signature hash covers it?

But you don't actually need this for recursion. Instead of having the user
supply the script in the witness stack and verifying it against the input
to obtain the quine, the script can simply contain a copy of itself as an
initial push (minus this push). You can then reconstruct the full script
quine using OP_CAT, as a 

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

[Nadav Ivgi via bitcoin-dev]

> via `sha_sequences`

Since you cannot expect txid stability with >1 inputs either way[0], it
should be sufficient to commit just to the current input's
nSequence/scriptSig to get txid stability for single input transactions. I
chatted with Jeremy about this and he appears to agree.

Not committing to the nSequence of other inputs gives them the freedom to
set it independently, so for example you can spend a CSV-encumbered output
alongside the covenant. And there seems to be no downside to doing this [1].

APO/APOAS already commits to the nSequence of the current input. And since
APO is Taproot-only, the scriptSig of the covenant input is guarrnated to
be empty, so it is also already committed to in a way.

However, without committing to all the nSequences which implicitly commits
to the number of inputs, the number has to be committed separately.

So my suggestion is to explicitly commit to the number of inputs, instead
of commiting to `sha_sequences`.

Cheers
shesek

[0] the additional input(s) will be third-party malleable, since their
prevouts can be replaced with an entirely different txid:vout
[1] BIP 119's rationale for committing to the nSequences is txid
malleability:
https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#committing-to-the-sequences-hash



On Sat, Apr 30, 2022 at 11:09 AM Nadav Ivgi  wrote:

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

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

[Nadav Ivgi via bitcoin-dev]

Hi darosior,

It's interesting to note that APOAS|SINGLE (with the ANYONECANPAY behaviour
and without covering the spent input index) has some interesting uses for
cases where the covenant only needs to restrict a single output (so useful
for e.g. vaults or spacechains, but not for batch channels or congestion
control).

For example in the vault use-case, it makes it possible to bump fees on the
unvault tx by adding more inputs and a change output, as well as unvault
multiple vaulted outputs in a single transaction.

For spacechains, it makes it possible to add the spaceblock hash OP_RETURN
and pay fees directly in the tx chain, instead of having to use an
additional tx to prepare an output that gets spent in the tx chain  (see
the diagram in [0]).

> via `sha_sequences` and maybe also `sha_amounts`

CTV does not commit to the input amounts. This has some practical
implications:

1. If it is committed, sending an even slightly incorrect amount will make
the covenant-encumbered spend path unusable.

With CTV, sending a slightly lower amount results in slightly lower fees,
while any extra gets spent/burned on fees. The covenant spend path only
becomes unusable if the amount is too low to cover for the outputs (+relay
fee for it to also be standard).

2. The ability to allow for additional inputs with unknown amounts makes it
possible to fee-bump the covenant spending transaction (with whole utxos
and no change). You can have one tapleaf for spending the covenant output
alone, and another one for attaching an extra fee input to it.

This also makes it possible to resolve the under-payment issue described in
(1), by adding an input that covers the original intended amount.

So my suggestion would be to either not cover `sha_amounts` in the msg
hash, or to make it optional behind a flag.

shesek

[0] https://github.com/fiatjaf/simple-ctv-spacechain

On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I would like to know people's sentiment about doing (a very slightly
> tweaked version of) BIP118 in place of
> (or before doing) BIP119.
>
> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for
> over 6 years. It presents proven and
> implemented usecases, that are demanded and (please someone correct me if
> i'm wrong) more widely accepted than
> CTV's.
>
> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made
> optional [0], can emulate CTV just fine.
> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more
> expensive to use. But we can consider CTV
> an optimization of APO-AS covenants.
>
> CTV advocates have been presenting vaults as the flagship usecase.
> Although as someone who've been trying to
> implement practical vaults for the past 2 years i doubt CTV is necessary
> nor sufficient for this (but still
> useful!), using APO-AS covers it. And it's not a couple dozen more virtual
> bytes that are going to matter for
> a potential vault user.
>
> If after some time all of us who are currently dubious about CTV's stated
> usecases are proven wrong by onchain
> usage of a less efficient construction to achieve the same goal, we could
> roll-out CTV as an optimization.  In
> the meantime others will have been able to deploy new applications
> leveraging ANYPREVOUT (Eltoo, blind
> statechains, etc..[1]).
>
>
> Given the interest in, and demand for, both simple covenants and better
> offchain protocols it seems to me that
> BIP118 is a soft fork candidate that could benefit more (if not most of)
> Bitcoin users.
> Actually i'd also be interested in knowing if people would oppose the
> APO-AS part of BIP118, since it enables
> CTV's features, for the same reason they'd oppose BIP119.
>
>
> [0] That is, to not commit to the other inputs of the transaction (via
> `sha_sequences` and maybe also
> `sha_amounts`). Cf
> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
> .
>
> [1] https://anyprevout.xyz/ "Use Cases" section
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Nadav Ivgi via bitcoin-dev]

Correction: thinking about this some more, you can't actually expect to
have a stable txid if you allow additional inputs at all...

So yes, amending BIP 118 to commit to sha_sequences (which indirectly also
commits to the number of inputs) as proposed in the OP should be sufficient
to get stable txids for single-input transactions.

(I initially thought that APO has to cover some additional tx parts for
this, but it seems that it's really just the scriptSig which is guarrnated
to be empty if you have a single input that is known to be the taproot APO
spend.)

So in overall, my (1) and (5) points are only applicable to
APO-as-currently-spec'd and not to the suggested APO revision.

On Fri, Apr 29, 2022 at 1:21 PM Nadav Ivgi  wrote:

> > This is *literally* what the post you are replying to is proposing to
> solve.
>
> I thought the changes mentioned in the OP (+ committing to the spent input
> index) only solves the half-spend problem, but not the stable txids one?
>
> There can be other inputs with a scriptSig, which doesn't get committed to
> in the APO hash. I guess this isn't too common, but there might be some
> cases where you would want to spend some (pre-selected) non-segwit inputs
> alongside your covenant, maybe for fees. With CTV you would pre-commit to
> the scriptSig which makes it non-malleable even if the script itself is.
>
> > Hmm? You can't have channel factories without Eltoo. (Well, you can in
> theory but good luck.)
> > Maybe you are refering to non-interactive channel creation?
>
> I was referring to what BIP 119 calls 'Batched Channel Creation' [0],
> which is a sort of a channel factory construction under a broader
> definition (and in fact was previously called that in the BIP [1]).
>
> > The case for stable txids is less strong if we have APO (and therefore
> Eltoo).
>
> There's merit in using these factory constructs for Poon-Dryja channels
> even if Eltoo was available.
> I don't foresee Eltoo taking over the penalty approach entirely, but
> rather the two living side by side.
>
> (It could theoretically be possible to use APO to open Poon-Dryja
> channels on top of unstable funding txids, but having stable txids makes
> this much more easily integratable with existing lightning implementations,
> without the invasive changes that unstable txids would bring.)
>
> > This has been addressed over and over and over again. If a QC is able
> overnight to spend a large fraction of
> > the supply, your coins in your super non-QC-vulnerable-bare-CTV-covenant
> (that would eventually become
> > vulnerable when trying to use it) are worthless.
>
> It might be the case that a sufficient fraction of supply does switch over
> to QC-protected outputs in time, with only some small minority that didn't
> actively switch over *and* with revealed bare pubkeys losing their funds,
> which wouldn't make BTC entirely worthless. It makes sense not to want to
> be in that minority, ideally without requiring further time-sensitive
> active action (esp if considering long-term deep cold storage for
> inheritance etc).
>
> (This of course assumes a safe post-QC mechanism to later spend these
> funds; IIUC there are some viable approaches for that using a two-step
> spending procedure, where you prove knowledge of the pubkey/script preimage
> while commiting to a future tx.)
>
> > Sorry for being sarcastic, but at this point it's not fair to use
> quantum-computer FUD to justify the
> > activation of CTV over APO, or encourage the use of legacy transactions
> over Taproot ones.
>
> Sorry if it came off as FUDing. I don't know enough to hold a strong
> opinion on whether the fear of QCs is justified or not. I know that many
> people on this list don't think so, but I also think that this fear is
> prevalent enough to warrant taking it into consideration (at least for
> features that target long-term SoV use cases; less so for features
> targeted at L2 MoE applications like lightning spacechains paypools etc).
>
> > you can also use the internal key optimization .. you can't have
> NUMS-ness then
>
> Right, which makes this unsuitable for the vaulting use case.
>
> > Also, it's not 33 extra vbytes vs CTV-in-segwitv0, but 33 extra *
> witness units* (8.25 vbytes).
>
> Ugh yes sorry about that! I realized after hitting send and meant to
> clarify that it should've been s/vbyte/WU/ in my next reply.
>
> > Are APO signatures more expensive to verify? .. the cost for the
> network of validating signatures already exists today
>
> Not compared to existing signature verifications, but compared to a
> CTV/TXHASH-like construction.
>
> Can anyone quantify how much of a difference this makes in practice?
>
> > i appreciate your reply and your efforts to explore the tradeoffs
> between the two approaches.
>
> Thank you, I appreciate your efforts on this too :-)
>
> shesek
>
> [0]
> https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Batched_Channel_Creation
> [1] https://github.com/bitcoin/bips/pull/1273
>

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

[Nadav Ivgi via bitcoin-dev]

> This is *literally* what the post you are replying to is proposing to
solve.

I thought the changes mentioned in the OP (+ committing to the spent input
index) only solves the half-spend problem, but not the stable txids one?

There can be other inputs with a scriptSig, which doesn't get committed to
in the APO hash. I guess this isn't too common, but there might be some
cases where you would want to spend some (pre-selected) non-segwit inputs
alongside your covenant, maybe for fees. With CTV you would pre-commit to
the scriptSig which makes it non-malleable even if the script itself is.

> Hmm? You can't have channel factories without Eltoo. (Well, you can in
theory but good luck.)
> Maybe you are refering to non-interactive channel creation?

I was referring to what BIP 119 calls 'Batched Channel Creation' [0], which
is a sort of a channel factory construction under a broader definition (and
in fact was previously called that in the BIP [1]).

> The case for stable txids is less strong if we have APO (and therefore
Eltoo).

There's merit in using these factory constructs for Poon-Dryja channels
even if Eltoo was available.
I don't foresee Eltoo taking over the penalty approach entirely, but rather
the two living side by side.

(It could theoretically be possible to use APO to open Poon-Dryja channels
on top of unstable funding txids, but having stable txids makes this much
more easily integratable with existing lightning implementations, without
the invasive changes that unstable txids would bring.)

> This has been addressed over and over and over again. If a QC is able
overnight to spend a large fraction of
> the supply, your coins in your super non-QC-vulnerable-bare-CTV-covenant
(that would eventually become
> vulnerable when trying to use it) are worthless.

It might be the case that a sufficient fraction of supply does switch over
to QC-protected outputs in time, with only some small minority that didn't
actively switch over *and* with revealed bare pubkeys losing their funds,
which wouldn't make BTC entirely worthless. It makes sense not to want to
be in that minority, ideally without requiring further time-sensitive
active action (esp if considering long-term deep cold storage for
inheritance etc).

(This of course assumes a safe post-QC mechanism to later spend these
funds; IIUC there are some viable approaches for that using a two-step
spending procedure, where you prove knowledge of the pubkey/script preimage
while commiting to a future tx.)

> Sorry for being sarcastic, but at this point it's not fair to use
quantum-computer FUD to justify the
> activation of CTV over APO, or encourage the use of legacy transactions
over Taproot ones.

Sorry if it came off as FUDing. I don't know enough to hold a strong opinion
on whether the fear of QCs is justified or not. I know that many people on
this list don't think so, but I also think that this fear is prevalent
enough to warrant taking it into consideration (at least for features that
target long-term SoV use cases; less so for features targeted at L2 MoE
applications like lightning spacechains paypools etc).

> you can also use the internal key optimization .. you can't have
NUMS-ness then

Right, which makes this unsuitable for the vaulting use case.

> Also, it's not 33 extra vbytes vs CTV-in-segwitv0, but 33 extra * witness
units* (8.25 vbytes).

Ugh yes sorry about that! I realized after hitting send and meant to
clarify that it should've been s/vbyte/WU/ in my next reply.

> Are APO signatures more expensive to verify? .. the cost for the network
of validating signatures already exists today

Not compared to existing signature verifications, but compared to a
CTV/TXHASH-like construction.

Can anyone quantify how much of a difference this makes in practice?

> i appreciate your reply and your efforts to explore the tradeoffs between
the two approaches.

Thank you, I appreciate your efforts on this too :-)

shesek

[0]
https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Batched_Channel_Creation
[1] https://github.com/bitcoin/bips/pull/1273

On Fri, Apr 29, 2022 at 11:31 AM darosior  wrote:

> Hi Shesek,
>
> 1. The resulting txids are not stable.
>
>
> This is *literally* what the post you are replying to is proposing to
> solve.
>
>
> This property could be important for some of the proposed CTV use-cases,
> like channel factories.
>
>
> Hmm? You can't have channel factories without Eltoo. (Well, you can in
> theory but good luck.)
> Maybe you are refering to non-interactive channel creation? The case for
> stable txids is less strong if we
> have APO (and therefore Eltoo). [0]
>
>
> 2. APO will only be available on Taproot, which some people might prefer
> to avoid for long-term multi-decade vault storage due to QC concerns. (also
> see my previous post on this thread [0])
>
>
> This has been addressed over and over and over again. If a QC is able
> overnight to spend a large fraction of
> the supply, your coins in your super 

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

[Nadav Ivgi via bitcoin-dev]

Here's a summary of the trade-offs I see for using APO as a CTV alternative:

1. The resulting txids are not stable.

CTV commits to enough tx information such that given the txid:vout of the
covenant-encumbered output, you can predict the txid of the spending tx
permitted by CTV (and of the entire transaction graph descending from it).

This property could be important for some of the proposed CTV use-cases,
like channel factories.

2. APO will only be available on Taproot, which some people might prefer to
avoid for long-term multi-decade vault storage due to QC concerns. (also
see my previous post on this thread [0])

3. Higher witness satisfaction cost of roughly 3x vbytes vs CTV-in-Taproot
(plus 33 extra vbytes vs CTV-in-segwitv0 *in the case of a single CTV
branch*, for the taproot control block. with more branches CTV-in-taproot
eventually becomes preferable).

4. Higher network-wide full-node validation costs (checking a signature is
quite more expensive than hashing, and the hashing is done in both cases).

5. As APO is currently spec'd, it would suffer from the half-spend problem:
if you have multiple outputs encumbered under an APO covenant that requires
the same tx sigmsg hash, it becomes possible to spend all of them together
as multiple inputs in a single transaction and burn the extra to mining
fees.

If I'm not mistaken, I believe this makes the simple-apo-vault
implementation [1] vulnerable to spending multiple vaulted outputs of the
same denomination together and burning all but the first one. I asked the
author for a more definitive answer on twitter [2].

Fixing this requires amending BIP 118 with some new sigmsg flags (making
the ANYONECANPAY behaviour optional, as mentioned in the OP).

This is definitely possible but also means that APO as-is isn't a
CTV-replacement candidate, without first going through some more design and
review iterations.

shesek

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020326.html
[1] https://github.com/darosior/simple-anyprevout-vault
[2] https://twitter.com/shesek/status/1519874493434544128



On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I would like to know people's sentiment about doing (a very slightly
> tweaked version of) BIP118 in place of
> (or before doing) BIP119.
>
> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for
> over 6 years. It presents proven and
> implemented usecases, that are demanded and (please someone correct me if
> i'm wrong) more widely accepted than
> CTV's.
>
> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made
> optional [0], can emulate CTV just fine.
> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more
> expensive to use. But we can consider CTV
> an optimization of APO-AS covenants.
>
> CTV advocates have been presenting vaults as the flagship usecase.
> Although as someone who've been trying to
> implement practical vaults for the past 2 years i doubt CTV is necessary
> nor sufficient for this (but still
> useful!), using APO-AS covers it. And it's not a couple dozen more virtual
> bytes that are going to matter for
> a potential vault user.
>
> If after some time all of us who are currently dubious about CTV's stated
> usecases are proven wrong by onchain
> usage of a less efficient construction to achieve the same goal, we could
> roll-out CTV as an optimization.  In
> the meantime others will have been able to deploy new applications
> leveraging ANYPREVOUT (Eltoo, blind
> statechains, etc..[1]).
>
>
> Given the interest in, and demand for, both simple covenants and better
> offchain protocols it seems to me that
> BIP118 is a soft fork candidate that could benefit more (if not most of)
> Bitcoin users.
> Actually i'd also be interested in knowing if people would oppose the
> APO-AS part of BIP118, since it enables
> CTV's features, for the same reason they'd oppose BIP119.
>
>
> [0] That is, to not commit to the other inputs of the transaction (via
> `sha_sequences` and maybe also
> `sha_amounts`). Cf
> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
> .
>
> [1] https://anyprevout.xyz/ "Use Cases" section
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

[Nadav Ivgi via bitcoin-dev]

> The whole point of a wallet vault is that you can get the security of a
multisig wallet without having to sign using as many keys.

In my view, the point of a vault is the ability to keep your primary wallet
keys in *highly* deep cold storage (e.g. metal backup only, not loaded on
any HW wallets, with geographically distributed shares and a slow
cumbersome process for collecting them), which is made possible because
you're not supposed to actually need to use these keys, except for the
extraordinary (typically once or twice in a lifetime?) circumstances of
theft.

The user can then use a warmer model for the keys they use more frequently
for the covenant-encumbered two-step spending. But these warmer keys can
themselves also be cold and/or multi-sig, yet more accessible. For example,
a 2-of-2 with standard hardware wallets you have within reach in your
apartment.

So if you have a cold wallet that you anticipate having to access once
every, say, 2-3 months, no matter what scheme you currently use to secure
it, you can improve your overall security by using that same scheme for
securing the covenant-encumbered keys, then use a colder more secure scheme
for your primary keys under the assumption that you'll only have to access
them at most once every several years.

IIUC what you were describing is that you can use your regular multisig
scheme for the primary cold wallet keys, and a 1-of-1 for the
covenant-encumbered keys (which can even be hot on your phone etc).

Both approaches are valid, one gets you more security while the other gets
you more convenience. And there is of course a whole range of options that
can be chosen in between that gets you some of both.

shesek

On Wed, Apr 27, 2022 at 11:09 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> @Russell
> > OP_PUBKEY, and OP_PUBKEYHASH as wildcards
>
> Ah I see. Very interesting. Thanks for clarifying.
>
> @Nadav
> > You can have a CTV vault where the hot key signer is a multisig to get
> the advantages of both.
>
> Yes, you can create a CTV vault setup where you unvault to a multisig
> wallet, but you don't get the advantages of both. Rather you get none of
> the advantages and still have all the downsides you get with a multisig
> wallet. The whole point of a wallet vault is that you can get the security
> of a multisig wallet without having to sign using as many keys.
>
> On Mon, Apr 25, 2022 at 5:28 PM Russell O'Connor 
> wrote:
>
>> On Sun, Apr 24, 2022 at 7:04 PM Billy Tetrud 
>> wrote:
>>
>>> @Russel
>>> > the original MES vault .. commits to the destination address during
>>> unvaulting
>>>
>>> I see. Looking at the MES16 paper, OP_COV isn't described clearly enough
>>> for me to understand that it does that. However, I can imagine how it
>>> *might* do that.
>>>
>>> One possibility is that the intended destination is predetermined and
>>> hardcoded. This wouldn't be very useful, and also wouldn't be different
>>> than how CTV could do it, so I assume that isn't what you envisioned this
>>> doing.
>>>
>>> I can imagine instead that the definition of the pattern could be
>>> specified as a number indicating the number of stack items in the pattern,
>>> followed by that number of stack items. If that's how it is done, I can see
>>> the user inputting an intended destination script (corresponding to the
>>> intended destination address) which would then be somehow rotated in to the
>>> right spot within the pattern, allowing the pattern to specify the coins
>>> eventually reaching an address with that script. However, this could be
>>> quite cumbersome, and would require fully specifying the scripts along the
>>> covenant pathways leading to a fair amount of information duplication
>>> (since scripts must be specified both in the covenant and in spending the
>>> subsequent output). Both of these things would seem to make OP_COV in
>>> practice quite an expensive opcode to spend with. It also means that, since
>>> the transactor must fully specify the script, its not possible to take
>>> advantage of taproot's script hiding capabilities (were it to send to a
>>> taproot address).
>>>
>>
>> So my understanding is that the COV proposal in MES lets you check that
>> the output's scriptPubKey matches the corresponding script item from the
>> stack, but the script item's value additionally allows some wildcard
>> values.  In particular, it makes use of the otherwise reserved opcodes
>> OP_PUBKEY, and OP_PUBKEYHASH as wildcards representing any, let's say,
>> 32-byte or 20-byte push value.
>>
>> If you just used COV by itself, then these wildcards would be third-party
>> malleable, but you also have to sign the transaction with the hot wallet
>> key, which removes the malleability.
>>
>> No need to rotate anything into place.
>>
>> I hope this makes sense.
>>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> 

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

[Nadav Ivgi via bitcoin-dev]

Back in the 2017 block size wars I brought up the idea [0] of using
time-locked-weighted voting as a mechanism to gauge community/hodler
sentiment (lived on testnet for awhile at https://hodl.voting [1]).

Basically, the user locks up some bitcoins with an OP_CSV while committing
to some statement (using a pay-to-contract-hash construct in my
implementation[2]). Votes are then weighted as  x .

This has some interesting advantages over the more naive coin weighting
scheme used at the time (Bitcoinocracy [3]):

1. There's a real cost attached to voting, in the form of lost liquidity
and losing the ability to sell. The handicap principle suggests that this
makes for more reliable signaling, getting people to put more thought and
consideration into their vote (and whether they really care/know enough
about the issue to vote on it at all).
2. It shows that the voter has a long-term interest in the value of bitcoin
(and stands to lose if bitcoin is harmed), and gives more influence to
long-term hodlers that possess strong confidence in bitcoin.
3. Custodians don't get disproportionate voting power with their customers'
funds (not without getting themselves into fractional reserve, at least).
5. Selling your vote if you're disinterested in the outcome isn't a
no-brainer like in the naive scheme.

A drawback is that in a chain-split scenario, you cannot use these bitcoins
to influence the markets (participate in futures markets, sell the side of
the split you want to see die off etc). But some people might not agree to
lose self-custody over their coins in order to do that, while with
time-weighted voting they can retain full self-custody. Or maybe they're
only willing to risk some X% on centralized futures markets, and still have
aside some Y% to allocate for timelocking.

To clarify, I don't really see this as 'voting' despite calling it that.
I'm definitely not advocating to use this as some authoritative
decision-making voting mechanism or as part of an activation mechanism,
only possibly as one more market signal to look at among many.

As for the proposal in the OP, it could be argued that mining fees are not
a highly reliable signal because users have to pay them anyway when
transacting, which makes the voting itself zero-cost (perhaps except for
waiting some more time to get it confirmed?). And as others have mentioned,
this gives influence primarily to transactors (the tx volume by exchanges
and payment processors easily eclipses that of end users) and not to
hodlers (while my idea does the exact opposite, so maybe makes sense to use
both?).

shesek

[0]
https://bitcoinmagazine.com/markets/hodlvoting-voting-your-bitcoins-better
[1] http://web.archive.org/web/20170710161455/https://hodl.voting/
[2] https://github.com/shesek/proof-of-hodl (hackathon grade code)
[3] Seems like a version of it now lives at
https://bitcoinocracy.herokuapp.com/

On Tue, Apr 26, 2022 at 11:12 PM Keagan McClelland via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> Alongside the debate with CTV right now there's a second debate that was
> not fully hashed out in the activation of Taproot. There is a lot of
> argument around what Speedy Trial is or isn't, what BIP8 T/F is or isn't
> etc. A significant reason for the breakdown in civility around this debate
> is that because we don't have a means of measuring user support for
> proposed sof-fork changes, it invariably devolves into people claiming that
> their circles support/reject a proposal, AND that their circles are more
> broadly representative of the set of Bitcoin users as a whole.
>
> It seems everyone in this forum has at one point or another said "I would
> support activation of  if there was consensus on it, but there isn't".
> This statement, in order to be true, requires that there exist a set of
> conditions that would convince you that there is consensus. People have
> tried to dodge this question by saying "it's obvious", but the reality is
> that it fundamentally isn't. My bubble has a different "obvious" answer
> than any of yours.
>
> Secondly, due to the trauma of the block size wars, no one wants to utter
> a statement that could imply that miners have any influence over what
> rulesets get activated or don't. As such "miner signaling" is consistently
> devalued as a signal for market demand. I don't think this is reasonable
> since following the events of '17  miners are aware that they have the
> strong incentive that they understand market demand. Nevertheless, as it
> stands right now the only signal we have to work with is miner signaling,
> which I think is rightly frustrating to a lot of people.
>
> So how can we measure User Support for a proposed rule change?
>
> I've had this idea floating around in the back of my head for a while, and
> I'd like to solicit some feedback here. Currently, all forms of activation
> that are under consideration involve miner signaling in one form or
> another. What if we could make it 

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

[Nadav Ivgi via bitcoin-dev]

On Mon, Apr 25, 2022 at 1:36 PM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If you unvault an output to your hot wallet, the thief could be lying in
wait, ready to steal those funds upon them landing.

One way to mitigate some of the risk is to split up your UTXOs so that your
hot wallet exposure is limited.

> However, if you compare it against a multisig wallet (eg 2 of 3), you can
see that while theft of a single key would never result in any theft in
that setup, it could in a CTV vault.

These are two orthogonal things though. You can have a CTV vault where the
hot key signer is a multisig to get the advantages of both. In this case
the addition of a CTV-based unvaulting procedure is an improvement compared
to not using it.

shesek

On Mon, Apr 25, 2022 at 1:36 PM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> @Matt
> >  both of which are somewhat frustrating limitations, but not security
> limitations, only practical ones.
>
> So I think the first limitation you mentioned (that if your hot wallet's
> key gets stolen you need) can be legitimately considered a security
> limitation. Not because you need to rotate your keys, but because you might
> *not know* your hot wallet key has been stolen. If you unvault an output to
> your hot wallet, the thief could be lying in wait, ready to steal those
> funds upon them landing. At that point, you would then know your hot wallet
> key was compromised and could rotate your vault keys in order to prevent
> further theft. However, the fact that there is a clear theft vulnerability
> is something I would say should be considered a "security limitation".
>
> As you mentioned, this is of course also a security limitation of a hot
> wallet, so this setup definitely has a lot of advantages over a simple hot
> wallet. However, if you compare it against a multisig wallet (eg 2 of 3),
> you can see that while theft of a single key would never result in any
> theft in that setup, it could in a CTV vault. The other trade offs there
> are ones of practicality and convenience.
>
> This isn't to say a CTV vault wouldn't be useful. Just that it has
> significant trade offs.
>
> @Russel
> > the original MES vault .. commits to the destination address during
> unvaulting
>
> I see. Looking at the MES16 paper, OP_COV isn't described clearly enough
> for me to understand that it does that. However, I can imagine how it
> *might* do that.
>
> One possibility is that the intended destination is predetermined and
> hardcoded. This wouldn't be very useful, and also wouldn't be different
> than how CTV could do it, so I assume that isn't what you envisioned this
> doing.
>
> I can imagine instead that the definition of the pattern could be
> specified as a number indicating the number of stack items in the pattern,
> followed by that number of stack items. If that's how it is done, I can see
> the user inputting an intended destination script (corresponding to the
> intended destination address) which would then be somehow rotated in to the
> right spot within the pattern, allowing the pattern to specify the coins
> eventually reaching an address with that script. However, this could be
> quite cumbersome, and would require fully specifying the scripts along the
> covenant pathways leading to a fair amount of information duplication
> (since scripts must be specified both in the covenant and in spending the
> subsequent output). Both of these things would seem to make OP_COV in
> practice quite an expensive opcode to spend with. It also means that, since
> the transactor must fully specify the script, its not possible to take
> advantage of taproot's script hiding capabilities (were it to send to a
> taproot address).
>
> However, my assumptions might be incorrect. If you think OP_COV would be a
> useful opcode, I would encourage you to write up a complete specification.
>
> > What ways can we build a secured vault that commits to the destination
> address?
>
> Some kind of passed-through state allows doing this. With OP_COV (if my
> assumptions above are correct), the intended destination can be passed
> through the output script pattern(s). With my own proposed
> op_pushoutputstack
> ,
> state is passed as an attachment on the output more directly. Curious what
> you think about that proposal.
>
> > Are there elegant ways of building secure vaults by using CTV plus
> something else.
>
> Since CTV predefines all the transactions that can happen under its
> control, passed state like this can't help because any dynamic state would
> change the template and render the CTV transaction invalid. I don't see any
> way of solving this problem for CTV.
>
> I'm curious how you think op_cat could enable this with CTV (other than
> the cat+schnorr tricks that don't require CTV at all).
>
>
>
> On Sat, Apr 23, 2022 at 2:31 PM 

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

[Nadav Ivgi via bitcoin-dev]

darosior via bitcoin-dev wrote:
> i doubt CTV is necessary nor sufficient for this

I would be interested to hear more on this.

Is it not necessary because you can exchange and store pre-signed
transactions instead?

What purpose is it not sufficient for? There are some vault designs out
there that are able to achieve interesting properties with CTV, like James
O'Beirne's simple-ctv-vault:

https://github.com/jamesob/simple-ctv-vault
(the basic design expressed in Minsc:
https://min.sc/nextc/#gist=001cf1fcb0e24ca9f3614c4db9bfe57d:4)

On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I would like to know people's sentiment about doing (a very slightly
> tweaked version of) BIP118 in place of
> (or before doing) BIP119.
>
> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for
> over 6 years. It presents proven and
> implemented usecases, that are demanded and (please someone correct me if
> i'm wrong) more widely accepted than
> CTV's.
>
> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made
> optional [0], can emulate CTV just fine.
> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more
> expensive to use. But we can consider CTV
> an optimization of APO-AS covenants.
>
> CTV advocates have been presenting vaults as the flagship usecase.
> Although as someone who've been trying to
> implement practical vaults for the past 2 years i doubt CTV is necessary
> nor sufficient for this (but still
> useful!), using APO-AS covers it. And it's not a couple dozen more virtual
> bytes that are going to matter for
> a potential vault user.
>
> If after some time all of us who are currently dubious about CTV's stated
> usecases are proven wrong by onchain
> usage of a less efficient construction to achieve the same goal, we could
> roll-out CTV as an optimization.  In
> the meantime others will have been able to deploy new applications
> leveraging ANYPREVOUT (Eltoo, blind
> statechains, etc..[1]).
>
>
> Given the interest in, and demand for, both simple covenants and better
> offchain protocols it seems to me that
> BIP118 is a soft fork candidate that could benefit more (if not most of)
> Bitcoin users.
> Actually i'd also be interested in knowing if people would oppose the
> APO-AS part of BIP118, since it enables
> CTV's features, for the same reason they'd oppose BIP119.
>
>
> [0] That is, to not commit to the other inputs of the transaction (via
> `sha_sequences` and maybe also
> `sha_amounts`). Cf
> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
> .
>
> [1] https://anyprevout.xyz/ "Use Cases" section
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Nadav Ivgi via bitcoin-dev]

darosior via bitcoin-dev wrote:

> CTV advocates have been presenting vaults as the flagship usecase.
Although as someone who've been trying to
> implement practical vaults for the past 2 years i doubt CTV is necessary
nor sufficient for this (but still
> useful!), using APO-AS covers it. And it's not a couple dozen more
virtual bytes that are going to matter for
> a potential vault user.

Some potential vault users looking to store funds for long time periods
(say of decades) might have quantumphobia and prefer to avoid Taproot for
that reason.

One of the arguments presented for not using pubkey hashes in Taproot is
that quantumphobic people could choose to continue using non-Taproot
outputs. Making a feature that's targeted for long-term cold-storage vaults
available on Taproot only might be less ideal in that view.

Cheers
shesek

On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I would like to know people's sentiment about doing (a very slightly
> tweaked version of) BIP118 in place of
> (or before doing) BIP119.
>
> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for
> over 6 years. It presents proven and
> implemented usecases, that are demanded and (please someone correct me if
> i'm wrong) more widely accepted than
> CTV's.
>
> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made
> optional [0], can emulate CTV just fine.
> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more
> expensive to use. But we can consider CTV
> an optimization of APO-AS covenants.
>
> CTV advocates have been presenting vaults as the flagship usecase.
> Although as someone who've been trying to
> implement practical vaults for the past 2 years i doubt CTV is necessary
> nor sufficient for this (but still
> useful!), using APO-AS covers it. And it's not a couple dozen more virtual
> bytes that are going to matter for
> a potential vault user.
>
> If after some time all of us who are currently dubious about CTV's stated
> usecases are proven wrong by onchain
> usage of a less efficient construction to achieve the same goal, we could
> roll-out CTV as an optimization.  In
> the meantime others will have been able to deploy new applications
> leveraging ANYPREVOUT (Eltoo, blind
> statechains, etc..[1]).
>
>
> Given the interest in, and demand for, both simple covenants and better
> offchain protocols it seems to me that
> BIP118 is a soft fork candidate that could benefit more (if not most of)
> Bitcoin users.
> Actually i'd also be interested in knowing if people would oppose the
> APO-AS part of BIP118, since it enables
> CTV's features, for the same reason they'd oppose BIP119.
>
>
> [0] That is, to not commit to the other inputs of the transaction (via
> `sha_sequences` and maybe also
> `sha_amounts`). Cf
> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
> .
>
> [1] https://anyprevout.xyz/ "Use Cases" section
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CTV Signet Parameters

[Nadav Ivgi via bitcoin-dev]

> nobody's going to benefit from that possibility anyway.

 James O'Beirne's simple-ctv-vault appears to be using bare CTV outputs:

https://github.com/jamesob/simple-ctv-vault/blob/7dd6c4ca25debb2140cdefb79b302c65d1b24937/main.py#L217-L218
https://github.com/jamesob/simple-ctv-vault/blob/7dd6c4ca25debb2140cdefb79b302c65d1b24937/main.py#L324-L325

I guess this suggests that it was not tested on signet?

On Fri, Apr 22, 2022 at 3:58 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Apr 21, 2022 at 10:05:20AM -0500, Jeremy Rubin via bitcoin-dev
> wrote:
> > I can probably make some show up sometime soon. Note that James' vault
> uses
> > one at the top-level https://github.com/jamesob/simple-ctv-vault, but I
> > think the second use of it (since it's not segwit wrapped) wouldn't be
> > broadcastable since it's nonstandard.
>
> The whole point of testing is so that bugs like "wouldn't be broadcastable
> since it's nonstandard" get fixed. If these things are still in the
> "interesting thought experiment" stage, but nobody but Jeremy is
> interested enough to start making them consistent with the proposed
> consensus and policy rules, it seems very premature to be changing
> consensus or policy rules.
>
> > One case where you actually use less space is if you have a few different
> > sets of customers at N different fee priority level. Then, you might need
> > to have N independent batches, or risk overpaying against the customer's
> > priority level. Imagine I have 100 tier 1 customers and 1000 tier 2
> > customers. If I batcher tier 1 with tier 2, to provide tier 1 guarantees
> > I'd need to pay tier 1 rate for 10x the customers. With CTV, I can
> combine
> > my batch into a root and N batch outputs. This eliminates the need for
> > inputs, signatures, change outputs, etc per batch, and can be slightly
> > smaller. Since the marginal benefit on that is still pretty small, having
> > bare CTV improves the margin of byte wise saving.
>
> Bare CTV only saves bytes when *spending* -- but this is when you're
> creating the 1100 outputs, so an extra 34 or 67 bytes of witness data
> seems fairly immaterial (0.05% extra vbytes?). It doesn't make the small
> commitment tx any smaller.
>
> ie, scriptPubKey looks like:
>  - bare ctv: [push][32 bytes][op_nop4]
>  - p2wsh: [op_0][push][32 bytes]
>  - p2tr: [op_1][push][32 bytes]
>
> while witness data looks like:
>  - bare ctv: empty scriptSig, no witness
>  - pw2sh: empty scriptSig, witness = "[push][32 bytes][op_nop4]"
>  - p2tr: empty scriptSig, witness = 33B control block,
>  "[push][32 bytes][op_nop4]"
>
> You might get more a benefit from bare ctv if you don't pay all 1100
> outputs in a single tx when fees go lower; but if so, you're also wasting
> quite a bit more block space in that case due to the intermediate
> transactions you're introducing, which makes it seem unlikely that
> you care about the extra 9 or 17 vbytes bare CTV would save you per
> intermediate tx...
>
> I admit that I am inclined towards micro-optimising things to save
> those bytes if it's easy, which does incline me towards bare CTV; but
> the closest thing we have to real user data suggests that nobody's going
> to benefit from that possibility anyway.
>
> > Even if we got rid of bare ctv, segwit v0 CTV would still exist, so we
> > couldn't use OP_SUCCESSx there either. segwitv0 might be desired if
> someone
> > has e.g. hardware modules or MPC Threshold Crypto that only support ECDSA
> > signatures, but still want CTV.
>
> If you desire new features, then you might have to upgrade old hardware
> that can't support them.
>
> Otherwise that would be an argument to never use OP_SUCCESSx: someone
> might want to use whatever new feature we might imagine on hardware that
> only supports ECDSA signatures.
>
> Cheers,
> aj
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CTV Signet Parameters

[Nadav Ivgi via bitcoin-dev]

> I didn't think DROP/1 is necessary here? Doesn't leaving the 32 byte hash
on the stack evaluate as true?

Not with Taproot's CLEANSTACK rule. It can make sense to always use `DROP
OP_1` even outside of Taproot, just to keep things consistent and to avoid
potential errors when switching from non-Taproot to Taproot. FWIW that's
what I found myself doing when playing with CTV in P2WSH

On Wed, Apr 20, 2022 at 5:31 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Feb 17, 2022 at 01:58:38PM -0800, Jeremy Rubin via bitcoin-dev
> wrote:
> > AJ Wrote (in another thread):
> > >   I'd much rather see some real
> > >   third-party experimentation *somewhere* public first, and Jeremy's
> CTV
> > >   signet being completely empty seems like a bad sign to me.
>
> There's now been some 2,200 txs on CTV signet, of which (if I haven't
> missed anything) 317 have been CTV spends:
>
>  - none have been bare CTV (ie, CTV in scriptPubKey directly, not via
>p2sh/p2wsh/taproot)
>
>  - none have been via p2sh
>
>  - 3 have been via taproot:
>
> https://explorer.ctvsignet.com/tx/f73f4671c6ee2bdc8da597f843b2291ca539722a168e8f6b68143b8c157bee20
>
> https://explorer.ctvsignet.com/tx/7e4ade977db94117f2d7a71541d87724ccdad91fa710264206bb87ae1314c796
>
> https://explorer.ctvsignet.com/tx/e05d828bf716effc65b00ae8b826213706c216b930aff194f1fb2fca045f7f11
>
>The first two of these had alternative merkle paths, the last didn't.
>
>  - 314 have been via p2wsh
>
> https://explorer.ctvsignet.com/tx/62292138c2f55713c3c161bd7ab36c7212362b648cf3f054315853a081f5808e
>(don't think there's any meaningfully different examples?)
>
> As far as I can see, all the scripts take the form:
>
>   [PUSH 32 bytes] [OP_NOP4] [OP_DROP] [OP_1]
>
> (I didn't think DROP/1 is necessary here? Doesn't leaving the 32 byte
> hash on the stack evaluate as true? I guess that means everyone's using
> sapio to construct the txs?)
>
> I don't think there's any demos of jamesob's simple-ctv-vault [0], which
> I think uses a p2wsh of "IF n CSV DROP hotkey CHECKSIG ELSE lockcoldtx CTV
> ENDIF", rather than taproot branches.
>
> [0] https://github.com/jamesob/simple-ctv-vault
>
> Likewise I don't think there's any examples of "this CTV immediately;
> or if fees are too high, this other CTV that pays more fees after X
> days", though potentially they could be hidden in the untaken taproot
> merkle branches.
>
> I don't think there's any examples of two CTV outputs being combined
> and spent in a single transaction.
>
> I don't see any txs with nSequence set meaningfully; though most (all?)
> of the CTV spends seem to set nSequence to 0x0040 which I think
> doesn't have a different effect from 0xfffe?
>
> That looks to me like there's still not much practical (vs theoretical)
> exploration of CTV going on; but perhaps it's an indication that CTV
> could be substantially simplified and still get all the benefits that
> people are particularly eager for.
>
> > I am unsure that "learning in public" is required --
>
> For a consensus system, part of the learning is "this doesn't seem that
> interesting to me; is it actually valuable enough to others that the
> change is worth the risk it imposes on me?" and that's not something
> you can do purely in private.
>
> One challenge with building a soft fork is that people don't want to
> commit to spending time building something that relies on consensus
> features and run the risk that they might never get deployed. But the
> reverse of that is also a concern: you don't want to deploy consensus
> changes and run the risk that they won't actually turn out to be useful.
>
> Or, perhaps, to "meme-ify" it -- part of the "proof of work" for deploying
> a consensus change is actually proving that it's going to be useful.
> Like sha256 hashing, that does require real work, and it might turn out
> to be wasteful.
>
> Cheers,
> aj
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Nadav Ivgi via bitcoin-dev]

Having large portions of the network using a different minrelayfee could
make it easier to reliably get different parts of the network to accept
different conflicting transactions into their mempools, which could
potentially be used to double-spend unconfirmed non-rbf transactions with
more ease. Node operators that accept unconfirmed payments with a
minrelayfee that's higher than what other nodes/miners are typically
accepting would be at risk.

Relying on unconfirmed transactions is of course discouraged so I'm not
sure how much weight this should be given if at all, but I thought it was
at least worth bringing up.

Nadav


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

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

[bitcoin-dev] Minsc, a Miniscript-based scripting language

[Nadav Ivgi via bitcoin-dev]

Hi all,

I recently released Minsc, a high-level scripting language for expressing
Bitcoin Script spending conditions using a simple and familiar syntax.

Minsc is based on the Miniscript Policy language, with additional features
and syntactic sugar sprinkled on top, including variables, functions, infix
notation, human-readable times and more.

A live compiler (Minsc->Policy->Miniscript->Script) and documentation are
available on the website: https://min.sc

Source code (in Rust) is available on github:
https://github.com/shesek/minsc

Some example Minsc scripts:

- A user and a 2FA service need to sign off, but after 90 days the user
alone is enough

  pk(user_pk) && (9@pk(service_pk) || older(90 days))

- Traditional preimage-based HTLC

  $redeem = pk(A) && sha256(H);
  $refund = pk(B) && older(10);

  likely@$redeem || $refund

- Liquid-like federated pegin with emergency recovery keys

  $federation = 4 of [ pk(A), pk(B), pk(C), pk(D), pk(E) ];
  $recovery = 2 of [ pk(F), pk(G), pk(H) ];
  $timeout = older(heightwise 2 weeks);

  likely@$federation || ($timeout && $recovery)

- The BOLT #3 received HTLC policy

  fn htlc_received($revoke_pk, $local_pk, $remote_pk, $secret, $delay) {
$success = pk($local_pk) && hash160($secret);
$timeout = older($delay);

pk($revoke_pk) || (pk($remote_pk) && ($success || $timeout))
  }

  htlc_received(A, B, C, H, 3 hours)

- 2FA where the user has a 2-of-2 setup and the service provider is a
3-of-4 federation

  fn two_factor($user, $provider, $delay) =
$user && (likely@$provider || older($delay));

  $user = pk(user_desktop) && pk(user_mobile);
  $providers = [ pk(P1), pk(P2), pk(P3), pk(P4) ];

  two_factor($user, 3 of $providers, 4 months)

- Easily add NSA backdoors to everything ️

  _backdoor=pk(usgovt), _pk=pk, _older=older, _after=after,
  _sha256=sha256, _ripemd160=ripemd160;

  fn pk(x) = _pk(x) || _backdoor;
  fn older(x) = _older(x) || _backdoor;
  fn after(x) = _after(x) || _backdoor;
  fn sha256(x) = _sha256(x) || _backdoor;
  fn ripemd160(x) = _ripemd160(x) || _backdoor;

  (pk(A) && sha256(H)) || (pk(B) && older(10))

Feedback is appreciated!

Nadav

P.S Since every Miniscript Policy is also a valid Minsc expression, the
min.sc web code editor UI could also be useful for experimenting with bare
policies. You'll get syntax highlighting, parentheses matching, real-time
compilation (in a web worker so the browser doesn't freeze) and syntax
error reporting.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] MAD-HTLC

[Nadav Ivgi via bitcoin-dev]

Hi ZmnSCPxj,

You are of course correct. I had considered the effect of reorgs, but the
email seemed to be getting too lengthy to mention that too.

You would need a few spare blocks in which Bob won't be accused of bribery
as a safety margin, which does reduce the time frame in which Alice can get
her transaction confirmed in order to have a valid bribery fraud. This
seems workable if the time frame was long enough (over a few hours should
be sufficient, assuming we consider reorgs of over 3-4 blocks to be
unlikely), but could indeed be problematic if the time frame is already
short to begin with.

Nadav

On Thu, Jun 25, 2020 at 7:04 AM ZmnSCPxj  wrote:

> Good morning Nadav,
>
> > > I and some number of Lightning devs consider this to be sufficient
> disincentive to Bob not attacking in the first place.
> >
> > An additional disincentive could be introduced in the form of bribery
> proofs for failed attempts.
> >
> > If we assume that "honest" users of the LN protocol won't reveal their
> timelocked transactions before reaching the timelock expiry (they shouldn't
> anyway because standard full node implementations won't relay them), we can
> prove that Bob attempted bribery and failed to an outside observer by
> showing Bob's signed timelocked transaction, spending an output that was in
> reality spent by a different transaction prior to the locktime expiry,
> which should not be possible if Bob had waited.
>
>
> Unfortunately this could be subject to an inversion of this attack.
>
> Alice can wait for the timelock to expire, then bribe miners to prevent
> confirmation of the Bob timelocked transaction, getting the Alice
> hashlocked transaction confirmed.
>
> Now of course you do mention "prior to the locktime expiry" but there is
> now risk at around locktime.
>
> Particularly, "natural" orphaned blocks and short-term chainsplits can
> exist.
> Bob might see that the locktime has arrived and broadcast the signed
> timelocked transaction, then Alice sees the locktime has not yet arrived
> (due to short-term chainsplits/propagation delays) and broadcast the signed
> hashlocked transaction, then in the end the Alice side of the short-term
> chainsplit is what solidifies into reality due to random chance on which
> miner wins which block.
> Then Bob can now be accused of bribery, even though it acted innocently;
> it broadcasted the timelock branch due to a natural chainsplit but Alice
> hashlocked branch got confirmed.
>
> Additional complications can be added on top to help mitigate this edge
> case but more complex == worse in general.
> For example it could "prior to locktime expiry" can ignore a few blocks
> before the actual timelock, but this might allow Bob to mount the attack by
> initiating its bribery behavior earlier by those few blocks.
>
> Finally, serious attackers would just use new pseudonyms, the important
> thing is to make pseudonyms valuable and costly to lose, so it is
> considered sufficient that LN nodes need to have some commitment to the LN
> in the form of actual channels (which are valuable, potentially
> money-earning constructs, and costly to set up).
>
> Other HTLC-using systems, such as the "SwapMarket" being proposed by Chris
> Belcher, could use similar disincentivizing; I know Chris is planning a
> fidelity bond system for SwapMarket makers, for example, which would mimic
> the properties of LN channels (costly to set up, money-earning).
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] MAD-HTLC

[Nadav Ivgi via bitcoin-dev]

> I and some number of Lightning devs consider this to be sufficient
disincentive to Bob not attacking in the first place.

An additional disincentive could be introduced in the form of bribery
proofs for failed attempts.

If we assume that "honest" users of the LN protocol won't reveal their
timelocked transactions before reaching the timelock expiry (they shouldn't
anyway because standard full node implementations won't relay them), we can
prove that Bob attempted bribery and failed to an outside observer by
showing Bob's signed timelocked transaction, spending an output that was in
reality spent by a different transaction prior to the locktime expiry,
which should not be possible if Bob had waited.

These proofs would be gossiped, and lightning network participants could
choose not to peer with Bob when they see them. This might require some
sort of a scoring/reputation scheme that makes it harder for Bob to attack
with new throw-away identities to be effective. (i.e. limiting your
exposure to peers to some BTC amount based on their historical public
channels records, using fidelity bonds, etc.)

Bob could still send these bribery transactions privately to selected
miners, but not making them public would greatly reduce the participating
miners' confidence that there is enough participating hashpower for the
attack to be profitable.

Nadav

On Thu, Jun 25, 2020 at 4:38 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Stanga et al,
>
>
> > > Hi ZmnSCPxj,
> > >
> > > Thank you for taking the time to respond, these are very good points.
> Responses inline.
> > >
> > > On Tue, Jun 23, 2020 at 12:48 PM ZmnSCPxj 
> wrote:
> > >
> > > > Good morning Itay, Ittay, and Matan,
> > > >
> > > > I believe an unstated assumption in Bitcoin is that miners are
> short-sighted.
> > > >
> > > > The reasoning for this assumption is:
> > > >
> > > > * Deployment of new mining hardware controlled by others may occur
> at any time you do not control.
> > > >   * Thus, any transactions you leave on the table are potentially
> taken by somebody else and not by you.
> > > >   * Sudden changes in hashpower distribution may reduce your
> expected future earnings, so any future theoretical earnings should be
> discounted (*in addition to* expected return-on-investment on getting money
> you can invest *now*).
> > >
> > > Our analysis assumes constant difficulty, i.e., no significant changes
> of the miners set. Indeed, hash-rate changes typically occur at a much
> larger granularity than your average HTLC timeout. For instance, we noticed
> plenty of lightning nodes use timeouts of a day. So, we do not consider
> optimization at infinity, just a day ahead, and within this time frame all
> the factors you mentioned are not expected to dramatically change.
> > >
> > > That being said, it would be interesting to analyze the effect of
> miners joining during the HTLC duration. Intuitively, this shouldn’t affect
> the results, as those new miners have the same incentive to wait for the
> higher-paying tx.
>
> We already know that hashrate tends to trend upwards, and that we do not
> expect hashrate to fall except for occasional transients.
>
> The expectation is not that new miners have different incentives.
> Instead, the expectation is that current miners discount future possible
> gains because in the future, they expect to have less hashrate share than
> right now.
>
> The only trustless way for Bob to bribe miners into deferring Alice tx is
> to attach the bribe to the future confirmation of the Bob tx, thus Bob is
> offering future-coins, not present-coins like Alice can offer, and the fact
> that miners expect an overall uptrend in total hashrate (leading to an
> overall downtrend in their hashrate share) means that miners discount the
> Bob offered future-coins.
> The discounting is proportional to the time delay involved, as a larger
> delay implies greater reduction in hashrate share.
>
> This discounting is, again, *in addition to* natural discounting a.k.a. "I
> will gladly pay you Thursday for a hamburger today", the hamburger seller
> will want some pretty stiff assurances plus a bigger payment on Thursday
> for giving you a hamburger today, due to expected returns on investment.
>
>
> > >
> > >
> > > > It also strikes me that, in a world with RBF and CPFP, the same
> endpoint (i.e. miners earn the entire fund of the HTLC) is achieved by
> existing HTLCs, without the additional branch and script opcodes needed by
> MAD-HTLC.
> > > > For example, if an HTLC is confirmed but the hashlock-claiming
> transaction is not being confirmed (because miners are holding it up
> because Bob is offering a much higher fee in the future for the
> timelock-claiming transaction), then Alice can, regardless of the reason
> why it is not being confirmed, bump up the fee with RBF or CPFP.
> > > >
> > > > If the fee bump offered by Alice is sufficiently large, then miners
> will start re-preferring 

Re: [bitcoin-dev] Announcing Bitcoin Wallet Tracker

[Nadav Ivgi via bitcoin-dev]

Hi Antoine,

I designed both APIs, so they definitely do share some similarities.

It's difficult to compare their performance directly, since
esplora-electrs keeps a full index of everything, while bwt tracks
your wallet addresses only.

If you're only interested in your wallet addresses and don't have a
*really* huge number of them, bwt will definitely perform better, as
it can avoid a lot of unnecessary indexing work. If you do have a lot
of addresses, esplora-electrs will be better suited for the job, as
its designed to deal with high volumes of data and does not rely on
the bitcoind wallet functionality, which was not designed for this.

I'm not sure where the line for "really huge" crosses exactly though,
I have not put this to the test. Definitely if you're tracking
millions of addresses, probably also for hundreds of thousands,
possibly even less?

API design wise, the main differences between the two are:

- Esplora provides every bit of information one might want to know
about transactions/blocks, while bwt intentionally tries to reduce
this to the subset useful in the context of app development.

- bwt provides wallet-contextual information, like key origins next to
addresses and the net change inflicted on the wallet's balance by
transactions.

- Esplora doesn't provide real-time updates (yet), while bwt provides
them using two different mechanisms (SSE and Web Hooks).

Nadav



On Sun, May 31, 2020 at 5:56 PM darosior  wrote:
>
> Hi,
>
> I gave a quick look to the http API, and it seems very similar to Esplora's. 
> So I wonder : how does
> bwt compares to Esplora, performance-wise ?
>
> Thanks!
> Antoine
>
>
> ‐‐‐ Original Message ‐‐‐
> Le samedi, mai 30, 2020 4:16 PM, Nadav Ivgi via bitcoin-dev 
>  a écrit :
>
> Hi all,
>
> I recently released bwt [0], an HD wallet indexer implemented in Rust, using
> a model similar to that of Electrum Personal Server.
>
> It uses the bitcoind wallet functionality to do the heavy lifting and builds
> additional indexes on top of that, which can be queried using the Electrum
> RPC protocol, as well as a more modern, developer-friendly HTTP REST API.
>
> The electrum server can also be used as an electrum plugin [1], which
> integrates the server straight into the electrum client. From the user's
> perspective, this allows connecting electrum directly to a full node.
>
> The HTTP API is my take on a modern design for a wallet tracking API aimed
> at app developers. Some use-cases include using it as a backend for wallets
> (similarly to Samuari's Dojo) or to track deposits to a watch-only xpub
> (similarly to BTCPay's NBXplorer).
>
> Compared to using the bitcoind RPC directly, bwt provides:
>
> - The ability to track an xpub and automatically have new addresses derived
>   and imported as needed, according to the gap limit.
>
> - Two additional indexes, one for looking up the transaction history of
>   addresses, and another one for looking up txo spends (a map of
>   funding_txid:vout => spending_txid:vin).
>
> - Real-time updates using Server-Sent Events [2] (a long-lived streaming HTTP
>   connection) or Web Hooks [3] (an HTTP request sent to a configured URL).
>   The updates being sent [4] directly provide information about the funded
>   and spent wallet txos, instead of the client figuring it out from the tx.
>
> - Some API conveniences and simplifications, like including key origin
>   information directly alongside inputs/outputs [5], the ability to specify
>   key origins in place of addresses (eg. GET /hd/15cb9edc/8/utxos), a compact
>   history format [6], and an easy way to catch-up with missed events [7].
>   Unless explicitly asked for, the API omits information about non-wallet
>   inputs/outputs and protocol-level details like scriptsig and witnesses,
>   which are typically not needed for higher-level app development.
>
> The indexer is designed in a way that minimizes RPC requests to bitcoind. By
> using labels to store key origin information, it is able to index incoming
> transactions using the information available from `listtransactions` alone
> (plus 3 extra rpc requests that don't grow with the number of transactions),
> but requires 1 additional rpc call per outgoing transaction (to learn which
> prevouts were spent). It can index 10k incoming txs in under a second, or a
> mixture of 5k/5k in under 5 seconds. The index is currently entirely in-
> memory and does not get persisted. The indexer logic can be seen in [8].
>
> One major item on the roadmap that I'm hoping to tackle soon is support for
> output script descriptors.
>
> If anyone is interested in contributing, the README has some useful developer
> resources [9] and a handy script for setting up a development environment.
>
> This is an earl

[bitcoin-dev] Announcing Bitcoin Wallet Tracker

[Nadav Ivgi via bitcoin-dev]

Hi all,

I recently released bwt [0], an HD wallet indexer implemented in Rust, using
a model similar to that of Electrum Personal Server.

It uses the bitcoind wallet functionality to do the heavy lifting and builds
additional indexes on top of that, which can be queried using the Electrum
RPC protocol, as well as a more modern, developer-friendly HTTP REST API.

The electrum server can also be used as an electrum plugin [1], which
integrates the server straight into the electrum client. From the user's
perspective, this allows connecting electrum directly to a full node.

The HTTP API is my take on a modern design for a wallet tracking API aimed
at app developers. Some use-cases include using it as a backend for wallets
(similarly to Samuari's Dojo) or to track deposits to a watch-only xpub
(similarly to BTCPay's NBXplorer).

Compared to using the bitcoind RPC directly, bwt provides:

- The ability to track an xpub and automatically have new addresses derived
  and imported as needed, according to the gap limit.

- Two additional indexes, one for looking up the transaction history of
  addresses, and another one for looking up txo spends (a map of
  funding_txid:vout => spending_txid:vin).

- Real-time updates using Server-Sent Events [2] (a long-lived streaming
HTTP
  connection) or Web Hooks [3] (an HTTP request sent to a configured URL).
  The updates being sent [4] directly provide information about the funded
  and spent wallet txos, instead of the client figuring it out from the tx.

- Some API conveniences and simplifications, like including key origin
  information directly alongside inputs/outputs [5], the ability to specify
  key origins in place of addresses (eg. GET /hd/15cb9edc/8/utxos), a
compact
  history format [6], and an easy way to catch-up with missed events [7].
  Unless explicitly asked for, the API omits information about non-wallet
  inputs/outputs and protocol-level details like scriptsig and witnesses,
  which are typically not needed for higher-level app development.

The indexer is designed in a way that minimizes RPC requests to bitcoind. By
using labels to store key origin information, it is able to index incoming
transactions using the information available from `listtransactions` alone
(plus 3 extra rpc requests that don't grow with the number of transactions),
but requires 1 additional rpc call per outgoing transaction (to learn which
prevouts were spent). It can index 10k incoming txs in under a second, or a
mixture of 5k/5k in under 5 seconds. The index is currently entirely in-
memory and does not get persisted. The indexer logic can be seen in [8].

One major item on the roadmap that I'm hoping to tackle soon is support for
output script descriptors.

If anyone is interested in contributing, the README has some useful
developer
resources [9] and a handy script for setting up a development environment.

This is an early alpha release, recommended for use with testnet/regtest.

All feedback welcome!

Cheers,
Nadav

[0] https://github.com/shesek/bwt
[1] https://github.com/shesek/bwt#electrum-plugin
[2] https://github.com/shesek/bwt#server-sent-events
[3] https://github.com/shesek/bwt#web-hooks
[4] https://github.com/shesek/bwt#event-categories
[5] https://github.com/shesek/bwt#wallet-transaction-format
[6] https://github.com/shesek/bwt#get-txssinceblock-heightcompact
[7]
https://github.com/shesek/bwt#catching-up-with-missed-events--re-org-detection
[8] https://github.com/shesek/bwt/blob/master/src/indexer.rs
(sync_transactions and load_transactions_since)
[9] https://github.com/shesek/bwt#developing
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev