On 2024-01-01 00:17, yuri...@pm.me wrote:
I'm afraid I didn't understand your objection. [...] I suspect my proposed scheme can be implemented with available, existing Bitcoin infrastructure.
Is a soft fork or a hard fork required? If so, the proposal will need a lot of peer review and user acceptance.
What are the benefits of your proposal? As I understand it, the benefit is smaller transactions. How much smaller will they be in terms of vbytes? For example, a transaction today with one input performing a taproot keypath spend and one taproot-paying output is 111 vbytes[1]. What will be the total onchain size of an equivalent one-input, one-output transaction using your scheme?
My comment (not objection) is that modest decreases in onchain data size may not provide a significant enough benefit to attract reviewers and interested users, especially if a proposal is complicated by a dependencies on many things that have not previously been included in Bitcoin (such as new hash functions).
If I'm deeply misunderstanding your proposal and my questions don't make sense, I'd very much appreciate a clarification about what your proposal does.
Thanks, -Dave [1] https://bitcoinops.org/en/tools/calc-size/ _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
