rich1.0npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3chttps://nostr.ae/npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3cnjumphttps://nostr.ae📅 Original date posted:2017-05-13 📝 Original message:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 If people want to influence the decisions of miners, all they need to do is mine. I do not see why any person would want to pay, and then trust, another to mine accordingly. Each person can mine and attain their level of influence. This not only avoids the side payment, but earns the person money. There is nothing inherently wrong with paying people to run nodes or signal "readiness", but there is no reason whatsoever to consider these ideas beneficial from a personal/economic or security/decentralization standpoint. If you are not running a node you are not part of the economic consensus. If you are not mining you have no say in transaction ordering. The "solution" is both obvious and necessary to secure Bitcoin . If a person does not want to bother then he/she clearly does not have a strong opinion. As developers we should be focused on reducing the complexities of mining and of validation, not finding ways for people to avoid participating in these necessarily distributed roles. e On 05/12/2017 05:49 PM, Luke Dashjr via bitcoin-dev wrote: > On Friday 12 May 2017 10:22:14 PM Peter Todd wrote: >> nVersion signaling is already technically unenforceable, in the >> sense that we don't have good ways of ensuring miners actually >> adopt the rules they're claiming to signal. Equally, it's users >> who ultimately adopt rules, not miners, and attempting to pay >> miners to signal certain bits will further confuse this point. > > This BIP doesn't change that. Enforcement remains primarily by > users. > >> Quite likely the outcome of users trying to anonymously pay >> anonymous miners to signal certain bits will be the complete >> breakdown of the honesty of the nVersion signalling system, >> currently enforced only by "gentlemans agreement". > > You assume users will pay for signalling of softforks prematurely. > So long as it waits until deployment of the softfork is > widespread, this risk is minimal. At worst, it creates risks > similar to a UASF. So long as UASF is the alternative, this way > seems strictly better. > >> Also, as an aside, this "specification" again shows the >> inadequacy and unreadability of English language specifications. >> I'd strongly suggest you delete it and instead mark the >> "reference implementation" as the specification. > > How so? > > On Friday 12 May 2017 10:17:30 PM ZmnSCPxj wrote: >> Minor editorial nitpick, this paragraph is repeated, maybe one of >> these should be Testnet? >> >> For Bitcoin '''mainnet''', the BIP8 '''starttime''' will be TBD >> (Epoch timestamp TBD) and BIP8 '''timeout''' will be TBD (Epoch >> timestamp TBD). >> >> For Bitcoin '''mainnet''', the BIP8 '''starttime''' will be TBD >> (Epoch timestamp TBD) and BIP8 '''timeout''' will be TBD (Epoch >> timestamp TBD). > > Fixed, thanks. > > Luke _______________________________________________ bitcoin-dev > mailing list bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJZFnzNAAoJEDzYwH8LXOFOlMsH/2Li7lDTr57EC2mSt4BuCf3Q Q1sx21CBumm6OQKMxd207wgXTaxVJVmrGPXfJ6ZW8Bf+2tMKgc/LsZfzXdEo5+Fx iTkdgJeW8QbKiEGzOFKMxWXH9jyCnd0WcDnKw/v7WqUhYfy2c9wz9RzCMY5iJqph xd2+DeiEIjXIvE+l2TXGwjnB8Wp41QeY0I98kG3HHwNvNREbbGS/BjtLj5+eBygU m+6dxkJoEttms31F47WFoZRzN7u5pe3BY5kDfZdVkbG7MOomSYwlhMvR3PtA1wrz FeAUcHpp9MPj+qgHGwAGMfJiG/5WsVSrl/dJTm68zPOdwH60fMNNT/Srfbj1Ty8= =9Xik -----END PGP SIGNATURE-----