Re: [bitcoin-dev] Seeking concept ACKs for transaction terminology BIP
Hello Murch, It makes sense to me too. Thanks! Antoine Original Message On Apr 5, 2023, 8:54 PM, Murch via bitcoin-dev wrote: > Hey everyone, Over the years, I have participated in a few conversations > about various aspects of transactions. Often a chunk of the conversation is > spent on establishing a shared vocabulary. There are many competing > terms—e.g. I can think of at least three additional terms that refer to > `scriptPubKey`. I’ve drafted an informational BIP that proposes terminology > for various components and aspects of transactions. As some established terms > are already contradictory, the proposal does not aim for a perfectly > consistent selection of terms, but rather just to establish a shared > vocabulary to avoid confusion. Draft: https://github.com/Xekyo/bips/pull/1 > Please let me know whether you’d be interested in the creation of such a BIP. > Cheers, Murch ___ 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] Wallet vaults with pre-signed transactions but no ephemeral keys
Hello Billy, Yes it's basically a (simple) instantiation of Revault. You can find more at [https://github.com/revault](https://github.com/revault/) (you most likely want the `practical-revault` repo). There is a description of the concept, the specification of a communication protocol between the participants as well as the implementation of the whole. Such a design presents some advantages, but it has two major issues: - You need to make sure all your watchtowers received the Cancel signature before you sign the Unvault transaction. But how can you get this guarantee in the usual (and reasonable) model of an untrusted laptop? - You can only have policies on the Unvault transaction (eg "You can only Unvault up to X BTC during working hours"), not on the Spend transaction (eg "You can only send coins to a Script with pubkey Y required in all spending paths"). Revault allows to use cosigning servers that act as anti-replay oracles to have policies on the spend, but this is obviously *very* suboptimal. Both issues are solvable with covenants. Antoine Poinsot --- Original Message --- Le lundi 23 janvier 2023 à 6:39 PM, Billy Tetrud via bitcoin-dev a écrit : > In the discussion around James' OP_VAULT proposal, it was implied that > precomputed vaults must use ephemeral keys that must be deleted as part of > the vaulting protocol, like [Bryan Bishop's > proposal](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017229.html). > Looking around, I haven't been able to find any wallet vault proposal that > doesn't require ephemeral keys, so at the risk of posting something that's > obvious to everyone, I wanted to share a simple way to do a wallet vault > without requiring any key deletion. > > The basic idea is to create an N-of-N multisig address, and pre-sign some > transactions from it with N-1 keys to an address with several timelocked > spend paths. This has the fallback that funds can always be spent immediately > if you use all the keys, just like a normal N-of-N multisig address (since > that's what it is at its core), but the usage of any of the pre-signed > transactions leads to an address that guarantees a clawback within a time > window. Here's a 3-of-3 example: > > Vault Initialization: > 1. Create 3 of 3 Vault Address > 2. Create an Interim Address that can send with: > * 1 of 3 keys after a timelock of 1 month > * 2 of 3 keys after a timelock of 1 week > * 3 of 3 keys with no timelock > > Vaulting: > 1. Create a transaction sending an output to the Vault Address > 2. Create a transaction spending that Vault Address output to the Interim > Address > 3. Presign one copy of the step-2 transaction for each of the three > combinations of two keys. > 4. Store seeds separately, store the wallet config as well as the three > presigned transactions with each seed. > > Unvaulting: > 1. Sign one of the pre-signed transactions with the missing signature. > 2. Broadcast > 3. Wait the appropriate timelock for the number of keys you want to sign with. > 4. Create a transaction sending from the Interim Address. > 5. Broadcast > Recovering (after unvaulting step 2 after the broadcasted transaction to the > Interim Address has been mined): > 1. Sign the utxo with all three keys to any destination. Alternatively sign > with two keys, wait 1 week. > 2. Broadcast it > > This has the usual downsides of pre-signed vaults that you need to backup > these transactions for each vaulting, complications involving the flexibility > (or lack thereof) of fees, and inflexibility in how much to unvault (must be > the whole utxo, no change). This could of course be augmented with various > techniques to make fee handling more flexible (anchor outputs, multiple > versions of the presigned transactions with different fees, etc). More > complicated presigning schemes could allow for some flexibility in unvaulting > amount (eg by sending change back into the vault, and creating additional > pre-signed transactions for that new output). > > It also has the same downside that OP_CTV vaults have, where a stolen key can > steal funds from the interim address by racing the owner with their own > transaction once the necessary delay has passed. Note that James' OP_VAULT > opcode wouldn't have this problem. > > But not requiring any toxic waste keys seems like a pretty good benefit over > Bryan Bishop's original proposal. > > Anyways sorry if this was already on people's radar and just too obvious to > post about.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Wallet policies for descriptor wallets
Hello Salvatore, It's not something about the specifications of wallet policies, but regarding the guidelines for implementers on signing devices. Quoting BIP-wallet-policies: > Moreover, other limitations like the limited size of the screen might affect > what design choices are available in practice. Therefore, minimizing the size > of the information shown on-screen is important for a good user experience; > that is crucial since the ability for the user to completely validate > on-screen the kind of script used (and each of the involved keys) is a > prerequisite for secure usage, as the machine that is interacting with the > hardware signer (and running the software wallet) is considered untrusted. > The device shows the wallet policy to the user using the secure screen. > - Template with miniscript for "1 of 2 equally likely keys": > wsh(or_b(pk(@0/**),s:pk(@1/**))) Actually you can save a few more characters, and gain some clarity, by showing the "semantic policy" instead of the actual Miniscript. If the intent is for the user to verify the semantic of the Bitcoin Script they are importing, you can just drop all the type information. For instance, for a Miniscript representing the Miniscript policy "a 3-of-3 that becomes a 2-of-3 after 90 days" instead of showing: thresh(3,pk(Alice),s:pk(Bob),s:pk(Carol),sln:older(12960)) You could show: thresh(3,pk(Alice),pk(Bob),pk(Carol),older(12960)) For this specific example you'd save 8 (confusing) characters to be verified on the signing device. I wonder if signing devices could even go further and display a plain english verification to the user, like "This policy contains 4 spending paths. Be ready to verify the 4 spending paths. The first spending path is Alice, Bob and Carol signing together. The second spending path is Bob and Carol signing together after 90 days. The third spending path is Alice and Carol signing together after 90 days. The third spending path is Alice and Bob signing together after 90 days ." It seems feasible to be doable in a general manner from a Miniscript "semantic policy". I guess it clashes with the user willing to check their backup against the policy registered on the device. You could always have the user-friendly policy check at first and have an option to show the raw descriptor for them to be able to cross-check it with their backup. PS: the numerous usage of the word "policy" is getting complex lol, is it a Miniscript concrete policy, a Miniscript semantic policy, a BIP-wallet-policies policy? :) Antoine Poinsot --- Original Message --- Le lundi 21 novembre 2022 à 12:27 PM, Salvatore Ingala via bitcoin-dev a écrit : > Hi list, > > Following up on this topic, I now opened a pull request with the BIP proposal: > > https://github.com/bitcoin/bips/pull/1389 > > I also attempted a proof-of-concept of how an integration of wallet policies > to HWI might look like: > > https://github.com/bitcoin-core/HWI/pull/647 > > which might help to provide context, and also serves as a demo of the > possible UX flows with hardware signers (as currently implemented in the > Ledger bitcoin app). > > There are no substantial changes to the initial version proposed to the list: > - some additional restrictions to the allowed descriptors were added as > further simplifications; > - added test vectors and observations on backwards compatibility; > - general improvements to the text. > > I look forward to your comments and improvements. > Salvatore Ingala > > On Thu, 5 May 2022 at 16:32, Salvatore Ingala > wrote: > >> In the implementation work to implement descriptors and miniscript support >> in hardware wallets [a][b], I encountered a number of challenges. Some of >> them are technical in nature (e.g. due to constraints of embedded >> development). Others are related to the attempts of shaping a good user >> experience; with bitcoin reaching more people who are not tech-savvy, >> self-custody is only as secure as what those newcomers can use easily enough. >> >> The main tool that I am using to address some of these challenges is a layer >> that sits _on top_ of descriptors/miniscript, while staying very close to >> it. Since there is nothing that is vendor-specific in the vast majority of >> the approach I'm currently using, I tried to distill it here for your >> comments, and will propose a BIP if this is deemed valuable. >> >> I called the language "wallet policies" (suggestions for a better name are >> welcome). I believe an approach based on wallet policies can benefit all >> hardware wallets (stateless or not) that want to securely support complex >> scripts; moreover, wallet policies are close enough to descriptors that >> their integration should be extremely easy for any software wallet that is >> currently using descriptors. >> >> [a]: https://blog.ledger.com/bitcoin-2 - early demo >> [b]: https://blog.ledger.com/miniscript-is-coming - miniscript example >>
Re: [bitcoin-dev] Wallet policies for descriptor wallets
Thanks for taking the time to write up about the implementation of output
descriptors on signing devices, and
for proposing a method to overcome encountered difficulties for the following
implementers.
I have some questions with regard to the modifications to the descriptor
language required to make the
registration flow reasonable on a signing device.
To sum up, starting from the currently spec'd output descriptors [0] you need:
1. The `` optimization for the common usecase of using 2 descriptors
at different derivation indices
for receive and change. [1]
2. The `/**` optimization for the common usecase of `/<0;1>` for point 1).
3. A new key expression `@i` referring to an index in a list of keys.
The first point was already discussed at great length [2]. Whether or not we
agree using the derivation path
for change detection is a sane thing to do, most signing devices need to
support this to not break
compatibility. I think the advantage boils down to not make the user write two
almost-similar descriptors on
its backup, since it doesn't necessarily help readibility for human
verification.
I'm not so sure about the second point. Is another deviation from the standard
worth it just for saving 3
characters?
Disgressing, if we are to have a carve-out in the descriptor language for the
common usecase of change/receive
keychains maybe your `/**` applies better than the proposed `/` as the
latter can open the door to
further carve-out requests.
For the third point, it does indeed seem unrealistic to check both the keys and
the descriptor at the same
time. Even just because of the screen size (if the width an xpub is, what, 3
times the width of your screen,
by the time you finished verifying it you have forgotten the descriptor context
in which this key was!). It
becomes harder as you get larger descriptors with Miniscript or Taproot, as you
mentioned. Even the Miniscript
compiler at [3] supports key aliasing to workaround the inconvenience of long
keys.
However, why does it need to be a change to the descriptor language? It looks a
lot like something that needs
to be handled at the application level with key aliasing. The flow would be
first to register known keys, and
then when registering a descriptor the keys would be replaced by their aliases
for smoother verification. For
stateless devices, the registration of keys could use the same flow you
described for descriptors.
In the end it's just replacing the vector and indices with a mapping and label,
which make it a *much* better
UX (checking aliases vs looking up indices in a vector). For instance:
Key registration:
Alice:
xpub6FLhTbeNidZkyC729yW6K6a5zuDxKUL8Q6oZm4XG2ov9PdxAyyDNEUm3jet8ENnvYsy6nCgsofN6FeVxakLDTdWGoxtmoYcu2exhqh9HjtV
Bob:
xpub6CoUua86qHYdDmnQL7imGN3zUMpVjRT4uDtRxYvfFj2v8JRvsaaGtf9ggv9NiL8sx3rFh6po92WBChwb37gDGuuU2Qo7zi3ZKC9cLjAsdQw
Notary:
xpub6DjUwtKmK7uqsd5p9w3eoJ4cjuML51nW85BTWuBaHEoxfmDGD3uPf6ZghsVeyuZUSuYEL4ajkVrfXzmotHHPtf6oBNYUQDSSBD4zUEiDoap
Descriptor registration (policy language for simpl.):
tr(NUMS,{
multi(2,Alice,Bob),
and(older(52560),and(Notary,Alice)),
and(older(52560),and(Notary,Bob))
})
In conclusion, if we were to have an optimization in the descriptor language
for the common receive/change
usecase, i don't think you need another "wallet policy language" than the
existing output descriptors language
with key aliasing/registration?
Unrelated question, since you mentioned `musig2` descriptors in this context. I
thought Musig2 wasn't really
feasible for hardware signing devices, especially stateless ones. Do you
think/know whether it is actually
possible for a HW to take part in a Musig2?
Thanks,
Antoine
[0] https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki
[1] https://github.com/bitcoin/bitcoin/pull/22838
[2] https://github.com/bitcoin/bitcoin/issues/17190
[3] https://bitcoin.sipa.be/miniscript/
--- Original Message ---
Le jeudi 5 mai 2022 à 4:32 PM, Salvatore Ingala via bitcoin-dev
a écrit :
> In the implementation work to implement descriptors and miniscript support in
> hardware wallets [a][b], I encountered a number of challenges. Some of them
> are technical in nature (e.g. due to constraints of embedded development).
> Others are related to the attempts of shaping a good user experience; with
> bitcoin reaching more people who are not tech-savvy, self-custody is only as
> secure as what those newcomers can use easily enough.
>
> The main tool that I am using to address some of these challenges is a layer
> that sits _on top_ of descriptors/miniscript, while staying very close to it.
> Since there is nothing that is vendor-specific in the vast majority of the
> approach I'm currently using, I tried to distill it here for your comments,
> and will propose a BIP if this is deemed valuable.
>
> I called the language "wallet policies" (suggestions for a better name
Re: [bitcoin-dev] ANYPREVOUT in place of CTV
Hi Jacob, I think you are a bit confused about how CTV and (tweaked) APO covenants compare. Both would commit to the same template, so one isn't "safer" than the other. Just more efficient in how it commits to the template. Replies on the specifics inline. > While I agree with the arguments in favour of (optional ANYONECANPAY) APOAS > in lieu of CTV in the short-term (given the additional benefit of enabling > Eltoo), there's a point to add in favour of CTV (or similar) in the long-term > beyond as an optimisation. In the long term, we'd hopefully have more powerful covenants to enable more interesting applications. At this point CTV would be an optimisation for these covenant constructions instead of an APO one. My request for feedback was more about the short term, where some are requesting the activation of CTV to start playing with covenants before we settle on the way forward to more useful covenant. Not that i'm in favour of it, but if it gains sufficient traction then i believe there is a case for instead doing a tweaked APO that would optionally commit to the input index, nSequences, etc..[0] I think this addresses the technical debt concerns of CTV once we have more interesting covenants, as no covenant can entirely emulate a signature hash type. > With APOAS-based covenants, the signature message algorithm is tied to both > the covenant commitment and transaction validation. Coupling these things > introduces a trade-off between safety and flexibility with covenant-based > applications. What do you mean "tied to the transaction validation"? To me "transaction validation" is what a node does to check whether a block is valid, but you probably mean something else here. With APOAS-based covenants, the signature message *is* the covenant commitment. I don't see how it is coupled to anything else. I also don't see how it could ever differ in safety or flexibility with another hashed-template approach (CTV) if the template is the same. > E.g. the maximally safe and restricted covenant commits to all inputs and > outputs of the transaction (using SIGHASH ALL). However, a less restricted > covenant commits to, for example, a single input and a single output (using > ANYONECANPAY|SINGLE) but opens itself up to attacks making use of transaction > malleability and signature replay. Indeed the APO approach is more flexible as sighash types may be combined. You can opt-in to more malleability. I don't think it's a bad thing. Now, sure, the commitment may be replayed, but it's inherent to any commitment that doesn't commit to the prevout (whether it is CTV or APO, or any other type of templated covenant that you'd place in the ScriptPubKey) otherwise you'd have a circular hash dependency. If you are talking about the "half spend" by which two coins with the same covenant get spent in the same transaction, then committing to the input index fixes this. Interestingly the instance you give *does* commit to the input index without any tweak to the current APO proposal. > If instead we separate the covenant commitment from the signatures to > validate transactions (as with CTV and TXHASH + CHECKSIGFROMSTACK) then we > by-pass this trade-off. CTV doesn't "separate the signature and the commitment", it doesn't need a signature. Sure one can be added to further restrict a spending path, but it isn't necessary since the transaction is pre-defined and can't be malleated. It also sounds like you imply the APO covenant is using a "real" signature. It's not. The pubkey may well be G. The signature is just a roundabout way to access the hash. So if you wanted to have, say, a covenant only available to a participant you'd go the same way with either CTV or APO covenants: <0x01 G> OP_CHECKSIGVERIFY OP_CHECKSIG OP_CTV OP_VERIFY OP_CHECKSIG > The flexibility of additional templates with new CTV versions or with the > TXHASH primitive seems to me to enable significantly more utility for > covenant-based applications. TXHASH would definitely enable more utility. Additional templates with new CTV versions would require a new soft fork for new (hardcoded) usecases. But i'm not going to restart the conversation around the benefits of slightly more general covenant primitives [1]. :-) Antoine [0] See the OP for rationale[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html [0] Cf the OP for the rationale___ 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
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 wehave 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 non-QC-vulnerable-bare-CTV-covenant (that would eventually become vulnerable when trying to use it) are worthless.[1] Sorry for being sarcastic, but at this point it's not fair to use quantum-computer FUD to justify theactivation of CTV over APO, or encourage the use of legacy transactions over Taproot ones. > 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). Again, this is what my post discusses. Here are the arguments from my post about why i don't think it's a big deal: 1. You can in this case see CTV as an optimization of (tweaked) APOAS. A lot of us are doubtful about CTV usecases for real people. So much that it was even proposed to temporarily activate it to see if it would ever have any real traction! [2] My point with this post was: what if we do (a slightly tweaked) BIP118, that is otherwise useful. And if this use of covenants is really getting traction then we can roll out an optimization in the form of CTV (or better covenants, as we'd have had more research put into it by this time). 2. CTV is mainly sold for its usage inside vaults. While i'm not convinced, a few more vbytes should not matter for this usecase. Also, it's not 33 extra vbytes vs CTV-in-segwitv0, but 33 extra * witness units* (8.25 vbytes). Aside, you can also use the internal key optimization with APO. But i don't think it's desirable just to save32 WU, as you can't have NUMS-ness then. [3] > 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). Are APO signatures more expensive to verify? If not i don't think this should be a reason to constrain us to a much less useful construction, as the cost for the network of validating signatures already exists today. Evenif it didn't, the tradeoff of cost/usefulness needs to be considered. > 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). Yes! And as i mentioned on Twitter also committing to the input index which i forgot to add in the OP here. While i don't think the specific points are valid, i appreciate your reply and your efforts to explore the tradeoffs between the two approaches. Thanks, Antoine [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html [1] https://bitcoin.stackexchange.com/a/91050/101498 [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020242.html [3] https://twitter.com/darosior/status/1518979155362254849?s=20&t=mGkw7K8mcyQwdLImFvdebw > 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 > wrote: > >> I would like to know people's sentiment about doing (a very slightly tweaked >> version of) BIP
[bitcoin-dev] CTV, covenants and vaults (was: : Re: ANYPREVOUT in place of CTV)
> > i doubt CTV is necessary nor sufficient for this > I would be interested to hear more on this. A lot of people have been conflating vaults and covenants, especially lately. I believe we should differentiate more Bitcoin vaults, a scheme that defines a "staged transaction process" [0], and Bitcoin covenants. I find that there was a lot of confusion spread around that. Everything was a vault, from the marketing of a mobile wallet with a 2of3 account to a covenant scheme. ( :) It led to the confusion that a Bitcoin covenant would be necessary in order to have a Bitcoin vault. It's incorrect: https://github.com/revault/practical-revault/blob/master/introduction.md (or [1], but albeit pretty clever, i don't think it's practical). Now, CTV is useful for Bitcoin vaults. For instance i believe it's useful to pre-commit to a Cancel transaction directly in the Unvault Script. This matters a lot as today you need to be sure that your watchtowers (or any other network monitor) have had the Cancel transaction signature of all participants in the vault before you sign the Unvault transaction. A covenant, as simple as CTV, fixes this. It makes sure that not only any Unvault you sign can be Canceled, but also that when you spin up a new watchtower you don't need to send to it all the signatures for all the current vaults. Of course you'd want to add some secret here to avoid the annoyance of all your Unvaults being able to be canceled by some rando on the network. But you can derive them from a secret shared only once. Also on the topic of reducing interactivity, i think that CTV or another more powerful covenants that allows to commit to all parts of a transaction (for malleability) can be useful for the complicated issue of fee bumping [2]. However, it's not sufficient. You are not going to be able to receive coins on a CTV that commits to the Unvault (whose output would commit to either the Cancel immediately, or something else after a delay). It would be an enormous footgun. For this, i believe something like TLUV with IN_OUT_AMOUNT [3] is a much more interesting direction. Furthermore, committing entirely to the withdrawal amounts in advance is very impractical. It is the one largest UX barrier in my opinion. Users don't think in coins, but in amount to transfer. In order to have an almost decent UX you would have to prepare a first stage transaction that creates a nice (what is nice? It's very hard to reason about) distribution of coin amounts. This is a big tradeoff between usability and cost (granularity). Of course it's not new to CTV, It's an issue today with Revault. It's just a problem faced by today's implementation(s) (i don't know of any other "real" vault implementation) of Bitcoin vaults that CTV does not solve. I realise that you might not care to receive coins on a single-sig Script and have a vaulting step in a single-party situation. I guess i just think vaults are more interesting in organisational situations, where a set of participants only marginally trust another one (that may be a subset) and want to both limit the amount they have access to and apply policies on how they would use the funds. Antoine [0] All vaults architectures i know of are characterized by the necessity to unlock the funds in multiple stages, one of which is timelocked. [1] https://arxiv.org/abs/2005.11776 [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020122.html[3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html ------- Original Message --- Le lundi 25 avril 2022 à 6:57 PM, Nadav Ivgi a écrit : > 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 > 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 "ANYONECA
Re: [bitcoin-dev] ANYPREVOUT in place of CTV
Just a correction to my previous mail. Sorry for the non-attribution, i didn't recall APO covenants had been discussed in the context of CTV. > > a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV? > > I'm not aware of any specific to CTV. It's just that the fields covered in > the CTV hash are very close to what The comparison was already done by Anthony Towns. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017036.html Jeremy Rubin already pointed out that it missed committing to the nSequences hash and number of inputs (and optionally scriptSigs). https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017038.html --- Original Message --- Le lundi 25 avril 2022 à 3:35 PM, darosior via bitcoin-dev a écrit : > Hi Richard, > > > Sounds good to me. Although from an activation perspective it may not be > > either/or, both proposals do > > compete for scarce reviewer time > > Yes, of course. Let's say i was more interested in knowing if people who > oppose CTV would oppose > SIGHASH_ANYPREVOUT too. I think talking about activation of anything at this > point is premature. > > > For someone not as versed in CTV, why is it necessary that ANYONECANPAY be > > optional to emulate CTV? Is there > > a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV? > > I'm not aware of any specific to CTV. It's just that the fields covered in > the CTV hash are very close to what > ANYPREVOUT_ANYSCRIPT's signature hash covers [0]. The two things that CTV > commits to that APO_AS does not are > the number of inputs and the hash of the inputs' sequences [1]. > Not committing to the number of inputs and other inputs' data is today's > behaviour of ANYONECANPAY that can > be combined with other signature hash types [1]. Thus APO_AS makes ACP > mandatory, and to emulate CTV > completely it should be optional. > > > Antoine > > [0] > https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Detailed_Specification > [1] > https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message > [2] > https://github.com/bitcoin/bitcoin/blob/10a626a1d6776447525f50d3e1a97b3c5bbad7d6/src/script/interpreter.cpp#L1327, > > https://github.com/bitcoin/bitcoin/blob/10a626a1d6776447525f50d3e1a97b3c5bbad7d6/src/script/interpreter.cpp#L1517-L1522 > > > --- Original Message --- > Le dimanche 24 avril 2022 à 10:41 PM, Richard Myers remy...@yakshaver.org a > écrit : > > > > > Hi darosior, > > > > Thanks for sharing your thoughts on this. > > > > > I would like to know people's sentiment about doing (a very slightly > > > tweaked version of) BIP118 in place of > > > (or before doing) BIP119. > > > > Sounds good to me. Although from an activation perspective it may not be > > either/or, both proposals do compete for scarce reviewer time so their > > ordering will necessarily be driven by reviewer's priorities. My priority > > is eltoo which is why I focus on BIP-118. > > > > > SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made > > > optional [0], can emulate CTV just fine. > > > > For someone not as versed in CTV, why is it necessary that ANYONECANPAY be > > optional to emulate CTV? Is there a write-up that explains how APO-AS w/out > > ANYONECANPAY approximates CTV? > > > > In the case of eltoo commit txs, we use bring-your-own-fee (BYOF) to > > late-bind fees; that means ANYONECANPAY will always be paired with APO-AS > > for eltoo. Settlement txs in eltoo use just APO and do not necessarily need > > to be paired with ANYONECANPAY. > > > > I would guess making ANYONECANPAY the default for APO-AS was a way to > > squeeze in one more sighash flag. Perhaps there's another way to do it? > > > > Including SIGHASH_GROUP with APO for eltoo is also tempting. Specifically > > so the counter-party who commits a settlement tx can use for fees their > > settled to_self balance. How to rejigger the sighash flags to accommodate > > both APO and GROUP may be worth some discussion. > > > > The BIP-118 proposal will certainly benefit from having input from > > reviewers looking at other protocols than eltoo. > > > > -- Richard > > ___ > 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
Hi Richard, > Sounds good to me. Although from an activation perspective it may not be > either/or, both proposals do compete for scarce reviewer time Yes, of course. Let's say i was more interested in knowing if people who oppose CTV would oppose SIGHASH_ANYPREVOUT too. I think talking about activation of anything at this point is premature. > For someone not as versed in CTV, why is it necessary that ANYONECANPAY be > optional to emulate CTV? Is there a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV? I'm not aware of any specific to CTV. It's just that the fields covered in the CTV hash are very close to what ANYPREVOUT_ANYSCRIPT's signature hash covers [0]. The two things that CTV commits to that APO_AS does not are the number of inputs and the hash of the inputs' sequences [1]. Not committing to the number of inputs and other inputs' data is today's behaviour of ANYONECANPAY that can be combined with other signature hash types [1]. Thus APO_AS makes ACP mandatory, and to emulate CTV completely it should be optional. Antoine [0] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Detailed_Specification [1] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message [2] https://github.com/bitcoin/bitcoin/blob/10a626a1d6776447525f50d3e1a97b3c5bbad7d6/src/script/interpreter.cpp#L1327, https://github.com/bitcoin/bitcoin/blob/10a626a1d6776447525f50d3e1a97b3c5bbad7d6/src/script/interpreter.cpp#L1517-L1522 --- Original Message --- Le dimanche 24 avril 2022 à 10:41 PM, Richard Myers a écrit : > Hi darosior, > > Thanks for sharing your thoughts on this. > > > I would like to know people's sentiment about doing (a very slightly > > tweaked version of) BIP118 in place of > > (or before doing) BIP119. > > > Sounds good to me. Although from an activation perspective it may not be > either/or, both proposals do compete for scarce reviewer time so their > ordering will necessarily be driven by reviewer's priorities. My priority is > eltoo which is why I focus on BIP-118. > > > SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made > > optional [0], can emulate CTV just fine. > > > For someone not as versed in CTV, why is it necessary that ANYONECANPAY be > optional to emulate CTV? Is there a write-up that explains how APO-AS w/out > ANYONECANPAY approximates CTV? > > In the case of eltoo commit txs, we use bring-your-own-fee (BYOF) to > late-bind fees; that means ANYONECANPAY will always be paired with APO-AS for > eltoo. Settlement txs in eltoo use just APO and do not necessarily need to be > paired with ANYONECANPAY. > > I would guess making ANYONECANPAY the default for APO-AS was a way to squeeze > in one more sighash flag. Perhaps there's another way to do it? > > Including SIGHASH_GROUP with APO for eltoo is also tempting. Specifically so > the counter-party who commits a settlement tx can use for fees their settled > to_self balance. How to rejigger the sighash flags to accommodate both APO > and GROUP may be worth some discussion. > > The BIP-118 proposal will certainly benefit from having input from reviewers > looking at other protocols than eltoo. > > -- Richard ___ 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
Hi, Richard Myers has an implementation of Eltoo using Bitcoin Core's functional test framework: https://github.com/remyers/bitcoin/blob/eltoo-anyprevout/test/functional/simulate_eltoo.py. He blogged about it, too. https://yakshaver.org/2021/07/26/first.html He seems to have something similar for covenants, but it's WIP: https://github.com/remyers/bitcoin/blob/covenant-anyprevout/test/functional/feature_apocovenant.py. https://yakshaver.org/2021/11/18/covenants.html. His APO page looks like a good reference on the topic: https://yakshaver.org/bitcoin/#anyprevout. --- Original Message --- Le vendredi 22 avril 2022 à 1:44 PM, rot13maxi a écrit : > Good morning darosior, > > Do you know if there is a working implementation of APO somewhere that people > can use to try out some of the proposed usecases? For example, it would be > great to see what eltoo would actually look like on an APO signet. Or to see > some working code for a vault using covenants in an APO world. > > I haven’t seen much in the way of APO implementations recently, but I also > haven’t gone looking, so would appreciate any links! > > Thanks > > On Fri, Apr 22, 2022 at 7:11 AM, darosior via bitcoin-dev > wrote: > >> I would like to know people's sentiment about doing (a very slightly tweaked >> version of) BIP118 in place of >> (or before doing) BIP119. >> >> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for over >> 6 years. It presents proven and >> implemented usecases, that are demanded and (please someone correct me if >> i'm wrong) more widely accepted than >> CTV's. >> >> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made >> optional [0], can emulate CTV just fine. >> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more >> expensive to use. But we can consider CTV >> an optimization of APO-AS covenants. >> >> CTV advocates have been presenting vaults as the flagship usecase. Although >> as someone who've been trying to >> implement practical vaults for the past 2 years i doubt CTV is necessary nor >> sufficient for this (but still >> useful!), using APO-AS covers it. And it's not a couple dozen more virtual >> bytes that are going to matter for >> a potential vault user. >> >> If after some time all of us who are currently dubious about CTV's stated >> usecases are proven wrong by onchain >> usage of a less efficient construction to achieve the same goal, we could >> roll-out CTV as an optimization. In >> the meantime others will have been able to deploy new applications >> leveraging ANYPREVOUT (Eltoo, blind >> statechains, etc..[1]). >> >> Given the interest in, and demand for, both simple covenants and better >> offchain protocols it seems to me that >> BIP118 is a soft fork candidate that could benefit more (if not most of) >> Bitcoin users. >> Actually i'd also be interested in knowing if people would oppose the APO-AS >> part of BIP118, since it enables >> CTV's features, for the same reason they'd oppose BIP119. >> >> [0] That is, to not commit to the other inputs of the transaction (via >> `sha_sequences` and maybe also >> `sha_amounts`). Cf >> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message. >> >> [1] https://anyprevout.xyz/ "Use Cases" section >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] ANYPREVOUT in place of CTV
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
Re: [bitcoin-dev] mempool transaction witness-replacement
Hi Larry, Thanks for bringing this up. I'm curious to know if this is helpful for pinning as long as you have a way to statically analyze Script to prevent witness stuffing [0]. I agree it *could* still be useful for miners, but subject to all the complications of RBF. > An advantage of this mempool-accept policy change is that it's > miner-incentive compatible (miners would prefer to mine a transaction > with a higher feerate). There is more to be "miner-incentive compatible" than increasing feerate. For instance, the latest RBF discussions made the miner incentive to maximize absolute fees more well known. I think the same goes for witness replacement: if you don't have as many MBs of transaction you are comfortable with in your mempool, you don't want it to shrink further. Antoine [0] See the 'Malleability' section of https://bitcoin.sipa.be/miniscript/. Note however this currently only applies to third party malleability (in pinning attacks the aversary is internal to the contract). On the other hand Miniscript already allows you to get the maximum satisfaction size, so you can cover for the worst case scenario already. --- Original Message --- Le mardi 22 mars 2022 à 8:04 PM, Larry Ruane via bitcoin-dev a écrit : > Greetings list, > > This is my first time posting here. > > Question for you: > > Should the Bitcoin Core mempool replace an existing transaction with one > > that has the same txid (having the same effect, same spends and outputs) > > but a sufficiently smaller witness (different wtxid) and thus a higher > > feerate? This is what https://github.com/bitcoin/bitcoin/pull/24007 > > proposes, and I'd like to get opinions on two questions: > > 1. Is this a beneficial change? Specifically, is anyone creating an > > application that would broadcast transactions with the same txid but > > different witnesses as an earlier transaction? > > 2. If this change has benefit, what should be considered a sufficiently > > better feerate or reduction in witness size? > > An advantage of this mempool-accept policy change is that it's > > miner-incentive compatible (miners would prefer to mine a transaction > > with a higher feerate). But there is of course a code complexity cost, > > and transaction-relay DoS concern. > > Being miner-incentive compatible is good, but is that sufficient > > justification for merging? I'm posting to the mailing list in hopes that > > there are use-cases that we (the PR authors) aren't aware of. Please > > reply here or on the PR if you can think of any. > > A perhaps subtle advantage: This PR may provide a defense against a > > mempool pinning attack: if you have a transaction shared with other > > parties, and one of them broadcasts the transaction with a bloated > > witness (thus intentionally reducing the feerate in hopes of delaying > > or preventing confirmation), you currently have no way to change it. > > If there is an application out there that uses same-txid-different-witness > > transactions shared between counterparties, this PR would help make > > those applications safe. > > Question 2 gets at a DoS tradeoff: If the new transaction may have > > only a very slightly smaller witness, an attacker might re-broadcast it > > many times, consuming a lot of relay bandwidth, and CPU to update > > the mempool. On the other hand, if the new transaction must have a much > > smaller witness, then it wouldn't be possible to replace a transaction with > > a beneficially-smaller one. > > This could be a per-node setting, but it's desirable for the node > > network to largely agree on relay policies (although a configuration > > option might be useful for testing and experimentation). > > Background: > > Bip125 (Replace-by-fee) allows an incoming transaction to replace one > > or more existing conflicting transactions if certain DoS-mitigation > > conditions are met: > > https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md > > Witness-replacement is similar to RBF, but differs in a few ways: > > - RBF rule 4 requires an absolute fee increase, which is not possible if > > the txid isn't changing (since the inputs, outputs, and amounts must be > > the same). So if transaction witness-replacement (same txid but different > > wtxid) is allowed, it can't be considered just a special case of an RBF, > > although it may have some similar policies (and for the same reasons). > > - With witness-replacement, it's not necessary to evict mempool > > descendant transactions because their inputs' txid references to their > > parent (who is being replaced) remain valid. > > - The new transaction replaces exactly one existing transaction since > > the inputs are the same. (In general, with RBF, the new transaction may > > conflict-out multiple existing mempool transactions, namely, all that > > spend the same outputs as the new transaction.) > > - RBF requires the original transaction to signal replaceability > > (rule 1). This
Re: [bitcoin-dev] Covenants and feebumping
Hi ZmnSCPxj, Thanks for the feedback. The DLC idea is interesting but you are centralizing the liveness requirements, effectively creating a SPOF: in order to bypass the revocation clause no need to make sure to down each and every watchtower anymore, just down the oracle and you are sure no revocation transaction can be pushed. > Okay, let me see if I understand your concern correctly. > When using a signature challenge, the concern is that you need to presign > multiple versions of a transaction with varying feerates. I was thinking of having a hot key (in this case probably shared amongst the monitors) where they would sign the right fee level at broadcast time. Pre-signing makes it quickly too many signatures (and kills the purpose of having covenants in the first place). > And you have a set of network monitors / watchtowers that are supposed to > watch the chain on your behalf in case your ISP suddenly hates you for no > reason. > The more monitors there are, the more likely that one of them will be > corrupted by a miner and jump to the highest-feerate version, overpaying fees > and making miners very happy. > Such is third-party trust. > Is my understanding correct? Your understanding of the tradeoff is correct. --- Original Message --- Le jeudi 17 mars 2022 à 12:29 AM, ZmnSCPxj a écrit : > Good morning Antoine, > > > For "hot contracts" a signature challenge is used to achieve the same. I > > know the latter is imperfect, since > > > > the lower the uptime risk (increase the number of network monitors) the > > higher the DOS risk (as you duplicate > > > > the key).. That's why i asked if anybody had some thoughts about this and > > if there was a cleverer way of doing > > > > it. > > Okay, let me see if I understand your concern correctly. > > When using a signature challenge, the concern is that you need to presign > multiple versions of a transaction with varying feerates. > > And you have a set of network monitors / watchtowers that are supposed to > watch the chain on your behalf in case your ISP suddenly hates you for no > reason. > > The more monitors there are, the more likely that one of them will be > corrupted by a miner and jump to the highest-feerate version, overpaying fees > and making miners very happy. > > Such is third-party trust. > > Is my understanding correct? > > A cleverer way, which requires consolidating (but is unable to eliminate) > third-party trust, would be to use a DLC oracle. > > The DLC oracle provides a set of points corresponding to a set of feerate > ranges, and commits to publishing the scalar of one of those points at some > particular future block height. > > Ostensibly, the scalar it publishes is the one of the point that corresponds > to the feerate range found at that future block height. > > You then create adaptor signatures for each feerate version, corresponding to > the feerate ranges the DLC oracle could eventually publish. > > The adaptor signatures can only be completed if the DLC oracle publishes the > corresponding scalar for that feerate range. > > You can then send the adaptor signatures to multiple watchtowers, who can > only publish one of the feerate versions, unless the DLC oracle is hacked and > publishes multiple scalars (at which point the DLC oracle protocol reveals a > privkey of the DLC oracle, which should be usable for slashing some bond of > the DLC oracle). > > This prevents any of them from publishing the highest-feerate version, as the > adaptor signature cannot be completed unless that is what the oracle > published. > > There are still drawbacks: > > * Third-party trust risk: the oracle can still lie. > > * DLC oracles are prevented from publishing multiple scalars; they cannot be > prevented from publishing a single wrong scalar. > > * DLCs must be time bound. > > * DLC oracles commit to publishing a particular point at a particular fixed > time. > > * For "hot" dynamic protocols, you need the ability to invoke the oracle at > any time, not a particular fixed time. > > The latter probably makes this unusable for hot protocols anyway, so maybe > not so clever. > > Regards, > > ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Covenants and feebumping
e 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 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 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 usinga specific vault standard and guess other leaves and >> replace the witness to use the highest-feeratespending path. You could >> require a signature from any of the participants. Or, at the cost of >> anadditional 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 > 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, a
[bitcoin-dev] Covenants and feebumping
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
Re: [bitcoin-dev] [Lightning-dev] [Pre-BIP] Fee Accounts
> Necromancing might be a reasonable name for attacks that work by getting an > out-of-date version of a tx mined. It's not an "attack"? There is no such thing as an out-of-date transaction, if you signed and broadcasted it in the first place. You can't rely on the fact that a replacement transaction would somehow invalidate a previous version of it. --- Original Message --- Le samedi 19 février 2022 à 10:39 AM, Peter Todd a écrit : > On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote: > > > > 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). > > Mentioning "computation" when talking about transactions is misleading: > > blockchain transactions have nothing to do with computation. > > > Something that only increases possibility to make progress cannot be > > > > pinning. > > It is incorrect to say that all use-cases have the property that any version > of > > a transaction being mined is progress. > > > 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). > > Necromancing might be a reasonable name for attacks that work by getting an > > out-of-date version of a tx mined. > > > 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. > > Your understanding of how OpenTimestamps calendars work appears to be > > incorrect. There is no chain of unconfirmed transactions. Rather, OTS > calendars > > use RBF to update the timestamp tx with a new merkle tip hash for to all > > outstanding per-second commitments once per new block. In high fee situations > > it's normal for there to be dozens of versions of that same tx, each with a > > slightly higher feerate. > > OTS calendars can handle any of those versions getting mined. But older > > versions getting mined wastes money, as the remaining commitments still need > to > > get mined in a subsequent transaction. Those remaining commitments are also > > delayed by the time it takes for the next tx to get mined. > > There are many use-cases beyond OTS with this issue. For example, some > entities > > use "in-place" replacement for update low-time-preference settlement > > transactions by adding new txouts and updating existing ones. Older versions > of > > those settlement transactions getting mined rather than the newer version > > wastes money and delays settlement for the exact same reason it does in OTS. > > If fee accounts or any similar mechanism get implemented, they absolutely > > should be opt-in. Obviously, using a currently non-standard nVersion bit is a > > possible approach. Conversely, with CPFP it may be desirable in the settlement > > case to be able to prevent outputs from being spent in the same block. Again, > > an nVersion bit is a possible approach. > > > 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. > > I just checked: all the BTC transaction accellerator services I could find > look > > to be either scams, or very expensive. We need compelling reasons to make this > > nuisance attack significantly cheaper. > > > 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. > > As I said above, no it doesn't. > > -- > > https://petertodd.org 'peter'[:-1]@petertodd.org > > Lightning-dev mailing list > > lightning-...@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Thoughts on fee bumping
James, You seem to imply that the scenario described isn't prevented today. It is. The mempool acceptance for a replacement not only depend on the transaction feerate but also the transaction fee [0]. That's why i raised it in the first place... Antoine [0] https://github.com/bitcoin/bitcoin/blob/66636ca438cb65fb18bcaa4540856cef0cee2029/src/validation.cpp#L944-L947 Of course if you are evicting transactions then you don't have the issue i mentioned, so it's fine doing so. Original Message On Feb 17, 2022, 19:18, James O'Beirne < james.obei...@gmail.com> wrote: >> Is it really true that miners do/should care about that? > > De facto, any miner running an unmodified version of bitcoind doesn't > care about anything aside from ancestor fee rate, given that the > BlockAssembler as-written orders transactions for inclusion by > descending ancestor fee-rate and then greedily adds them to the block > template. [0] > > If anyone has any indication that there are miners running forks of > bitcoind that change this behavior, I'd be curious to know it. > > Along the lines of what AJ wrote, optimal transaction selection is > NP-hard (knapsack problem). Any time that a miner spends deciding how > to assemble the next block is time not spent grinding on the nonce, and > so I'm skeptical that miners in practice are currently doing anything > that isn't fast and simple like the default implementation: sorting > fee-rate in descending order and then greedily packing. > > But it would be interesting to hear evidence to the contrary. > > --- > > You can make the argument that transaction selection is just a function > of mempool contents, and so mempool maintenance criteria might be the > thing to look at. Mempool acceptance is gated based on a minimum > feerate[1]. Mempool eviction (when running low on space) happens on > the basis of max(self_feerate, descendant_feerate) [2]. So even in the > mempool we're still talking in terms of fee rates, not absolute fees. > > That presents us with the "is/ought" problem: just because the mempool > *is* currently gating only on fee rate doesn't mean that's optimal. But > if the whole point of the mempool is to hold transactions that will be > mined, and if there's good reason that txns are chosen for mining based > on fee rate (it's quick and good enough), then it seems like fee rate > is the approximation that should ultimately prevail for txn > replacement. > > [0]: > https://github.com/bitcoin/bitcoin/blob/master/src/node/miner.cpp#L310-L320 > [1]: > https://github.com/bitcoin/bitcoin/blob/master/src/txmempool.cpp#L1106 > [2]: > https://github.com/bitcoin/bitcoin/blob/master/src/txmempool.cpp#L1138-L1144___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
> Such a construct would present dangerous implications to the fungibility of > individual UTXOs by introducing a totally different risk model in being paid > with such a coin compared to any other coin not encumbered by such a condition How is that different from being paid in an altcoin? It seems to me that being able to say "sorry, your money isn't good here" is at the heart of Bitcoin's security (similarly to enforcing the network rules with your node). If someone can coerce you into using another currency, you've already lost. Now there is left the influence on the system of an user being coerced into using gov coin (on another chain) or an encumbered bit coin. Sure the latter would decrease the supply available, but that's already possible to do today. --- Original Message --- Le vendredi 11 février 2022 à 7:12 PM, digital vagabond via bitcoin-dev a écrit : > This is Shinobi (can verify out of band at @brian_trollz on Twitter, I only > signed up to the list with this email to read initially, but feel like I > should reply to this as I think I am one of the only people in this space who > has voiced concerns with recursive covenants). > > My concerns don't really center specifically around recursion itself > necessarily, but unbounded recursion in combination with too much > generality/flexibility in what types of conditions future UTXOs can be > encumbered with based on the restriction of such covenants. Forgive the hand > waiving arguments without getting into specific opcodes, but I would > summarize my concerns with a hypothetical construct that I believe would be > incredibly damaging to fungibility. Imagine a covenant design that was > flexible enough to create an encumbrance like this: a script specifies a > specific key in a multisig controlled by some authority figure (or a branch > in the script that would allow unilateral control by such an authority), and > the conditions of the covenant would perpetually require than any spend from > the covenant can only be sent to a script involving that key from said > authority, preventing by consensus any removal of that central authorities > involvement in control over that UTXO. Such a construct would present > dangerous implications to the fungibility of individual UTXOs by introducing > a totally different risk model in being paid with such a coin compared to any > other coin not encumbered by such a condition, and also potentially introduce > a shift in the scope of what a 51% attack could accomplish in terms of > permanent consequences attempting to coerce coins into such covenants, as > opposed to right now only being able to accomplish censorship or temporary > network disruption. > > I know that such a walled garden could easily be constructed now with > multisig and restrictions on where coins can be withdrawn to from exchanges > or whatever place they initially purchased from, as is demonstrated by the > implementation of the Asset Management Platform by Blockstream for use on > Liquid with regulated equity tokens, but I think the important distinction > between such non-consensus system designed to enforce such restrictions and a > recursive covenant to accomplish the same is that in the case of a > multisig/non-consensus based system, exit from that restriction is still > possible under the consensus rules of the protocol. If such a construct was > possible to build with a recursive covenant enforced by consensus, coins > encumbered by such a covenant would literally be incapable of escaping those > restrictions without hardforking the protocol, leaving any such UTXOs > permanently non-fungible with ones not encumbered by such conditions. > > I'm not that deeply familiar with all the working pieces involved in the > recent TXHASH + CSFS proposal, and whether such a type of overly (IMO) > generalized recursion would be possible to construct, but one of the reasons > CTV does not bother me in terms of such concerns is the inability to > infinitely recurse in such a generalized way given the requirements to > exactly specify the destination of future spends in constructing a chain of > CTV encumbrances. I'd very much appreciate any feedback on my concerns, and > if this side tracks the discussion I apologize, but I felt given the issue > has been mentioned a few times in this thread it was appropriate for me to > voice the concerns here so they could be addressed directly. > > On Fri, Feb 11, 2022 at 11:42 AM James O'Beirne via bitcoin-dev > wrote: > >> I don't oppose recursive covenants per se, but in prior posts I have >> expressed uncertainty about proposals that enable more "featureful" >> covenants by adding more kinds of computation into bitcoin script. >> >> Not that anyone here is necessarily saying otherwise, but I am very >> interested in limiting operations in bitcoin script to "verification" (vs. >> "computation") to the extent practical, and instead encourag
Re: [bitcoin-dev] Thoughts on fee bumping
Well because in the example i gave you this decreases the miner's reward. The rule of increasing feerate you stated isn't always economically rationale. Note how it can also be extended, for instance if the miner only has 1.5vMB of txs and is not assured to receive enough transactions to fill 2 blocks he might be interested in maximizing absolute fees, not feerate. Sure, we could make the argument that long term we need a large backlog of transactions anyways.. But that'd be unfortunately not in phase with today's reality. Original Message On Feb 11, 2022, 00:51, James O'Beirne wrote: >> It's not that simple. As a miner, if i have less than 1vMB of transactions >> in my mempool. I don't want a 10sats/vb transaction paying 10sats by a >> 100sats/vb transaction paying only 1sats. > > I don't understand why the "<1vMB in the mempool" case is even worth > consideration because the miner will just include the entire mempool in the > next block regardless of feerate.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Thoughts on fee bumping
(I have not yet read the recent posts on RBF but i wanted to react on the "additive feerate".) > # Purely additive feerate bumps should never be impossible It's not that simple. As a miner, if i have less than 1vMB of transactions in my mempool. I don't want a 10sats/vb transaction paying 10sats by a 100sats/vb transaction paying only 1sats. Apart from that i very much agree with the approach of taking a step back and reframing, with CPFP being inadapted long term (wasteful, not useful for delegating fee bumping (i'm surprised i didn't mention it publicly but it makes it unsuitable for Revault for instance), and the current carve-out rule makes it only suitable for 2-party protocols), and the `diff` approach. All that again with the caveat that i need to update myself on the recent proposals. Original Message On Feb 10, 2022, 20:40, James O'Beirne via bitcoin-dev wrote: > There's been much talk about fee-bumping lately, and for good reason - > dynamic fee management is going to be a central part of bitcoin use as > the mempool fills up (lord willing) and right now fee-bumping is > fraught with difficulty and pinning peril. > > Gloria's recent post on the topic[0] was very lucid and highlights a > lot of the current issues, as well as some proposals to improve the > situation. > > As others have noted, the post was great. But throughout the course > of reading it and the ensuing discussion, I became troubled by the > increasing complexity of both the status quo and some of the > proposed remedies. > > Layering on special cases, more carve-outs, and X and Y percentage > thresholds is going to make reasoning about the mempool harder than it > already is. Special consideration for "what should be in the next > block" and/or the caching of block templates seems like an imposing > dependency, dragging in a bunch of state and infrastructure to a > question that should be solely limited to mempool feerate aggregates > and the feerate of the particular txn package a wallet is concerned > with. > > This is bad enough for protocol designers and Core developers, but > making the situation any more intractable for "end-users" and wallet > developers feels wrong. > > I thought it might be useful to step back and reframe. Here are a few > aims that are motivated chiefly by the quality of end-user experience, > constrained to obey incentive compatibility (i.e. miner reward, DoS > avoidance). Forgive the abstract dalliance for a moment; I'll talk > through concretes afterwards. > > # Purely additive feerate bumps should never be impossible > > Any user should always be able to add to the incentive to mine any > transaction in a purely additive way. The countervailing force here > ends up being spam prevention (a la min-relay-fee) to prevent someone > from consuming bandwidth and mempool space with a long series of > infinitesimal fee-bumps. > > A fee bump, naturally, should be given the same per-byte consideration > as a normal Bitcoin transaction in terms of relay and block space, > although it would be nice to come up with a more succinct > representation. This leads to another design principle: > > # The bandwidth and chain space consumed by a fee-bump should be minimal > > Instead of prompting a rebroadcast of the original transaction for > replacement, which contains a lot of data not new to the network, it > makes more sense to broadcast the "diff" which is the additive > contribution towards some txn's feerate. > > This dovetails with the idea that... > > # Special transaction structure should not be required to bump fees > > In an ideal design, special structural foresight would not be needed > in order for a txn's feerate to be improved after broadcast. > > Anchor outputs specified solely for CPFP, which amount to many bytes of > wasted chainspace, are a hack. It's probably uncontroversial at this > point to say that even RBF itself is kind of a hack - a special > sequence number should not be necessary for post-broadcast contribution > toward feerate. Not to mention RBF's seemingly wasteful consumption of > bandwidth due to the rebroadcast of data the network has already seen. > > In a sane design, no structural foresight - and certainly no wasted > bytes in the form of unused anchor outputs - should be needed in order > to add to a miner's reward for confirming a given transaction. > > Planning for fee-bumps explicitly in transaction structure also often > winds up locking in which keys are required to bump fees, at odds > with the idea that... > > # Feerate bumps should be able to come from anywhere > > One of the practical downsides of CPFP that I haven't seen discussed in > this conversation is that it requires the transaction to pre-specify the > keys needed to sign for fee bumps. This is problematic if you're, for > example, using a vault structure that makes use of pre-signed > transactions. > > What if the key you specified n the anchor outputs for a bunch of > pre-
Re: [bitcoin-dev] A fee-bumping model
es by a factor of N, any miner with a fraction >> > larger than 1/N of the >> > network hashrate now has an incentive to censor your transaction at first >> > to get you to panic. > >> Yes I think miner-harvesting attacks should be weighed carefully in the >> design of offchain contracts fee-bumping strategies, at least in the future >> when the mining reward exhausts further. > > Miner-harvesting (such cool naming!) is interesting, but I want to clarify > the value of N - I don't think it's the factor by which you increase the fees > on just your transaction. > To codify: your transaction pays a fee of `f1` right now and might pay a fee > of `f2` in a later block that the miner expects to mine with 1/N probability. > The economically rational miner isn't incentivized if simply `f2 = N * f1` > unless their mempool is otherwise empty. > By omitting your transaction in this block, the miner can include another > transaction/package paying `g1` fees instead, so they lose `f1-g1` in fees > right now. In the future block, they have the choice between collecting `f2` > or `g2` (from another transaction/package) in fees, so their gain is > `max(f2-g2, 0)`. > So the equation is more like: a miner with 1/N of the hashrate, employing > this censorship strategy, gains only if `max(f2-g2, 0) > N * (f1-g1)`. More > broadly, the miner only profits if `f2` is significantly higher than `g2` and > `f1` is about the same feerate as everything else in your mempool: it seems > like they're betting on how much you _overshoot_, not how much you bump. Right. I was talking in the worst case where they don't have a replacement package with a feerate of `g1`. They are even more incentivized to try that if they do. Since `f1` is already expected to be the next block feerate, by how much you bump is technically by how much your overshoot. So much for dismissing your fee estimator! > Slightly related question: in contracts, generally, the timelock deadline is > revealed in the script, so the miner knows how "desperate" we are right? For P2WSH, yes. > Is that a problem? I don't think so. As long as we don't bump the feerate by the N factor mentioned above, they have an incentive to try to take the fees while they still can (or someone else will). > For Revault, if your Cancel transaction is a keypath spend (I think I > remember reading that somewhere?) and you don't reveal the script, they don't > see your timelock deadline yes? It *could* be once we move to Taproot (2weeks). Yep! They would only know about it on a successful spend which would reveal the branch with the timelock. It's a good point in that the attack above could be made impractical through privacy. Although i don't think it's realistic: due to the necessary script-path spends it would be trivial to cluster coins managed by a Revault setup and deduce whether a given transaction is a Cancel with very high accuracy. > Again, thanks for the digging and sharing. :) Thanks for the interest and getting me to re-think through this! Best, Antoine > Best, > Gloria > > On Tue, Nov 30, 2021 at 3:27 PM darosior via bitcoin-dev > wrote: > >> Hi Antoine, >> >> Thanks for your comment. I believe for Lightning it's simpler with regard to >> the management of the UTxO pool, but harder with regard to choosing >> a threat model. >> Responses inline. >> >>> For any opened channel, ensure the confirmation of a Commitment transaction >>> and the children HTLC-Success/HTLC-Timeout transactions. Note, in the >>> Lightning security game you have to consider (at least) 4 types of players >>> moves and incentives : your node, your channel counterparties, the miners, >>> the crowd of bitcoin users. The number of the last type of players is >>> unknown from your node, however it should not be forgotten you're in >>> competition for block space, therefore their block demands bids should be >>> anticipated and reacted to in consequence. With that remark in mind, >>> implications for your LN fee-bumping strategy will be raised afterwards. >>> >>> For a LN service provider, on-chain overpayments are bearing on your >>> operational costs, thus downgrading your economic competitiveness. For the >>> average LN user, overpayment might price out outside a LN non-custodial >>> deployment, as you don't have the minimal security budget to be on your own. >> >> I think this problem statement can be easily generalised to any offchain >> contract. And your points stand for all of them. >> "For any opened contract, ensure at any point the con
Re: [bitcoin-dev] A fee-bumping model
market. > Reputation, which might be to avoid due to the latent centralization effect, > might be hard to stack and audit reliably for an emergency mechanism running, > hopefully, once in a halvening period. Maybe maybe some cryptographic or > economically based mechanism on slashing or swaps could be found... Unfortunately, given current mining centralisation, pools are in a very good position to offer pretty decent SLAs around that. With a block space insurance, you of course don't need all these convoluted fee-bumping hacks. I'm very concerned that large stakeholders of the "offchain contracts ecosystem" would just go this (easier) way and further increase mining centralisation pressure. I agree that a cryptography-based scheme around this type of insurance services would be the best way out. > Antoine > > Le lun. 29 nov. 2021 à 09:34, darosior via bitcoin-dev > a écrit : > >> Hi everyone, >> >> Fee-bumping is paramount to the security of many protocols building on >> Bitcoin, as they require the >> confirmation of a transaction (which might be presigned) before the >> expiration of a timelock at any >> point after the establishment of the contract. >> >> The part of Revault using presigned transactions (the delegation from a >> large to a smaller multisig) >> is no exception. We have been working on how to approach this for a while >> now and i'd like to share >> what we have in order to open a discussion on this problem so central to >> what seem to be The Right >> Way [0] to build on Bitcoin but which has yet to be discussed in details (at >> least publicly). >> >> I'll discuss what we came up with for Revault (at least for what will be its >> first iteration) but my >> intent with posting to the mailing list is more to frame the questions to >> this problem we are all >> going to face rather than present the results of our study tailored to the >> Revault usecase. >> The discussion is still pretty Revault-centric (as it's the case study) but >> hopefully this can help >> future protocol designers and/or start a discussion around what everyone's >> doing for existing ones. >> >> ## 1. Reminder about Revault >> >> The part of Revault we are interested in for this study is the delegation >> process, and more >> specifically the application of spending policies by network monitors >> (watchtowers). >> Coins are received on a large multisig. Participants of this large multisig >> create 2 [1] >> transactions. The Unvault, spending a deposit UTxO, creates an output paying >> either to the small >> multisig after a timelock or to the large multisig immediately. The Cancel, >> spending the Unvault >> output through the non-timelocked path, creates a new deposit UTxO. >> Participants regularly exchange the Cancel transaction signatures for each >> deposit, sharing the >> signatures with the watchtowers they operate. They then optionally [2] sign >> the Unvault transaction >> and share the signatures with the small multisig participants who can in >> turn use them to proceed >> with a spending. Watchtowers can enforce spending policies (say, can't >> Unvault outside of business >> hours) by having the Cancel transaction be confirmed before the expiration >> of the timelock. >> >> ## 2. Problem statement >> >> For any delegated vault, ensure the confirmation of a Cancel transaction in >> a configured number of >> blocks at any point. In so doing, minimize the overpayments and the UTxO set >> footprint. Overpayments >> increase the burden on the watchtower operator by increasing the required >> frequency of refills of the >> fee-bumping wallet, which is already the worst user experience. You are >> likely to manage a number of >> UTxOs with your number of vaults, which comes at a cost for you as well as >> everyone running a full >> node. >> >> Note that this assumes miners are economically rationale, are incentivized >> by *public* fees and that >> you have a way to propagate your fee-bumped transaction to them. We also >> don't consider the block >> space bounds. >> >> In the previous paragraph and the following text, "vault" can generally be >> replaced with "offchain >> contract". >> >> ## 3. With presigned transactions >> >> As you all know, the first difficulty is to get to be able to unilaterally >> enforce your contract >> onchain. That is, any participant must be able to unilaterally bum
[bitcoin-dev] A fee-bumping model
Hi everyone, Fee-bumping is paramount to the security of many protocols building on Bitcoin, as they require the confirmation of a transaction (which might be presigned) before the expiration of a timelock at any point after the establishment of the contract. The part of Revault using presigned transactions (the delegation from a large to a smaller multisig) is no exception. We have been working on how to approach this for a while now and i'd like to share what we have in order to open a discussion on this problem so central to what seem to be The Right Way [0] to build on Bitcoin but which has yet to be discussed in details (at least publicly). I'll discuss what we came up with for Revault (at least for what will be its first iteration) but my intent with posting to the mailing list is more to frame the questions to this problem we are all going to face rather than present the results of our study tailored to the Revault usecase. The discussion is still pretty Revault-centric (as it's the case study) but hopefully this can help future protocol designers and/or start a discussion around what everyone's doing for existing ones. ## 1. Reminder about Revault The part of Revault we are interested in for this study is the delegation process, and more specifically the application of spending policies by network monitors (watchtowers). Coins are received on a large multisig. Participants of this large multisig create 2 [1] transactions. The Unvault, spending a deposit UTxO, creates an output paying either to the small multisig after a timelock or to the large multisig immediately. The Cancel, spending the Unvault output through the non-timelocked path, creates a new deposit UTxO. Participants regularly exchange the Cancel transaction signatures for each deposit, sharing the signatures with the watchtowers they operate. They then optionally [2] sign the Unvault transaction and share the signatures with the small multisig participants who can in turn use them to proceed with a spending. Watchtowers can enforce spending policies (say, can't Unvault outside of business hours) by having the Cancel transaction be confirmed before the expiration of the timelock. ## 2. Problem statement For any delegated vault, ensure the confirmation of a Cancel transaction in a configured number of blocks at any point. In so doing, minimize the overpayments and the UTxO set footprint. Overpayments increase the burden on the watchtower operator by increasing the required frequency of refills of the fee-bumping wallet, which is already the worst user experience. You are likely to manage a number of UTxOs with your number of vaults, which comes at a cost for you as well as everyone running a full node. Note that this assumes miners are economically rationale, are incentivized by *public* fees and that you have a way to propagate your fee-bumped transaction to them. We also don't consider the block space bounds. In the previous paragraph and the following text, "vault" can generally be replaced with "offchain contract". ## 3. With presigned transactions As you all know, the first difficulty is to get to be able to unilaterally enforce your contract onchain. That is, any participant must be able to unilaterally bump the fees of a transaction even if it was co-signed by other participants. For Revault we can afford to introduce malleability in the Cancel transaction since there is no second-stage transaction depending on its txid. Therefore it is pre-signed with ANYONECANPAY. We can't use ANYONECANPAY|SINGLE since it would open a pinning vector [3]. Note how we can't leverage the carve out rule, and neither can any other more-than-two-parties contract. This has a significant implication for the rest, as we are entirely burning fee-bumping UTxOs. This opens up a pinning vector, or at least a significant nuisance: any other party can largely increase the absolute fee without increasing the feerate, leveraging the RBF rules to prevent you from replacing it without paying an insane fee. And you might not see it in your own mempool and could only suppose it's happening by receiving non-full blocks or with transactions paying a lower feerate. Unfortunately i know of no other primitive that can be used by multi-party (i mean, >2) presigned transactions protocols for fee-bumping that aren't (more) vulnerable to pinning. ## 4. We are still betting on future feerate The problem is still missing one more constraint. "Ensuring confirmation at any time" involves ensuring confirmation at *any* feerate, which you *cannot* do. So what's the limit? In theory you should be ready to burn as much in fees as the value of the funds you want to get out of the contract. So... For us it'd mean keeping for each vault an equivalent amount of funds sitting there on the watchtower's hot wallet. For Lightning, it'd mean keeping an equivalent amount of funds as the sum of all your channels balances sitting th
Re: [bitcoin-dev] death to the mempool, long live the mempool
Hi Niftynei, I share the concerns raised about direct connections to mining pools being a centralization pressure: de-anonymization and an inevitable higher barrier to entry. Making it more difficult to reach smaller miners is another one. Regarding fee estimation you state: > Initial feerate estimation would need to be based on published blocks, not > pending transactions (as this information would no longer be available) The current fee estimation algorithm uses both, not only the pending transactions (game-able). Although i agree that past-block(s) based fee estimation isn't that bad, it's worth mentioning that not tracking the confirmation time of relayed transactions drops the ability to have a target in the estimation. That is it's good enough for time-sensitive transactions where you always target the next block but not for other usages which usually target a few dozen of blocks in the future. However, as we discussed recently, i do believe their is a failure mode here. On one hand, directly connecting to pools is already possible today and pretty effective given the current mining centralization. On the other hand, it's not possible for most pre-signed txs protocols to reliably (securely) use the Bitcoin tx relay network today to propagate time-sensitive transactions. Furthermore, even if these are fixed (eg via package-relay for (today's) Lightning Network) it seems like there is a stark contrast between what "L2 [0] protocols" need and what regular node operators can reasonably offer. A node operator is incentivized to relay transactions to: - have more privacy *if* they use their node to broadcast transactions (make it less distinguishable which relayed transaction comes from the wallet) - provide fee estimates *if* they need them - avoid bandwidth spikes on block connection (compact block relay) L2s would ideally need the tx relaying nodes to do more computation and lift their DOS mitigations for all miner-incentive-compatible transactions to eventually be relayed to most of the miners. One obvious instance of such a dilemma is the RBF rules. Such protocols getting increasingly developed and used create a strong incentive for their users/stakeholders to directly connect to mining pools [1], with all the consequences for the network mentioned in the replies to your mail and elsewhere. Before we get to this, i think there is a strong case for an opt-in and publicly accessible "overlay" network to relay miner-incentive compatible transactions with higher DOS limits. This way the cost is not imposed to L1 node runners, and L2s can operate with more safety assumptions without (entirely) falling for centralization. Thanks for publicly starting this discussion, Antoine [0] Using "L2s" for the sake of brevety, whatever it means i mean "protocols using pre-signed Bitcoin transactions which timely confirmation might be a security requirement". [1] Wen block space insurance contracts ‐‐‐ Original Message ‐‐‐ Le mardi 26 octobre 2021 à 4:56 AM, lisa neigut via bitcoin-dev a écrit : > Hi all, > > In a recent conversation with @glozow, I had the realization that the mempool > is obsolete and should be eliminated. > > Instead, users should submit their transactions directly to mining pools, > preferably over an anonymous communication network such as tor. This can > easily be achieved by mining pools running a tor onion node for this express > purpose (or via a lightning network extension etc) > > Mempools make sense in a world where mining is done by a large number of > participating nodes, eg where the block template is constructed by a majority > of the participants on the network. In this case, it is necessary to > socialize pending transaction data to all participants, as you don’t know > which participant will be constructing the winning block template. > > In reality however, mempool relay is unnecessary where the majority of > hashpower and thus block template creation is concentrated in a > semi-restricted set. > > Removing the mempool would greatly reduce the bandwidth requirement for > running a node, keep intentionality of transactions private until > confirmed/irrevocable, and naturally resolve all current issues inherent in > package relay and rbf rules. It also resolves the recent minimum relay > questions, as relay is no longer a concern for unmined transactions. > > Provided the number of block template producing actors remains beneath, say > 1000, it’d be quite feasible to publish a list of tor endpoints that nodes > can independently + directly submit their transactions to. In fact, merely > allowing users to select their own list of endpoints to use alternatively to > the mempool would be a low effort starting point for the eventual replacement. > > On the other hand, removing the mempool would greatly complicate solo mining > and would also make BetterHash proposals, which move the block template > construction away from a
Re: [bitcoin-dev] Proposal: Package Mempool Accept and Package RBF
Hi Gloria, > In summary, it seems that the decisions that might still need attention/input > from devs on this mailing list are: > 1. Whether we should start with multiple-parent-1-child or 1-parent-1-child. > 2. Whether it's ok to require that the child not have conflicts with mempool > transactions. I would like to point out that package relay is not only useful in Lightning's adversarial scenarii but also for a better user experience of CPFP. Take for instance a wallet managing coins it can only spend using pre-signed transactions. It may batch these coins into a single transaction, but only after broadcasting the pre-signed tx for each of these coins. So for a 3 utxos it'd be: coin1 -> pres. tx1 - | coin2 -> pres. tx2 - | - - - spending transaction coin3 -> pres. tx3 - | Now all these pre-signed transactions are pre-signed with a fixed feerate, which might be below the mempool minimum fee at the time of broadcast. This is a usecase for multiple-parents-1-child packages. This is also something we do for Revault: you have pre-signed Unvault transactions, each have a CPFP output [0]. Since their confirmation is not security critical, you'd really want to batch the child-fee-paying tx. Regarding 2. i did not come up with a reason for dropping this rule (yet?) since if you need to replace the child you can use individual submission, and if you need to replace the parent the child itself does not conflict anymore. Thanks for the effort put into requesting feedback, Antoine [0] https://github.com/revault/practical-revault/blob/master/transactions.md#unvault_tx___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode
Hi Anthony, This post is a follow-up to your insight on Twitter [0], sent here for better posterity, accessibility and readability than Twitter. And also to motivate this idea by giving another concrete [1] usecase for it. Revault [2] is a multi-party "vault" protocol. It involves 2 sets of participants that may or may not intersect (although i expect the second one to often be a subset of the first one). The stakeholders, analogous to the "cold keys", receive coins on a (large) N-of-N multisig and presign an Unvault transaction which creates an Unvault output which pays to either the (small) K-of-M multisig of the managers after a timelock or to the N-of-N immediately (allowing for a Cancel transaction). This allows for partial delegation of the funds, and some automated policies (can't broadcast the Unvault outside business hours, can't unvault more than BTC a week, etc..) that can be enforced by watchtowers. That's nice, but it would be even nicer if we could have policies on the Spend transaction (the one created by the managers to spend the Unvault output) itself to further restrict how the coin can move [3]. But in order to do so, you'd need the managers to disclaim the Spend transaction they are going to use before broadcasting the Unvault and somehow commit to it at unvaulting time. Apart from stupid hacks [4] i could not find a reasonable covenant design as a solution to this issue. It think TLUV fixes this. The idea (your idea, actually) is to receive coins not to a N-of-N anymore but to a Taproot with a branch which contains the manager multisig + a TLUV which would replace the current branch being executed by a CSV + CTV which input hash value will be taken from the witness stack at Unvault broadcast. Therefore chosen by the managers at spending time, and available for the entire duration of the timelock. So, the scripts would be something like (assuming CAT, CTV, TLUV): V = max acceptable fees D = "CTV CSV DROP 1" C = "<32 bytes> D" B = " CHECKSIG CHECKSIGADD ... CHECKSIGADD EQUALVERIFY IN_OUT_AMOUNT SUB LESSTHANOREQUAL DUP VERIFY SIZE 32 EQUALVERIFY <0xc0 | len(D) + 32 + 1 | 0x20> SWAP CAT "Tapleaf" SHA256 DUP CAT SWAP CAT SHA256 0 SWAP 2 TLUV " A = " CHECKSIGVERIFY CHECKSIGVERIFY ... CHECKSIG" The deposit output ScriptPubKey would be Taproot(A, B) [5]. The unvault output ScriptPubKey would be Taproot(A, C). This also allows for a lot more flexibility (batching at the Unvault level [7], use RBF instead of more wasteful CPFP, etc..) and creates a number of problems [6] on which i won't expand on. But it does the most important part: it enables it. Looking forward to more feedback on your proposal! Thanks, Antoine [0] https://twitter.com/ajtowns/status/1435884659146059776?s=20 [1] we've proposed Revault a year and a half ago, have been building it since. We should have a first version released soon (tm). [2] https://github.com/revault [3] technically we do optionally offer this at the moment, but at the expense of a reduction of security and a pretty ugly hack: by using "anti-replay" oracles (cosigning servers that are only going to sign only once for a given prevout) [4] the last bad idea to date is "have ANYPREVOUT, presign the Unvault with SIGHASH_SINGLE, enforce that the Unvault output is only spent with a transaction spending :1 and have managers append an output to the Unvault enforcing a covenant just before broadcast" [5] as a branch because i don't know how to use the keypath spend for a multisig with cold keys (yet). [6] as such you'd need a sig for canceling but not for unvaulting, so it reverses the security model from "can't do anything til everyone signed" to "can steal until everyone has signed" so you'd need a TLUV for the cancel spending path as well, but then how to make this covenant non-replayable, flexible enough to feebump but not enough be vulnerable to pining, etc.. [7] Note that this means all Cancel must be confirmed to recover the funds but a single one needs to in order to prevent a spending. ‐‐‐ Original Message ‐‐‐ Le jeudi 9 septembre 2021 à 8:53 AM, Anthony Towns via bitcoin-dev a écrit : > On Thu, Sep 09, 2021 at 04:41:38PM +1000, Anthony Towns wrote: > > > I'll split this into two emails, this one's the handwavy overview, > > > > the followup will go into some of the implementation complexities. > > (This is informed by discussions with Greg, Matt Corallo, David Harding > > and Jeremy Rubin; opinions and mistakes my own, of course) > > First, let's talk quickly about IN_OUT_AMOUNT. I think the easiest way to > > deal with it is just a single opcode that pushes two values to the stack; > > however it could be two opcodes, or it could even accept a parameter > > letting you specify which input (and hence which corresponding output) > > you're talking about (-1 meaning the current input perhaps). > > Anyway, a big complication here is that amounts in
Re: [bitcoin-dev] Note on Sequence Lock Upgrades Defect
Hi Jeremy, I think it would be nice to have and suggested something similar (enforce minimality) in the context of Miniscript a few months ago [0]. However your code: const bool seq_is_reserved = (txin.nSequence < CTxIn::SEQUENCE_FINAL-2) && ( // when sequence is set to disabled, it is reserved for future use ((txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) != 0) || // when sequence has bits set outside of the type flag and locktime mask, // it is reserved for future use. ((~(CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG | CTxIn::SEQUENCE_LOCKTIME_MASK) & txin.nSequence) != 0) ); Would effectively prevent Lightning Network commitment transactions from relaying. The protocol uses a hack encoding the commitment transaction numbering in the part of nSequence (and nLockTime) without consensus meaning. This both sets the LOCKTIME_DISABLE_FLAG and uses bits outside of the mask. [0] https://github.com/rust-bitcoin/rust-miniscript/pull/246#issue-671512626 [1] https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#commitment-transaction ‐‐‐ Original Message ‐‐‐ Le lundi 6 septembre 2021 à 5:17 AM, Jeremy via bitcoin-dev a écrit : > BIP 68 says >= 2:This specification defines the meaning of sequence numbers > for transactions with an nVersion greater than or equal to 2 for which the > rest of this specification relies on. > BIP-112 says not < 2 > // Fail if the transaction's version number is not set high > // enough to trigger BIP 68 rules. > if (static_cast(txTo->nVersion) < 2) return false; > > A further proof that this needs fix: the flawed upgradable semantic exists in > script as well as in the transaction nSeqeunce. we can't really control the > transaction version an output will be spent with in the future, so it would > be weird/bad to change the semantic in transaction version 3. > > -- > [@JeremyRubin](https://twitter.com/JeremyRubin)https://twitter.com/JeremyRubin > > On Sun, Sep 5, 2021 at 7:36 PM David A. Harding wrote: > >> On Fri, Sep 03, 2021 at 08:32:19PM -0700, Jeremy via bitcoin-dev wrote: >>> Hi Bitcoin Devs, >>> >>> I recently noticed a flaw in the Sequence lock implementation with respect >>> to upgradability. It might be the case that this is protected against by >>> some transaction level policy (didn't see any in policy.cpp, but if not, >>> I've put up a blogpost explaining the defect and patching it >>> https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/ >> >> Isn't this why BIP68 requires using tx.version=2? Wouldn't we just >> deploy any new nSequence rules with tx.version>2? >> >> -Dave___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent
> Note, I think that the tx mutation proposal relies on interactivity in the > worst-case scenario where a counterparty wants to increase its fee-bumping > output from the contract balance. This interactivity may lure a counterparty > to alway lock the worst-case fee-bumping reserve in the output. I believe > anchor output enables more "real-time" fee-bumping reserve adjustment ? Anchor outputs / malleability allow for real-time adjustment of long-lived contracts (for which the today worst case is much larger than the worst case estimated at the contract creation time). However it's a really interested for vaults, as you have multiple parties with the same goal (getting this Cancel transaction confirmed). Therefore you have this slight "tragedy of the commons" of whose fee-bumping wallet is going to pay for sponsoring the next Cancel (and it's exacerbated by / for external redundancy providers). With this approach, fees are taxed from the shared coins, so there is no pernicious incentive to delay the broadcast of your revocation transaction in the hope that another watchtower will pay the fee instead of you. I think this applies to multi-party channels too, by having some kind of a shared budget. You would also have a large UX improvement with regard to the fee-bumping wallet: no need to have one (fb wallet refills are really *really* poor UX) one and maintain a nice laid-out UTXO pool. In the end, both approaches seem desirable: the output for paying most of the fees from shared coins, therefore dwarfing the "tragedy of the common" concerns, and the malleability to still be able to dynamically allocate more funds to feebump in case of a black swan event (but essentially needs a single refill at startup as it's never spent from). As a side note, this can "just" be implemented by exchanging N (varying depending on the granularity) signatures with increasing feerates. Again, this might be reasonable in some usecases but not others (eg if you are already generating tons of sigs, or have longer chain of unconfirmed transactions). > Cheers, > Antoine > > [0] Incautious sighash alleability is unsafe. Be careful, otherwise kitties > will perish by the thousands : > https://github.com/revault/practical-revault/pull/83 > > Le dim. 6 juin 2021 à 22:28, Lloyd Fournier a écrit : > >> Hi Antione, >> >> Thanks for bringing up this important topic. I think there might be another >> class of solutions over input based, CPFP and sponsorship. I'll call them tx >> mutation schemes. The idea is that you can set a key that can increase the >> fee by lowering a particular output after the tx is signed without >> invalidating the signature. The premise is that anytime you need to bump the >> fee of a transaction you must necessarily have funds in an output that are >> going to you and therefore you can sacrifice some of them to increase the >> fee. This is obviously destructive to txids so child presigned transactions >> will have to use ANYPREVOUT as in your proposal. The advantage is that it >> does not require keeping extra inputs around to bump the fee. >> >> So imagine a new opcode OP_CHECKSIG_MUTATED >> . >> This would check that is valid against if the >> current transaction had the output at reduced by . To >> make this more efficient, if the public key is one byte: 0x02 it references >> the taproot *external key* (similar to how ANYPREVOUT uses 0x01 to refer to >> internal key[1]). >> Now for our protocol we want both parties (p1 and p2) to be able to fee bump >> a commitment transaction. They use MuSig to sign the commitment tx under the >> external key with a decent fee for the current conditions. But in case it >> proves insufficient they have added the following two leaves to their key in >> the funding output as a backup so that p1 and p2 can unilaterally bump the >> fee of anything they sign spending from the funding output: >> >> 1. OP_CHECKSIG_MUTATED(0, 0x02, , ) >> OP_CHECKSIGADD(p1-fee-bump-key, ) OP_2 >> OP_NUMEQUALVERIFY >> 2. OP_CHECKSIG_MUTATED(1, 0x02, , ) >> OP_CHECKSIGADD(p2-fee-bump-key, ) OP_2 >> OP_NUMEQUALVERIFY >> >> where <...> indicates the thing comes from the witness stack. >> So to bump the fee of the commit tx after it has been signed either party >> takes the and adds a signature under their fee-bump-key >> for the new tx and reveals their fee bump leaf. is >> checked against the old transaction while the fee bumped transaction is >> checked against the fee bump key. >> >> I know I have left out how to change mempool eviction rules to accommodate >> this kind of fee bumping without DoS or pinning attacks but hopefully I have >> demonstrated that this class of solutions also exists. >> >> [1] https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawiki >> >> Cheers, >> >> LL >> >> On Fri, 28 May 2021 at 07:13, Antoine Riard via bitcoin-dev >> wrote: >> >>> Hi, >>> >>> This post is pursuing a wider discussion around better f
Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent
Hi, Another thing to consider when comparing these two techniques is anti-fee sniping protection. If you are going to feebump directly your revocation transaction by adding inputs to it, the nLockTime has already been signed in advance. Therefore your are sponsoring a transaction that could be included in any reorged block. This is not a big deal for now but i'm concerned it may become one, especially since this type of transaction might be the highest fee-paying ones on the network (there is a lot at stake). Having a new sighash type not masking the nLockTime so that it can be set by the feebumper could help with this, even though the presumably low pre-signed fee can still be snipped (since the ALL signature is added to the feebump inputs). The recent BIP proposal by Chris Belcher [0] also just uncovered (to me) a new hack: if the feebumping coins are less than 65,535 blocks old, we could also set the nSequence of these coins to achieve the same purpose [1]. And this can be done with today's Bitcoin! Antoine P. [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019048.html [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002412.html ‐‐‐ Original Message ‐‐‐ Le vendredi 28 mai 2021 à 6:13 AM, Antoine Riard a écrit : >> Unfortunately, ACP | SINGLE is trivially pinable [0] (TL;DR: i can just >> attach an output paying immediately to me, and construct a tx chain spending >> it). We are using ACP | ALL for Revault, >> which is the reason why we need a well laid-out pool of fee-bumping UTXOs >> (as you need to consume them entirely). > > Oh yes, I should have mentioned this pinning vector. The witnessScript I've > in mind to make secure that type of chain of transactions would be one MuSig > key for all contract participants, where signature are committed with > SIGHASH_ANYPREVOUT | SIGHASH_IOMAP, one pubkey per participant to lockdown > the transaction with SIGHASH_ALL. I think it works and prevents malicious > in-flight attachment of input/output to a multi-party transaction ? > >> I believe that it's better to broadcast a single fan-out transaction >> creating your entire UTXO pool in advance. You could create one coin per >> contract you are watching which value would be >> used to bump your transaction feerate from the presigned one to -say- the >> average feerate over the past month, and then have smaller coins that you >> could attach to any transaction to bump >> by a certain threshold (say, 10sat/vbyte). You would create as many small >> coin as your reserve algorithm tells you (which could be "i need to be able, >> worst case, to close all my contracts >> with the worst historical feerate." or (fractional reserve version) "i need >> to be able, worst case, to close 10% of my contracts at the average feerate >> of the past year, the remaining ones sorry >> for my loss"). [1] > >> This method is both much more optimal (though you need to sometimes incur >> the cost of many small additional inputs) and also makes sure that your >> feebump does not depend on the confirmation of a first stage transaction (as >> you can only RBF with new inputs if they are confirmed). > > I see, so you spread your bumping UTXO pool in two ranges : at least one > bumping utxo per contract, and a subpool of emergency smaller coins, ready to > be attached on any contract. I think this strategy makes sense for vaults as > you can afford a bunch of small coins at different feerates, spending the > ones not used afterwards. And higher cells of feerate reserve as the worst > historical feerate are relatively not that much compared to locked-in vaults > value. That said, I'm more dubious about LN, where node operators might not > keep the worst-case fee-bumping reserve, as the time value of the coins > aren't worth the channel liquidity at stake. > >> Why not just attaching it at the tail of the chain? Bumping the last child >> with additional input would effectively be a CPFP for the entire chain in >> this case. > > Yes, input-based bumping targeting the tail of the chain works at the > transaction level. But if you assume bounded visibility of network mempools, > one of your counterparties might have broadcast a concurrent state, thus > making your CPFP irrelevant for propagation. Though smarter tx-relay > techniques such as "attach-on-contract-utxo-root" CPFP (or also known as > "blinded CPFP") might solve this issue. > > Le jeu. 27 mai 2021 à 17:45, darosior a écrit : > >> Hi, >> >>> ## Input-Based >>> >>> I think input-based fee-bumping has been less studied as fee-bumping >>> primitive for L2s [1]. One variant of input-based fee-bumping usable today >>> is the leverage of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleability >>> flags. If the transaction is the latest stage of the contract, a bumping >>> input can be attached just-in-time, thus increasing the feerate of the >>> whole package. >> >> Unfortunately, ACP
Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent
> Oh yes, I should have mentioned this pinning vector. The witnessScript I've > in mind to make secure that type of chain of transactions would be one MuSig > key for all contract participants, where signature are committed with > SIGHASH_ANYPREVOUT | SIGHASH_IOMAP, one pubkey per participant to lockdown > the transaction with SIGHASH_ALL. I think it works and prevents malicious > in-flight attachment of input/output to a multi-party transaction ? So something like `or(and(pk(FB),pk(A)),and(pk(FB),pk(B)),and(pk(FB),pk(C)))` with each `or` in their own leaf? I think it works, but only if the keys `A`, `B`, `C` are "hot", as in available to the fee-bumper. For Revault it means introducing a key for each watchtower in the vaults descriptors, which is meh but technically feasible since they are identified. This kinda break our replication model though. On the other end for Lightning... You'd need to know what watchtower (or your node) is going to be willing to feebump? The descriptor can very quickly get very convoluted: `or(and(pk(FB),pk(A_NODE)),and(pk(FB),pk(A_WT1)),and(pk(FB),pk(A_WT2)),and(pk(FB),pk(B_NODE)),and(pk(FB),pk(B_WT1)),and(pk(FB),pk(B_WT2)))` for only 2 participants in a channel where one of either the node or two watchtowers (identified beforehand !!) can feebump. > I see, so you spread your bumping UTXO pool in two ranges : at least one > bumping utxo per contract, and a subpool of emergency smaller coins, ready to > be attached on any contract. I think this strategy makes sense for vaults as > you can afford a bunch of small coins at different feerates, spending the > ones not used afterwards. And higher cells of feerate reserve as the worst > historical feerate are relatively not that much compared to locked-in vaults > value. That said, I'm more dubious about LN, where node operators might not > keep the worst-case fee-bumping reserve, as the time value of the coins > aren't worth the channel liquidity at stake. Yes. That's a bit concerning, but i guess it's a tradeoff. Amusingly the incentive is at odds with routing: you want to keep your channels unbalanced if you run on fractional fee-bumping reserves so that if things go south you can still salvage most of your funds by focusing your fee-bumping on the unbalanced (to you) channels :p . > Yes, input-based bumping targeting the tail of the chain works at the > transaction level. But if you assume bounded visibility of network mempools, > one of your counterparties might have broadcast a concurrent state, thus > making your CPFP irrelevant for propagation. Though smarter tx-relay > techniques such as "attach-on-contract-utxo-root" CPFP (or also known as > "blinded CPFP") might solve this issue. Oh, yes, good point.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent
Hi, > ## Input-Based > > I think input-based fee-bumping has been less studied as fee-bumping > primitive for L2s [1]. One variant of input-based fee-bumping usable today is > the leverage of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleability flags. > If the transaction is the latest stage of the contract, a bumping input can > be attached just-in-time, thus increasing the feerate of the whole package. Unfortunately, ACP | SINGLE is trivially pinable [0] (TL;DR: i can just attach an output paying immediately to me, and construct a tx chain spending it). We are using ACP | ALL for Revault, which is the reason why we need a well laid-out pool of fee-bumping UTXOs (as you need to consume them entirely). > Input-based (today): If the bumping utxo is offering an adequate feerate > point in function of network mempools congestion at time of broadcast, only 1 > input. If a preliminary fan-out transaction to adjust feerate point must be > broadcasted first, 1 input and 2 outputs more must be accounted for. Onchain > footprint: 2 inputs + 3 outputs. I believe that it's better to broadcast a single fan-out transaction creating your entire UTXO pool in advance. You could create one coin per contract you are watching which value would be used to bump your transaction feerate from the presigned one to -say- the average feerate over the past month, and then have smaller coins that you could attach to any transaction to bump by a certain threshold (say, 10sat/vbyte). You would create as many small coin as your reserve algorithm tells you (which could be "i need to be able, worst case, to close all my contracts with the worst historical feerate." or (fractional reserve version) "i need to be able, worst case, to close 10% of my contracts at the average feerate of the past year, the remaining ones sorry for my loss"). [1] This method is both much more optimal (though you need to sometimes incur the cost of many small additional inputs) and also makes sure that your feebump does not depend on the confirmation of a first stage transaction (as you can only RBF with new inputs if they are confirmed). > Input-based (today): In case of rebroadcast, the fee-bumping input is > attached to the root of the chain of transactions and as such breaks the > chain validity in itself. Beyond the rebroadcast of the updated root under > replacement policy, the remaining transactions must be updated and > rebroadcast. Rebroadcast footprint: the whole chain of transactions. Why not just attaching it at the tail of the chain? Bumping the last child with additional input would effectively be a CPFP for the entire chain in this case. Thanks for starting this discussion :) Antoine [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017835.html [1] Credits to Jacob Swambo, who came up with the single fan-out transaction and with whom i'm discussing how to practically apply these ideas to Revault.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic
Hi Antoine, Thank you for the disclosure. > * Onchain DLC/Coinswap/Vault : Those contract protocols have also multiple > stages of execution with time-sensitive transactions opening the way to > pinning attacks. Those protocols being non-deployed or in early phase, I > would recommend that any in-protocol competing transactions explicitly signal > RBF. For what it's worth, Revault isn't vulnerable as all transactions signal RBF and there is no way to sneak a non-signaling competing transaction (as long as the CSV isn't matured yet). Thanks, Antoine (the other one)___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Hardware wallets and "advanced" Bitcoin features
Hi Antoine, and Kevin, >> * Proposed improvement: The HW should display the Bitcoin Script itself when >> possible (including the unlock conditions). > > What level of script literacy are you assuming on your users ? I can see > enterprise/hobbyist folks to know enough of Script to understand the intended > behavior but I don't think that's a reasonable assumption for your average > user. Of course, Miniscript Policy makes things easier, but IMHO, I still > hope to see some mature, higher-level language (e.g Ivy) to ease script > semantic understanding and thus widen the crowd of users. No Script literacy should be assumed. I believe with Miniscript Policy (with possibly alias instead of pubkeys, see below) we are to the highest possible level of abstraction without loss of meaning for user verification. I don't think Ivy would be helpful here. Also, as Kevin mentioned, anything would be better than an address anyways. > Further, I would do a bit on UX research on the correctness model expected by > your users. I.e if they fail to verify accordingly, are they losing funds, > transaction doesn't confirm, transaction doesn't even propagate, etc. You > should also make assumptions on the mental resources you're required from > them. Time-sensitive L2 protocols have a wide scope to check, e.g not > verifying the nSequence/nLocktime fields can provoke funds failures. Regarding the correctness, with the OP threat model (laptop compromised), for any transaction: if they fail to verify the locking policy, fund loss. Re nSeq: If we trust the HM, and the HM support Miniscript, it must be able to satisfy inputs in a sa[n,f]e way. >> This applies to pre-signed transaction protocols especially well as the >> template of these transactions could be known > and recognized by the HW. Typically for Revault, the HW could display: > "Unvault Transaction, all expected pubkeys > present in the script". > > In the future, I would expect templates of high-security protocols like > vaults to be part of the trusted computing base of any decent HW. I think > good standards there would avoid HW vendors to come with some kind of > certified-templates scheme and thus having to bless custom scripts of every > vaults implementations. +1 >> Then there is PSBT support and the maximum transaction size limit for > these: we need more transparency from HW manufacturers on their li > mitations. > > I understand them, Script is full of subtleties, taproot is likely to have > more of them and if you take sighash malleability that's not something you > want your average user to play with. Maybe it > would be better to come up with a first wave of script features on which you > expect transparency ? For sure, OP_CSV is a good candidate. I agree that rather than supporting all of Script it would be better to support a "safe", analyzable subset of Script: that's Miniscript :p I also believe supporting any new Script capabilities without Miniscript would be a huge footgun. It would also ease the upgrade to Tapscript. >> Once any input of a (pre-signed)transaction is > spent, this transaction isn't valid anymore. Most pre-signed transactions > protocols are used today as a form of defense > mechanism, spending any input would mean incapacitating the entire defense > mechanism. > > I don't see the exact issue here. E.g in Lightning, even if you pre-sign a > justice transaction punishing every revokeable outputs on counterparty > transaction, and one input is spent, will current HWs prevent you to-resign > an updated justice transaction ? That's because in Revault we don't require HMs for watchtowers. Funds holders are expected to have a routine signing of cancel / deterrent / unvault transactions and share them with the watchtowers. The attack Kevin is talking about is a (expected-to-be-stateless) HM will happily sign a cancel of deterrent transaction that spends an already-signed input. So let's say a fund holder sends a signature for an Unvault tx and a Cancel tx that does not spend this Unvault to their watchtower. The watchtower would cringe (in our v0 protocol, send an NACK): but the NACK isn't handled by the HM therefore at the end of the day the already-compromised laptop is ensuring the (statefull) validity of the signature. Thanks, Antoine > Le jeu. 14 janv. 2021 à 13:46, Kevin Loaec via bitcoin-dev > a écrit : > >> Hello everyone, >> >> I would like to start a discussion on improving Hardware Wallets. >> >> My approach to this right now is from a vault protocol we are developing >> (Revault, [1]), and its Hardware Wallet >> requirements. I started working on a Github Issue in our repo [2], other >> people recommended us to do a more general >> discussion on the mailing list instead as it could benefit many other >> protocols and users. >> This email discusses improvements that would benefit everyone, and some that >> are more suitable for "layer 2" or pre- >> signed transactions proto
Re: [bitcoin-dev] Revault: a multi-party vault architecture
The fee bumping construction I described in the previous post is potentially vulnerable to transaction pinning. We shared a SINGLE | ANYONECANPAY signature for the first (and only) input of revaulting transactions to allow any party to append an input and an output in order to bump the transaction fees. An user would either append an input signed with ALL, or replace their SINGLE | ANYONECANPAY signature with one using ALL before broadcasting the transaction. This allowed one party to decrease the transaction fees down to the minimum relay fees, and possibly pin the transaction by spending their added single-pubkey output. We now exchange ALL | ANYONECANPAY signatures for revaulting transactions to restrict the creation of a new output only spendable by one party. The fee bumping is now done in two stages (to avoid consuming an entire utxo) : Unvaulting transaction | vault prevout | unvault output |-- \ \ Revaulting transaction \ --- | unvault prevout | new vault output | --- | fee bump prevout | / Single-party wallet transaction / -/ | wallet prevout | fee bump output|-- - | wallet change output | This construction isn't perfect as a malicious party could still pin its fee bumping transaction and prevent the other stakeholders from **immediatly** replacing this input, because of the second rule of BIP125 : > The replacement transaction may only include an unconfirmed input if that > input was included > in one of the original transactions. However, I think it's preferable as : - Depending on the unvault CSV, the honest party might pay a high fee to have the fee-bumping transaction confirm in one of the next two blocks, and then use this now confirmed output as an additional input of the revaulting transaction. - If the amount is consequent, the honest party may sacrifice an entire confirmed utxo from its wallet (effectively skipping the fee bumping transaction). - It's realistic to expect, for such an application, users' wallets to have a pool of confirmed utxo that might be sacrificed if the amount is consequent AND the CSV is so small (which is anyway a bad idea in the first place) that you are not sure to have the fee bumping transaction to be confirmed before its maturity, ). Thanks, Antoine / Darosior ‐‐‐ Original Message ‐‐‐ Le vendredi, avril 24, 2020 5:00 PM, darosior a écrit : > Hi all, > > Kevin Loaec and I have been working on a new multiparty vault architecture > and I think it reached the point where we’d welcome some feedback. > > Intended usage and limitations > > === > > The aim is to secure the shared storage of coins without relying on a trusted > third party and by disincentivizing theft attempts, while not restricting the > usage of the funds for day-to-day operations. > > Revault uses N-of-N multisigs and thus does not protect against intentional > locking of funds (such as refusal to sign, or key erasure). Therefore it > assumes its users (likely companies with already on-going agreements between > shareholders) to be able to solve intentional blockage outside the Bitcoin > network (such as through legal contracts). > > The actual architecture > > > > We called it revault as it relies on pre-signed and revocable (revaultable) > transactions. > The users pre-sign a transaction chain as the only used way to spend from a > vault output. > They would have signed a set of transactions to either cancel a spend attempt > or lock the funds for some time beforehand. The funds are always better > locked for a long time than stolen. > > The transactions > > > > The system is composed of mainly 6 transaction types (with N the number of > stakeholders) : > > - The “vault” transaction which pays to a N-of-N, by which funds are > received. > - The “emergency” transaction, which spends the vault output and pays to a > [here goes a > high value]-days timelocked N-of-N (with N differents but statics keys, > assumed to be physically stored in hard(/long) to access locations). > > - The “unvault” transaction, which spends the vault output and pays to > [either the vault’s N-of-N, or after X blocks
[bitcoin-dev] Revault: a multi-party vault architecture
Hi all, Kevin Loaec and I have been working on a new multiparty vault architecture and I think it reached the point where we’d welcome some feedback. Intended usage and limitations == The aim is to secure the shared storage of coins without relying on a trusted third party and by disincentivizing theft attempts, while not restricting the usage of the funds for day-to-day operations. Revault uses N-of-N multisigs and thus does not protect against intentional locking of funds (such as refusal to sign, or key erasure). Therefore it assumes its users (likely companies with already on-going agreements between shareholders) to be able to solve intentional blockage outside the Bitcoin network (such as through legal contracts). The actual architecture === We called it revault as it relies on pre-signed and revocable (revaultable) transactions. The users pre-sign a transaction chain as the only used way to spend from a vault output. They would have signed a set of transactions to either cancel a spend attempt or lock the funds for some time beforehand. The funds are always better locked for a long time than stolen. The transactions The system is composed of mainly 6 transaction types (with N the number of stakeholders) : - The “vault” transaction which pays to a N-of-N, by which funds are received. - The “emergency” transaction, which spends the vault output and pays to a [here goes a high value]-days timelocked N-of-N (with N differents but statics keys, assumed to be physically stored in hard(/long) to access locations). - The “unvault” transaction, which spends the vault output and pays to [either the vault’s N-of-N, or *after X blocks* to a subset of the stakeholders AND a co-signing server]. - The “unvault emergency” transaction, which spends the unvault output and pays to the same script as the first emergency transaction. - The “cancel” transaction, which spends the unvault output and pays back to a new vault utxo. - The “spend” transaction, which spends the unvault output and pays to an external address (potentially contained in a list of destinations previously agreed-upon by all the stakeholders). The process --- The stakeholders would exchange the signatures of all the revaulting transactions after the reception of a new vault utxo, and then exchange the signatures of the unvaulting transaction. Before doing so, the coins are not available to be spent. In order to spend a vault, the subset of the stakeholders who manages the funds (for example, the traders of an investment fund) would make the cosigning server (which only signs a transaction once) sign the spend transaction. They would then present it to the other watchers which would ACK the spend (if paying to an authorized address), and broadcast the "unvault" transaction. Finally, and after X blocks have passed they would be able to broadcast the spend transaction. If a stakeholder's watcher detects an unvaulting transaction without knowing about its child “spend” transaction, it triggers an automatic “cancel” transaction (not encumbered by the timelock). At any point -even in the middle of a spend- any of the stakeholder can trigger an emergency transaction if anything nasty is happening. Any network watcher noticing the broadcast of an emergency transaction would also broadcast all other vaults’ emergency transactions. This network watching and revaulting power can be replicated (watchtowers) to further decrease the reliance on a single machine or internet access. Pre-signed transactions fun --- In order to avoid our security assumptions to be as weak as betting on the value of the feerate in the future, stakeholders exchange SINGLE | ANYONECANPAY signatures for the revaulting transactions and append their own as SIGHASH_ALL before broadcasting. They can add another input (and potentially output) in order to bump the fees before doing so. We protect ourselves from the bug by leveraging the fact the revaulting (namely the "emergency", "unvault emergency", and "cancel" transactions) only have *strictly* one input and one output. The change being part of the spend transaction. In addition, revaulting transactions may signal for RBF to cover a feerate increase after the broadcast. Anyhow, a significant breathing room can be added to the feerate as these transactions are not intended to be used under normal circumstances. Worth mentioning The original draft of this architecture was first designed by Kevin Loaec who was hired by NOIA to do so. It was inspired by Bryan Bishop’s single-party vault architecture (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017229.html), who published a demo implementation of it last week (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017755.html, https://github.com/kanzure/python-vaults). Kevin
