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 e
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 exa
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
Tapr
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 set
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
