> to bring the equilibrium
The important thing to highlight is that's not equilibrium between active users
and miners.
This needed in the future equilibrium is between:
Active Users (transactional tax) vs Passive Users (i.e. stakeholders: inflation
tax)
And miners will only earn as much as t
On March 2, 2023 6:20:35 PM GMT, Luke Dashjr via bitcoin-dev
wrote:
>This sounds like something that should be written up as a BIP and use a normal
>service bit assignment...?
The purpose of the experimental service bits is experiments. If the details of
utreexo aren't nailed down and may ch
I read the draft and this seems to have some functionality that I am looking
for. I'm pretty new to bitcoin-dev, but I'm persistent and have a lot of time
on my hands.
I would like multiple tapleaves be restricted on the amount that they can spend.
Say an input of 1 BTC, has a locking script of
This sounds like something that should be written up as a BIP and use a
normal service bit assignment...?
Luke
On 3/2/23 01:55, kcalvinalvin via bitcoin-dev wrote:
Hello all,
Wanted to tell the mailing list that I'll be using service bit 24 (1
<< 24) to signal that nodes are Utreexo capable
Greetings AJ,
Glad I could resurrect the idea!
> Then instead of `idx hash delay OP_TRIGGER_FORWARD` you
write `idx hash delay 2 "OP_CSV OP_DROP OP_FORWARD_OUTPUTS"
OP_FORWARD_LEAF_UPDATE`
Interesting idea! (I'll let you be the one to scope creep the proposal :) )
To be pedantic, EXPR_TRIGGER w
Hello all,
Wanted to tell the mailing list that I'll be using service bit 24 (1 << 24) to
signal that nodes are Utreexo capable nodes on testnet and signet as requested
by the comment in protocol.h in bitcoind
(https://github.com/bitcoin/bitcoin/blob/74981aa02d2b14ad1c0b82d1eb09cf3169eaa8ae/src
