Re: [bitcoin-dev] [Pre-BIP] Fee Accounts

2022-01-19 Thread Jeremy via bitcoin-dev
SIGHASH_BUNDLE https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-April/015862.html By cycles I meant that if you commit to the sponsors by TXID from the witness, you could "sponsor yourself" directly or through a cycle involving > 1 txn. With OP_VER I was talking about the proposal I l

Re: [bitcoin-dev] [Pre-BIP] Fee Accounts

2022-01-19 Thread Billy Tetrud via bitcoin-dev
Hmm, I don't know anything about SIGHASH_BUNDLE. The only references online I can find are just mentions (mostly from you). What is SIGHASH_BUNDLE? > unless you're binding a WTXID That could work, but it would exclude cases where you have a transaction that has already been partially signed and

Re: [bitcoin-dev] CTV BIP review

2022-01-19 Thread Michael Folkson via bitcoin-dev
Eric, Luke Can I request that you don't discuss activation methods for future soft forks on a thread for CTV BIP review? I (and a number of others [0]) do not support an upcoming activation attempt of standalone OP_CTV. If you want to discuss activation methods for soft forks generally it would

Re: [bitcoin-dev] CTV BIP review

2022-01-19 Thread Alex Schoof via bitcoin-dev
Hey Jeremy, > On the topic of drafting BIPs for specific use cases, I agree that would be valuable and can consider it. > However, I'm a bit skeptical of that approach overall as I don't necessarily think that the applications *must be* standard, and I view BIPs as primarily for standardization wh

Re: [bitcoin-dev] [Pre-BIP] Fee Accounts

2022-01-19 Thread Billy Tetrud via bitcoin-dev
> because you make transactions third party malleable it becomes possible to bundle and unbundle transactions. What I was suggesting doesn't make it possible to malleate someone else's transaction. I guess maybe my proposal of using a sighash flag might have been unclear. Imagine it as a script o

Re: [bitcoin-dev] [Pre-BIP] Fee Accounts

2022-01-19 Thread Billy Tetrud via bitcoin-dev
I see, its not primarily to make it cheaper to append fees, but also allows appending fees in cases that aren't possible now. Is that right? I can certainly see the benefit of a more general way to add a fee to any transaction, regardless of whether you're related to that transaction or not. How w

Re: [bitcoin-dev] On the regularity of soft forks

2022-01-19 Thread Billy Tetrud via bitcoin-dev
> That day is nowhere near IMO and maybe we won't see it in my lifetime. I think there is a reasonable argument to be made that maybe bitcoin needs to move faster now than it should in the future, and the cost of having the community remain vigilant against harmful changes is worth the extra spee

Re: [bitcoin-dev] Covenants and capabilities in the UTXO model

2022-01-19 Thread Billy Tetrud via bitcoin-dev
> 'assert that my parent has a scriptpubkey of X'... That way you can, for example, have a UTXO which only allows itself to be absorbed by a transaction also involving a UTXO with a particular capability I'm not sure I fully follow. I usually think about covenants as having the reverse form, that