Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
I don't have a specific response to share at this moment, but I may make one later. But for the sake of elevating the discourse, I'd encourage people responding this to read through https://rubin.io/bitcoin/2021/12/04/advent-7/ as I think it has some helpful terminology and categorizations. I bring this up because I think that recursion is often given as a shorthand for "powerful" because the types of operations that support recursion typically also introduce open ended covenants, unless they are designed specially not to. As a trivial example a covenant that makes a coin spendable from itself to itself entirely with no authorization is recursive but fully enumerated in a sense and not particularly interesting or useful. Therefore when responding you might be careful to distinguish if it is just recursion which you take issue with or open ended or some combination of properties which severally might be acceptable. TL;DR there are different properties people might care about that get lumped in with recursion, it's good to be explicit if it is a recursion issue or something else. Cheers, Jeremy On Thu, Feb 10, 2022, 4:55 PM David A. Harding wrote: > On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev > wrote: > > Whether [recursive covenants] is an issue or not precluding this sort > > of design or not, I defer to others. > > For reference, I believe the last time the merits of allowing recursive > covenants was discussed at length on this list[1], not a single person > replied to say that they were opposed to the idea. > > I would like to suggest that anyone opposed to recursive covenants speak > for themselves (if any intelligent such people exist). Citing the risk > of recursive covenants without presenting a credible argument for the > source of that risk feels to me like (at best) stop energy[2] and (at > worst) FUD. > > -Dave > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019203.html > [2] > http://radio-weblogs.com/0107584/stories/2002/05/05/stopEnergyByDaveWiner.html > (thanks to AJ who told me about stop energy one time when I was > producing it) > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev wrote: > Whether [recursive covenants] is an issue or not precluding this sort > of design or not, I defer to others. For reference, I believe the last time the merits of allowing recursive covenants was discussed at length on this list[1], not a single person replied to say that they were opposed to the idea. I would like to suggest that anyone opposed to recursive covenants speak for themselves (if any intelligent such people exist). Citing the risk of recursive covenants without presenting a credible argument for the source of that risk feels to me like (at best) stop energy[2] and (at worst) FUD. -Dave [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019203.html [2] http://radio-weblogs.com/0107584/stories/2002/05/05/stopEnergyByDaveWiner.html (thanks to AJ who told me about stop energy one time when I was producing it) signature.asc Description: PGP signature ___ 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 >
Re: [bitcoin-dev] Thoughts on fee bumping
This is great in theory, but I think it kinda misses *why* the complexity keeps creeping in. We agree on (most of) the goals here, but the problem is the goals explicitly lead to the complexity, its not some software engineering failure or imagination failure that leads to the complexity. On 2/10/22 14:40, James O'Beirne via bitcoin-dev wrote: -snip- # 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: This is where *all* the complexity comes from. If our goal is to "ensure a bump increases a miner's overall revenue" (thus not wasting relay for everyone else), then we precisely *do* need > Special consideration for "what should be in the next > block" and/or the caching of block templates seems like an imposing > dependency Whether a transaction increases a miner's revenue depends precisely on whether the transaction (package) being replaced is in the next block - if it is, you care about the absolute fee of the package and its replacement. If it is not in the next block (or, really, not near a block boundary or further down in the mempool where you assume other transactions will appear around it over time), then you care about the fee *rate*, not the fee difference. > # 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 entirely misses the network cost. Yes, sure, we can send "diffs", but if you send enough diffs eventually you send a lot of data. We cannot simply ignore network-wide costs like total relay bandwidth (or implementation runtime DoS issues). # 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 This has nothing to do with fee bumping, though, this is only solved with covenants or something in that direction, not different relay policy. Coming down to earth, the "tabula rasa" thought experiment above has led me to favor an approach like the transaction sponsors design that Jeremy proposed in a prior discussion back in 2020[1]. How does this not also fail your above criteria of not wasting block space? Further, this doesn't solve pinning attacks at all. In lightning we want to be able to *replace* something in the mempool (or see it confirm soon, but that assumes we know exactly what transaction is in "the" mempool). Just being able to sponsor something doesn't help if you don't know what that thing is. Matt ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Thoughts on fee bumping
> 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
One quick thought to the proposal and perhaps to sponsors in general(didn't have time to go over original proposal again): Since sponsors can come from anywhere, the wallet application must have access to the mempool to know what inputs must be double spent to RBF the sponsor transaction. Seems like an important difference to be considered. On Fri, Feb 11, 2022 at 3:49 AM James O'Beirne via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> 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-signed txns is compromised? What if you'd like to be able to > dynamically select the wallet that bumps fees? CPFP does you no favors > here. > > There is of course a tension between allowing fee bumps to come from > anywhere and the threat of pinning-like attacks. So we should venture > to remove pinning as a possibility, in line with the first design > principle I discuss. > > > --- > > Coming down to earth, the "tabula rasa" thought experiment above
Re: [bitcoin-dev] Advancing the security of Neutrino using minimally trusted oracles
This would be very useful for the Validating Lightning Signer project, since we need to prove to a non-network connected signer that a UTXO has not been spent. It allows the signer to make sure the channel is still active. ( the related design doc is at https://gitlab.com/lightning-signer/docs/-/blob/master/oracle.md ) I think it would be useful if the oracles were non-interactive, so that they can communicate with the world over a one-way connection. This would reduce their attack surface. Instead of signing over a client-provided timestamp, we could pre-quantize the timestamp and emit attestations for each quantum time step. On Thu, Feb 10, 2022 at 11:10 AM enclade via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The design document which inspired Neutrino outlined the use of oracles to > provide a moderate level of confidence to lightweight clients in the > filters they have received from an untrusted source. Current > implementations of lightweight wallets using Neutrino either trust in a > single source, or a sampling of untrusted peers for this information. The > determinism of the filter headers allows for them to be simply and > compactly attested by a potentially large number of authoritative sources > with minimal loss in privacy. These sources could be exchanges, hardware > wallet manufacturers, block explorers, or other well known parties. > > The most obvious transport for these oracles is DNS, several[0][1] > implementations of tools exist which provide either headers or raw filter > data to clients by encoding it in record responses. With careful > construction oracles can operate using DNS with extremely low resource > requirements and attack surface, while providing a privacy maximizing > service to their clients. For situations where DNS is not appropriate, > other tools can aggregate the signatures into other formats as required. > > Clients could consider their view of the current network state to be > strong when several of their oracle sources present agreeing signatures, or > display an error to their user if no suitable number of attestations could > be found. Fault or fraud proofs can be generated by any party by simply > collecting differing signatures, for example if an oracle was presenting > disjoint filter headers from its peers the error would be readily apparent > and provable. > > - > > Host names and their associated keys would be baked into the binaries of > client software supporting the system, but their location and credentials > could be attested in a text file of their primary domain. For example, a > popular fictional exchange could advertise their ability to provide this > service using RFC5785. > > # curl https://pizzabase.com/.well-known/neutrino.txt > > 03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c...@neutrino.pizzabase.com > > The client would request its known sources for attestations, using the > current unix timestamp as a nonce. Use of a lower precision (for example > rounded to 60 seconds) allows the oracle to cache the result with a long > TTL, while allowing a client to poll with relatively high frequency if > required. > > # dig 6204dd70.neutrino.pizzabase.com > # dig 6204dd70.neutrino.blockspaghettini.com > # dig 6204dd70.neutrino.mtgnocchi.com > > Oracles would return the current block hash, hash of the tip of the > neutrino header chain, and a ECDSA signature over the data including the > requesting quantized timestamp. In totality giving the client sufficient > and portable evidence that their view of the state of the network has not > been tampered with, while maintaining as much privacy as possible. > > - > > RFC. > > [0]: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013417.html > [1]: https://github.com/mempoolco/chaindnsd > [2]: https://bitcoinheaders.net/ > ___ > 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] Thoughts on fee bumping
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-signed txns is compromised? What if you'd like to be able to dynamically select the wallet that bumps fees? CPFP does you no favors here. There is of course a tension between allowing fee bumps to come from anywhere and the threat of pinning-like attacks. So we should venture to remove pinning as a possibility, in line with the first design principle I discuss. --- Coming down to earth, the "tabula rasa" thought experiment above has led me to favor an approach like the transaction sponsors design that Jeremy proposed in a prior discussion back in 2020[1]. Transaction sponsors allow feerates to be bumped after a transaction's broadcast, regardless of the structure of the original transaction. No rebroadcast (wasted bandwidth) is required for the original txn data. No wasted chainspace on only-maybe-used prophylactic anchor outputs. The interface for end-users is very straightforward: if you want to bump fees, specify a transaction that contributes incrementally to package feerate for some txid. Simple. In the original discussion, there were a few
[bitcoin-dev] Advancing the security of Neutrino using minimally trusted oracles
The design document which inspired Neutrino outlined the use of oracles to provide a moderate level of confidence to lightweight clients in the filters they have received from an untrusted source. Current implementations of lightweight wallets using Neutrino either trust in a single source, or a sampling of untrusted peers for this information. The determinism of the filter headers allows for them to be simply and compactly attested by a potentially large number of authoritative sources with minimal loss in privacy. These sources could be exchanges, hardware wallet manufacturers, block explorers, or other well known parties. The most obvious transport for these oracles is DNS, several[0][1] implementations of tools exist which provide either headers or raw filter data to clients by encoding it in record responses. With careful construction oracles can operate using DNS with extremely low resource requirements and attack surface, while providing a privacy maximizing service to their clients. For situations where DNS is not appropriate, other tools can aggregate the signatures into other formats as required. Clients could consider their view of the current network state to be strong when several of their oracle sources present agreeing signatures, or display an error to their user if no suitable number of attestations could be found. Fault or fraud proofs can be generated by any party by simply collecting differing signatures, for example if an oracle was presenting disjoint filter headers from its peers the error would be readily apparent and provable. - Host names and their associated keys would be baked into the binaries of client software supporting the system, but their location and credentials could be attested in a text file of their primary domain. For example, a popular fictional exchange could advertise their ability to provide this service using RFC5785. # curl https://pizzabase.com/.well-known/neutrino.txt 03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c...@neutrino.pizzabase.com The client would request its known sources for attestations, using the current unix timestamp as a nonce. Use of a lower precision (for example rounded to 60 seconds) allows the oracle to cache the result with a long TTL, while allowing a client to poll with relatively high frequency if required. # dig 6204dd70.neutrino.pizzabase.com # dig 6204dd70.neutrino.blockspaghettini.com # dig 6204dd70.neutrino.mtgnocchi.com Oracles would return the current block hash, hash of the tip of the neutrino header chain, and a ECDSA signature over the data including the requesting quantized timestamp. In totality giving the client sufficient and portable evidence that their view of the state of the network has not been tampered with, while maintaining as much privacy as possible. - RFC. [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013417.html [1]: https://github.com/mempoolco/chaindnsd [2]: https://bitcoinheaders.net/ ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Pre-BIP] Fee Accounts
That's not really pinning; painning usually refers to pinning something to the bottom of the mempool whereas these mechanisms make it easier to guarantee that progress can be made on confirming the transactions you're interested in. Often times in these protocols "the call is coming inside the house". It's not a third party adding fees we are scared of, it's a direct party to the protocol! Sponsors or fee accounts would enable you to ensure the protocol you're working on makes forward progress. For things like Eltoo the internal ratchet makes this work well. Protocols which depend on in mempool replacements before confirmation already must be happy (should they be secure) with any prior state being mined. If a third party pays the fee you might even be happier since the execution wasn't on your dime. Cheers, Jeremy On Wed, Feb 9, 2022, 10:59 PM Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sat, Jan 01, 2022 at 12:04:00PM -0800, Jeremy via bitcoin-dev wrote: > > Happy new years devs, > > > > I figured I would share some thoughts for conceptual review that have > been > > bouncing around my head as an opportunity to clean up the fee paying > > semantics in bitcoin "for good". The design space is very wide on the > > approach I'll share, so below is just a sketch of how it could work which > > I'm sure could be improved greatly. > > > > Transaction fees are an integral part of bitcoin. > > > > However, due to quirks of Bitcoin's transaction design, fees are a part > of > > the transactions that they occur in. > > > > While this works in a "Bitcoin 1.0" world, where all transactions are > > simple on-chain transfers, real world use of Bitcoin requires support for > > things like Fee Bumping stuck transactions, DoS resistant Payment > Channels, > > and other long lived Smart Contracts that can't predict future fee rates. > > Having the fees paid in band makes writing these contracts much more > > difficult as you can't merely express the logic you want for the > > transaction, but also the fees. > > > > Previously, I proposed a special type of transaction called a "Sponsor" > > which has some special consensus + mempool rules to allow arbitrarily > > appending fees to a transaction to bump it up in the mempool. > > > > As an alternative, we could establish an account system in Bitcoin as an > > "extension block". > > > > > This type of design works really well for channels because the addition > of > > fees to e.g. a channel state does not require any sort of pre-planning > > (e.g. anchors) or transaction flexibility (SIGHASH flags). This sort of > > design is naturally immune to pinning issues since you could offer to > pay a > > fee for any TXID and the number of fee adding offers does not need to be > > restricted in the same way the descendant transactions would need to be. > > So it's important to recognize that fee accounts introduce their own kind > of > transaction pinning attacks: third parties would be able to attach > arbitrary > fees to any transaction without permission. This isn't necessarily a good > thing: I don't want third parties to be able to grief my transaction > engines by > getting obsolete transactions confirmed in liu of the replacments I > actually > want confirmed. Eg a third party could mess up OpenTimestamps calendars at > relatively low cost by delaying the mining of timestamp txs. > > Of course, there's an obvious way to fix this: allow transactions to > designate > a pubkey allowed to add further transaction fees if required. Which Bitcoin > already has in two forms: Replace-by-Fee and Child Pays for Parent. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > ___ > bitcoin-dev mailing list > bitcoin-dev@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
