Re: [bitcoin-dev] Bitcoin covenants are inevitable
Bitcoin's finite supply is the main argument for people investing in it, the whole narrative around bitcoin is based on its finite supply. While it has its flaws and basically condemns bitcoin to be only used as a store of value (and not as a currency), I don't think it's worth questioning it at this point. Just my 2 sats. Giuseppe. On Sun, Jul 3, 2022, 11:44 AM Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Jun 29, 2022 at 12:44:11PM +0200, Kate Salazar via bitcoin-dev > wrote: > > > On an idealistic level, I agree with Keagan that it would make sense to > > > have "a balance of fees to that effect". I think doing that would be > > > technically/economically optimal. However, I think there is an enormous > > > benefit to having a cultural aversion to monetary inflation and the > > > consequences of convincing the bitcoin community that inflation is ok > could > > > have unintended negative consequences (not to mention how difficult > > > convincing the community would be in the first place). There's also the > > > economic distortion that inflation causes that has a negative effect > which > > > should also be considered. The idea of decaying utxo value is > interesting > > > to consider, but it would not solve the economic distortion that > > > monetary inflation causes, because that distortion is a result of > monetary > > > devaluation (which decaying utxos would be a form of). Then again, > maybe in > > > this case the distortion of inflation would actually be a correction - > > > correcting for the externality of benefit received by holders. I'm > > > stream-of-consciousnessing a bit, but anyways, I suspect its not worth > the > > > trouble to perfect the distribution of bitcoin blockchain security > costs to > > > include holders. Tho, if I were to go back in time and influence how > > > bitcoin was designed, I might advocate for it. > > > > > > > Pool operators are free to request larger fees from older utxos, or from > > all utxos, or from newer utxos, at their judgement, looking at the > > blockspace demand census and at what the other pool operators are doing. > > This is not consensus, it's policy. It's not a technology problem, it's > > solved above in the social layer. > > If pool operators can easily collude like you are proposing, we have a > serious > problem with pool centralization. > > What you would actually expect in a healthy Bitcoin ecosystem is for some > pool > operators to defect, and them winding up mining those transactions for > market-based fees, eventually forcing the pool operators who are trying to > charge a discriminatory premium to give up. > > -- > 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
Re: [bitcoin-dev] Bitcoin covenants are inevitable
On Wed, Jun 29, 2022 at 12:44:11PM +0200, Kate Salazar via bitcoin-dev wrote: > > On an idealistic level, I agree with Keagan that it would make sense to > > have "a balance of fees to that effect". I think doing that would be > > technically/economically optimal. However, I think there is an enormous > > benefit to having a cultural aversion to monetary inflation and the > > consequences of convincing the bitcoin community that inflation is ok could > > have unintended negative consequences (not to mention how difficult > > convincing the community would be in the first place). There's also the > > economic distortion that inflation causes that has a negative effect which > > should also be considered. The idea of decaying utxo value is interesting > > to consider, but it would not solve the economic distortion that > > monetary inflation causes, because that distortion is a result of monetary > > devaluation (which decaying utxos would be a form of). Then again, maybe in > > this case the distortion of inflation would actually be a correction - > > correcting for the externality of benefit received by holders. I'm > > stream-of-consciousnessing a bit, but anyways, I suspect its not worth the > > trouble to perfect the distribution of bitcoin blockchain security costs to > > include holders. Tho, if I were to go back in time and influence how > > bitcoin was designed, I might advocate for it. > > > > Pool operators are free to request larger fees from older utxos, or from > all utxos, or from newer utxos, at their judgement, looking at the > blockspace demand census and at what the other pool operators are doing. > This is not consensus, it's policy. It's not a technology problem, it's > solved above in the social layer. If pool operators can easily collude like you are proposing, we have a serious problem with pool centralization. What you would actually expect in a healthy Bitcoin ecosystem is for some pool operators to defect, and them winding up mining those transactions for market-based fees, eventually forcing the pool operators who are trying to charge a discriminatory premium to give up. -- https://petertodd.org 'peter'[:-1]@petertodd.org 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] Adding SIGHASH to TXID
> Have you seen the inherited ID proposal from John Law on this list? I didn't see that before posting, I'm still trying to get more familiar with that (and with proposals, where every single field in each transaction is controlled for inclusion or exclusion). > Honestly, I've yet to fully load in exactly how the applications of it work, > but I'd be interested to hear your thoughts. The main use case is to control transaction flow. If you have everything signed with SIGHASH_ALL, then it is obvious that you can just use txid, and everything works. But on the other hand, if you use other sighashes, for example SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, then you should be able to make a new transaction spending your signed output, no matter which inputs and outputs will be added to the previous one. And that's why SIGHASH_PREVOUT_SOMETHING is needed, to control, which parts of the previous transaction are signed, and which are not. And to do that, it is needed to take the previous transaction, referenced by txid, and to modify it, based on provided SIGHASH_PREVOUT_SOMETHING sighashes. To push things one step further, I think different sighashes should be proposed by default, that would make users more familiar with the whole concept of sighashes. Because now, the default behavior is to sign everything with SIGHASH_ALL. I think it should be changed, the Core client should propose different sighashes, based on created transaction, just to allow transaction joining. To start with, it could be just a simple checkbox "allow transaction joining", that would enable it, to see if it will be simple enough for most users. SIGHASH_ANYONECANPAY - used for every input (because it allows fee bumping without changing signatures) SIGHASH_SINGLE - used only when there is any corresponding output, and only when it has higher or equal amount than the corresponding input SIGHASH_ALL - used when there is no corresponding output, or when the corresponding output is smaller, to prevent detaching it In general, I think the transaction should be displayed like it is visible in many block explorers, and after clicking each input, users should see, what is signed, and what is not, so they should control sighashes in a similar user interface, as they use to choose coins. Inputs and outputs should be grayed or highlighted, based on sighashes selected by user, to allow understanding them better. On 2022-05-07 13:55:48 user Jeremy Rubin wrote: Have you seen the inherited ID proposal from John Law on this list? It's a pretty thorough treatment of this type of proposal, curious if you think it overlaps what you had in mind? Honestly, I've yet to fully load in exactly how the applications of it work, but I'd be interested to hear your thoughts. On Sat, May 7, 2022, 4:55 AM vjudeu via bitcoin-dev wrote: For now, we have txid:vout as a previous transaction output. This means that to have a stable TXID, we are forced to use SIGHASH_ALL somewhere, just to prevent any transaction modifications that can happen during adding some inputs and outputs. But it seems that new sighashes could be far more powerful than we expected: it is technically possible to not only remove previous transaction output by using SIGHASH_ANYPREVOUT. We can do more and do it better, we could decide, how to calculate this txid at all! So, something like SIGHASH_PREVOUT_NONE would be similar to SIGHASH_NONE (applied to the previous transaction, taken from txid). To have SIGHASH_ANYPREVOUT, we need to remove absolutely everything, I don't know any such sighashes, because even SIGHASH_NONE | SIGHASH_ANYONECANPAY will commit at least to some fields, for example to the locktime. But, if we introduce SIGHASH_PREVOUT_XYZ flags for all existing sighashes, we would have this: SIGHASH_PREVOUT_NONE SIGHASH_PREVOUT_SINGLE SIGHASH_PREVOUT_ALL SIGHASH_PREVOUT_ANYONECANPAY Then, the procedure is as follows: we use txid:vout to find our previous transaction. Then, we apply those sighashes to this previous transaction, to form a new txid, that will be checked during every OP_CHECKSIG-based opcode. In this way, our txid:vout is used just to do transaction lookup, after that, sighashes can be applied to the previous transaction, so our txid could remain stable, even if someone will add some inputs and outputs. By default, we could use SIGHASH_PREVOUT_ALL, that would mean our txid:vout remains unchanged. Then, SIGHASH_PREVOUT_SINGLE would obviously mean, that we want to commit only to this particular previous transaction output. That would allow adding any new outputs to the previous transaction, without affecting our replaced txid, but also without blindly accepting any txid, because some data of the previous transaction would be still hashed. Then, SIGHASH_PREVOUT_NONE is an interesting case, because it would mean that no outputs of the previous transaction are checked. But still, the inputs will be! That would mean: "I
