Luke,
I previously explored an extra state to require signalling before activation in
an earlier draft of BIP8, but the overall impression I got was that gratuitous
orphaning was undesirable, so I dropped it. I understand the motivation behind
it (to ensure miners are upgraded), but it's also ra
It's not pointless: it's a wake-up call for miners asleep "at the wheel", to
ensure they upgrade in time. Not having a mandatory signal turned out to be a
serious bug in BIP 9, and one which is fixed in BIP 148 (and remains a problem
for BIP 149 as-is). Additionally, it makes the activation deci
I've already opened a PR almost 2 weeks ago to do this and fix the other
issues BIP 9 has. https://github.com/bitcoin/bips/pull/550
It just needs your ACK to merge.
On Wednesday 05 July 2017 1:30:26 AM shaolinfry via bitcoin-dev wrote:
> Some people have criticized BIP9's blocktime based thresh
On Tue, Jul 4, 2017 at 6:30 PM, shaolinfry via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Some people have criticized BIP9's blocktime based thresholds arguing they
> are confusing (the first retarget after threshold). It is also vulnerable
> to miners fiddling with timestamps i
On Tue, Jul 04, 2017 at 09:30:26PM -0400, shaolinfry via bitcoin-dev wrote:
> Some people have criticized BIP9's blocktime based thresholds arguing they
> are confusing (the first retarget after threshold). It is also vulnerable to
> miners fiddling with timestamps in a way that could prevent or
Some people have criticized BIP9's blocktime based thresholds arguing they are
confusing (the first retarget after threshold). It is also vulnerable to miners
fiddling with timestamps in a way that could prevent or delay activation - for
example by only advancing the block timestamp by 1 second
Hi ZmnSCPxj,
In my scheme, if you read carefully through the pseudocode, a block list
> node is valid only if its block is valid.
>
It seems this is a contradiction against the "blind" part of blind merge
mining. How can a bitcoin blockchain node enforce this without tracking the
sidechain?
Bas
Your BIP would take away the only way the *receiver* has to raise the
fee: CPFP. And the receiver is arguably the more important party in this
question. After all the sender has no real incentive for his payment to
be confirmed; it's receiver who has.
On 07/02/2017 10:35 PM, Rhavar via bitcoin-de
Good morning Paul, Chris, and CryptAxe,
@Paul
>> >Your way is actually very similar to mine. Mine _forces_ the bribe to be
>> >in the earliest txn (the coinbase) and to only occur once. Yours doesn"t
>> >do anything to refund the briber, if the sidechain (but not the
>> >mainchain) reorganizes (as
