Thanks for resurrecting this idea for discussion Will.
I see three reasons for reducing block header bandwidth:
1. support for long range block header broadcast via alternative
communication modalities like radio where every byte counts
2. where repurposed mobile devices with SPV wallets are us
Thanks for sharing your thoughts ZmnSCPxj. I think I can summarize your
concern as: A node without direct internet connectivity can not rely on an
opportunistically incentivized local network peer for blockchain
information because the off-grid node's direct LN peers could collude to
not forward th
I've been looking at using compressed block headers from the perspective of
a node that wants to use SMS messages to sync block headers. I realized
that it would be helpful if sendheaders2 took a parameter for how often to
send compact blockheaders. For example, in the case of an SMS transport
laye
Thanks AJ for the updated BIP - very exciting!
I'm also interested in this in the context of a Taproot version of
Decker-Russell-Osuntokun (eltoo). Thanks ZmnSCPxj for summarizing your
thoughts on how this would work. I have had some difficulty understanding
when someone might want to use ANYPREVO
When you say that a special relay network might be more "smart about
replacement" in the context of ANYPREVOUT*, do you mean these nodes could
RBF parts of a package like this:
Given:
- Package A = UpdateTx_A(n=1): txin: AnchorTx, txout: SettlementTx_A(n=1)
-> HtlcTxs(n=1)_A -> .chain of transa
I implemented some basic functional test scripts for the eltoo channel update
scheme to better understand BIP-118/Anyprevout (APO). My tests are based on the
rough Taproot eltoo scripts AJ Towns outlined on this list back in 2019. These
tests also require AJ's APO branch of core. This is just th
Hi darosior,
Thanks for sharing your thoughts on this.
> I would like to know people's sentiment about doing (a very slightly tweaked
> version of) BIP118 in place of
> (or before doing) BIP119.
Sounds good to me. Although from an activation perspective it may not be
either/or, both proposals