Jeremy Rubin [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-07-03 to 2022-10-20
💬 Posted a total of 99 messages
📚 Participated in the following categories: bitcoin-dev, Pre-BIP, Lightning-dev, PROPOSAL, Opt-in full-RBF
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:05:09 UTC

- reply

📅 Original date posted:2022-02-18
📝 Original message:
> As I said, it's a new kind of pinning attack, distinct from other types
of pinning attack.
I think pinning is "formally defined" as sequences of transactions which
prevent or make it less likely for you to make any progress (in terms of
units of computation proceeding).
Something that only increases possibility to make progress cannot be
pinning.
If you want to call it something else, with a negative connotation, maybe
call it "necromancing" (bringing back txns that would otherwise be
feerate/fee irrational).
I would posit that we should be wholly unconcerned with necromancing -- if
your protocol is particularly vulnerable to a third party necromancing then
your protocol is insecure and we shouldn't hamper Bitcoin's forward
progress on secure applications to service already insecure ones. Lightning
is particularly necromancy resistant by design, but pinning vulnerable.
This is also true with things like coinjoins which are necromancy resistant
but pinning vulnerable.
Necromancy in particular is something that isn't uniquely un-present in
Bitcoin today, and things like package relay and elimination of pinning are
inherently at odds with making necromancy either for CPFP use cases.
In particular, for the use case you mentioned "Eg a third party could mess
up OpenTimestamps calendars at relatively low cost by delaying the mining
of timestamp txs.", this is incorrect. A third party can only accelerate
the mining on the timestamp transactions, but they *can* accelerate the
mining of any such timestamp transaction. If you have a single output chain
that you're RBF'ing per block, then at most they can cause you to shift the
calendar commits forward one block. But again, they cannot pin you. If you
want to shift it back one block earlier, just offer a higher fee for the
later RBF'd calendar. Thus the interference is limited by how much you wish
to pay to guarantee your commitment is in this block as opposed to the next.
By the way, you can already do out-of-band transaction fees to a very
similar effect, google "BTC transaction accelerator". If the attack were at
all valuable to perform, it could happen today.
Lastly, if you do get "necromanced" on an earlier RBF'd transaction by a
third party for OTS, you should be relatively happy because it cost you
less fees overall, since the undoing of your later RBF surely returned some
satoshis to your wallet.
Best,
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220218/83410688/attachment.html>

2023-06-09 13:05:08 UTC

- reply

📅 Original date posted:2022-02-10
📝 Original message:
That's not really pinning; painning usually refers to pinning something to
the bottom of the mempool whereas these mechanisms make it easier to
guarantee that progress can be made on confirming the transactions you're
interested in.
Often times in these protocols "the call is coming inside the house". It's
not a third party adding fees we are scared of, it's a direct party to the
protocol!
Sponsors or fee accounts would enable you to ensure the protocol you're
working on makes forward progress. For things like Eltoo the internal
ratchet makes this work well.
Protocols which depend on in mempool replacements before confirmation
already must be happy (should they be secure) with any prior state being
mined. If a third party pays the fee you might even be happier since the
execution wasn't on your dime.
Cheers,
Jeremy
On Wed, Feb 9, 2022, 10:59 PM Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sat, Jan 01, 2022 at 12:04:00PM -0800, Jeremy via bitcoin-dev wrote:
> > Happy new years devs,
> >
> > I figured I would share some thoughts for conceptual review that have
> been
> > bouncing around my head as an opportunity to clean up the fee paying
> > semantics in bitcoin "for good". The design space is very wide on the
> > approach I'll share, so below is just a sketch of how it could work which
> > I'm sure could be improved greatly.
> >
> > Transaction fees are an integral part of bitcoin.
> >
> > However, due to quirks of Bitcoin's transaction design, fees are a part
> of
> > the transactions that they occur in.
> >
> > While this works in a "Bitcoin 1.0" world, where all transactions are
> > simple on-chain transfers, real world use of Bitcoin requires support for
> > things like Fee Bumping stuck transactions, DoS resistant Payment
> Channels,
> > and other long lived Smart Contracts that can't predict future fee rates.
> > Having the fees paid in band makes writing these contracts much more
> > difficult as you can't merely express the logic you want for the
> > transaction, but also the fees.
> >
> > Previously, I proposed a special type of transaction called a "Sponsor"
> > which has some special consensus + mempool rules to allow arbitrarily
> > appending fees to a transaction to bump it up in the mempool.
> >
> > As an alternative, we could establish an account system in Bitcoin as an
> > "extension block".
>
> <snip>
>
> > This type of design works really well for channels because the addition
> of
> > fees to e.g. a channel state does not require any sort of pre-planning
> > (e.g. anchors) or transaction flexibility (SIGHASH flags). This sort of
> > design is naturally immune to pinning issues since you could offer to
> pay a
> > fee for any TXID and the number of fee adding offers does not need to be
> > restricted in the same way the descendant transactions would need to be.
>
> So it's important to recognize that fee accounts introduce their own kind
> of
> transaction pinning attacks: third parties would be able to attach
> arbitrary
> fees to any transaction without permission. This isn't necessarily a good
> thing: I don't want third parties to be able to grief my transaction
> engines by
> getting obsolete transactions confirmed in liu of the replacments I
> actually
> want confirmed. Eg a third party could mess up OpenTimestamps calendars at
> relatively low cost by delaying the mining of timestamp txs.
>
> Of course, there's an obvious way to fix this: allow transactions to
> designate
> a pubkey allowed to add further transaction fees if required. Which Bitcoin
> already has in two forms: Replace-by-Fee and Child Pays for Parent.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220210/bfed4525/attachment.html>

2023-06-07 23:08:02 UTC

- reply

📅 Original date posted:2022-04-26
📝 Original message:I can't find all of my earlier references around this, I thought I made a
thread on it, but as a reminder, my thoughts for mild tweaks to APO that
make it a bit less hacky are as follows:
- Remove OP_1 key punning and replace it with OP_GENERATOR and
OP_INTERNALKEY (maybe OP_EXTERNALKEY too?). The key punning is useful
generically, because I may want to reuse the internal key in conjunction
with a script path in some circumstances.
- Add an additional sequence field that is specific to a signature with no
other consensus meaning, so APO can be used with absolute timelocks. For
example, this makes it impossible for more than one ratchet to be
aggregated within a single transaction under any circumstance if their
sequences differ (not sure this is a good example, but an example
nonetheless).
- Replace tagged keys for APO with either a Checksig2 or a separate feature
flag that enables or disables APO behavior so that we can have programmatic
control over if APO is allowed for a given key (e..g., OP_IF <N> CSV DROP
CHECKSIG2 OP_ELSE CHECKSIG OP_ENDIF enables APO to be turned on after a
certain time, perhaps for a pre-approved backup transaction).
Overall, this would make eltoo ratchets look something like this:
<sig> <seq> OP_1 OP_INTERNALKEY OP_CHECKSIG2VERIFY <N> OP_GREATERTHAN
where checksig2 leaves seq on the stack which can be used to enforce the
ratchet.
and covenants like:
<sig> OP_1 OP_1 OP_GENERATOR OP_CHECKSIG2VERIFY
On Fri, Apr 22, 2022 at 4:23 AM 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/20220426/8de4425a/attachment-0001.html>

2023-06-07 23:06:26 UTC

- reply

📅 Original date posted:2022-03-13
📝 Original message:Hi Antoine,
I have a few high level thoughts on your post comparing these types of
primitive to an explicit soft fork approach:
1) Transaction sponsors *is* a type of covenant. Precisely, it is very
similar to an "Impossible Input" covenant in conjunction with a "IUTXO" I
defined in my 2017 workshop
https://rubin.io/public/pdfs/multi-txn-contracts.pdf (I know, I know...
self citation, not cool, but helps with context).
However, for Sponsors itself we optimize the properties of how it works &
is represented, as well as "tighten the hatches" on binding to specific TX
vs merely spend of the outputs (which wouldn't work as well with APO).
Perhaps thinking of something like sponsors as a form of covenant, rather
than a special purpose thing, is helpful?
There's a lot you could do with a general "observe other txns in {this
block, the chain}" primitive. The catch is that for sponsors we don't
*care* to enable people to use this as a "smart contracting primitive", we
want to use it for fee bumping. So we don't care about programmability, we
care about being able to use the covenant to bump fees.
2) On Chain Efficiency.
A) Precommitted Levels
As you've noted, an approach like precomitted different fee levels might
work, but has substantial costs.
However, with sponsors, the minimum viable version of this (not quite what
is spec'd in my prior email, but it could be done this way if we care to
optimize for bytes) would require 1 in and 1 out with only 32 bytes extra.
So that's around 40 bytes outpoint + 64 bytes signature + 40 bytes output +
32 bytes metadata = 174 bytes per bump. Bumps in this way can also
amortize, so bumping >1 txn at the same time would hit the limit of 32
bytes + 144/n bytes to bump more than one thing. You can imagine cases
where this might be popular, like "close >1 of my LN channels" or "start
withdrawals for 5 of my JamesOB vaulted coins"
B) Fancy(er) Covenants
We might also have something with OP_CAT and CSFS where bumps are done as
some sort of covenant-y thing that lets you arbitrarily rewrite
transactions.
Not too much to say other than that it is difficult to get these down in
size as the scripts become more complex, not to mention the (hotly
discussed of late) ramifications of those covenants more generally.
Absent a concrete fancy covenant with fee bumping, I can't comment.
3) On Capital Efficiency
Something like a precommitted or covenant fee bump requires the fee capital
to be pre-committed inside the UTXO, whereas for something like Sponsors
you can use capital you get sometime later. In certain models -- e.g.,
channels -- where you might expect only log(N) of your channels to fail in
a given epoch, you don't need to allocate as much capital as if you were to
have to do it in-band. This is also true for vaults where you know you only
want to open 1 per month let's say, and not <all of your vaults> per month,
which pre-committing requires.
4) On Protocol Design
It's nice that you can abstract away your protocol design concerns as a
"second tier composition check" v.s. having to modify your protocol to work
with a fee bumping thing.
There are a myriad of ways dynamic txns (e.g. for Eltoo) can lead to RBF
pinning and similar, Sponsor type things allow you to design such protocols
to not have any native way of paying for fees inside the actual
"Transaction Intents" and use an external system to create the intended
effect. It seems (to me) more robust that we can prove that a Sponsors
mechanism allows any transaction -- regardless of covenant stuff, bugs,
pinning, etc -- to move forward.
Still... careful protocol design may permit the use of optimized
constructions! For example, in a vault rather than assigning *no fee* maybe
you can have a single branch with a reasonable estimated fee. If you are
correct or overshot (let's say 50% chance?) then you don't need to add a
sponsor. If you undershot, not to worry, just add a sponsor. Adopted
broadly, this would cut the expected value of using sponsors by <however
good you are at estimating future fees>. This basically enables all
protocols to try to be more efficient, but backstop that with a guaranteed
to work safe mechanism.
There was something else I was going to say but I forgot about it... if it
comes to me I'll send a follow up email.
Cheers,
Jeremy
p.s.
>
> *Of course this makes for a perfect DoS: it would be trivial for a miner
> to infer that you are using*
> *a specific vault standard and guess other leaves and replace the witness
> to use the highest-feerate*
> *spending path. You could require a signature from any of the
> participants. Or, at the cost of an**additional depth, in the tree you
> could "salt" each leaf by pairing it with -say- an OP_RETURN leaf.*
you don't need a salt, you just need a unique payout addr (e.g. hardened
derivation) per revocation txn and you cannot guess the branch.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
On Sat, Mar 12, 2022 at 10:34 AM darosior via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The idea of a soft fork to fix dynamic fee bumping was recently put back
> on the table. It might
> sound radical, as what prevents today reasonable fee bumping for contracts
> with presigned
> transactions (pinning) has to do with nodes' relay policy. But the
> frustration is understandable
> given the complexity of designing fee bumping with today's primitives. [0]
> Recently too, there was a lot of discussions around covenants. Covenants
> (conceptually, not talking
> about any specific proposal) seem to open lots of new use cases and to be
> desired by (some?) Bitcoin
> application developers and users.
> I think that fee bumping using covenants has attractive properties, and it
> requires a soft fork that
> is already desirable beyond (trying) to fix fee bumping. However i could
> not come up with a solution
> as neat for other protocols than vaults. I'd like to hear from others
> about 1) taking this route for
> fee bumping 2) better ideas on applying this to other protocols.
>
>
> In a vault construction you have a UTxO which can only be spent by an
> Unvaulting transaction, whose
> output triggers a timelock before the expiration of which a revocation
> transaction may be confirmed.
> The revocation transaction being signed in advance (typically before
> sharing the signature for the
> Unvault transaction) you need fee bumping in order for the contract to
> actually be enforceable.
>
> Now, with a covenant you could commit to the revocation tx instead of
> presigning it. And using a
> Taproot tree you could commit to different versions of it with increasing
> feerate. Any network
> monitor (the brooadcaster, a watchtower, ..) would be able to RBF the
> revocation transaction if it
> doesn't confirm by spending using a leaf with a higher-feerate transaction
> being committed to.
>
> Of course this makes for a perfect DoS: it would be trivial for a miner to
> infer that you are using
> a specific vault standard and guess other leaves and replace the witness
> to use the highest-feerate
> spending path. You could require a signature from any of the participants.
> Or, at the cost of an
> additional depth, in the tree you could "salt" each leaf by pairing it
> with -say- an OP_RETURN leaf.
> But this leaves you with a possible internal blackmail for multi-party
> contracts (although it's less
> of an issue for vaults, and not one for single-party vaults).
> What you could do instead is attaching an increasing relative timelock to
> each leaf (as the committed
> revocation feerate increases, so does the timelock). You need to be
> careful to note wreck miner
> incentives here (see [0], [1], [2] on "miner harvesting"), but this
> enables the nice property of a
> feerate which "adapts" to the block space market. Another nice property of
> this approach is the
> integrated anti fee sniping protection if the revocation transaction pays
> a non-trivial amount of
> fees.
>
> Paying fees from "shared" funds instead of a per-watchtower fee-bumping
> wallet opened up the
> blackmail from the previous section, but the benefits of paying from
> internal funds shouldn't be
> understated.
> No need to decide on an amount to be refilled. No need to bother the user
> to refill the fee-bumping
> wallet (before they can participate in more contracts, or worse before a
> deadline at which all
> contracts are closed). No need for a potentially large amount of funds to
> just sit on a hot wallet
> "just in case". No need to duplicate this amount as you replicate the
> number of network monitors
> (which is critical to the security of such contracts).
> In addition, note how modifying the feerate of the revocation transaction
> in place is less expensive
> than adding a (pair of) new input (and output), let alone adding an entire
> new transaction to CPFP.
> Aside, and less importantly, it can be made to work with today's relay
> rules (just use fee thresholds
> adapted to the current RBF thresholds, potentially with some leeway to
> account for policy changes).
> Paying from shared funds (in addition to paying from internal funds) also
> prevents pervert
> incentives for contracts with more than 2 parties. In case one of the
> parties breaches it, all
> remaining parties have an incentive to enforce the contract.. But only one
> would otherwise pay for
> it! It would open up the door to some potential sneaky techniques to wait
> for another party to pay
> for the fees, which is at odd with the reactive security model.
>
> Let's examine how it could be concretely designed. Say you have a vault
> wallet software for a setup
> with 5 participants. The revocation delay is 144 blocks. You assume
> revocation to be infrequent (if
> one happens it's probably a misconfigured watchtower that needs be fixed
> before the next
> unvaulting), so you can afford infrequent overpayments and larger fee
> thresholds. Participants
> assume the vault will be spent within a year and assume a maximum possible
> feerate for this year of
> 10ksat/vb.
> They create a Taproot tree of depth 7. First leaf is the spending path
> (open to whomever the vault
> pays after the 144 blocks). Then the leaf `i` for `i` in `[1, 127]` is a
> covenant to the revocation
> transaction with a feerate `i * 79` sats/vb and a relative timelock of `i
> - 1` blocks.
> Assuming the covenant to the revocation transaction is 33 bytes [3],
> that's a witness of:
> 1 + 33 + 1 + 33 + 7 * 32 = 292 WU (73 vb)
> ^^^^^^ ^^^^^^^^^^^^^^
> witscript control block
> for any of the revocation paths. The revocation transaction is 1-input
> 1-output, so in total it's
> 10.5 + 41 + 73 + 43 = 167.5 vb
> ^^^^ ^^^^^^^^^^^ ^^^^
> header input|witness output
> The transaction size is not what you'd necessarily want to optimize for
> first, still, it is smaller
> in this case than using other feebumping primitives and has a smaller
> footprint on the UTxO set. For
> instance for adding a feebumping input and change output assuming all
> Taproot inputs and outputs
> (CPFP is necessarily even larger):
> 5 * 64 + 1 + 5 * (32 + 1) + 1 + 33 = 520 WU (105 vb)
> ^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^
> witness witscript control
> 10.5 + 41 + 105 + 41 + 16.5 + 2 * 43 = 300 vb
> ^^^^ ^^^^^^^^ ^^^^^^^^^ ^^^^^^
> header input|witness fb input|witness outputs
> From there, you can afford more depths at the tiny cost of 8 more vbytes
> each. You might want them
> for:
> - more granularity (if you can afford large enough timelocks)
> - optimizing for the spending path rather than the revocation one
> - adding a hashlock to prevent nuisance (with the above script a third
> party could malleate a
> spending path into a revocation one). You can use the OP_RETURN trick
> from above to prevent that.
>
> Unfortunately, the timelocked-covenant approach to feebumping only applies
> to bumping the first
> transaction of a chain (you can't pay for the parent with a timelock) so
> for instance it's not
> usable for HTLC transactions in Lightning to bump the parent commitment
> tx. The same goes for
> bumping the update tx in Coinpool.
> It could be worked around by having a different covenant per participant
> (paying the fee from either
> of the participants' output) behind a signature check. Of course it
> requires funds to already be in
> the contract (HTLC, Coinpool leaf) to pay for your own unilateral close,
> but if you don't have any
> fund in the contract it doesn't make sense to try to feebump it in the
> first place. The same goes
> for small amounts: you'd only allocate up to the value of the contract
> (minus a dust preference) in
> fees in order to enforce it.
> This is less nice for external monitors as it requires a private key (or
> another secret) to be
> committed to in advance) to be able to bump [4] and does not get rid of
> the "who's gonna pay for the
> enforcement" issue in >2-parties contracts. Still, it's more optimal and
> usable than CPFP or adding
> a pair of input/output for all the reasons mentioned above.
>
>
> Thoughts?
> Antoine
>
>
> [0]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019614.html
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019615.html
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019627.html
> [3] That's obviously close to the CTV construction. But using another more
> flexible (and therefore
> less optimized) construction would not be a big deal. It might in fact
> be necessary for more
> elaborated (realistic?) usecases than the simple one detailed here.
> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220312/980f7dcc/attachment-0001.html>