Re: [bitcoin-dev] One-Shot Replace-By-Fee-Rate

2024-01-23 Thread Peter Todd via bitcoin-dev
On Mon, Jan 22, 2024 at 10:52:01PM +, Peter Todd via bitcoin-dev wrote: > An even simpler fix would be to just require that all unconfirmed inputs in a > replacement come from the *same* replaced transaction. That would make certain > rare, but economically viable, replacements infeasible. But

Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage

2024-01-23 Thread Greg Tonoski via bitcoin-dev
On Wed, Jan 17, 2024 at 12:30 AM Nagaev Boris wrote: > > Node operators are likely to put UTXO set to SSD and blocks to HDD. > SSD is more expensive than HDD. Again, the UTXO set size argument is irrelevant. A simple transaction is at disadvantage even if it doesn't result in a change of UTXO

Re: [bitcoin-dev] BIP process friction

2024-01-23 Thread Michael Folkson via bitcoin-dev
Thanks for this Peter, really helpful. > It is a much more fundamental standard than Ordinals or Taproot Assets, in the sense that transaction replacement is expected to be used by essentially all wallets as all wallets have to deal with fee-rate fluctuations; I do not think that Ordinals or

Re: [bitcoin-dev] MuSig2 derivation, descriptor, and PSBT field BIPs

2024-01-23 Thread Michael Folkson via bitcoin-dev
Hi Christopher In the absence of a response from someone who is working on MuSig2/FROST etc I did ask Tim Ruffing about the problems with using x-only pubkeys for MuSig2 etc in an (online) London Bitcoin Devs meetup [0] in 2022. His response was: "If you want to do more complex things, for

Re: [bitcoin-dev] Compressed Bitcoin Transactions

2024-01-23 Thread Tom Briar via bitcoin-dev
Hi Jonas, As it turns out, most of our size savings come from eliminating unneeded hashes and public keys, which get recovered on decompression. gzip actually expands transactions due to the way it attempts to compress pseudorandom data, my numbers show a legacy transaction of 222 bytes being