* [bitcoin-dev] Rethinking “Incentive Compatibility” Within the Bitcoin Protocol @ 2022-12-10 12:10 John Carvalho 2022-12-11 13:58 ` Michael Folkson 2022-12-11 15:30 ` Daniel Edgecumbe 0 siblings, 2 replies; 5+ messages in thread From: John Carvalho @ 2022-12-10 12:10 UTC (permalink / raw) To: Bitcoin [-- Attachment #1: Type: text/plain, Size: 4085 bytes --] As we debate mempoolfullrbf, and I familiarize myself with related PRs from engineers trying to reign in all of the possible behaviors that make it inconsistent, I can’t help but think about how I see people using the term “incentive-compatible” and how it seems to be awfully presumptive. The idea that a single Bitcoin transaction can be “incentive-compatible” by simply restricting it to having a higher fee or fee rate is theoretical, likely narrow, and not totally objective. RBF is inherently a fee-minimization tool, which as a concept, as I understand “incentive-compatibility” to be about miners in this context, makes RBF to be anti-incentives; miners are fee maximizers. Miners want the most fees per block, and per lifetime, do they not? If miners, and the mempool, are prioritizing for the smallest txns with the highest fees, over the longest acceptable amount of time, this may conflict with extra-mempool behaviors that result in more txns per block / per lifetime. If this isn’t making sense yet, let me summarize by how such a problem would express: a per-transaction fee-minimized, fully replaceable mempool as policy, that appears to always require the highest fee per txn, but ultimately includes less txns per block and less fees per lifetime. Basically, less use cases, less users, less txns — all to enforce a misunderstood theory and predictive speculation of what people want out of the system and what miners will do about it. Simply, we probably want designs that fill blocks, and we don’t need to do anything at all to facilitate bidding on a use case like replacement. Bidding does not require protocol enforcement, it is miner-subjective. So why are we pursuing it? Why do we even have RBF? Why are we trying to clean up all of the mess RBF creates with more and more code? If bidding is already accepted as incentive-compatible, and Bitcoin already allows setting a fee, then replacement requires no special code at all. I would think a holistic definition of what is incentive-compatible would be something more like what is “market compatible” and enables the complementary goals & incentives of every user in the system to make it thrive. It has been shown that users control Bitcoin (UASF) and thus ultimately miners would be incentivized to do what users want, up to the point of inability or loss. Correct? So, in contrast, how would the opposite, a user-compatible design, express? Well, I think the idea of txns being able to signal intent and desired behavior is more interesting (more useful) than a mempool that overrides all intent with RBF, and possibly more incentive-compatible than mempoolfullrbf as concept. Since we can’t be sure what the market wants, but we can be sure that the more users we have, making the most possible txns, at the highest possible prices, will yield the most valuable Bitcoin, and thus the most hashpower, we could entertain giving users the most ways to express their intent, the most flexibility. The most basic design would be to simply have no mempool policy at all, and let market incentives emerge on their own, but we have a status quo to consider, and most users do not have the technical expertise to express their own policies with misc patches and hacks of their Bitcoin Core software. I know this is a bit of a high-level abstract perspective, but I think it is important to respect such dynamics when making smaller decisions. It certainly is not our charge to prioritize what miners want any more than any other user type, nor is it within our ability to predict the future or fully model incentives of all players across all use cases. I know some of you may scoff at my bias for use cases like zero-conf, but what I am trying to convey is a possible folly in active management, speculation, and misapplied game theory that may permeate many Bitcoin Core decisions and designs, even beyond the mempoolrbf / zero-conf debate. So, what to do? — John Carvalho CEO, Synonym.to [-- Attachment #2: Type: text/html, Size: 4129 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Rethinking “Incentive Compatibility” Within the Bitcoin Protocol 2022-12-10 12:10 [bitcoin-dev] Rethinking “Incentive Compatibility” Within the Bitcoin Protocol John Carvalho @ 2022-12-11 13:58 ` Michael Folkson 2022-12-11 14:56 ` John Carvalho 2022-12-11 15:30 ` Daniel Edgecumbe 1 sibling, 1 reply; 5+ messages in thread From: Michael Folkson @ 2022-12-11 13:58 UTC (permalink / raw) To: John Carvalho, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 7476 bytes --] Hey John There was a discussion [0] started by Lisa on the mailing list last year on whether there is any point to a full node maintaining a mempool last year which you may find interesting. I also recommend Gloria's presentation [1] from Adopting Bitcoin last year on transaction relay policy. I think those are better resources than anything I could write. But I guess I'd summarize it like this. The job of the P2P/mempool/policy protocol devs in setting defaults is to ensure anyone can effectively propagate a consensus valid transaction across the network ultimately making its way into miners' mempools without harming network health (full node uptime, DoS attacks etc) and to give higher layers built on top of the Bitcoin network the best chance to succeed. If they totally screwed up that job with the defaults or they were unable to cater for a particular use case within default policy then there is always the alternative of submitting consensus valid transactions directly to miners bypassing the P2P network entirely. But clearly it is much better if the P2P network functions smoothly and every transaction isn't forced to be directly submitted to a miner. It is policy too of course rather than consensus so if the full node operator wants to change from the defaults they are free to do so without risking being forked off the network or risking a chain split. > I know some of you may scoff at my bias for use cases like zero-conf, but what I am trying to convey is a possible folly in active management, speculation, and misapplied game theory that may permeate many Bitcoin Core decisions and designs, even beyond the mempoolrbf / zero-conf debate. This stuff is difficult to follow and understand especially for people who haven't been into Bitcoin for long or are trying to build Bitcoin businesses full time, there are lots of subtleties. I've certainly struggled at many points in my learning journey and I'm sure I will continue to do so in future. So there is no scoffing (from me at least) at individuals trying to learn and businesses trying to thrive and provide services to their customers. Unfortunately there are occasionally scenarios where trade-offs have to be weighed up and decisions have to be made where some people aren't happy. You may disagree but I'm a lot more comfortable delegating responsibility for policy defaults to those who have worked full time in this area for years than say consensus changes where I think we all have a responsibility to ensure suboptimal or worse harmful changes aren't made to the consensus rules. I thought your input on the CTV discussion earlier in the year was really positive for example. On this topic though I think you could do with doing some more reading as there is a lot of past discussion. I'm sure those who work in this area full time would be happy to answer any questions you have if you do. Thanks Michael [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019572.html [1]: https://btctranscripts.com/adopting-bitcoin/2021/2021-11-16-gloria-zhao-transaction-relay-policy/ -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ------- Original Message ------- On Saturday, December 10th, 2022 at 14:10, John Carvalho via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > As we debate mempoolfullrbf, and I familiarize myself with related PRs from engineers trying to reign in all of the possible behaviors that make it inconsistent, I can’t help but think about how I see people using the term “incentive-compatible” and how it seems to be awfully presumptive. > > The idea that a single Bitcoin transaction can be “incentive-compatible” by simply restricting it to having a higher fee or fee rate is theoretical, likely narrow, and not totally objective. RBF is inherently a fee-minimization tool, which as a concept, as I understand “incentive-compatibility” to be about miners in this context, makes RBF to be anti-incentives; miners are fee maximizers. > > Miners want the most fees per block, and per lifetime, do they not? If miners, and the mempool, are prioritizing for the smallest txns with the highest fees, over the longest acceptable amount of time, this may conflict with extra-mempool behaviors that result in more txns per block / per lifetime. > > If this isn’t making sense yet, let me summarize by how such a problem would express: a per-transaction fee-minimized, fully replaceable mempool as policy, that appears to always require the highest fee per txn, but ultimately includes less txns per block and less fees per lifetime. Basically, less use cases, less users, less txns — all to enforce a misunderstood theory and predictive speculation of what people want out of the system and what miners will do about it. > > Simply, we probably want designs that fill blocks, and we don’t need to do anything at all to facilitate bidding on a use case like replacement. > > Bidding does not require protocol enforcement, it is miner-subjective. So why are we pursuing it? Why do we even have RBF? Why are we trying to clean up all of the mess RBF creates with more and more code? If bidding is already accepted as incentive-compatible, and Bitcoin already allows setting a fee, then replacement requires no special code at all. > > I would think a holistic definition of what is incentive-compatible would be something more like what is “market compatible” and enables the complementary goals & incentives of every user in the system to make it thrive. > > It has been shown that users control Bitcoin (UASF) and thus ultimately miners would be incentivized to do what users want, up to the point of inability or loss. Correct? > > So, in contrast, how would the opposite, a user-compatible design, express? Well, I think the idea of txns being able to signal intent and desired behavior is more interesting (more useful) than a mempool that overrides all intent with RBF, and possibly more incentive-compatible than mempoolfullrbf as concept. > > Since we can’t be sure what the market wants, but we can be sure that the more users we have, making the most possible txns, at the highest possible prices, will yield the most valuable Bitcoin, and thus the most hashpower, we could entertain giving users the most ways to express their intent, the most flexibility. > > The most basic design would be to simply have no mempool policy at all, and let market incentives emerge on their own, but we have a status quo to consider, and most users do not have the technical expertise to express their own policies with misc patches and hacks of their Bitcoin Core software. > > I know this is a bit of a high-level abstract perspective, but I think it is important to respect such dynamics when making smaller decisions. It certainly is not our charge to prioritize what miners want any more than any other user type, nor is it within our ability to predict the future or fully model incentives of all players across all use cases. > > I know some of you may scoff at my bias for use cases like zero-conf, but what I am trying to convey is a possible folly in active management, speculation, and misapplied game theory that may permeate many Bitcoin Core decisions and designs, even beyond the mempoolrbf / zero-conf debate. > > So, what to do? > > — > > John Carvalho > CEO, Synonym.to [-- Attachment #2: Type: text/html, Size: 11019 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Rethinking “Incentive Compatibility” Within the Bitcoin Protocol 2022-12-11 13:58 ` Michael Folkson @ 2022-12-11 14:56 ` John Carvalho 2022-12-11 15:44 ` Michael Folkson 0 siblings, 1 reply; 5+ messages in thread From: John Carvalho @ 2022-12-11 14:56 UTC (permalink / raw) To: Michael Folkson, Bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 10571 bytes --] While I appreciate your reference links, and will check them out (thanks!), I do not appreciate your repeated takes about my character or quality of experience. I have been in Bitcoin for 10 years, I build with it, I manage a Bitcoin company with 8 engineers, and, modesty aside, there aren't very many non-engineers that grasp how Bitcoin works as well as I do. I put lots of time into Bitcoin, and do my best to scrutinize all concepts presented to me. When I post in github, you mention I should be banned and you ignore my substantive arguments. If I post on the list here, you imply I am a noob, have difficulty understanding, and that I'm biased by business. This is not useful other than some, probably false, notion that maybe you can position yourself as superior or myself as dismissable. My post is an analysis on incentives and how we understand them when designing for Bitcoin. You explained a bit about what the mempool is for, and some dynamics about it, but you may notice that doing something like mempoolfullrbf is actually inconsistent with a goal of mempool harmony. It is a disruptive change, therefore a tradeoff. The arguments for making that tradeoff use some oversimplified concepts, in my opinion. So, I am questioning the quality of current theory, and showing how it might be insufficient. - Do you think it is possible that a fully replaceable mempool, and obsoletion of zero-conf (merchant/consumer) use cases could result in less overall mining income? If not, why not? - Could this, and other active management by Bitcoin Core engineers, result in an overall less valuable, less useful Bitcoin, and is that bad for miners/security? - Do you think it is inconsistent that on one hand, Bitcoiners argue that miners do not control Bitcoin, yet Bitcoin Core is biasing decisions to cater to mining incentives over user incentives? Should miners do what users want, and might that be their actual incentive? - Do you think it is Core's place to influence or steer policy based on speculation about what may happen in the future, even when it conflicts with the present and past? *These* are the interesting questions. Do you have reasoned answers? You suggest you are comfortable outsourcing your understanding and decisions to others, well I am not, and my post was meant to show some reasons why. It is important that Bitcoiners question how, when, and whether Bitcoin software is changed, regardless of their ability to create or audit code. Please analyze my ideas instead of me, thank you. Or, you could stay out of it and outsource that to someone else as well. ~John On Sun, Dec 11, 2022 at 1:58 PM Michael Folkson < michaelfolkson@protonmail•com> wrote: > Hey John > > There was a discussion [0] started by Lisa on the mailing list last year > on whether there is any point to a full node maintaining a mempool last > year which you may find interesting. I also recommend Gloria's presentation > [1] from Adopting Bitcoin last year on transaction relay policy. > > I think those are better resources than anything I could write. But I > guess I'd summarize it like this. The job of the P2P/mempool/policy > protocol devs in setting defaults is to ensure anyone can effectively > propagate a consensus valid transaction across the network ultimately > making its way into miners' mempools without harming network health (full > node uptime, DoS attacks etc) and to give higher layers built on top of the > Bitcoin network the best chance to succeed. If they totally screwed up that > job with the defaults or they were unable to cater for a particular use > case within default policy then there is always the alternative of > submitting consensus valid transactions directly to miners bypassing the > P2P network entirely. But clearly it is much better if the P2P network > functions smoothly and every transaction isn't forced to be directly > submitted to a miner. It is policy too of course rather than consensus so > if the full node operator wants to change from the defaults they are free > to do so without risking being forked off the network or risking a chain > split. > > > I know some of you may scoff at my bias for use cases like zero-conf, > but what I am trying to convey is a possible folly in active management, > speculation, and misapplied game theory that may permeate many Bitcoin Core > decisions and designs, even beyond the mempoolrbf / zero-conf debate. > > This stuff is difficult to follow and understand especially for people who > haven't been into Bitcoin for long or are trying to build Bitcoin > businesses full time, there are lots of subtleties. I've certainly > struggled at many points in my learning journey and I'm sure I will > continue to do so in future. So there is no scoffing (from me at least) at > individuals trying to learn and businesses trying to thrive and provide > services to their customers. Unfortunately there are occasionally scenarios > where trade-offs have to be weighed up and decisions have to be made where > some people aren't happy. You may disagree but I'm a lot more comfortable > delegating responsibility for policy defaults to those who have worked full > time in this area for years than say consensus changes where I think we all > have a responsibility to ensure suboptimal or worse harmful changes aren't > made to the consensus rules. I thought your input on the CTV discussion > earlier in the year was really positive for example. On this topic though I > think you could do with doing some more reading as there is *a lot* of > past discussion. I'm sure those who work in this area full time would be > happy to answer any questions you have if you do. > > Thanks > Michael > > [0]: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019572.html > [1]: > https://btctranscripts.com/adopting-bitcoin/2021/2021-11-16-gloria-zhao-transaction-relay-policy/ > > -- > Michael Folkson > Email: michaelfolkson at protonmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > ------- Original Message ------- > On Saturday, December 10th, 2022 at 14:10, John Carvalho via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > > As we debate mempoolfullrbf, and I familiarize myself with related PRs > from engineers trying to reign in all of the possible behaviors that make > it inconsistent, I can’t help but think about how I see people using the > term “incentive-compatible” and how it seems to be awfully presumptive. > > The idea that a single Bitcoin transaction can be “incentive-compatible” > by simply restricting it to having a higher fee or fee rate is theoretical, > likely narrow, and not totally objective. RBF is inherently a > fee-minimization tool, which as a concept, as I understand > “incentive-compatibility” to be about miners in this context, makes RBF to > be anti-incentives; miners are fee maximizers. > > Miners want the most fees per block, and per lifetime, do they not? If > miners, and the mempool, are prioritizing for the smallest txns with the > highest fees, over the longest acceptable amount of time, this may conflict > with extra-mempool behaviors that result in more txns per block / per > lifetime. > > If this isn’t making sense yet, let me summarize by how such a problem > would express: a per-transaction fee-minimized, fully replaceable mempool > as policy, that appears to always require the highest fee per txn, but > ultimately includes less txns per block and less fees per lifetime. > Basically, less use cases, less users, less txns — all to enforce a > misunderstood theory and predictive speculation of what people want out of > the system and what miners will do about it. > > Simply, we probably want designs that fill blocks, and we don’t need to do > anything at all to facilitate bidding on a use case like replacement. > > Bidding does not require protocol enforcement, it is miner-subjective. So > why are we pursuing it? Why do we even have RBF? Why are we trying to clean > up all of the mess RBF creates with more and more code? If bidding is > already accepted as incentive-compatible, and Bitcoin already allows > setting a fee, then replacement requires no special code at all. > > I would think a holistic definition of what is incentive-compatible would > be something more like what is “market compatible” and enables the > complementary goals & incentives of every user in the system to make it > thrive. > > It has been shown that users control Bitcoin (UASF) and thus ultimately > miners would be incentivized to do what users want, up to the point of > inability or loss. Correct? > > So, in contrast, how would the opposite, a user-compatible design, > express? Well, I think the idea of txns being able to signal intent and > desired behavior is more interesting (more useful) than a mempool that > overrides all intent with RBF, and possibly more incentive-compatible than > mempoolfullrbf as concept. > > Since we can’t be sure what the market wants, but we can be sure that the > more users we have, making the most possible txns, at the highest possible > prices, will yield the most valuable Bitcoin, and thus the most hashpower, > we could entertain giving users the most ways to express their intent, the > most flexibility. > > The most basic design would be to simply have no mempool policy at all, > and let market incentives emerge on their own, but we have a status quo to > consider, and most users do not have the technical expertise to express > their own policies with misc patches and hacks of their Bitcoin Core > software. > > I know this is a bit of a high-level abstract perspective, but I think it > is important to respect such dynamics when making smaller decisions. It > certainly is not our charge to prioritize what miners want any more than > any other user type, nor is it within our ability to predict the future or > fully model incentives of all players across all use cases. > > I know some of you may scoff at my bias for use cases like zero-conf, but > what I am trying to convey is a possible folly in active management, > speculation, and misapplied game theory that may permeate many Bitcoin Core > decisions and designs, even beyond the mempoolrbf / zero-conf debate. > > So, what to do? > > — > > John Carvalho > CEO, Synonym.to > > > [-- Attachment #2: Type: text/html, Size: 14025 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Rethinking “Incentive Compatibility” Within the Bitcoin Protocol 2022-12-11 14:56 ` John Carvalho @ 2022-12-11 15:44 ` Michael Folkson 0 siblings, 0 replies; 5+ messages in thread From: Michael Folkson @ 2022-12-11 15:44 UTC (permalink / raw) To: John Carvalho; +Cc: Bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 12232 bytes --] I think it best I leave this discussion to others then as something I've written has obviously offended you. I'll also leave it to others to assess whether I was disrespectful or attacking your character or quality of experience in that email. Someone working on the P2P or mempool part of the Bitcoin Core codebase for years is going to understand the code and the subtle trade-offs of mempool policy defaults better than you or I. I hate to break it to you. Just like you are going to understand Synonym's business and technology better than that P2P/mempool developer. We all have different skillsets and different experiences. > When I post in github, you mention I should be banned and you ignore my substantive arguments. Pull requests on Bitcoin Core's GitHub repository are for technical review of the concept, approach and code contained within that pull request. Submitting your Concept (N)ACK and reasoning is perfectly fine as is opening a pull request with the same changes. But the general high level discussion (back and forth etc) you seem to want to have is much better suited here than on a Bitcoin Core pull request. It is impossible for the Bitcoin Core project to operate if the world's population aren't willing to follow project norms and want to have discussions on subjects that aren't within the scope of that pull request. I and others requested you go here and you initially refused and said you struggled to use this forum. But yeah I'm not interested in engaging a shouting match. So with regards to your questions I'll leave it to others to discuss them with you. Thanks Michael -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ------- Original Message ------- On Sunday, December 11th, 2022 at 16:56, John Carvalho <john@synonym•to> wrote: > While I appreciate your reference links, and will check them out (thanks!), I do not appreciate your repeated takes about my character or quality of experience. I have been in Bitcoin for 10 years, I build with it, I manage a Bitcoin company with 8 engineers, and, modesty aside, there aren't very many non-engineers that grasp how Bitcoin works as well as I do. I put lots of time into Bitcoin, and do my best to scrutinize all concepts presented to me. > > When I post in github, you mention I should be banned and you ignore my substantive arguments. If I post on the list here, you imply I am a noob, have difficulty understanding, and that I'm biased by business. This is not useful other than some, probably false, notion that maybe you can position yourself as superior or myself as dismissable. > > My post is an analysis on incentives and how we understand them when designing for Bitcoin. You explained a bit about what the mempool is for, and some dynamics about it, but you may notice that doing something like mempoolfullrbf is actually inconsistent with a goal of mempool harmony. It is a disruptive change, therefore a tradeoff. The arguments for making that tradeoff use some oversimplified concepts, in my opinion. > > So, I am questioning the quality of current theory, and showing how it might be insufficient. > > - Do you think it is possible that a fully replaceable mempool, and obsoletion of zero-conf (merchant/consumer) use cases could result in less overall mining income? If not, why not? > - Could this, and other active management by Bitcoin Core engineers, result in an overall less valuable, less useful Bitcoin, and is that bad for miners/security? > - Do you think it is inconsistent that on one hand, Bitcoiners argue that miners do not control Bitcoin, yet Bitcoin Core is biasing decisions to cater to mining incentives over user incentives? Should miners do what users want, and might that be their actual incentive? > - Do you think it is Core's place to influence or steer policy based on speculation about what may happen in the future, even when it conflicts with the present and past? > > *These* are the interesting questions. Do you have reasoned answers? > > You suggest you are comfortable outsourcing your understanding and decisions to others, well I am not, and my post was meant to show some reasons why. It is important that Bitcoiners question how, when, and whether Bitcoin software is changed, regardless of their ability to create or audit code. > > Please analyze my ideas instead of me, thank you. Or, you could stay out of it and outsource that to someone else as well. > > ~John > > On Sun, Dec 11, 2022 at 1:58 PM Michael Folkson <michaelfolkson@protonmail•com> wrote: > >> Hey John >> >> There was a discussion [0] started by Lisa on the mailing list last year on whether there is any point to a full node maintaining a mempool last year which you may find interesting. I also recommend Gloria's presentation [1] from Adopting Bitcoin last year on transaction relay policy. >> >> I think those are better resources than anything I could write. But I guess I'd summarize it like this. The job of the P2P/mempool/policy protocol devs in setting defaults is to ensure anyone can effectively propagate a consensus valid transaction across the network ultimately making its way into miners' mempools without harming network health (full node uptime, DoS attacks etc) and to give higher layers built on top of the Bitcoin network the best chance to succeed. If they totally screwed up that job with the defaults or they were unable to cater for a particular use case within default policy then there is always the alternative of submitting consensus valid transactions directly to miners bypassing the P2P network entirely. But clearly it is much better if the P2P network functions smoothly and every transaction isn't forced to be directly submitted to a miner. It is policy too of course rather than consensus so if the full node operator wants to change from the defaults they are free to do so without risking being forked off the network or risking a chain split. >> >>> I know some of you may scoff at my bias for use cases like zero-conf, but what I am trying to convey is a possible folly in active management, speculation, and misapplied game theory that may permeate many Bitcoin Core decisions and designs, even beyond the mempoolrbf / zero-conf debate. >> >> This stuff is difficult to follow and understand especially for people who haven't been into Bitcoin for long or are trying to build Bitcoin businesses full time, there are lots of subtleties. I've certainly struggled at many points in my learning journey and I'm sure I will continue to do so in future. So there is no scoffing (from me at least) at individuals trying to learn and businesses trying to thrive and provide services to their customers. Unfortunately there are occasionally scenarios where trade-offs have to be weighed up and decisions have to be made where some people aren't happy. You may disagree but I'm a lot more comfortable delegating responsibility for policy defaults to those who have worked full time in this area for years than say consensus changes where I think we all have a responsibility to ensure suboptimal or worse harmful changes aren't made to the consensus rules. I thought your input on the CTV discussion earlier in the year was really positive for example. On this topic though I think you could do with doing some more reading as there is a lot of past discussion. I'm sure those who work in this area full time would be happy to answer any questions you have if you do. >> >> Thanks >> Michael >> >> [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019572.html >> [1]: https://btctranscripts.com/adopting-bitcoin/2021/2021-11-16-gloria-zhao-transaction-relay-policy/ >> >> -- >> Michael Folkson >> Email: michaelfolkson at [protonmail.com](http://protonmail.com/) >> Keybase: michaelfolkson >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 >> >> ------- Original Message ------- >> On Saturday, December 10th, 2022 at 14:10, John Carvalho via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >> >>> As we debate mempoolfullrbf, and I familiarize myself with related PRs from engineers trying to reign in all of the possible behaviors that make it inconsistent, I can’t help but think about how I see people using the term “incentive-compatible” and how it seems to be awfully presumptive. >>> >>> The idea that a single Bitcoin transaction can be “incentive-compatible” by simply restricting it to having a higher fee or fee rate is theoretical, likely narrow, and not totally objective. RBF is inherently a fee-minimization tool, which as a concept, as I understand “incentive-compatibility” to be about miners in this context, makes RBF to be anti-incentives; miners are fee maximizers. >>> >>> Miners want the most fees per block, and per lifetime, do they not? If miners, and the mempool, are prioritizing for the smallest txns with the highest fees, over the longest acceptable amount of time, this may conflict with extra-mempool behaviors that result in more txns per block / per lifetime. >>> >>> If this isn’t making sense yet, let me summarize by how such a problem would express: a per-transaction fee-minimized, fully replaceable mempool as policy, that appears to always require the highest fee per txn, but ultimately includes less txns per block and less fees per lifetime. Basically, less use cases, less users, less txns — all to enforce a misunderstood theory and predictive speculation of what people want out of the system and what miners will do about it. >>> >>> Simply, we probably want designs that fill blocks, and we don’t need to do anything at all to facilitate bidding on a use case like replacement. >>> >>> Bidding does not require protocol enforcement, it is miner-subjective. So why are we pursuing it? Why do we even have RBF? Why are we trying to clean up all of the mess RBF creates with more and more code? If bidding is already accepted as incentive-compatible, and Bitcoin already allows setting a fee, then replacement requires no special code at all. >>> >>> I would think a holistic definition of what is incentive-compatible would be something more like what is “market compatible” and enables the complementary goals & incentives of every user in the system to make it thrive. >>> >>> It has been shown that users control Bitcoin (UASF) and thus ultimately miners would be incentivized to do what users want, up to the point of inability or loss. Correct? >>> >>> So, in contrast, how would the opposite, a user-compatible design, express? Well, I think the idea of txns being able to signal intent and desired behavior is more interesting (more useful) than a mempool that overrides all intent with RBF, and possibly more incentive-compatible than mempoolfullrbf as concept. >>> >>> Since we can’t be sure what the market wants, but we can be sure that the more users we have, making the most possible txns, at the highest possible prices, will yield the most valuable Bitcoin, and thus the most hashpower, we could entertain giving users the most ways to express their intent, the most flexibility. >>> >>> The most basic design would be to simply have no mempool policy at all, and let market incentives emerge on their own, but we have a status quo to consider, and most users do not have the technical expertise to express their own policies with misc patches and hacks of their Bitcoin Core software. >>> >>> I know this is a bit of a high-level abstract perspective, but I think it is important to respect such dynamics when making smaller decisions. It certainly is not our charge to prioritize what miners want any more than any other user type, nor is it within our ability to predict the future or fully model incentives of all players across all use cases. >>> >>> I know some of you may scoff at my bias for use cases like zero-conf, but what I am trying to convey is a possible folly in active management, speculation, and misapplied game theory that may permeate many Bitcoin Core decisions and designs, even beyond the mempoolrbf / zero-conf debate. >>> >>> So, what to do? >>> >>> — >>> >>> John Carvalho >>> CEO, Synonym.to [-- Attachment #2: Type: text/html, Size: 18755 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Rethinking “Incentive Compatibility” Within the Bitcoin Protocol 2022-12-10 12:10 [bitcoin-dev] Rethinking “Incentive Compatibility” Within the Bitcoin Protocol John Carvalho 2022-12-11 13:58 ` Michael Folkson @ 2022-12-11 15:30 ` Daniel Edgecumbe 1 sibling, 0 replies; 5+ messages in thread From: Daniel Edgecumbe @ 2022-12-11 15:30 UTC (permalink / raw) To: M.K. Safi via bitcoin-dev I've been on the sidelines for a while reading these e-mails but it's become rather frustrating to read as of late. As far as I see it the fundamental principle is that the blockchain, via subsequent confirmations, is the way that security against double spends is provided in Bitcoin. The application of proof of work to achieve that is the primary innovation of the system that seperates it from simply using digital signatures. RBF doesn't actually materially affect that at all. Regardless of what happens in the mempool, if you rely on an N-conf transaction being final, and N blocks get reversed, either by an inadvertant chain split or by some sort of short term 51% attack behaviour, you're SOL. Zeroconf goes even beyond that - if you rely on a transaction in the mempool, a miner can choose to mine a conflicting one regardless of what the relay policy in Core is. The only cost to them is the fee difference between the two transactions, which in the vast majority of cases will be zero or in the favour of the miner. If we're going to talk about incentive compatibility - in this case the incentive compatible thing, perhaps even a design decision, is that miners just create a backchannel that ignores your censoring of transactions in the mempool. The debate itself feels like bikeshedding to me for that reason. It doesn't matter what colour we paint the zeroconf shed, it doesn't have a roof and it's made of cardboard. Daniel Edgecumbe | esotericnonsense d@esotericnonsense•com | https://esotericnonsense.com On Sat, Dec 10, 2022, at 12:10, John Carvalho via bitcoin-dev wrote: > As we debate mempoolfullrbf, and I familiarize myself with related PRs > from engineers trying to reign in all of the possible behaviors that > make it inconsistent, I can’t help but think about how I see people > using the term “incentive-compatible” and how it seems to be awfully > presumptive. > > The idea that a single Bitcoin transaction can be > “incentive-compatible” by simply restricting it to having a higher fee > or fee rate is theoretical, likely narrow, and not totally objective. > RBF is inherently a fee-minimization tool, which as a concept, as I > understand “incentive-compatibility” to be about miners in this > context, makes RBF to be anti-incentives; miners are fee maximizers. > > Miners want the most fees per block, and per lifetime, do they not? If > miners, and the mempool, are prioritizing for the smallest txns with > the highest fees, over the longest acceptable amount of time, this may > conflict with extra-mempool behaviors that result in more txns per > block / per lifetime. > > If this isn’t making sense yet, let me summarize by how such a problem > would express: a per-transaction fee-minimized, fully replaceable > mempool as policy, that appears to always require the highest fee per > txn, but ultimately includes less txns per block and less fees per > lifetime. Basically, less use cases, less users, less txns — all to > enforce a misunderstood theory and predictive speculation of what > people want out of the system and what miners will do about it. > > Simply, we probably want designs that fill blocks, and we don’t need to > do anything at all to facilitate bidding on a use case like replacement. > > Bidding does not require protocol enforcement, it is miner-subjective. > So why are we pursuing it? Why do we even have RBF? Why are we trying > to clean up all of the mess RBF creates with more and more code? If > bidding is already accepted as incentive-compatible, and Bitcoin > already allows setting a fee, then replacement requires no special code > at all. > > I would think a holistic definition of what is incentive-compatible > would be something more like what is “market compatible” and enables > the complementary goals & incentives of every user in the system to > make it thrive. > > It has been shown that users control Bitcoin (UASF) and thus ultimately > miners would be incentivized to do what users want, up to the point of > inability or loss. Correct? > > So, in contrast, how would the opposite, a user-compatible design, > express? Well, I think the idea of txns being able to signal intent and > desired behavior is more interesting (more useful) than a mempool that > overrides all intent with RBF, and possibly more incentive-compatible > than mempoolfullrbf as concept. > > Since we can’t be sure what the market wants, but we can be sure that > the more users we have, making the most possible txns, at the highest > possible prices, will yield the most valuable Bitcoin, and thus the > most hashpower, we could entertain giving users the most ways to > express their intent, the most flexibility. > > The most basic design would be to simply have no mempool policy at all, > and let market incentives emerge on their own, but we have a status quo > to consider, and most users do not have the technical expertise to > express their own policies with misc patches and hacks of their Bitcoin > Core software. > > I know this is a bit of a high-level abstract perspective, but I think > it is important to respect such dynamics when making smaller decisions. > It certainly is not our charge to prioritize what miners want any more > than any other user type, nor is it within our ability to predict the > future or fully model incentives of all players across all use cases. > > I know some of you may scoff at my bias for use cases like zero-conf, > but what I am trying to convey is a possible folly in active > management, speculation, and misapplied game theory that may permeate > many Bitcoin Core decisions and designs, even beyond the mempoolrbf / > zero-conf debate. > > So, what to do? > > — > > John Carvalho > CEO, Synonym.to > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-12-11 15:44 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-12-10 12:10 [bitcoin-dev] Rethinking “Incentive Compatibility” Within the Bitcoin Protocol John Carvalho 2022-12-11 13:58 ` Michael Folkson 2022-12-11 14:56 ` John Carvalho 2022-12-11 15:44 ` Michael Folkson 2022-12-11 15:30 ` Daniel Edgecumbe
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox