Bitcoin XT Fork

> I have been following the recent block size debates through the mailing list.  I had hoped the debate would resolve and that a fork proposal would achieve widespread consensus.  However with the formal release of Bitcoin XT 0.11A, this looks unlikely to happen, and so I am forced to share my concerns about this very dangerous fork.
>
> The developers of this pretender-Bitcoin claim to be following my original vision, but nothing could be further from the truth.  When I designed Bitcoin, I designed it in such a way as to make future modifications to the consensus rules difficult without near unanimous agreement.  Bitcoin was designed to be protected from the influence of charismatic leaders, even if their name is Gavin Andresen, Barack Obama, or Satoshi Nakamoto.  Nearly everyone has to agree on a change, and they have to do it without being forced or pressured into it.  By doing a fork in this way, these developers are violating the "original vision" they claim to honour.
>
> They use my old writings to make claims about what Bitcoin was supposed to be.  However I acknowledge that a lot has changed since that time, and new knowledge has been gained that contradicts some of my early opinions.  For example I didn't anticipate pooled mining and its effects on the security of the network.  Making Bitcoin a competitive monetary system while also preserving its security properties is not a trivial problem, and we should take more time to come up with a robust solution.  I suspect we need a better incentive for users to run nodes instead of relying solely on altruism.
>
> If two developers can fork Bitcoin and succeed in redefining what "Bitcoin" is, in the face of widespread technical criticism and through the use of populist tactics, then I will have no choice but to declare Bitcoin a failed project.  Bitcoin was meant to be both technically and socially robust.  This present situation has been very disappointing to watch unfold.
>
> Satoshi Nakamoto
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

> I have been following the recent block size debates through the
> mailing list.  I had hoped the debate would resolve and that a fork
> proposal would achieve widespread consensus.  However with the formal
> release of Bitcoin XT 0.11A, this looks unlikely to happen, and so I
> am forced to share my concerns about this very dangerous fork.
>
> The developers of this pretender-Bitcoin claim to be following my
> original vision, but nothing could be further from the truth.  When I
> designed Bitcoin, I designed it in such a way as to make future
> modifications to the consensus rules difficult without near unanimous
> agreement.  Bitcoin was designed to be protected from the influence of
> charismatic leaders, even if their name is Gavin Andresen, Barack
> Obama, or Satoshi Nakamoto.  Nearly everyone has to agree on a change,
> and they have to do it without being forced or pressured into it.  By
> doing a fork in this way, these developers are violating the "original
> vision" they claim to honour.
>
> They use my old writings to make claims about what Bitcoin was
> supposed to be.  However I acknowledge that a lot has changed since
> that time, and new knowledge has been gained that contradicts some of
> my early opinions.  For example I didn't anticipate pooled mining and
> its effects on the security of the network.  Making Bitcoin a
> competitive monetary system while also preserving its security
> properties is not a trivial problem, and we should take more time to
> come up with a robust solution.  I suspect we need a better incentive
> for users to run nodes instead of relying solely on altruism.
>
> If two developers can fork Bitcoin and succeed in redefining what
> "Bitcoin" is, in the face of widespread technical criticism and
> through the use of populist tactics, then I will have no choice but to
> declare Bitcoin a failed project.  Bitcoin was meant to be both
> technically and socially robust.  This present situation has been very
> disappointing to watch unfold.
>
> Satoshi Nakamoto
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

> I have been following the recent block size debates through the mailing list.  I had hoped the debate would resolve and that a fork proposal would achieve widespread consensus.  However with the formal release of Bitcoin XT 0.11A, this looks unlikely to happen, and so I am forced to share my concerns about this very dangerous fork.
>
> The developers of this pretender-Bitcoin claim to be following my original vision, but nothing could be further from the truth.  When I designed Bitcoin, I designed it in such a way as to make future modifications to the consensus rules difficult without near unanimous agreement.  Bitcoin was designed to be protected from the influence of charismatic leaders, even if their name is Gavin Andresen, Barack Obama, or Satoshi Nakamoto.  Nearly everyone has to agree on a change, and they have to do it without being forced or pressured into it.  By doing a fork in this way, these developers are violating the "original vision" they claim to honour.
>
> They use my old writings to make claims about what Bitcoin was supposed to be.  However I acknowledge that a lot has changed since that time, and new knowledge has been gained that contradicts some of my early opinions.  For example I didn't anticipate pooled mining and its effects on the security of the network.  Making Bitcoin a competitive monetary system while also preserving its security properties is not a trivial problem, and we should take more time to come up with a robust solution.  I suspect we need a better incentive for users to run nodes instead of relying solely on altruism.
>
> If two developers can fork Bitcoin and succeed in redefining what "Bitcoin" is, in the face of widespread technical criticism and through the use of populist tactics, then I will have no choice but to declare Bitcoin a failed project.  Bitcoin was meant to be both technically and socially robust.  This present situation has been very disappointing to watch unfold.
>
> Satoshi Nakamoto

> That made it to the news and is now discussed in various places. Could
> you please delete Satoshis old email addresses from the list and block
> them? Sorry to post this to all members but I can't find an owner for
> this list.

>
> On Aug 17, 2015 1:40 PM, "Oliver Egginger via bitcoin-dev"
> <bitcoin-dev@lists•linuxfoundation•org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>> That made it to the news and is now discussed in various places. Could
>> you please delete Satoshis old email addresses from the list and block
>> them? Sorry to post this to all members but I can't find an owner for
>> this list.
>
> Why should we block any email address?

> Am 17.08.2015 um 13:44 schrieb Jorge Timón:
>>
>> On Aug 17, 2015 1:40 PM, "Oliver Egginger via bitcoin-dev"
>> <bitcoin-dev@lists•linuxfoundation•org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>>> That made it to the news and is now discussed in various places. Could
>>> you please delete Satoshis old email addresses from the list and block
>>> them? Sorry to post this to all members but I can't find an owner for
>>> this list.
>>
>> Why should we block any email address?
>
> To avoid such discussions.

> On Mon, Aug 17, 2015 at 1:51 PM, Oliver Egginger <bitcoin@olivere•de> wrote:
>> Am 17.08.2015 um 13:44 schrieb Jorge Timón:
>>>
>>> On Aug 17, 2015 1:40 PM, "Oliver Egginger via bitcoin-dev"
>>> <bitcoin-dev@lists•linuxfoundation•org
>>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>>>> That made it to the news and is now discussed in various places. Could
>>>> you please delete Satoshis old email addresses from the list and block
>>>> them? Sorry to post this to all members but I can't find an owner for
>>>> this list.
>>>
>>> Why should we block any email address?
>>
>> To avoid such discussions.
>
> You mean to avoid discussions about his authenticity?
> Should that matter at all?
> Does the content of the post matter less than its author?

> Am 17.08.2015 um 18:32 schrieb Jorge Timón:
>> On Mon, Aug 17, 2015 at 1:51 PM, Oliver Egginger <bitcoin@olivere•de> wrote:
>>> Am 17.08.2015 um 13:44 schrieb Jorge Timón:
>>>>
>>>> On Aug 17, 2015 1:40 PM, "Oliver Egginger via bitcoin-dev"
>>>> <bitcoin-dev@lists•linuxfoundation•org
>>>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>>>>> That made it to the news and is now discussed in various places. Could
>>>>> you please delete Satoshis old email addresses from the list and block
>>>>> them? Sorry to post this to all members but I can't find an owner for
>>>>> this list.
>>>>
>>>> Why should we block any email address?
>>>
>>> To avoid such discussions.
>>
>> You mean to avoid discussions about his authenticity?
>> Should that matter at all?
>> Does the content of the post matter less than its author?
>
> It just creates confusion. Particularly in the media. I also find it
> unfair if people abuses Satoshi's name to submit their personal views on
> an issue.

> To avoid such discussions.

> I have been following the recent block size debates through the mailing
> list.  I had hoped the debate would resolve and that a fork proposal would
> achieve widespread consensus.  However with the formal release of Bitcoin
> XT 0.11A, this looks unlikely to happen, and so I am forced to share my
> concerns about this very dangerous fork.
>
> The developers of this pretender-Bitcoin claim to be following my original
> vision, but nothing could be further from the truth.  When I designed
> Bitcoin, I designed it in such a way as to make future modifications to the
> consensus rules difficult without near unanimous agreement.  Bitcoin was
> designed to be protected from the influence of charismatic leaders, even if
> their name is Gavin Andresen, Barack Obama, or Satoshi Nakamoto.  Nearly
> everyone has to agree on a change, and they have to do it without being
> forced or pressured into it.  By doing a fork in this way, these developers
> are violating the "original vision" they claim to honour.
>
> They use my old writings to make claims about what Bitcoin was supposed to
> be.  However I acknowledge that a lot has changed since that time, and new
> knowledge has been gained that contradicts some of my early opinions.  For
> example I didn't anticipate pooled mining and its effects on the security
> of the network.  Making Bitcoin a competitive monetary system while also
> preserving its security properties is not a trivial problem, and we should
> take more time to come up with a robust solution.  I suspect we need a
> better incentive for users to run nodes instead of relying solely on
> altruism.
>
> If two developers can fork Bitcoin and succeed in redefining what
> "Bitcoin" is, in the face of widespread technical criticism and through the
> use of populist tactics, then I will have no choice but to declare Bitcoin
> a failed project.  Bitcoin was meant to be both technically and socially
> robust.  This present situation has been very disappointing to watch unfold.
>
> Satoshi Nakamoto
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

>
> That made it to the news and is now discussed in various places. Could
> you please delete Satoshis old email addresses from the list and block
> them? Sorry to post this to all members but I can't find an owner for
> this list.
>
> - oliver

> On Mon, Aug 17, 2015 at 11:51 AM, Oliver Egginger via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
> > To avoid such discussions.
>
> You seem to be assuming that there is specific reason to believe the
> message is unauthentic.  This is not the case.
>
> Contrary to other poster's claims, if the message had been PGP signed
> that might, in fact, have arguably been weak evidence that it was
> unauthentic: no message from the system's creator that I (or
> apparently anyone) was aware of was ever signed with that key.

> A focus on the content is especially relevant because one of the core
> messages in the content is a request to eschew arguments from
> authority; which is perhaps the greatest challenge here: How can the
> founder of a system speak up to ask people to reject that kind of
> argument without implicitly endorsing that approach through their own
> act?

> I suspect we need a better incentive for users to run nodes instead of
> relying solely on altruism.
>

> On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>
>> I suspect we need a better incentive for users to run nodes instead of
>> relying solely on altruism.
>
>
> Is he talking about "full nodes" i.e. validating-only, or nodes in the sense
> of the original whitepaper (i.e. miners)? Because there is already plenty of
> incentive for running a node (i.e. the coinbase).

> enter the mining game. A bit like making P2Pool the one and only pool
> allowed on the network.

>> enter the mining game. A bit like making P2Pool the one and only pool
>> allowed on the network.
>
> Thats been suggested, though scalablity reasons make this hard: in the
> P2Pool design there is a substantial tradeoff in variance reduction vs
> communicatoin costs.

> Satoshi,
>
> As much as I want to believe this is you it's very difficult to ignore the
> fact that Vistomail could have been hacked and I'm currently speaking to a
> troll.
> Can you copy and paste what you wrote above, to
> http://p2pfoundation.ning.com as well, like how you did during the Dorian
> fiasco?
>
>
> Much appreciated.
>
>
> On Sat, Aug 15, 2015 at 10:43 AM, Satoshi Nakamoto via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
>> I have been following the recent block size debates through the mailing
>> list.  I had hoped the debate would resolve and that a fork proposal would
>> achieve widespread consensus.  However with the formal release of Bitcoin
>> XT 0.11A, this looks unlikely to happen, and so I am forced to share my
>> concerns about this very dangerous fork.
>>
>> The developers of this pretender-Bitcoin claim to be following my
>> original vision, but nothing could be further from the truth.  When I
>> designed Bitcoin, I designed it in such a way as to make future
>> modifications to the consensus rules difficult without near unanimous
>> agreement.  Bitcoin was designed to be protected from the influence of
>> charismatic leaders, even if their name is Gavin Andresen, Barack Obama, or
>> Satoshi Nakamoto.  Nearly everyone has to agree on a change, and they have
>> to do it without being forced or pressured into it.  By doing a fork in
>> this way, these developers are violating the "original vision" they claim
>> to honour.
>>
>> They use my old writings to make claims about what Bitcoin was supposed
>> to be.  However I acknowledge that a lot has changed since that time, and
>> new knowledge has been gained that contradicts some of my early opinions.
>> For example I didn't anticipate pooled mining and its effects on the
>> security of the network.  Making Bitcoin a competitive monetary system
>> while also preserving its security properties is not a trivial problem, and
>> we should take more time to come up with a robust solution.  I suspect we
>> need a better incentive for users to run nodes instead of relying solely on
>> altruism.
>>
>> If two developers can fork Bitcoin and succeed in redefining what
>> "Bitcoin" is, in the face of widespread technical criticism and through the
>> use of populist tactics, then I will have no choice but to declare Bitcoin
>> a failed project.  Bitcoin was meant to be both technically and socially
>> robust.  This present situation has been very disappointing to watch unfold.
>>
>> Satoshi Nakamoto
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

> For the record I would like to share my technical analysis of the Satoshi
> email which I wrote in a pastebin (http://pastebin.com/Ct5M8fa2) a few
> days ago.
>
> 1. The email is the one used by Satoshi to announce Bitcoin in the first
> place.
> http://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html
>
> 2. The email was not spoofed, it actually originated from vistomail's
> server. The email headers show the email originated from 190.97.163.93
> and the SPF records show this as an authorised sender for the email. This
> does not prove the account wasn't hacked of course, or that the account
> might have expired and be re-registered by someone else (vistomail is a
> paid for email provider).
>
> 3. While the email is not signed, and there are a number of PGP keys
> listed on key servers for him (to vary addresses), he didnt sign any emails
> with any PGP keys.
>
> It is therefore not possible to outright dismiss the email's authenticity
> as the email originates from an authentic source. The only questions is
> whether the webmail service was hacked or commandeered somehow.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

> This bitcoin-dev list restarted with an empty subscriber list on June
> 21st, 2015.  So whoever posted from satoshi@vistomail•com
> <mailto:satoshi@vistomail.com> subscribed and verified the address
> recently.  Do you propose that we manually approve new subscribers to
> prevent these kind of "abuses" as you put it?

> They use my old writings to make claims about what Bitcoin was supposed to be.  However I acknowledge that a lot has changed since that time, and new knowledge has been gained that contradicts some of my early opinions.  For example I didn't anticipate pooled mining and its effects on the security of the network.  Making Bitcoin a competitive monetary system while also preserving its security properties is not a trivial problem, and we should take more time to come up with a robust solution.  I suspect we need a better incentive for users to run nodes instead of relying solely on altruism.

> wallet, it's not very secure to use Hearn-style SPV mode, and volunteers
> running full nodes doesn't help things. Sybil attacking the IP address
> space is pretty easy in comparison to aquiring hashing power sufficient
> to create false confirmations, so any attacker able to do the former
> will likely be running the full node you're connecting too anyway.
> Ultimately, Hearn-style SPV is a close approximation to just trusting
> anyone with a non-trivial amount of hashing power. (and getting that is
> surprisingly easy, e.g. w/ SPV mining)

> Can you explain how the spv node fails against an attacker with a
> non-trivial amount of hash power where a full node doesn't? To attack an
> spv wallet that is waiting for 6 or 10 confirmations, you would not only
> need to Sybil them but also summon a massive amount of hashing power to
> create a chain of headers (while forgoing the opportunity to mine valid
> blocks with that hash power).
>
> But could someone with that much hash power not Sybil a full node and give
> them a chain for valid blocks (but on an orphan fork)? The failure model
> doesn't seem specific to spv to me.

> Hello,
>
> I might have a "crazy" simple solution.
> From the literature I read, it seems that Satochi has the keys that would
> authenticate him using Bitcoin.
>
> HBO John Oliver's program might have given me (and hopefully others) the
> brilliant idea to protect the Bitcoin network from the overzealous reach of
> the politicians. One need to start a Church, and to start the Church one
> need funds (121UZ1hDs9MgCHonA8vjXr89D8FuDf5c7t) to start.
>
> John Oliver's program on HBO about Churches (and the hypocrisy of some)
> was epic and such entity could argue that Bitcoin is a belief system (which
> it is) and would force the issue at a Federal level under the Church and
> State separation. - John's video :
> https://www.youtube.com/watch?v=7y1xJAVZxXg
>
> At this time, I am waiting for the License issue to walk its course in New
> York State.
>
> Currently:
>
>    - I am waiting for my License to be denied (to protest) and appeal it.
>    - Waiting to hear from the License process to appeal the law in
>    general.
>    - Meeting Elected officials (in New York City, NY State, and France)
>    and educating them on Bitcoin.
>
> Every time we (the community) talk about Bitcoin, it can sound like
> religion; therefore why not go all the way and do what John Oliver did ?
> Seed money would help. :)
>
> Regarding the Fork, from my perspective of a small company, I see that
> like it was with IRC with the ICMP node split. The Church thing is not here
> to take side but to "try" to protect the Bitcoin.
>
> We will need to ordain ministers selected after completing prescribed
> courses of study setup by the developers.
>
> In short I am asking Satochi to help this church with original coins. If
> it is a troll, I am talking to the Dev Community at large to recruit them
> to ordain the ministers.
>
> Regards,
> *Theo Chino*
>
>
> *https://www.facebook.com/groups/557495624389384
> <https://www.facebook.com/groups/557495624389384> (NY
> State)http://frenchmorning.com/en/2014/08/18/french-robin-hood-bitcoin-new-york
> <http://frenchmorning.com/en/2014/08/18/french-robin-hood-bitcoin-new-york>*
>
> *(My position on the fork is still the same as when I ran for a seat of
> the Foundation; still don't have enough information and thing will move
> faster than I can devote the time to read about it.)*
>
> On Mon, Aug 17, 2015 at 1:30 PM, Btc Drak via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
>> For the record I would like to share my technical analysis of the Satoshi
>> email which I wrote in a pastebin (http://pastebin.com/Ct5M8fa2) a few
>> days ago.
>>
>> 1. The email is the one used by Satoshi to announce Bitcoin in the first
>> place.
>> http://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html
>>
>> 2. The email was not spoofed, it actually originated from vistomail's
>> server. The email headers show the email originated from 190.97.163.93
>> and the SPF records show this as an authorised sender for the email.
>> This does not prove the account wasn't hacked of course, or that the
>> account might have expired and be re-registered by someone else (vistomail
>> is a paid for email provider).
>>
>> 3. While the email is not signed, and there are a number of PGP keys
>> listed on key servers for him (to vary addresses), he didnt sign any emails
>> with any PGP keys.
>>
>> It is therefore not possible to outright dismiss the email's authenticity
>> as the email originates from an authentic source. The only questions is
>> whether the webmail service was hacked or commandeered somehow.
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

> Would we discuss his
> posting if he would not claim to be Satoshi? There are a lot of smart
> people on this list, which publish occasionally quite useful ideas.

> Am 17.08.2015 um 21:03 schrieb Warren Togami Jr.:
> > This bitcoin-dev list restarted with an empty subscriber list on June
> > 21st, 2015.  So whoever posted from satoshi@vistomail•com
> > <mailto:satoshi@vistomail.com> subscribed and verified the address
> > recently.  Do you propose that we manually approve new subscribers to
> > prevent these kind of "abuses" as you put it?
>
> I would simply block the creators old email addresses. Easy with
> Mailman. I thought that would be a good and easy approach, but maybe I'm
> wrong.
>
> Some believes it is possible that the email could be genuine. Some say
> that only the content is important. I have closely followed. An
> interesting discussion. Thank you all so far.
>
> But let's say the poster would be the real Satoshi. Would we discuss his
> posting if he would not claim to be Satoshi? There are a lot of smart
> people on this list, which publish occasionally quite useful ideas. But
> much of this is hardly the subject of greater discussion. Especially not
> when it comes to the blocksize. On this subject almost everything has
> been already said. But not yet by everyone. Especially not by Satoshi.
>
> Satoshi would have a decisive influence on the community. I'm sure. To
> say it does not matter who's talking is maybe genteelly but a little bit
> remote from everyday life. Or not? Satoshi is the creator. What he says
> is in the newspaper and is perceived by all. If he says it's okay to do
> nothing as long as we stand together, then people have the courage to do
> maybe something dangerous or something wrong. Then people only follow
> their hearts. Otherwise they follow their fear. It is a paradox of the
> human nature that some type of Dictatorship can make you free. I say
> some type, not any type. Enough said.
>
> - oliver
>
>

> I honestly don't understand your position, but I get the sense that you
> are suggesting Satoshi wouldn't be welcome to return if he wanted to be
> active in development again?
>
> Warren
> On Aug 17, 2015 1:38 PM, "Oliver Egginger" <bitcoin@olivere•de
> <javascript:_e(%7B%7D,'cvml','bitcoin@olivere•de');>> wrote:
>
>> Am 17.08.2015 um 21:03 schrieb Warren Togami Jr.:
>> > This bitcoin-dev list restarted with an empty subscriber list on June
>> > 21st, 2015.  So whoever posted from satoshi@vistomail•com
>> <javascript:_e(%7B%7D,'cvml','satoshi@vistomail•com');>
>> > <mailto:satoshi@vistomail.com
>> <javascript:_e(%7B%7D,'cvml','satoshi@vistomail•com');>> subscribed and
>> verified the address
>> > recently.  Do you propose that we manually approve new subscribers to
>> > prevent these kind of "abuses" as you put it?
>>
>> I would simply block the creators old email addresses. Easy with
>> Mailman. I thought that would be a good and easy approach, but maybe I'm
>> wrong.
>>
>> Some believes it is possible that the email could be genuine. Some say
>> that only the content is important. I have closely followed. An
>> interesting discussion. Thank you all so far.
>>
>> But let's say the poster would be the real Satoshi. Would we discuss his
>> posting if he would not claim to be Satoshi? There are a lot of smart
>> people on this list, which publish occasionally quite useful ideas. But
>> much of this is hardly the subject of greater discussion. Especially not
>> when it comes to the blocksize. On this subject almost everything has
>> been already said. But not yet by everyone. Especially not by Satoshi.
>>
>> Satoshi would have a decisive influence on the community. I'm sure. To
>> say it does not matter who's talking is maybe genteelly but a little bit
>> remote from everyday life. Or not? Satoshi is the creator. What he says
>> is in the newspaper and is perceived by all. If he says it's okay to do
>> nothing as long as we stand together, then people have the courage to do
>> maybe something dangerous or something wrong. Then people only follow
>> their hearts. Otherwise they follow their fear. It is a paradox of the
>> human nature that some type of Dictatorship can make you free. I say
>> some type, not any type. Enough said.
>>
>> - oliver
>>
>>

> I honestly don't understand your position, but I get the sense that you
> are suggesting Satoshi wouldn't be welcome to return if he wanted to be
> active in development again?

> Am 18.08.2015 um 11:15 schrieb Warren Togami Jr.:
> > I honestly don't understand your position, but I get the sense that you
> > are suggesting Satoshi wouldn't be welcome to return if he wanted to be
> > active in development again?
>
> Who am I? Personally I have zero objection if the creator steps in. I
> think he would be highly welcome by the most people. At first I had the
> impression that the email was a fake, but maybe I was wrong. At the
> moment I think: Maybe it's even the best if we do not know exactly
> whether it was Satoshi or not.
>
> Unanimity is mission critical for Bitcoin and must be an absolute
> priority. If not the vast majority is in favor for a fork, then the fork
> should be avoided until a consensus is found. Even if it takes until the
> cows come home.
>
> But it is very likely now that it will come to a fork. No matter which
> site will win, this will produce a lot of humiliated people at the end.
> That's not good and leads to bitterness on both sites.
>
> - oliver
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> And this is how the powers that be compromise bitcoin. They can't stop
> TCP/IP, but they sure can take over the development team. It's a good thing
> that no one from the CIA has had any conversations with anyone from the
> bitcoin development team. Phew...
>
>
> On Tue, Aug 18, 2015 at 11:57 AM, Oliver Egginger via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
>> Am 18.08.2015 um 11:15 schrieb Warren Togami Jr.:
>> > I honestly don't understand your position, but I get the sense that you
>> > are suggesting Satoshi wouldn't be welcome to return if he wanted to be
>> > active in development again?
>>
>> Who am I? Personally I have zero objection if the creator steps in. I
>> think he would be highly welcome by the most people. At first I had the
>> impression that the email was a fake, but maybe I was wrong. At the
>> moment I think: Maybe it's even the best if we do not know exactly
>> whether it was Satoshi or not.
>>
>> Unanimity is mission critical for Bitcoin and must be an absolute
>> priority. If not the vast majority is in favor for a fork, then the fork
>> should be avoided until a consensus is found. Even if it takes until the
>> cows come home.
>>
>> But it is very likely now that it will come to a fork. No matter which
>> site will win, this will produce a lot of humiliated people at the end.
>> That's not good and leads to bitterness on both sites.
>>
>> - oliver
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

> I have been following the recent block size debates through the
> mailing list.  I had hoped the debate would resolve and that a fork
> proposal would achieve widespread consensus.  However with the
> formal release of Bitcoin XT 0.11A, this looks unlikely to happen,
> and so I am forced to share my concerns about this very dangerous
> fork.
>
> The developers of this pretender-Bitcoin claim to be following my
> original vision, but nothing could be further from the truth.  When
> I designed Bitcoin, I designed it in such a way as to make future
> modifications to the consensus rules difficult without near
> unanimous agreement.  Bitcoin was designed to be protected from the
> influence of charismatic leaders, even if their name is Gavin
> Andresen, Barack Obama, or Satoshi Nakamoto.  Nearly everyone has
> to agree on a change, and they have to do it without being forced
> or pressured into it.  By doing a fork in this way, these
> developers are violating the "original vision" they claim to
> honour.
>
> They use my old writings to make claims about what Bitcoin was
> supposed to be.  However I acknowledge that a lot has changed since
> that time, and new knowledge has been gained that contradicts some
> of my early opinions.  For example I didn't anticipate pooled
> mining and its effects on the security of the network.  Making
> Bitcoin a competitive monetary system while also preserving its
> security properties is not a trivial problem, and we should take
> more time to come up with a robust solution.  I suspect we need a
> better incentive for users to run nodes instead of relying solely
> on altruism.
>
> If two developers can fork Bitcoin and succeed in redefining what
> "Bitcoin" is, in the face of widespread technical criticism and
> through the use of populist tactics, then I will have no choice but
> to declare Bitcoin a failed project.  Bitcoin was meant to be both
> technically and socially robust.  This present situation has been
> very disappointing to watch unfold.
>
> Satoshi Nakamoto
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The "XT Fork" (better said, a POS alt*) and those behind it make not
> even a pretense to work through process involved with bitcoin developmen
> t.
>
> (*This is not intended as a slight toward any other alts, as here in
> this post I am focusing solely on XT.)
>
> Instead of abandoning their useless project, or at least conceding
> that their alt is operating essentially outside of the development
> funnel (by this I mean BIP process), the developers of XT, via their
> latest presentation of XT give nothing more than an attack on bitcoin
> (albeit one that, more than anything, is designed to sidetrack real
> discussion necessary to resolve the issues so as to achieve some level
> of consensus in block size debates).  Curiously, XT is not even truly
> the implementation of BIP 101; the actual proposed implementation of
> BIP 101 as proposed at
> https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki#implement
> ation
> is found here: https://github.com/bitcoin/bitcoin/pull/6341
> (It is currently a closed issue.)
>
> It's probably valid to call into question why Mike Hearn in particular
> persists with this project at all, as he has been its biggest
> cheerleader. Some reasons may be:
> 1) His interest in attacking bitcoin in the past (seems to be a
> recurring pattern)
> https://bitcointalk.org/index.php?topic=333824.0
>
> 2) His employment (has come up before) - QinetiQ, Google, etc
> https://plus.google.com/+MikeHearn/about - it's simply not
> unreasonable to ask why he's pushing it so hard when nobody wants it.
>
> 3) Various reasons mentioned here:
> https://www.reddit.com/r/Bitcoin/comments/39yaug/the_history_of_mike_hea
> rn_and_why_you_should_not/
>
>
> 4) His disinterest in following what is actually happening with votes
> on legitimate proposals (e.g. Garzik's BIP 100) in the blocks. (Caveat
> ~ one doesn't see the BIP 100 yet in bitcoin/bips because it won't
> appear for another couple weeks, supposedly.  The miners' voting is
> already happening however.) Even according to http://xtnodes.com/ we
> see that XT runs minimal nodes in comparison to the rest of nodes
> being run across the network.
>
> BIP 100 itself is anticipated to be submitted w/ implementation in the
> next 2 weeks and many miners are already voting on BIP 100 (as per
> Jeff Garzik, from a post 08/12/2015 12:46 PM -0400 to this mailing list)
> .
>
>  It is an insult to see Hearn fling the XT turd into the community
> repeatedly.
>
> How then to end this XT madness?
>
> "The ring was made in the fires of Mount Doom. Only there can it be
> unmade. The ring must be taken deep into Mordor and cast back into the
> fiery chasm from whence it came. One of you must do this."
> - - Lord Elrond
>
> Do not download this loathsome XT thing. Cast it back into the fires
> from whence it came.
>
> - -Odinn
>
>
> On 08/15/2015 10:43 AM, Satoshi Nakamoto via bitcoin-dev wrote:
> > I have been following the recent block size debates through the
> > mailing list.  I had hoped the debate would resolve and that a fork
> > proposal would achieve widespread consensus.  However with the
> > formal release of Bitcoin XT 0.11A, this looks unlikely to happen,
> > and so I am forced to share my concerns about this very dangerous
> > fork.
> >
> > The developers of this pretender-Bitcoin claim to be following my
> > original vision, but nothing could be further from the truth.  When
> > I designed Bitcoin, I designed it in such a way as to make future
> > modifications to the consensus rules difficult without near
> > unanimous agreement.  Bitcoin was designed to be protected from the
> > influence of charismatic leaders, even if their name is Gavin
> > Andresen, Barack Obama, or Satoshi Nakamoto.  Nearly everyone has
> > to agree on a change, and they have to do it without being forced
> > or pressured into it.  By doing a fork in this way, these
> > developers are violating the "original vision" they claim to
> > honour.
> >
> > They use my old writings to make claims about what Bitcoin was
> > supposed to be.  However I acknowledge that a lot has changed since
> > that time, and new knowledge has been gained that contradicts some
> > of my early opinions.  For example I didn't anticipate pooled
> > mining and its effects on the security of the network.  Making
> > Bitcoin a competitive monetary system while also preserving its
> > security properties is not a trivial problem, and we should take
> > more time to come up with a robust solution.  I suspect we need a
> > better incentive for users to run nodes instead of relying solely
> > on altruism.
> >
> > If two developers can fork Bitcoin and succeed in redefining what
> > "Bitcoin" is, in the face of widespread technical criticism and
> > through the use of populist tactics, then I will have no choice but
> > to declare Bitcoin a failed project.  Bitcoin was meant to be both
> > technically and socially robust.  This present situation has been
> > very disappointing to watch unfold.
> >
> > Satoshi Nakamoto
> >
> > _______________________________________________ bitcoin-dev mailing
> > list bitcoin-dev@lists•linuxfoundation•org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
> - --
> http://abis.io ~
> "a protocol concept to enable decentralization
> and expansion of a giving economy, and a new social good"
> https://keybase.io/odinn
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJV0+/fAAoJEGxwq/inSG8C4ZAIAKm1pEne0FlOW1O4zLe6mZOz
> YTcnpSHFiVw4AfUPgbzR813ODphnJqcwnoT1q/sojjqgIDtwZY+AqdjA3VAbe15D
> bAPlvQGmXMlaXq8OteDYPKxPzQMUlRtxEd9+sxO5IGFx0kvmKQLzdk6cmgawcRhN
> PrDyXIqLlx6Yp0REQ03v3poLTGojUkPLeqdMrJAjwpuAyv9F8iVUn7SeHemEi8cm
> fW4wOJogA8j9P//3a7+Cr8bjnOz6+QwpHsdlZlKM4VUTxt3Vgx4vu+SQjQxWgZEK
> I+HGvgQW1buoDxleBbFq6SJc55lhF41IB17tewuDuPzT2nL4zOkbis1tUk3ASxY=
> =Rm7w
> -----END PGP SIGNATURE-----
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

>
> On Aug 17, 2015 5:29 PM, "Peter Todd via bitcoin-dev"
> <bitcoin-dev@lists•linuxfoundation•org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: From the
> point of view of a
>> wallet, it's not very secure to use Hearn-style SPV mode, and
>> volunteers running full nodes doesn't help things. Sybil
>> attacking the IP address space is pretty easy in comparison to
>> aquiring hashing power sufficient to create false confirmations,
>> so any attacker able to do the former will likely be running the
>> full node you're connecting too anyway. Ultimately, Hearn-style
>> SPV is a close approximation to just trusting anyone with a
>> non-trivial amount of hashing power. (and getting that is
>> surprisingly easy, e.g. w/ SPV mining)
>
> Can you explain how the spv node fails against an attacker with a
> non-trivial amount of hash power where a full node doesn't? To
> attack an spv wallet that is waiting for 6 or 10 confirmations, you
> would not only need to Sybil them but also summon a massive amount
> of hashing power to create a chain of headers (while forgoing the
> opportunity to mine valid blocks with that hash power).
>
> But could someone with that much hash power not Sybil a full node
> and give them a chain for valid blocks (but on an orphan fork)? The
> failure model doesn't seem specific to spv to me.
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> My interpretation is that he's saying Satoshi wouldn't be welcome to
> return as Satoshi, because whatever he did/said would inevitably end up
> being treated with authority, which shouldn't be the case.
>
>
> On Tuesday, August 18, 2015, Warren Togami Jr. via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
>> I honestly don't understand your position, but I get the sense that you
>> are suggesting Satoshi wouldn't be welcome to return if he wanted to be
>> active in development again?
>>
>> Warren
>> On Aug 17, 2015 1:38 PM, "Oliver Egginger" <bitcoin@olivere•de> wrote:
>>
>>> Am 17.08.2015 um 21:03 schrieb Warren Togami Jr.:
>>> > This bitcoin-dev list restarted with an empty subscriber list on June
>>> > 21st, 2015.  So whoever posted from satoshi@vistomail•com
>>> > <mailto:satoshi@vistomail.com> subscribed and verified the address
>>> > recently.  Do you propose that we manually approve new subscribers to
>>> > prevent these kind of "abuses" as you put it?
>>>
>>> I would simply block the creators old email addresses. Easy with
>>> Mailman. I thought that would be a good and easy approach, but maybe I'm
>>> wrong.
>>>
>>> Some believes it is possible that the email could be genuine. Some say
>>> that only the content is important. I have closely followed. An
>>> interesting discussion. Thank you all so far.
>>>
>>> But let's say the poster would be the real Satoshi. Would we discuss his
>>> posting if he would not claim to be Satoshi? There are a lot of smart
>>> people on this list, which publish occasionally quite useful ideas. But
>>> much of this is hardly the subject of greater discussion. Especially not
>>> when it comes to the blocksize. On this subject almost everything has
>>> been already said. But not yet by everyone. Especially not by Satoshi.
>>>
>>> Satoshi would have a decisive influence on the community. I'm sure. To
>>> say it does not matter who's talking is maybe genteelly but a little bit
>>> remote from everyday life. Or not? Satoshi is the creator. What he says
>>> is in the newspaper and is perceived by all. If he says it's okay to do
>>> nothing as long as we stand together, then people have the courage to do
>>> maybe something dangerous or something wrong. Then people only follow
>>> their hearts. Otherwise they follow their fear. It is a paradox of the
>>> human nature that some type of Dictatorship can make you free. I say
>>> some type, not any type. Enough said.
>>>
>>> - oliver
>>>
>>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

> "How then to end this XT madness?"
>
> Instead of bashing on someone that has actually put a solution forward, make
> your own fork and see if your ideas on how to solve the issue are any
> better.
>
> As of now, 1Mb blocks are pure madness, and people are voting over an 8mb
> block increase every day that passes, even with a "useless project" like you
> call it.
>
> Go out there and see how bitcoin is actually used.
>
> http://twitter.com/gubatron
>
> On Tue, Aug 18, 2015 at 10:54 PM, odinn via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> The "XT Fork" (better said, a POS alt*) and those behind it make not
>> even a pretense to work through process involved with bitcoin developmen
>> t.
>>
>> (*This is not intended as a slight toward any other alts, as here in
>> this post I am focusing solely on XT.)
>>
>> Instead of abandoning their useless project, or at least conceding
>> that their alt is operating essentially outside of the development
>> funnel (by this I mean BIP process), the developers of XT, via their
>> latest presentation of XT give nothing more than an attack on bitcoin
>> (albeit one that, more than anything, is designed to sidetrack real
>> discussion necessary to resolve the issues so as to achieve some level
>> of consensus in block size debates).  Curiously, XT is not even truly
>> the implementation of BIP 101; the actual proposed implementation of
>> BIP 101 as proposed at
>> https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki#implement
>> ation
>> is found here: https://github.com/bitcoin/bitcoin/pull/6341
>> (It is currently a closed issue.)
>>
>> It's probably valid to call into question why Mike Hearn in particular
>> persists with this project at all, as he has been its biggest
>> cheerleader. Some reasons may be:
>> 1) His interest in attacking bitcoin in the past (seems to be a
>> recurring pattern)
>> https://bitcointalk.org/index.php?topic=333824.0
>>
>> 2) His employment (has come up before) - QinetiQ, Google, etc
>> https://plus.google.com/+MikeHearn/about - it's simply not
>> unreasonable to ask why he's pushing it so hard when nobody wants it.
>>
>> 3) Various reasons mentioned here:
>> https://www.reddit.com/r/Bitcoin/comments/39yaug/the_history_of_mike_hea
>> rn_and_why_you_should_not/
>>
>>
>> 4) His disinterest in following what is actually happening with votes
>> on legitimate proposals (e.g. Garzik's BIP 100) in the blocks. (Caveat
>> ~ one doesn't see the BIP 100 yet in bitcoin/bips because it won't
>> appear for another couple weeks, supposedly.  The miners' voting is
>> already happening however.) Even according to http://xtnodes.com/ we
>> see that XT runs minimal nodes in comparison to the rest of nodes
>> being run across the network.
>>
>> BIP 100 itself is anticipated to be submitted w/ implementation in the
>> next 2 weeks and many miners are already voting on BIP 100 (as per
>> Jeff Garzik, from a post 08/12/2015 12:46 PM -0400 to this mailing list)
>> .
>>
>>  It is an insult to see Hearn fling the XT turd into the community
>> repeatedly.
>>
>> How then to end this XT madness?
>>
>> "The ring was made in the fires of Mount Doom. Only there can it be
>> unmade. The ring must be taken deep into Mordor and cast back into the
>> fiery chasm from whence it came. One of you must do this."
>> - - Lord Elrond
>>
>> Do not download this loathsome XT thing. Cast it back into the fires
>> from whence it came.
>>
>> - -Odinn
>>
>>
>> On 08/15/2015 10:43 AM, Satoshi Nakamoto via bitcoin-dev wrote:
>> > I have been following the recent block size debates through the
>> > mailing list.  I had hoped the debate would resolve and that a fork
>> > proposal would achieve widespread consensus.  However with the
>> > formal release of Bitcoin XT 0.11A, this looks unlikely to happen,
>> > and so I am forced to share my concerns about this very dangerous
>> > fork.
>> >
>> > The developers of this pretender-Bitcoin claim to be following my
>> > original vision, but nothing could be further from the truth.  When
>> > I designed Bitcoin, I designed it in such a way as to make future
>> > modifications to the consensus rules difficult without near
>> > unanimous agreement.  Bitcoin was designed to be protected from the
>> > influence of charismatic leaders, even if their name is Gavin
>> > Andresen, Barack Obama, or Satoshi Nakamoto.  Nearly everyone has
>> > to agree on a change, and they have to do it without being forced
>> > or pressured into it.  By doing a fork in this way, these
>> > developers are violating the "original vision" they claim to
>> > honour.
>> >
>> > They use my old writings to make claims about what Bitcoin was
>> > supposed to be.  However I acknowledge that a lot has changed since
>> > that time, and new knowledge has been gained that contradicts some
>> > of my early opinions.  For example I didn't anticipate pooled
>> > mining and its effects on the security of the network.  Making
>> > Bitcoin a competitive monetary system while also preserving its
>> > security properties is not a trivial problem, and we should take
>> > more time to come up with a robust solution.  I suspect we need a
>> > better incentive for users to run nodes instead of relying solely
>> > on altruism.
>> >
>> > If two developers can fork Bitcoin and succeed in redefining what
>> > "Bitcoin" is, in the face of widespread technical criticism and
>> > through the use of populist tactics, then I will have no choice but
>> > to declare Bitcoin a failed project.  Bitcoin was meant to be both
>> > technically and socially robust.  This present situation has been
>> > very disappointing to watch unfold.
>> >
>> > Satoshi Nakamoto
>> >
>> > _______________________________________________ bitcoin-dev mailing
>> > list bitcoin-dev@lists•linuxfoundation•org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>>
>> - --
>> http://abis.io ~
>> "a protocol concept to enable decentralization
>> and expansion of a giving economy, and a new social good"
>> https://keybase.io/odinn
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJV0+/fAAoJEGxwq/inSG8C4ZAIAKm1pEne0FlOW1O4zLe6mZOz
>> YTcnpSHFiVw4AfUPgbzR813ODphnJqcwnoT1q/sojjqgIDtwZY+AqdjA3VAbe15D
>> bAPlvQGmXMlaXq8OteDYPKxPzQMUlRtxEd9+sxO5IGFx0kvmKQLzdk6cmgawcRhN
>> PrDyXIqLlx6Yp0REQ03v3poLTGojUkPLeqdMrJAjwpuAyv9F8iVUn7SeHemEi8cm
>> fW4wOJogA8j9P//3a7+Cr8bjnOz6+QwpHsdlZlKM4VUTxt3Vgx4vu+SQjQxWgZEK
>> I+HGvgQW1buoDxleBbFq6SJc55lhF41IB17tewuDuPzT2nL4zOkbis1tUk3ASxY=
>> =Rm7w
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> I find it quite notable that Gavin and Mike have been radio silent on
> the bitcoin-dev list and yet we see a stream of media articles, blog
> posts, pod casts, and from what I can tell ongoing backroom lobbying
> of companies to run bitcoin-XT without trying AT ALL to offer a
> neutral or balanced or multi proposal information package so that
> companies technical people can make a balanced informed decision.
> That is what the workshops are trying to provide.
>
> Gavin, Mike - anything to say here?
>
> Adam

> (and that in a hard fork it is not a miner vote really
> as in soft-forks).

> ignored the warnings.  Many also warned that 75% was an optimally BAD
> trigger ratio (and that in a hard fork it is not a miner vote really
> as in soft-forks).  Gavin & Mike ignored that warning to.  I know they
> heard those warnings because I told them 1:1 in person or via email
> and had on going conversations.  Others did too.

> Olivier Janssens claims that one of your colleagues is asking for Gavin
> to be removed from his position.  Is this true?
>
> https://www.reddit.com/r/Bitcoin/comments/3hksre/blockstream_employee_asking_to_remove_gavin_from/?sort=confidence
>
> http://pastebin.com/q2TT58Z5

> On Wed, Aug 19, 2015 at 5:53 PM, Adam Back via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
> > ignored the warnings.  Many also warned that 75% was an optimally BAD
> > trigger ratio (and that in a hard fork it is not a miner vote really
> > as in soft-forks).  Gavin & Mike ignored that warning to.  I know they
> > heard those warnings because I told them 1:1 in person or via email
> > and had on going conversations.  Others did too.
>
> I would like to add for the record, I also warned Gavin of this in his
> PR to Bitcoin Core, and also suggested a timeout which if
> activation/enforcement did not occur within, hard fork deployment
> would be cancelled. His response was to delete these from the PR
> claiming thresholds were not relevant conversation in his PR and
> belonged elsewhere (even though they had already been discussed
> elsewhere).

> On Wed, Aug 19, 2015 at 5:53 PM, Adam Back via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>> ignored the warnings.  Many also warned that 75% was an optimally BAD
>> trigger ratio (and that in a hard fork it is not a miner vote really
>> as in soft-forks).  Gavin & Mike ignored that warning to.  I know they
>> heard those warnings because I told them 1:1 in person or via email
>> and had on going conversations.  Others did too.
>
> I would like to add for the record, I also warned Gavin of this in his
> PR to Bitcoin Core, and also suggested a timeout which if
> activation/enforcement did not occur within, hard fork deployment
> would be cancelled. His response was to delete these from the PR
> claiming thresholds were not relevant conversation in his PR and
> belonged elsewhere (even though they had already been discussed
> elsewhere).

> It seems to be a recurring meme that BIP 101 is somehow "a solution
> put forward" where BIP 100, 102, 103, flexcap, extension blocks etc
> etc are not.
>
> That is not at ALL the case, and is insulting (present company excluded).
>
> It is just that no one else is reckless enough to bypass the review
> process and risk a controversial hard fork deployment war. Myself and
> many other people warned Gavin a network fork "war" would start (ie
> someone would think of some way to sabotage or attack the deployment
> of Bitcoin-XT via protocol, code, policy, consensus soft-fork etc. He
> ignored the warnings. Many also warned that 75% was an optimally BAD
> trigger ratio (and that in a hard fork it is not a miner vote really
> as in soft-forks). Gavin & Mike ignored that warning to. I know they
> heard those warnings because I told them 1:1 in person or via email
> and had on going conversations. Others did too.
>
> People can not blame bitcoin core or me, that this then predictably
> happened exactly as we said it would - it was completely obvious and
> predictable.
>
> In fact noBitcoinXT is even more dangerous and therefore amplified in
> effect in creating mutual assured destruction kind of risk profile
> than the loose spectrum of technical counters imagined. I did not
> personally put much effort into thinking about counters because I
> though it counter productive and hoped that Gavin & Mike would have
> the maturity to not start down such a path.
>
> Again any of the other proposals can easily be implemented. They
> *could* also spin up a web page and put up binaries, however no one
> else was crazy enough to try to start a deployment in that way.
>
> It is also puzzling timing - with all these BIPs and ongoing
> discussion and workshops coming imminently to then release ahead of
> that process where as far as I know Gavin said he was equally happy
> with BIP 100 or other proposal which ever is best, and on basically
> the eve of workshops planned to progress this collaboratively.
> Bitcoin-XT is also under tested, people are finding privacy bugs and
> other issues. (Not even mentioning the above 75% optimally bad
> parameter, and the damage to community reputation and collaborative
> environment that this all causes.)
>
> Very disappointing Gavin and Mike.
>
> I find it quite notable that Gavin and Mike have been radio silent on
> the bitcoin-dev list and yet we see a stream of media articles, blog
> posts, pod casts, and from what I can tell ongoing backroom lobbying
> of companies to run bitcoin-XT without trying AT ALL to offer a
> neutral or balanced or multi proposal information package so that
> companies technical people can make a balanced informed decision.
> That is what the workshops are trying to provide.
>
> Gavin, Mike - anything to say here?
>
> Adam
>
> On 18 August 2015 at 19:59, Angel Leon via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>  "How then to end this XT madness?"
>>
>>  Instead of bashing on someone that has actually put a solution forward, make
>>  your own fork and see if your ideas on how to solve the issue are any
>>  better.
>>
>>  As of now, 1Mb blocks are pure madness, and people are voting over an 8mb
>>  block increase every day that passes, even with a "useless project" like you
>>  call it.
>>
>>  Go out there and see how bitcoin is actually used.
>>
>>  http://twitter.com/gubatron
>>
>>  On Tue, Aug 18, 2015 at 10:54 PM, odinn via bitcoin-dev
>>  <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>>  The "XT Fork" (better said, a POS alt*) and those behind it make not
>>>  even a pretense to work through process involved with bitcoin developmen
>>>  t.
>>>
>>>  (*This is not intended as a slight toward any other alts, as here in
>>>  this post I am focusing solely on XT.)
>>>
>>>  Instead of abandoning their useless project, or at least conceding
>>>  that their alt is operating essentially outside of the development
>>>  funnel (by this I mean BIP process), the developers of XT, via their
>>>  latest presentation of XT give nothing more than an attack on bitcoin
>>>  (albeit one that, more than anything, is designed to sidetrack real
>>>  discussion necessary to resolve the issues so as to achieve some level
>>>  of consensus in block size debates). Curiously, XT is not even truly
>>>  the implementation of BIP 101; the actual proposed implementation of
>>>  BIP 101 as proposed at
>>>  https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki#implement
>>>  ation
>>>  is found here: https://github.com/bitcoin/bitcoin/pull/6341
>>>  (It is currently a closed issue.)
>>>
>>>  It's probably valid to call into question why Mike Hearn in particular
>>>  persists with this project at all, as he has been its biggest
>>>  cheerleader. Some reasons may be:
>>>  1) His interest in attacking bitcoin in the past (seems to be a
>>>  recurring pattern)
>>>  https://bitcointalk.org/index.php?topic=333824.0
>>>
>>>  2) His employment (has come up before) - QinetiQ, Google, etc
>>>  https://plus.google.com/+MikeHearn/about - it's simply not
>>>  unreasonable to ask why he's pushing it so hard when nobody wants it.
>>>
>>>  3) Various reasons mentioned here:
>>>  https://www.reddit.com/r/Bitcoin/comments/39yaug/the_history_of_mike_hea
>>>  rn_and_why_you_should_not/
>>>
>>>  4) His disinterest in following what is actually happening with votes
>>>  on legitimate proposals (e.g. Garzik's BIP 100) in the blocks. (Caveat
>>>  ~ one doesn't see the BIP 100 yet in bitcoin/bips because it won't
>>>  appear for another couple weeks, supposedly. The miners' voting is
>>>  already happening however.) Even according to http://xtnodes.com/ we
>>>  see that XT runs minimal nodes in comparison to the rest of nodes
>>>  being run across the network.
>>>
>>>  BIP 100 itself is anticipated to be submitted w/ implementation in the
>>>  next 2 weeks and many miners are already voting on BIP 100 (as per
>>>  Jeff Garzik, from a post 08/12/2015 12:46 PM -0400 to this mailing list)
>>>  .
>>>
>>>   It is an insult to see Hearn fling the XT turd into the community
>>>  repeatedly.
>>>
>>>  How then to end this XT madness?
>>>
>>>  "The ring was made in the fires of Mount Doom. Only there can it be
>>>  unmade. The ring must be taken deep into Mordor and cast back into the
>>>  fiery chasm from whence it came. One of you must do this."
>>>  - - Lord Elrond
>>>
>>>  Do not download this loathsome XT thing. Cast it back into the fires
>>>  from whence it came.
>>>
>>>  - -Odinn
>>>
>>>  On 08/15/2015 10:43 AM, Satoshi Nakamoto via bitcoin-dev wrote:
>>>  > I have been following the recent block size debates through the
>>>  > mailing list. I had hoped the debate would resolve and that a fork
>>>  > proposal would achieve widespread consensus. However with the
>>>  > formal release of Bitcoin XT 0.11A, this looks unlikely to happen,
>>>  > and so I am forced to share my concerns about this very dangerous
>>>  > fork.
>>>  >
>>>  > The developers of this pretender-Bitcoin claim to be following my
>>>  > original vision, but nothing could be further from the truth. When
>>>  > I designed Bitcoin, I designed it in such a way as to make future
>>>  > modifications to the consensus rules difficult without near
>>>  > unanimous agreement. Bitcoin was designed to be protected from the
>>>  > influence of charismatic leaders, even if their name is Gavin
>>>  > Andresen, Barack Obama, or Satoshi Nakamoto. Nearly everyone has
>>>  > to agree on a change, and they have to do it without being forced
>>>  > or pressured into it. By doing a fork in this way, these
>>>  > developers are violating the "original vision" they claim to
>>>  > honour.
>>>  >
>>>  > They use my old writings to make claims about what Bitcoin was
>>>  > supposed to be. However I acknowledge that a lot has changed since
>>>  > that time, and new knowledge has been gained that contradicts some
>>>  > of my early opinions. For example I didn't anticipate pooled
>>>  > mining and its effects on the security of the network. Making
>>>  > Bitcoin a competitive monetary system while also preserving its
>>>  > security properties is not a trivial problem, and we should take
>>>  > more time to come up with a robust solution. I suspect we need a
>>>  > better incentive for users to run nodes instead of relying solely
>>>  > on altruism.
>>>  >
>>>  > If two developers can fork Bitcoin and succeed in redefining what
>>>  > "Bitcoin" is, in the face of widespread technical criticism and
>>>  > through the use of populist tactics, then I will have no choice but
>>>  > to declare Bitcoin a failed project. Bitcoin was meant to be both
>>>  > technically and socially robust. This present situation has been
>>>  > very disappointing to watch unfold.
>>>  >
>>>  > Satoshi Nakamoto
>>>  >
>>>  > _______________________________________________ bitcoin-dev mailing
>>>  > list bitcoin-dev@lists•linuxfoundation•org
>>>  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>  >
>>>
>>>  - --
>>>  http://abis.io ~
>>>  "a protocol concept to enable decentralization
>>>  and expansion of a giving economy, and a new social good"
>>>  https://keybase.io/odinn
>>>
>>>> -----BEGIN PGP SIGNATURE-----
>>>>  Version: GnuPG v1
>>>>
>>>>  iQEcBAEBAgAGBQJV0+/fAAoJEGxwq/inSG8C4ZAIAKm1pEne0FlOW1O4zLe6mZOz
>>>>  YTcnpSHFiVw4AfUPgbzR813ODphnJqcwnoT1q/sojjqgIDtwZY+AqdjA3VAbe15D
>>>>  bAPlvQGmXMlaXq8OteDYPKxPzQMUlRtxEd9+sxO5IGFx0kvmKQLzdk6cmgawcRhN
>>>>  PrDyXIqLlx6Yp0REQ03v3poLTGojUkPLeqdMrJAjwpuAyv9F8iVUn7SeHemEi8cm
>>>>  fW4wOJogA8j9P//3a7+Cr8bjnOz6+QwpHsdlZlKM4VUTxt3Vgx4vu+SQjQxWgZEK
>>>>  I+HGvgQW1buoDxleBbFq6SJc55lhF41IB17tewuDuPzT2nL4zOkbis1tUk3ASxY=
>>>>  =Rm7w
>>>>  -----END PGP SIGNATURE-----
>>>
>>>  _______________________________________________
>>>  bitcoin-dev mailing list
>>>  bitcoin-dev@lists•linuxfoundation•org
>>>  https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>  _______________________________________________
>>  bitcoin-dev mailing list
>>  bitcoin-dev@lists•linuxfoundation•org
>>  https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

> Normal GitHub users submitting pull-reqs to Bitcoin Core can't delete
> other users' comments on their own pull-reqs...
>
> IMO that's an abuse of the pull-req process, and in turn, Gavin
> Andresens's commit access rights for the Bitcoin Core repo.

> I think this should weigh in favor of Gavin Andresen not having commit
> privileges for the Bitcoin Core repository.

> On Aug 19, 2015, at 12:12 PM, Santino Napolitano via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> Gavin has been very clear about the fact that he's on vacation. I'm not sure what you want Mike to say. It's obvious the Bitcoin Core developer pitchforks are out for him so there isn't really anything he can possibly say which will be constructively received on this highly adversarial and increasingly ridiculous charade of a mailing list. I feel as though they've made their case abundantly clear to anyone paying attention.

> On Wed, Aug 19, 2015 at 7:20 PM, Peter Todd <pete@petertodd•org>
> wrote:
>> Normal GitHub users submitting pull-reqs to Bitcoin Core can't
>> delete other users' comments on their own pull-reqs...
>>
>> IMO that's an abuse of the pull-req process, and in turn, Gavin
>> Andresens's commit access rights for the Bitcoin Core repo.
>
> For the avoidance of doubt here's the archive link of my comment
> https://archive.is/omvSY#40% (call me paranoid) and here's where he
> tells me he's censored my posts https://archive.is/vym6N#40%
>
>> I think this should weigh in favor of Gavin Andresen not having
>> commit privileges for the Bitcoin Core repository.
>
> It's time.

> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> On Aug 19, 2015, at 12:32 PM, odinn via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> Signed PGP part
> re. Gavin and commit access
>
> On 08/19/2015 12:15 PM, Btc Drak via bitcoin-dev wrote:
> > On Wed, Aug 19, 2015 at 7:20 PM, Peter Todd <pete@petertodd•org>
> > wrote:
> >> Normal GitHub users submitting pull-reqs to Bitcoin Core can't
> >> delete other users' comments on their own pull-reqs...
> >>
> >> IMO that's an abuse of the pull-req process, and in turn, Gavin
> >> Andresens's commit access rights for the Bitcoin Core repo.
> >
> > For the avoidance of doubt here's the archive link of my comment
> > https://archive.is/omvSY#40% (call me paranoid) and here's where he
> > tells me he's censored my posts https://archive.is/vym6N#40%
> >
> >> I think this should weigh in favor of Gavin Andresen not having
> >> commit privileges for the Bitcoin Core repository.
> >
> > It's time.
>
> I agree, fwiw.  If he's going to censor others then that's
> inconsistent with the responsibility of having commit access.
>
> > _______________________________________________ bitcoin-dev mailing
> > list bitcoin-dev@lists•linuxfoundation•org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
> --
> http://abis.io ~
> "a protocol concept to enable decentralization
> and expansion of a giving economy, and a new social good"
> https://keybase.io/odinn
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

> [...]
> core devs” and relying on the fact that many people out there can’t seem to
> tell the difference between a source code fork and a blockchain fork.

> On Aug 19, 2015, at 12:58 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
>
> On Wed, Aug 19, 2015 at 9:48 PM, Eric Lombrozo via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>> [...]
>> core devs” and relying on the fact that many people out there can’t seem to
>> tell the difference between a source code fork and a blockchain fork.
>
> And this is precisely why we should make perfectly clear that we're
> not against a code fork where Hearn or anyone else acts as a
> "benevolent dictator", just against the controversial hardfork it is
> attempting to deploy.
> Otherwise the PR battle is probably lost (which may mean users sell
> all their BTC for XTBTC [or just forget about their BTC and only care
> about their XTBTC]).

> But the consensus code should NOT be subject to the same commit policies…and we should make an effort to separate the two clearly. And we should find a way to communicate the difference succinctly and clearly to laypeople (which is something I think the XT opponents have been horrible at doing so far).

>> But the consensus code should NOT be subject to the same commit

>
> I think that effort is in progress (again, much slower that I would
> like it to be) and it's called libconsensus.
> Once we have libconsensus Bitcoin Core it's just another
> implementation (even if it is the reference one) and it's not "the
> specification of the consensus rules" which is a "privileged" position
> that brings all sorts of misunderstandings and problems (the block
> size debate is just one example).

> Once we have libconsensus Bitcoin Core it's just another
> implementation

>> But the consensus code should NOT be subject to the same commit

> [cross-posted to libbitcoin]
>
> On 08/19/2015 03:00 PM, Jorge Timón via bitcoin-dev wrote:> On Wed, Aug
> 19, 2015 at 10:04 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>> But the consensus code should NOT be subject to the same commit
> policies…and we should make an effort to separate the two clearly. And
> we should find a way to communicate the difference succinctly and
> clearly to laypeople (which is something I think the XT opponents have
> been horrible at doing so far).
>>
>> I think that effort is in progress (again, much slower that I would
>> like it to be) and it's called libconsensus.
>> Once we have libconsensus Bitcoin Core it's just another
>> implementation (even if it is the reference one) and it's not "the
>> specification of the consensus rules" which is a "privileged" position
>> that brings all sorts of misunderstandings and problems (the block
>> size debate is just one example).
>
> Jorge,
>
> I applaud your efforts and objectives WRT libconsensus independence. But
> as you know I differ with you on this point:
>
>> Once we have libconsensus Bitcoin Core it's just another
>> implementation
>
> I do not consider Bitcoin Core just another implementation as long as
> libconsensus is built directly out of the bitcoind repository. It's a
> finer point, but an important one. Eric makes this point emphatically as
> well:
>
>>> But the consensus code should NOT be subject to the same commit
> policies...and we should make an effort to separate the two clearly.
>
> As you have implied, it's not likely to happen in the Bitcoin Core repo.
> Taking a dependency on Bitcoin Core is a metaphorical deal with the
> devil from our perspective. So my question is, how do you expect other
> implementations to transition off of that repository (and commit
> policies)? Or do you expect the dependency to be perpetual?

> In our discussion leading up to libbitcoin building libbitcoin-consensus
> we disagreed on whether intentional hard forks would (or even could)
> happen. I think that issue is now settled. So my question remains how do
> stakeholders (users/miners) maintain consensus when it's their
> individual intent (the first objective of libconsensus), and diverge
> when intended (which a direct dependency on libconsensus makes harder)?
> IMO it's unreasonable to operate as if this won't happen, given that it has.

> There are a very small number of implementations that rely on consensus
> (fewer that aren't also forks of Bitcoin Core). I think it's time we
> discuss how to work together to achieve our mutual goal. I assume you
> have been in contact with all of us. If you would like to facilitate
> this I'd be happy to join in an offline discussion.

> On Wed, Aug 19, 2015 at 10:22:32AM -0700, Simon Liu via bitcoin-dev wrote:
>> Olivier Janssens claims that one of your colleagues is asking for Gavin
>> to be removed from his position.  Is this true?
>>
>> https://www.reddit.com/r/Bitcoin/comments/3hksre/blockstream_employee_asking_to_remove_gavin_from/?sort=confidence
>>
>> http://pastebin.com/q2TT58Z5
>
> IMO that's a very reasonable request; lately I've spent a lot of time
> having to educate journalists on how Bitcoin doesn't have a "chief
> scientist" with any kind of authority. Having Gavin Andresen in that
> position at the otherwise inactive and bankrupt Bitcoin Foundation
> misleads the public about the true nature of how Bitcoin operates,
> giving a misleading impression that it has the same centralized decision
> making as conventional financial systems do. Among other things, this
> harms the reputation of Bitcoin as a whole as it can confuse the public
> into thinking there aren't major differences between Bitcoin and those
> conventional financial systems.
>
> As the email said "Regardless of your personal view on XT this is bad
> for bitcoin." - a statement I agree with 100%
>

> On Thu, Aug 20, 2015 at 1:07 AM, Eric Voskuil <eric@voskuil•org> wrote:
>> [cross-posted to libbitcoin]
>>
>> On 08/19/2015 03:00 PM, Jorge Timón via bitcoin-dev wrote:> On Wed, Aug
>> 19, 2015 at 10:04 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>>> But the consensus code should NOT be subject to the same commit
>> policies…and we should make an effort to separate the two clearly. And
>> we should find a way to communicate the difference succinctly and
>> clearly to laypeople (which is something I think the XT opponents have
>> been horrible at doing so far).
>>>
>>> I think that effort is in progress (again, much slower that I would
>>> like it to be) and it's called libconsensus.
>>> Once we have libconsensus Bitcoin Core it's just another
>>> implementation (even if it is the reference one) and it's not "the
>>> specification of the consensus rules" which is a "privileged" position
>>> that brings all sorts of misunderstandings and problems (the block
>>> size debate is just one example).
>>
>> Jorge,
>>
>> I applaud your efforts and objectives WRT libconsensus independence. But
>> as you know I differ with you on this point:
>>
>>> Once we have libconsensus Bitcoin Core it's just another
>>> implementation
>>
>> I do not consider Bitcoin Core just another implementation as long as
>> libconsensus is built directly out of the bitcoind repository. It's a
>> finer point, but an important one. Eric makes this point emphatically as
>> well:
>>
>>>> But the consensus code should NOT be subject to the same commit
>> policies...and we should make an effort to separate the two clearly.
>>
>> As you have implied, it's not likely to happen in the Bitcoin Core repo.
>> Taking a dependency on Bitcoin Core is a metaphorical deal with the
>> devil from our perspective. So my question is, how do you expect other
>> implementations to transition off of that repository (and commit
>> policies)? Or do you expect the dependency to be perpetual?
>
> No, as previously explained, once libconsensus is complete it can be
> moved to a separate repository like libsecp256k1.

> At first it will need to be a subtree/subrepository of Bitcoin Core
> (like libsecp256k1 currently is), but I still don't undesrtand how
> that can possibly be a problem for alternative implementations (they
> can use a subtree as well if they want to). Depending on a separated
> libconsensus doesn't "make Bitcoin Core a dependency" more than
> depending on libsecp256k1 currently does.
>
>> In our discussion leading up to libbitcoin building libbitcoin-consensus
>> we disagreed on whether intentional hard forks would (or even could)
>> happen. I think that issue is now settled. So my question remains how do
>> stakeholders (users/miners) maintain consensus when it's their
>> individual intent (the first objective of libconsensus), and diverge
>> when intended (which a direct dependency on libconsensus makes harder)?
>> IMO it's unreasonable to operate as if this won't happen, given that it has.
>
> I believe the simplest option...

> would be to fork the libconsensus
> project and do the schism/controversial/contentious hardfork there.
> But of course modifying libconsensus will be much easier than
> modifying Bitcoin Core (if anything, because the amount of code is
> much smaller).

>> There are a very small number of implementations that rely on consensus
>> (fewer that aren't also forks of Bitcoin Core). I think it's time we
>> discuss how to work together to achieve our mutual goal. I assume you
>> have been in contact with all of us. If you would like to facilitate
>> this I'd be happy to join in an offline discussion.
>
> Unfortunately I only directly contacted libbitcoin because I was
> subscribed to the list at the time (maybe I'm still subscribed, not
> really sure).
> The other attempts to get feedback from other alternative
> implementations have been just mostly-ignored threads in bitcoin-dev.
> So, no, I cannot facilitate such a discussion, but I'm more than happy
> to collaborate to achieve our mutual goal.

>By the way, now that I remember why I subscribed to the libbitcoin
>list I want to share it with you.
>I met Amir Taaki in person in a spanish hackmeeting and had the chance
>to talk a lot with him, very interesting person whose input in this
>blocksize matter I would greatly appreciate. He explained some of his
>concerns with Bitcoin Core (Bitcoin-qt at the time) and he
>specifically named 2 persons: Mike Hearn and Gavin Andresen. If I
>remember correctly, Hearn had recently proposed a blacklisting scheme
>for Bitcoin.
>
>I remember I said something along the lines:
>"Mike Hearn has certainly proposed some nasty things but I don't think
>other devs will ever accept that kind of changes in Bitcoin-qt.
>Regarding Gavin, I believe he is someone that can be trusted even if
>he visited the CIA. If anything, I think he is overly conservative
>about some changes, but that's very understandable given how fragile
>Bitcoin is (specially at this early stage)".
>
>Looking back, I now realize that his concerns were not exaggerated at
>all and I was clearly wrong thinking Gavin was overly conservative.
>He was also worried about the payment protocol and we agreed to
>disagree there (maybe I should read all the payment protocol stuff
>more deeply).
>
>I don't want this to be taken as an argument of authority "Mike and
>Gavin cannot be trusted because Amir didn't trust them", just as a
>curious anecdote.
>Amir, I wouldn't like to put words in your mouth: that's why I cc'ed
>you so you can correct me in case my memory is failing.
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists•linuxfoundation•org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

> Can this anecdote and similar be removed from the mailing list.
>
> Possibly one of the reddits is a better place for this kind of thing.

>
> It is just that no one else is reckless enough to bypass the review process

> >
> > It is just that no one else is reckless enough to bypass the review process
>
>
> I keep seeing this notion crop up.
>
> I want to kill this idea right now:
>
>    - There were months of public discussion leading to up the authoring of
>    BIP 101, both on this mailing list and elsewhere.
>
>    - BIP 101 was submitted for review via the normal process. Jeff Garzik
>    specifically called Gavin out on Twitter and thanked him for following the
>    process:
>
>    https://twitter.com/jgarzik/status/614412097359708160
>
>    https://github.com/bitcoin/bips/pull/163
>
>    As you can see, other than a few minor typo fixes and a comment by sipa,
>    there was no other review offered.
>
>    - The implementation for BIP 101 was submitted to Bitcoin Core as a pull
>    request, to invoke the code review process:
>
>    https://github.com/bitcoin/bitcoin/pull/6341
>
>    Some minor code layout suggestions were made by Cory and incorporated.
>    Peter popped up to say there was no chance it'd ever be accepted ..... and
>    no further review was done.

> On Thu, Aug 20, 2015 at 11:00:14AM +0200, Mike Hearn via
> bitcoin-dev wrote:
>>>
>>> It is just that no one else is reckless enough to bypass the
>>> review process
>>
>>
>> I keep seeing this notion crop up.
>>
>> I want to kill this idea right now:
>>
>> - There were months of public discussion leading to up the
>> authoring of BIP 101, both on this mailing list and elsewhere.
>>
>> - BIP 101 was submitted for review via the normal process. Jeff
>> Garzik specifically called Gavin out on Twitter and thanked him
>> for following the process:
>>
>> https://twitter.com/jgarzik/status/614412097359708160
>>
>> https://github.com/bitcoin/bips/pull/163
>>
>> As you can see, other than a few minor typo fixes and a comment
>> by sipa, there was no other review offered.
>>
>> - The implementation for BIP 101 was submitted to Bitcoin Core as
>> a pull request, to invoke the code review process:
>>
>> https://github.com/bitcoin/bitcoin/pull/6341
>>
>> Some minor code layout suggestions were made by Cory and
>> incorporated. Peter popped up to say there was no chance it'd
>> ever be accepted ..... and no further review was done.
>
> No, I said there was no chance it'd be accepted "due to a number
> of BIP-level issues in addition to debate about the patch itself.
> For instance, Gavin has never given any details about testing; at
> minimum we'd need a BIP16 style quality assurance document. We also
> frown on writing software with building expiration dates, let alone
> expiration dates that trigger non-deterministically. (Note how my
> recently merged CLTV considered the year 2038 problem to avoid
> needing a hard fork at that date)"
>
> Of course no further review was done - issues were identified and
> they didn't get fixed. Why would we do further review on something
> that was broken whose author wasn't interested in fixing even
> non-controversial and obvious problems?
>
> The process is to do review, fix issues identified, and repeat
> until all issues are fixed.
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> Potentially relevant...
>
> "Incentivizing the running of full nodes"
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/0060

>
>

>
> (However, the issue to which I referred here is now closed)
>
> View whole thread:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/thre

>
>

>
> On 08/17/2015 02:44 PM, Chris Pacia via bitcoin-dev wrote:
>
>> On Aug 17, 2015 5:29 PM, "Peter Todd via bitcoin-dev"
>> <bitcoin-dev@lists•linuxfoundation•org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: From the
>> point of view of a
>>> wallet, it's not very secure to use Hearn-style SPV mode, and
>>> volunteers running full nodes doesn't help things. Sybil
>>> attacking the IP address space is pretty easy in comparison to
>>> aquiring hashing power sufficient to create false
>>> confirmations, so any attacker able to do the former will
>>> likely be running the full node you're connecting too anyway.
>>> Ultimately, Hearn-style SPV is a close approximation to just
>>> trusting anyone with a non-trivial amount of hashing power.
>>> (and getting that is surprisingly easy, e.g. w/ SPV mining)
>
>> Can you explain how the spv node fails against an attacker with a
>>  non-trivial amount of hash power where a full node doesn't? To
>> attack an spv wallet that is waiting for 6 or 10 confirmations,
>> you would not only need to Sybil them but also summon a massive
>> amount of hashing power to create a chain of headers (while
>> forgoing the opportunity to mine valid blocks with that hash
>> power).
>
>> But could someone with that much hash power not Sybil a full
>> node and give them a chain for valid blocks (but on an orphan
>> fork)? The failure model doesn't seem specific to spv to me.
>
>
>
>> _______________________________________________ bitcoin-dev
>> mailing list bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>

> Hello,
>
> Some background on this....
>
>
> A very long while ago I posted to the bitcoin-development mailing
> list some ABIS concepts having to do with microdonations:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-December/

>
>

> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January/0

>
>

>
> And an interesting post (which led me to explore BCN) via nullc:
> https://news.ycombinator.com/item?id=7765455 (posted 1 & 1/3 year
> ago).

>
>
> Anyway, some long while ago this discussion came up about
> "Incentives to run full nodes," and the last post in the thread was
> here:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/0060

>
>

>
> Since that time, some new developments have come to light which
> the participants in that thread may find interesting;
>
> Please see in part,
>
> https://bytecoin.org/news/bytecoin-wallet-1.0.8-release-introduces-mic

>
>

>
> This presents a working implementation in BCN; the concept as
> implemented there is arguably viable in BTC as well.
>
> Please explore, play with, discuss, etc.
>
> Cheers,
>
> - O
>
> odinn:
>> Potentially relevant...
>
>> "Incentivizing the running of full nodes"
>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/006

>
>>

>
>
> .html
>
>> (However, the issue to which I referred here is now closed)
>
>> View whole thread:
>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/thr

>
>>

>
>
> .html#6028
>
>> On 08/17/2015 02:44 PM, Chris Pacia via bitcoin-dev wrote:
>
>>> On Aug 17, 2015 5:29 PM, "Peter Todd via bitcoin-dev"
>>> <bitcoin-dev@lists•linuxfoundation•org
>>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: From the
>>>  point of view of a
>>>> wallet, it's not very secure to use Hearn-style SPV mode, and
>>>>  volunteers running full nodes doesn't help things. Sybil
>>>> attacking the IP address space is pretty easy in comparison
>>>> to aquiring hashing power sufficient to create false
>>>> confirmations, so any attacker able to do the former will
>>>> likely be running the full node you're connecting too
>>>> anyway. Ultimately, Hearn-style SPV is a close approximation
>>>> to just trusting anyone with a non-trivial amount of hashing
>>>> power. (and getting that is surprisingly easy, e.g. w/ SPV
>>>> mining)
>
>>> Can you explain how the spv node fails against an attacker with
>>> a non-trivial amount of hash power where a full node doesn't?
>>> To attack an spv wallet that is waiting for 6 or 10
>>> confirmations, you would not only need to Sybil them but also
>>> summon a massive amount of hashing power to create a chain of
>>> headers (while forgoing the opportunity to mine valid blocks
>>> with that hash power).
>
>>> But could someone with that much hash power not Sybil a full
>>> node and give them a chain for valid blocks (but on an orphan
>>> fork)? The failure model doesn't seem specific to spv to me.
>
>
>
>>> _______________________________________________ bitcoin-dev
>>> mailing list bitcoin-dev@lists•linuxfoundation•org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>