<unnamed>

Public Key

npub1f2w9pm06c4k9ay8rst7757thahg2tfrtd0n645zxrtsqwhvaysrswydpll

Profile Code

nprofile1qqsy48zsahav2mz7jr3c9l0209m7m599534khea26prp4cq8tkwjgpcpzpmhxue69uhkummnw3ezuamfdejszrthwden5te0dehhxtnvdakqz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcqve20m

Publishing to

nostr.wine

nos.lol

relay.damus.io

Last Notes

2023-06-07 23:19:25 UTC

- reply

📅 Original date posted:2023-02-07
🗒️ Summary of this message: Taproot/MAST spends have variable size, allowing for unfair fee extraction in multiparty transactions. Mitigations include RBF, minimum weight before signing, and a trusted coordinator.
📝 Original message:> 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 `<pk> CHECKSIG IF SHA256 <hash> EQUALVERIFY ENDIF`, Mallory can
initially demonstrate that she can spend with `FALSE <sig>`, then later
switch to spending with `<some large preimage> TRUE <sig>`. (or I guess
even `DROP <pk> 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 at 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 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/20230207/85947d66/attachment-0001.html>

2023-06-07 23:09:18 UTC

- reply

📅 Original date posted:2022-05-07
📝 Original message:On Sat, May 7, 2022 at 5:08 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at 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 PUSH(<script>) followed by the literal <script>.
When I started experimenting with recursive covenants on liquid, I started
with the approach of verifying user-supplied witness data against the
input. It ended up being quite complex and verbose with taproot, because
you have to compute the tagged taptree hash from the tapscript and
TWEAKVERIFY it against the prevout's taproot output key (which also
requires the internal key and parity flag, provided as two extra witness
elements by the user).
I then realized that it is much simpler to have the tapscript hold a copy
of itself, that it's as safe and that it reduces the witness size cost
(because you don't need to do the entire taproot dance to verify the
tapscript), and switched to this approach.
Here are two examples of recursive covenants using this approach that I
played with (for liquid, rough sketches, very lightly tested and has some
known issues. the $label thing is a scriptwiz notation and can be ignored):
https://gist.github.com/shesek/be910619b247ce5e1aedd84e9ba9db42 (auction)
https://gist.github.com/shesek/ede9ca921a394580b23d301b8d84deea (listed
price sale with royalty)
(And here's the second example written in Minsc:
https://min.sc/next/#gist=e1c9914b4cb940137122d6d30972c25c)
shesek
[0] It does not cover it, and it cannot be done even by providing the full
prev tx because the prevout txid is not covered either.
On Sat, May 7, 2022 at 5:08 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning Jorge,
>
> > Thanks a lot for the many clarifications.
> > Yeah, I forgot it wasn't OP_CAT alone, but in combination with other
> things.
> > I guess this wouldn't be a covenants proposal then.
> > But simplicity would enable covenants too indeed, no?
> > Or did I get that wrong too?
>
> Yes, it would enable covenants.
>
> However, it could also enable *recursive* covenants, depending on what
> introspection operations are actually implemented (though maybe not?
> Russell O'Connor should be the one that answers this).
>
> It is helpful to delineate between non-recursive covenants from recursive
> covenants.
>
> * Even ***with*** `OP_CAT`, the following will enable non-recursive
> covenants without enabling recursive covenants:
> * `OP_CTV`
> * `SIGHASH_ANYPREVOUT`
> * With `OP_CAT`, the following would enable recursive covenants:
> * `OP_EVAL`
> * `OP_CHECKSIGFROMSTACK`
> * `OP_TX`/`OP_TXHASH`
> * ...possibly more.
> * It is actually *easier* to *design* an opcode which inadvertently
> supports recursive covenants than to design one which avoids recursive
> covenants.
>
> Recursive covenants are very near to true Turing-completeness.
> We want to avoid Turing-completeness due to the halting problem being
> unsolvable for Turing-complete languages.
> That is, given just a program, we cannot determine for sure if for all
> possible inputs, it will terminate.
> It is important in our context (Bitcoin) that any SCRIPT programs we write
> *must* terminate, or else we run the risk of a DoS on the network.
>
> A fair amount of this is theoretical crap, but if you want to split hairs,
> recursive covenants are *not* Turing-complete, but are instead total
> functional programming with codata.
>
> As a very rough bastardization, a program written in a total functional
> programming language with codata will always assuredly terminate.
> However, the return value of a total functional programming language with
> codata can be another program.
> An external program (written in a Turing-complete language) could then
> just keep invoking the interpreter of the total functional programming
> language with codata (taking the output program and running it, taking
> *its* output program and running it, ad infinitum, thus effectively able to
> loop indefinitely.
>
> Translated to Bitcoin transactions, a recursive covenant system can force
> an output to be spent only if the output is spent on a transaction where
> one of the outputs is the same covenant (possibly with tweaks).
> Then an external program can keep passing the output program to the
> Bitcoin SCRIPT interpreter --- by building transactions that spend the
> previous output.
>
> This behavior is still of concern.
> It may be possible to attack the network by eroding its supply, by such a
> recursive covenant.
>
> --
>
> Common reactions:
>
> * We can just limit the number of opcodes we can process and then fail it
> if it takes too many operations!
> That way we can avoid DoS!
> * Yes, this indeed drops it from Turing-complete to total, possibly
> total functional programming **without** codata.
> But if it is possible to treat data as code, it may drop it "total but
> with codata" instead (i.e. recursive covenants).
> But if you want to avoid recursive covenants while allowing recursive
> ones (i.e. equivalent to total without codata), may I suggest you instead
> look at `OP_CTV` and `SIGHASH_ANYPREVOUT`?
>
> * What is so wrong with total-with-codata anyway??
> So what if the recursive covenant could potentially consume all
> Bitcoins, nobody will pay to it except as a novelty!!
> If you want to burn your funds, 1BitcoinEater willingly accepts it!
> * The burden of proof-of-safety is on the proposer, so if you have some
> proof that total-with-codata is safe, by construction, then sure, we can
> add opcodes that may enable recursive covenants, and add `OP_CAT` back in
> too.
>
> 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/bitcoin-dev/attachments/20220508/4b8325a8/attachment-0001.html>

2023-06-07 23:08:53 UTC

- reply

📅 Original date posted:2022-05-01
📝 Original message:> 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 <nadav at shesek.info> 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 at 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 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/20220501/515b1504/attachment.html>

2023-06-07 23:07:24 UTC

- reply

📅 Original date posted:2022-04-20
📝 Original message:> 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 at 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 0x00400000 which I think
> doesn't have a different effect from 0xfffffffe?
>
> 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 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/20220420/5f867336/attachment-0001.html>

2023-06-07 18:26:36 UTC

- reply

📅 Original date posted:2020-08-21
📝 Original message: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 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/fb241441/attachment.html>

2023-06-07 18:25:39 UTC

- reply

📅 Original date posted:2020-06-25
📝 Original message: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 <ZmnSCPxj at protonmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200625/b7933c5a/attachment-0001.html>

2023-06-07 18:25:38 UTC

- reply

📅 Original date posted:2020-06-25
📝 Original message:> 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 at 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 <ZmnSCPxj at protonmail.com>
> 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 the Alice hashlock transaction.
> > > > To counter this, Bob has to bid up its version higher.
> > > >
> > > > As the timeout approaches, Alice can bump up its fee until it is
> just 1 satoshi short of the total fund.
> > > > It is rational for Alice to do so since at timeout, it can expect to
> lose the entire fund.
> > > > In order for Bob to win, it has to beat that fee, at which point it
> equals or exceeds the total fund, and miners get the total fund (or more).
> > > >
> > > > Knowing this end-point, rational Bob will not even begin this game.
> > > >
> > > > I think this research considers these two endpoints to be distinct:
> > > >
> > > > * Bob misbehaves and the entire fund is punished by miners, leaving
> miners with the fund and Alice and Bob without money (MAD-HTLC).
> > > > * Bob misbehaves, Alice counters, and the ensuing fee war leads to
> fees approaching the fund value, leaving miners with the fund and Alice and
> Bob without money (standard HTLC).
> > > >
> > > > But in practice I think both endpoints are essentially equivalent.
> > >
> > > These are not the same scenario, since in HTLC there is a race between
> Alice and Bob. Alice might not wish to pay the full HTLC amount once she
> sees Bob is trying to cheat. She could wait until close to the timeout so
> as to reduce the time Bob can respond. Of course Bob would do the same. So
> this is an actual race, and Bob takes no risk since his payment is all from
> the HTLC amount. Mutual destruction is only assured under certain
> assumptions in HTLC. MAD-HTLC achieves security without relying on such
> assumptions.
>
> Alice already knows that a rational Bob (who it might never interact with
> again in the future) will take the funds at the locktime L.
> Thus, Alice can offer, at time L - 1, the entire fund, minus 1 satoshi, to
> miners.
> Alice getting 1 satoshi versus 0 satoshi is a no-brainer for Alice.
> Bob can only beat this offer by offering the entire fund, at which point
> Bob earns nothing and it performed an attack for no benefit.
>
> I and some number of Lightning devs consider this to be sufficient
> disincentive to Bob not attacking in the first place.
>
>
> > >
> > >
> > > > --
> > > >
> > > > What MAD-HTLC can do would be to make different claims:
> > > >
> > > > * Inputs:
> > > > * Bob 1 BTC - HTLC amount
> > > > * Bob 1 BTC - Bob fidelity bond
> > > >
> > > > * Cases:
> > > > * Alice reveals hashlock at any time:
> > > > * 1 BTC goes to Alice
> > > > * 1 BTC goes to Bob (fidelity bond refund)
> > > > * Bob reveals bob-hashlock after time L:
> > > > * 2 BTC goes to Bob (HTLC refund + fidelity bond refund)
> > > > * Bob cheated, anybody reveals both hashlock and bob-hashlock:
> > > > * 2 BTC goes to miner
> > > >
> > > > This is an actual improvement over HTLC: Bob misbehavior leads to
> loss of the fidelity bond.
> > > > The above cases can be assured by requiring both Alice and Bob to
> sign in the alice-hashlock branch, so that the splitting of the fund is
> enforced, and SegWit signing so that the dependent transaction is signed
> before the HTLC-funding transaction is.
> > > > It can also be implemented with `OP_CHECKTEMPLATEVERIFY`.
> > >
> > > The cases you present are exactly how MAD-HTLC works. It comprises two
> contracts (UTXOs):
> > > * Deposit (holding the intended HTLC tokens), with three redeem paths:
> > > - Alice (signature), with preimage "A", no timeout
> > > - Bob (signature), with preimage "B", timeout T
> > > - Any entity (miner), with both preimages "A" and "B", no timeout
> > > * Collateral (the fidelity bond, doesn't have to be of the same amount)
> > > - Bob (signature), no preimage, timeout T
> > > - Any entity (miner), with both preimages "A" and "B", timeout T
> > >
> > > Only Bob initially knows preimage "B", and is required to reveal it if
> he wishes to get the Deposit tokens.
> > >
> > > Consider first the case where Alice publishes preimage "A": Bob can
> safely publish preimage "B" and get both the Deposit and Collateral tokens
> after the timeout.
> > > Now, consider the case where Alice does not publish preimage "A": If
> Bob publishes preimage "B" he gets nothing (and so does Alice - this is the
> mutual assured destruction), and if he doesn't, he gets the Collateral
> tokens.
>
> Thank you for the clarification.
>
> 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/bitcoin-dev/attachments/20200625/86ee66c8/attachment-0001.html>