On Wed, Mar 01, 2023 at 10:05:47AM -0500, Greg Sanders via bitcoin-dev wrote:
> Below is a sketch of a replacement for the two opcodes.
I like this! I tried to come up with something along similar lines for
similar reasons, but I think I tried too hard to reduce it to two opcodes
or something and
Hi Giuseppe,
One side-effect this has is that until enough fees accumulate in the
mempool to satisfy min_fees, the rational behaviour for miners would be to
try and fork the chain tip, competing for the fees in the latest block
(+whatever got into the mempool in the meanwhile and can fit in). This
Hello everyone,
I'm relatively new here so what I'm proposing could have already been
discussed, or may be flawed or inapplicable. I apologize for that.
I was picturing a situation where block rewards are almost zero, and the
base layer is mainly used as a settlement layer for relatively few larg
On 2023-02-27 03:32, Rastislav Budinsky via bitcoin-dev wrote:
When a miner mines a block he takes all the fees currently. However
with the proposed solution he takes only fraction M and remaining
fraction C is sent to one of more contracts. One contract at its
simplest collects fees from the min
Hello James,
First off, thank you for crafting an interesting idea like this that is
aimed at solving a serious problem. I see a lot of excitement about the use
cases, and I think it's worth iterating on.
Attempting to keep the idealized functionality constant, I'd like to
explore a design detour
