Alphonse Pace [ARCHIVE] on Nostr: đź“… Original date posted:2017-03-26 đź“ť Original message:As a user, I would far ...
đź“… Original date posted:2017-03-26
đź“ť Original message:As a user, I would far prefer a split over any kind of mandatory change
that would drastically harm the ecosystem. Many users feel the same way.
Level 3 is a pure attack on users who do not conform to your beliefs.
Please do not put words in people's mouths claiming they wouldn't prefer a
split when many would. If you wish to fork off, please do so responsibly.
-Alphonse
On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello Alex,
>
> Thank you for the thoughtful reply.
>
> Surely you are aware that what you are proposing is vastly different from
> the way soft forks have historically worked.
>
>
> Yes, it is different. It’s different because the future network upgrade
> to larger blocks includes a loosening of the consensus ruleset whereas
> previous upgrades have included a tightening of the rule set. (BTW—this is
> not my proposal, I am describing what I have recently learned through my
> work with Bitcoin Unlimited and discussions with miners and businesses).
>
> With a tightening of the rule set, a hash power minority that has not
> upgraded will not produce a minority branch; instead they will simply have
> any invalid blocks they produce orphaned, serving as a wake-up call to
> upgrade.
>
> With a loosening of the consensus rule set, the situation is different: a
> hash power minority that has not upgraded will produce a minority branch,
> that will also drag along non-upgraded node operators, leading to potential
> confusion. The idea behind orphaning the blocks of non-upgraded miners was
> to serve as a wake-up call to upgrade, to reduce the chances of a minority
> chain emerging in the first place, similar to what happens automatically
> with a soft-forking change. If one's worry is a chain split, then this
> seems like a reasonable way to reduce the chances of that worry
> materializing. The Level 3 anti-split protection takes this idea one step
> further to ensure that if a minority branch does emerge, that transactions
> cannot be confirmed on that branch.
>
> First of all, the bar for miners being on the new chain is extremely high,
> 95%.
>
>
> I’m very confident that most people do NOT want a split, especially the
> miners. The upgrade to larger blocks will not happen until miners are
> confident that no minority chain will survive.
>
> Second of all, soft forks make rule restrictions on classes of
> transactions that are already non-standard so that any non-upgraded miners
> are unlikely to be including txs in their blocks which would violate the
> new rules and should not have their blocks orphaned even after the fork.
>
>
> I agree that the soft-fork mechanism usually works well. I believe this
> mechanism (or perhaps a modified version of it) to increase the block size
> limit will likewise work well. All transactions types that are currently
> valid will be valid after the upgrade, and no new types of transactions are
> being created. The “block-size-limit gene" of network nodes is simply
> evolving to allow the network to continue to grow in the way it has always
> grown. (If you’re interested, here is my talk at Coinbase where I discuss
> this: https://www.youtube.com/watch?v=pWnFDocAmfg)
>
> Finally, soft forks are designed to only be used when there is a very wide
> community consensus and the intention is not to overrule anyone's choice to
> remain on the old rules but to ensure the security of nodes that may have
> neglected to upgrade. Obviously it is impossible to draw a bright line
> between users who intentionally are not upgrading due to opposition and
> users that are just being lazy. But in the case of a proposed BU hard fork
> it is abundantly clear that there is a very significant fraction, in fact
> likely a majority of users who intentionally want to remain on the old
> rules.
>
>
> My read is completely different. I still have never talked with a person
> in real life who doesn’t want the block size limit to increase. Indeed, I
> have met people who worry that Bitcoin Unlimited is “trying to take
> over”—and thus they are worried for other reasons—but this couldn’t be
> further from the truth. For example, what most people within BU would love
> to see is a simple patch to Bitcoin Core 0.14 that allows node operators to
> adjust the size of blocks their nodes will accept, so that these node
> operators can follow consensus through the upgrade if they choose to.
>
> This is not a fight about “Core vs. BU”; Bitcoin’s future is one of
> “genetic diversity” with multiple implementations, so that a bug in one
> doesn’t threaten the network as a whole. To me it seems this is largely a
> fight about whether node operators should be easily able to adjust the size
> of blocks their nodes accept. BU makes it easy for node operators to
> accept larger blocks; Core doesn’t believe users should have this power
> (outside of recompiling from source, which few users can do).
>
> As a Bitcoin user I find it abhorrent the way you are proposing to
> intentionally cripple the chain and rules I want to use instead of just
> peacefully splitting.
>
>
> Once again, this is not my proposal. I am writing about what I have come
> to learn over the past several weeks. When I first heard about these
> ideas, I was initially against them too. They seemed harsh and merciless.
> It wasn’t until I got out their and started talking to more people in the
> community that the rationale started to make sense to me: the biggest
> concern people had was a chain split!
>
> So I guess the “ethics” here depend on the lens through which one is
> looking. People who believe that an important outcome of the upgrade to
> larger blocks is to avoid a blockchain split may be more favourable to
> these ideas than people who want the upgrade to result in a split (or are
> OK with a split), as it sounds like you do (is this true that you’d rather
> split than accept blocks with more than 1,000,000 bytes of transaction
> information in them? Sorry if I misunderstood).
>
> But if one's intention is to split and not follow the majority hash power
> when blocks become larger, then why not change the proof-of-work? This
> would certainly result in a peaceful splitting, as you said you desire.
>
> Best regards,
> Peter R
>
>
>
>
> On Sat, Mar 25, 2017 at 3:28 PM, Peter R via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> One of the purported benefits of a soft-forking change (a tightening of
>> the consensus rule set) is the reduced risk of a blockchain split compared
>> to a loosening of the consensus rule set. The way this works is that
>> miners who fail to upgrade to the new tighter ruleset will have their
>> non-compliant blocks orphaned by the hash power majority. This is a strong
>> incentive to upgrade and has historically worked well. If a minority
>> subset of the network didn’t want to abide by the new restricted rule set,
>> a reasonable solution would be for them to change the proof-of-work and
>> start a spin-off from the existing Bitcoin ledger (
>> https://bitcointalk.org/index.php?topic=563972.0).
>>
>> In the case of the coming network upgrade to larger blocks, a primary
>> concern of both business such as Coinbase and Bitpay, and most miners, is
>> the possibility of a blockchain split and the associated confusion, replay
>> risk, etc. By applying techniques that are known to be successful for
>> soft-forking changes, we can likewise benefit in a way that makes a split
>> less likely as we move towards larger blocks. Two proposed techniques to
>> reduce the chances of a split are:
>>
>> 1. That miners begin to orphan the blocks of non-upgraded miners once a
>> super-majority of the network hash power has upgraded. This would serve as
>> an expensive-to-ignore reminder to upgrade.
>>
>> 2. That, in the case where a minority branch emerges (unlikely IMO),
>> majority miners would continually re-org that minority branch with empty
>> blocks to prevent transactions from confirming, thereby eliminating replay
>> risk.
>>
>> Just like after a soft forking change, a minority that does not want to
>> abide by the current ruleset enforced by the majority could change the
>> proof-of-work and start a spin-off from the existing Bitcoin ledger, as
>> suggested by Emin.
>>
>> Best regards,
>> Peter R
>>
>>
>> > On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >
>> > On 03/24/2017 07:00 PM, Aymeric Vitte wrote:
>> >> I don't know what "Time is running short I fear" stands for and when
>> 50%
>> >> is supposed to be reached
>> >
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA512
>> >
>> > On 03/24/2017 07:00 PM, Aymeric Vitte wrote: > I don't know what
>> > "Time is running short I fear" stands for and when 50% > is supposed
>> > to be reached
>> >
>> > According to current hashrate distribution tracking site coin.dance,
>> > very likely within less than four weeks according to current hashrate
>> > takeover rate.
>> >
>> > While a fork is very likely, that I dont really fear because worst
>> > case scenario is that bitcoin still survives and the invalid chain
>> > becomes an alt. My fear is the centralized mining power being used
>> > to attack the valid chain with intentions on killing it. [1]
>> >
>> > Shouldn't this 50% attack they are threatening be a concern? If it
>> > is a concern, what options are on the table. If it is not a concern
>> > please enlightent me as to why.
>> >
>> >
>> > [1] Source:
>> > https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_rizun
>> _tells_miners_to_force_a_hard_fork_by/
>> >
>> > Text:
>> >
>> > The attack quoted from his article:
>> > https://medium.com/@peter_r/on-the-emerging-consensus-regard
>> ing-bitcoins-block-size-limit-insights-from-my-visit-with-2348878a16d8
>> >
>> > [Level 2] Anti-split protection Miners will orphan the
>> > blocks of non-compliant miners prior to the first larger block
>> > to serve as a reminder to upgrade. Simply due to the possibility
>> > of having blocks orphaned, all miners would be motivated to
>> > begin signalling for larger blocks once support definitively
>> > passes 51%. If some miners hold out (e.g., they may not be
>> > paying attention regarding the upgrade), then they will begin
>> > to pay attention after losing approximately $15,000 of revenue
>> > due to an orphaned block.
>> >
>> > [Level 3] Anti-split protection In the scenario where Levels
>> > 1 and 2 protection fails to entice all non-compliant miners to
>> > upgrade, a small-block minority chain may emerge. To address the
>> > risk of coins being spent on this chain (replay risk), majority
>> > miners will deploy hash power as needed to ensure the minority
>> > chain includes only empty blocks after the forking point. This
>> > can easily be accomplished if the majority miners maintain a
>> > secret chain of empty blocks built off their last empty
>> > block publishing only as much of this chain as necessary
>> > to orphan any non-empty blocks produced on the minority chain.
>> >
>> >
>> >
>> >
>> > - --
>> > Cannon
>> > PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
>> > Email: cannon at cannon-ciota.info
>> >
>> > NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
>> > BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
>> > If this matters to you, use PGP.
>> > -----BEGIN PGP SIGNATURE-----
>> >
>> > iQIcBAEBCgAGBQJY1pbaAAoJEAYDai9lH2mwOO0QANOWqGzPNlifWguc+Y5UQxQM
>> > eAiztAayQBoAyLcFE7/qdtSNlUxbIAHG17fM+aNkehjYH2oN5ODJ+j7E2Yt6EoUH
>> > h5t8MLhNRG/YGF1hJK8Io940EmdcjuNmohiZvrjIqEOYggmLU3hR6J4gsuGsQQhu
>> > gY3sMS/TtT+gZNH8w53ePGrsVhuQR7yEMMr91/vM4+Q5abpwqLeYLnslaZDcd3XK
>> > VB9vyyK08r34J1GQt/H4UvTvGs28MFKBkvueA/Sfyvnrih7+WSQLuSvhiFr+cW1B
>> > TmSVYrB2DzyHN27jDCI2ty3ryNE4PMYcaeLfI2TTbsD/MuVU5lK0kM/1JajP4eRj
>> > j+P03OipuQiy/dNU63w0Uka2PbdKhDC13hVtK/ttBbNppbjnGeB9PYSJCzOpInGw
>> > NwAyz0rVS/llGsdctcII7Z6AUMGuJXzsosY8vjUroU+KFRDqIbDfC53sH7DaPh7u
>> > YawwId5S5RnZsAGCUJ+qNcg0s728J1eDjofN291IS5sOKMzpI7KhaOhFxjnk1MpN
>> > ZAlQeTlvG+sAdn61QMQK1NbFt0km+jcqyVh0+L01yB0K4VDi1YFJaSBOaYUELBXa
>> > 8a6WhZf5nrl5UIpH7rRcPzzqchcdYczy5VRZp2UsU+HYeqLXlcN0a03yPpVQik9S
>> > /T93MuZgmvSCry5MlccA
>> > =R71g
>> > -----END PGP SIGNATURE-----
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170326/88bf8628/attachment-0001.html>;
đź“ť Original message:As a user, I would far prefer a split over any kind of mandatory change
that would drastically harm the ecosystem. Many users feel the same way.
Level 3 is a pure attack on users who do not conform to your beliefs.
Please do not put words in people's mouths claiming they wouldn't prefer a
split when many would. If you wish to fork off, please do so responsibly.
-Alphonse
On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello Alex,
>
> Thank you for the thoughtful reply.
>
> Surely you are aware that what you are proposing is vastly different from
> the way soft forks have historically worked.
>
>
> Yes, it is different. It’s different because the future network upgrade
> to larger blocks includes a loosening of the consensus ruleset whereas
> previous upgrades have included a tightening of the rule set. (BTW—this is
> not my proposal, I am describing what I have recently learned through my
> work with Bitcoin Unlimited and discussions with miners and businesses).
>
> With a tightening of the rule set, a hash power minority that has not
> upgraded will not produce a minority branch; instead they will simply have
> any invalid blocks they produce orphaned, serving as a wake-up call to
> upgrade.
>
> With a loosening of the consensus rule set, the situation is different: a
> hash power minority that has not upgraded will produce a minority branch,
> that will also drag along non-upgraded node operators, leading to potential
> confusion. The idea behind orphaning the blocks of non-upgraded miners was
> to serve as a wake-up call to upgrade, to reduce the chances of a minority
> chain emerging in the first place, similar to what happens automatically
> with a soft-forking change. If one's worry is a chain split, then this
> seems like a reasonable way to reduce the chances of that worry
> materializing. The Level 3 anti-split protection takes this idea one step
> further to ensure that if a minority branch does emerge, that transactions
> cannot be confirmed on that branch.
>
> First of all, the bar for miners being on the new chain is extremely high,
> 95%.
>
>
> I’m very confident that most people do NOT want a split, especially the
> miners. The upgrade to larger blocks will not happen until miners are
> confident that no minority chain will survive.
>
> Second of all, soft forks make rule restrictions on classes of
> transactions that are already non-standard so that any non-upgraded miners
> are unlikely to be including txs in their blocks which would violate the
> new rules and should not have their blocks orphaned even after the fork.
>
>
> I agree that the soft-fork mechanism usually works well. I believe this
> mechanism (or perhaps a modified version of it) to increase the block size
> limit will likewise work well. All transactions types that are currently
> valid will be valid after the upgrade, and no new types of transactions are
> being created. The “block-size-limit gene" of network nodes is simply
> evolving to allow the network to continue to grow in the way it has always
> grown. (If you’re interested, here is my talk at Coinbase where I discuss
> this: https://www.youtube.com/watch?v=pWnFDocAmfg)
>
> Finally, soft forks are designed to only be used when there is a very wide
> community consensus and the intention is not to overrule anyone's choice to
> remain on the old rules but to ensure the security of nodes that may have
> neglected to upgrade. Obviously it is impossible to draw a bright line
> between users who intentionally are not upgrading due to opposition and
> users that are just being lazy. But in the case of a proposed BU hard fork
> it is abundantly clear that there is a very significant fraction, in fact
> likely a majority of users who intentionally want to remain on the old
> rules.
>
>
> My read is completely different. I still have never talked with a person
> in real life who doesn’t want the block size limit to increase. Indeed, I
> have met people who worry that Bitcoin Unlimited is “trying to take
> over”—and thus they are worried for other reasons—but this couldn’t be
> further from the truth. For example, what most people within BU would love
> to see is a simple patch to Bitcoin Core 0.14 that allows node operators to
> adjust the size of blocks their nodes will accept, so that these node
> operators can follow consensus through the upgrade if they choose to.
>
> This is not a fight about “Core vs. BU”; Bitcoin’s future is one of
> “genetic diversity” with multiple implementations, so that a bug in one
> doesn’t threaten the network as a whole. To me it seems this is largely a
> fight about whether node operators should be easily able to adjust the size
> of blocks their nodes accept. BU makes it easy for node operators to
> accept larger blocks; Core doesn’t believe users should have this power
> (outside of recompiling from source, which few users can do).
>
> As a Bitcoin user I find it abhorrent the way you are proposing to
> intentionally cripple the chain and rules I want to use instead of just
> peacefully splitting.
>
>
> Once again, this is not my proposal. I am writing about what I have come
> to learn over the past several weeks. When I first heard about these
> ideas, I was initially against them too. They seemed harsh and merciless.
> It wasn’t until I got out their and started talking to more people in the
> community that the rationale started to make sense to me: the biggest
> concern people had was a chain split!
>
> So I guess the “ethics” here depend on the lens through which one is
> looking. People who believe that an important outcome of the upgrade to
> larger blocks is to avoid a blockchain split may be more favourable to
> these ideas than people who want the upgrade to result in a split (or are
> OK with a split), as it sounds like you do (is this true that you’d rather
> split than accept blocks with more than 1,000,000 bytes of transaction
> information in them? Sorry if I misunderstood).
>
> But if one's intention is to split and not follow the majority hash power
> when blocks become larger, then why not change the proof-of-work? This
> would certainly result in a peaceful splitting, as you said you desire.
>
> Best regards,
> Peter R
>
>
>
>
> On Sat, Mar 25, 2017 at 3:28 PM, Peter R via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> One of the purported benefits of a soft-forking change (a tightening of
>> the consensus rule set) is the reduced risk of a blockchain split compared
>> to a loosening of the consensus rule set. The way this works is that
>> miners who fail to upgrade to the new tighter ruleset will have their
>> non-compliant blocks orphaned by the hash power majority. This is a strong
>> incentive to upgrade and has historically worked well. If a minority
>> subset of the network didn’t want to abide by the new restricted rule set,
>> a reasonable solution would be for them to change the proof-of-work and
>> start a spin-off from the existing Bitcoin ledger (
>> https://bitcointalk.org/index.php?topic=563972.0).
>>
>> In the case of the coming network upgrade to larger blocks, a primary
>> concern of both business such as Coinbase and Bitpay, and most miners, is
>> the possibility of a blockchain split and the associated confusion, replay
>> risk, etc. By applying techniques that are known to be successful for
>> soft-forking changes, we can likewise benefit in a way that makes a split
>> less likely as we move towards larger blocks. Two proposed techniques to
>> reduce the chances of a split are:
>>
>> 1. That miners begin to orphan the blocks of non-upgraded miners once a
>> super-majority of the network hash power has upgraded. This would serve as
>> an expensive-to-ignore reminder to upgrade.
>>
>> 2. That, in the case where a minority branch emerges (unlikely IMO),
>> majority miners would continually re-org that minority branch with empty
>> blocks to prevent transactions from confirming, thereby eliminating replay
>> risk.
>>
>> Just like after a soft forking change, a minority that does not want to
>> abide by the current ruleset enforced by the majority could change the
>> proof-of-work and start a spin-off from the existing Bitcoin ledger, as
>> suggested by Emin.
>>
>> Best regards,
>> Peter R
>>
>>
>> > On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >
>> > On 03/24/2017 07:00 PM, Aymeric Vitte wrote:
>> >> I don't know what "Time is running short I fear" stands for and when
>> 50%
>> >> is supposed to be reached
>> >
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA512
>> >
>> > On 03/24/2017 07:00 PM, Aymeric Vitte wrote: > I don't know what
>> > "Time is running short I fear" stands for and when 50% > is supposed
>> > to be reached
>> >
>> > According to current hashrate distribution tracking site coin.dance,
>> > very likely within less than four weeks according to current hashrate
>> > takeover rate.
>> >
>> > While a fork is very likely, that I dont really fear because worst
>> > case scenario is that bitcoin still survives and the invalid chain
>> > becomes an alt. My fear is the centralized mining power being used
>> > to attack the valid chain with intentions on killing it. [1]
>> >
>> > Shouldn't this 50% attack they are threatening be a concern? If it
>> > is a concern, what options are on the table. If it is not a concern
>> > please enlightent me as to why.
>> >
>> >
>> > [1] Source:
>> > https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_rizun
>> _tells_miners_to_force_a_hard_fork_by/
>> >
>> > Text:
>> >
>> > The attack quoted from his article:
>> > https://medium.com/@peter_r/on-the-emerging-consensus-regard
>> ing-bitcoins-block-size-limit-insights-from-my-visit-with-2348878a16d8
>> >
>> > [Level 2] Anti-split protection Miners will orphan the
>> > blocks of non-compliant miners prior to the first larger block
>> > to serve as a reminder to upgrade. Simply due to the possibility
>> > of having blocks orphaned, all miners would be motivated to
>> > begin signalling for larger blocks once support definitively
>> > passes 51%. If some miners hold out (e.g., they may not be
>> > paying attention regarding the upgrade), then they will begin
>> > to pay attention after losing approximately $15,000 of revenue
>> > due to an orphaned block.
>> >
>> > [Level 3] Anti-split protection In the scenario where Levels
>> > 1 and 2 protection fails to entice all non-compliant miners to
>> > upgrade, a small-block minority chain may emerge. To address the
>> > risk of coins being spent on this chain (replay risk), majority
>> > miners will deploy hash power as needed to ensure the minority
>> > chain includes only empty blocks after the forking point. This
>> > can easily be accomplished if the majority miners maintain a
>> > secret chain of empty blocks built off their last empty
>> > block publishing only as much of this chain as necessary
>> > to orphan any non-empty blocks produced on the minority chain.
>> >
>> >
>> >
>> >
>> > - --
>> > Cannon
>> > PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
>> > Email: cannon at cannon-ciota.info
>> >
>> > NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
>> > BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
>> > If this matters to you, use PGP.
>> > -----BEGIN PGP SIGNATURE-----
>> >
>> > iQIcBAEBCgAGBQJY1pbaAAoJEAYDai9lH2mwOO0QANOWqGzPNlifWguc+Y5UQxQM
>> > eAiztAayQBoAyLcFE7/qdtSNlUxbIAHG17fM+aNkehjYH2oN5ODJ+j7E2Yt6EoUH
>> > h5t8MLhNRG/YGF1hJK8Io940EmdcjuNmohiZvrjIqEOYggmLU3hR6J4gsuGsQQhu
>> > gY3sMS/TtT+gZNH8w53ePGrsVhuQR7yEMMr91/vM4+Q5abpwqLeYLnslaZDcd3XK
>> > VB9vyyK08r34J1GQt/H4UvTvGs28MFKBkvueA/Sfyvnrih7+WSQLuSvhiFr+cW1B
>> > TmSVYrB2DzyHN27jDCI2ty3ryNE4PMYcaeLfI2TTbsD/MuVU5lK0kM/1JajP4eRj
>> > j+P03OipuQiy/dNU63w0Uka2PbdKhDC13hVtK/ttBbNppbjnGeB9PYSJCzOpInGw
>> > NwAyz0rVS/llGsdctcII7Z6AUMGuJXzsosY8vjUroU+KFRDqIbDfC53sH7DaPh7u
>> > YawwId5S5RnZsAGCUJ+qNcg0s728J1eDjofN291IS5sOKMzpI7KhaOhFxjnk1MpN
>> > ZAlQeTlvG+sAdn61QMQK1NbFt0km+jcqyVh0+L01yB0K4VDi1YFJaSBOaYUELBXa
>> > 8a6WhZf5nrl5UIpH7rRcPzzqchcdYczy5VRZp2UsU+HYeqLXlcN0a03yPpVQik9S
>> > /T93MuZgmvSCry5MlccA
>> > =R71g
>> > -----END PGP SIGNATURE-----
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170326/88bf8628/attachment-0001.html>;