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
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
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
> 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
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
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
