[bitcoin-dev] Bitcoin XT Fork

[bitcoin-dev] Bitcoin XT Fork

[Satoshi Nakamoto]

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

Re: [bitcoin-dev] Bitcoin XT Fork

[Laszlo Hanyecz]

Sounds legit.

On Aug 15, 2015, at 5:43 PM, 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

Re: [bitcoin-dev] Bitcoin XT Fork

[jl2012]

Sign with the key 5EC948A1 or shut up, you scammer

Satoshi Nakamoto via bitcoin-dev 於 2015-08-15 13:43 寫到:
> 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

Re: [bitcoin-dev] Bitcoin XT Fork

[Oliver Egginger]

Am 15.08.2015 um 19:43 schrieb Satoshi Nakamoto via 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.

- oliver

Re: [bitcoin-dev] Bitcoin XT Fork

[Jorge Timón]

[-- Attachment #1: Type: text/plain, Size: 378 bytes --]

On Aug 17, 2015 1:40 PM, "Oliver Egginger via bitcoin-dev" <
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?

[-- Attachment #2: Type: text/html, Size: 522 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[Oliver Egginger]

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.

- oliver

Re: [bitcoin-dev] Bitcoin XT Fork

[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?

Re: [bitcoin-dev] Bitcoin XT Fork

[Oliver Egginger]

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.

- oliver

Re: [bitcoin-dev] Bitcoin XT Fork

[Jorge Timón]

On Mon, Aug 17, 2015 at 7:01 PM, Oliver Egginger <bitcoin@olivere.de> wrote:
> 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.

Yes, people have been abusing his name in the block size debate to
present their own personal views, almost from the beginning, and that
has been very annoying.
But I don't remember you proposing to block their emails from the list
in those occasions.
For all I know this could have been the real Satoshi. But I just
maintain what I've said when arguments of authority (an old fallacy)
have been used: only the arguments matter, not who makes them (which
is also what logic says).
Maybe the people using the arguments of authority actually care about
whether the author is Satoshi or not to determine what they think
about what the content says.
But I personally don't care: I can say that I agree with what the post
says no matter if it is written by Satoshi or someone else (because
the identity of the author doesn't change what I think of the
content).

Re: [bitcoin-dev] Bitcoin XT Fork

[Gregory Maxwell]

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.

The headers on the message check out.  The mail server in question is
also not an open relay.  At the moment the only reason I have to doubt
the authenticity of it is merely the fact that it exists after so much
air silence, but that isn't especially strong.

In the presence of doubt, it's better to take it just for its content.
And on that front it is more on-topic, civil, and productively
directed than a substantial fraction of new messages on the list.  I
certainly do not see a reason to hide it.

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?

This whole tangest is a waste of time.  If you believe the message is
unauthentic or not the best response is the same as if it is
authentic. Focus on the content. If its worth responding to, do. If
it's not don't. Then move on with life.

Re: [bitcoin-dev] Bitcoin XT Fork

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 187 bytes --]

In times of controversy or flamewar on the Linux kernel mailing list,
occasionally fake "Linus Torvalds" or other spoofed posts would appear.  It
is the nature of email.  Just ignore it.

[-- Attachment #2: Type: text/html, Size: 251 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[Btc Drak]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1682 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[Anon Moto]

[-- Attachment #1: Type: text/plain, Size: 2651 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 3300 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[Warren Togami Jr.]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

On Mon, Aug 17, 2015 at 4:40 AM, Oliver Egginger via bitcoin-dev <
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.
>
> - oliver


This bitcoin-dev list restarted with an empty subscriber list on June 21st,
2015.  So whoever posted from 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?

Warren

[-- Attachment #2: Type: text/html, Size: 1100 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]

On Mon, Aug 17, 2015 at 05:18:02PM +0000, Gregory Maxwell via bitcoin-dev wrote:
> 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.

<snip>

> 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?

Something I only recently realised is that Satoshi's apparent policy(1)
of never making any cryptographically secure signatures to link together
his posts - or indeed any communication at all - fits well with the
avoidance of creating a central authority figure. Currently every single
thing Satoshi ever apparently wrote can only be linked together by
trusting third parties - email archives could have been hacked,
bitcointalk might have fake messages, etc. Obviously in practice we have
reasonable assurance that the same person or group was behind most of
the messages we now consider to be "from Satoshi", but ultimately
strictly speaking we can only take each message individually, for the
arguments contained within.

As you've often said, the biggest achievement by Satoshi in the creation
of Bitcoin was to create a system where the identity of the creator is a
mere historical footnote. We can probably go further, and state that
while doing so, Satoshi quite counter-intuitively took steps to avoid
even creating a pseudoanonymous identity.


1) "Does anyone have anything at all signed by Satoshi's PGP key?",
   Peter Todd, Sept 13, 2014, Bitcoin-development mailing list,
   http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-September/006606.html

-- 
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[Hector Chu]

[-- Attachment #1: Type: text/plain, Size: 742 bytes --]

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).

The issue is that the reward is more or less like a decentralised lottery
with high entry cost. If the income could be smoothed like in a mining
pool, without actually being a mining pool, then perhaps more people would
pay to enter the mining game. A bit like making P2Pool the one and only
pool allowed on the network.

[-- Attachment #2: Type: text/html, Size: 1102 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[Gregory Maxwell]

On Mon, Aug 17, 2015 at 7:16 PM, Hector Chu via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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).

One can mine without running a node, unfortunately, thats where the
comments about pooled mining come from.

Also, this distionction between full nodes that "Validate" and
(presumably) SPV wallets that don't validate isn't consistent with the
design of Bitcoin.

> 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.

Re: [bitcoin-dev] Bitcoin XT Fork

[Jorge Timón]

On Mon, Aug 17, 2015 at 9:28 PM, Gregory Maxwell via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>> 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.

Pools could be somehow required to do p2pool between them, but there
would still be pools to further reduce variance, no?

Re: [bitcoin-dev] Bitcoin XT Fork

[Marcel Jamin]

[-- Attachment #1: Type: text/plain, Size: 3055 bytes --]

His account on that website was also compromised.

2015-08-17 21:02 GMT+02:00 Anon Moto via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> 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
>
>

[-- Attachment #2: Type: text/html, Size: 4161 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[Oliver Egginger]

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] Incentives to run full nodes

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 3864 bytes --]

On Sat, Aug 15, 2015 at 12:43:54PM -0500, Satoshi Nakamoto via bitcoin-dev wrote:
> 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.

Re: full nodes, my thinking along those lines has been:

1) Incentivising full-nodes is a red herring

We can look at this from multiple angles. 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)

From the point of view of full node or miner, having your peers be
valiating nodes is at best just a bandwidth optimization; all you need
from the rest of the P2P network is flood-fill capability with
reasonable DoS resistance. This isn't a problem that strongly requires
validation, and if bandwidth needs started to get excessive, sharding
the flood-fill network to limit bandwidth of any one flood-fill peer
would be relatively easy.


2) The best incentive to validate is clear and immediate failure when you don't

Currently the game theory and attacks possible against non-validating
nodes is a very complex landscape, full of cases where small attacks are
infeasible, but larger attacks possible. In particular, in many cases
you have co-ordination problems, where an attack is only viable if you
can steal at least a block reward worth of Bitcoins to make up for your
opportunity cost. This risks lulling people into complacency as attacks
seem rare, even if the risk is still quite high as the few attacks that
will happen will be very high impact.

If the system as a whole made small-scale attacks easier, we wouldn't
see this complacency, and people would build stronger systems. A
concrete example is Gregory Maxwell's idea of having all blocks commit
to two separate merkle trees, one valid and one invalid. Determining
which was which would require active validation, and because the block
as a whole is still valid regardless, this gives the opportunity to run
constant "fire drills" to uncover flaws in validation. Notable, this
scheme would even be compatible with SPV clients provided that all
sources of invalidity can be proven with a compact fraud proof.

A more extreme version of this notion is my embedded consensus ideas,
where you rely on the PoW for only proof-of-publication and/or
anti-replay functionality. Determining if coins (or any other asset) are
real becomes a clear job of validating history yourself, and/or trusting
others to do that validation. For instance, my smartcolors colored-coin
protocol work implemented client-side validation of colored coins, with
a planned (but not fully implemented - client ran out of funds)
optimization/trust tradeoff of having the issuer periodically sign
merkle-trees committing to all valid proofs within the system on an
offline machine.

-- 
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [bitcoin-dev] Incentives to run full nodes

[Chris Pacia]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

On Aug 17, 2015 5:29 PM, "Peter Todd via bitcoin-dev" <
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.

[-- Attachment #2: Type: text/html, Size: 1475 bytes --]

Re: [bitcoin-dev] Incentives to run full nodes

[Joseph Poon]

Hi Chris, I don't speak for Peter, but here's my opinion on the matter
anyway.

On Mon, Aug 17, 2015 at 05:44:56PM -0400, Chris Pacia via bitcoin-dev wrote:
> 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.

With SPV, it is possible to create a transaction that spends from
non-existent coins. With sufficient hashpower, you can construct an SPV
proof which sends 1,000 bitcoin to the victim. The attack is
"overloadable" in the sense that the attacker is never out of money
(they never needed to have 1,000 BTC in the first place). Whereas if the
victim is running a full node, the attacker must be signing and spending
real outputs in their control, there is a possibility in a re-org that
the victim will eventually get their money if it gets re-orged back.

On a more fundamental level, the SPV attack isn't on re-orging real/live
transactions, it's an attack on *how much money you currently have*. If
the client is using SPV, they never had the money in the first place
when attacked, irrespective of re-orgs.

It is possible to attack thousands of people at once (everyone gets
1,000 bitcoin in false transactions) with a fraction of the hashpower
(lie in wait until you get a sufficiently long chain of blocks). If you
wished to attack a full-node, it requires you orphaning a chain of valid
blocks *live*, meaning you have to send real coins in a real transaction
to the victim first. With SPV validation, you only need to construct a
chain of invalid blocks off the current blockheight *whenever*. This
means you can attack with substantially less hashpower; you don't need
51% of the hashpower to attack SPV wallets. It may be economically
unviable to attack a single victim with a full node within a very short
timeframe, but it can be economically viable to attack thousands of
victims doing SPV validation in a long timeframe.

Note I'm not arguing that SPV should be compeletely avoided, I don't
have a solid opinion on that (and some threats can definitely be
mitigated in various ways, and I certainly like/appreciate the
convenience of SPV), but the current SPV security model is definitely
weaker than running a full node (if you're handling a lot of money, you
should be running a full node), are these issues not well-known by all
in the bitcoin community?

-- 
Joseph Poon

Re: [bitcoin-dev] Bitcoin XT Fork

[Gregory Maxwell]

On Mon, Aug 17, 2015 at 8:37 PM, Oliver Egginger via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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.

I actually learned something important and infulential in my thinking
from the post. So I am happy it happened regardless of the other
things around it.  Because of the _very_ poor SNR on the list right
now I'm not sure if I would have seen it if it were sent by JoeBob.
(This is a greater issue, and I'm not suggesting that people start
posting with fake identities to get over the noise floor... but I'm
just presenting the facts of it as I see them here).

The rest of the traffic, not so useful, thank heavens for threaded
mail user agents.

Re: [bitcoin-dev] Bitcoin XT Fork

[Warren Togami Jr.]

[-- Attachment #1: Type: text/plain, Size: 2067 bytes --]

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
>
>

[-- Attachment #2: Type: text/html, Size: 2580 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[Micha Bailey]

[-- Attachment #1: Type: text/plain, Size: 2603 bytes --]

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
> <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
>>
>>

[-- Attachment #2: Type: text/html, Size: 3278 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[Oliver Egginger]

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

Re: [bitcoin-dev] Bitcoin XT Fork

[Anon Moto]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 2247 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[Sergio Demian Lerner]

[-- Attachment #1: Type: text/plain, Size: 2307 bytes --]

Just to add some superfluous and unessential spice to this discussion,
there were two Satoshi users originally registered in sourceforge, one
registered very soon after the other. So I say Satoshi were at least two
people, so it may be the case that one Satoshi re-appeared, but the other
did not.

Ore maybe one Satoshi is for Bitcoin XT, and the other Satoshi is against
it.

Satoshi wars!


On Tue, Aug 18, 2015 at 5:59 PM, Anon Moto via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
>
>

[-- Attachment #2: Type: text/html, Size: 3528 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[odinn]

-----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-----

Re: [bitcoin-dev] Bitcoin XT Fork

[Angel Leon]

[-- Attachment #1: Type: text/plain, Size: 6645 bytes --]

"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
>

[-- Attachment #2: Type: text/html, Size: 8899 bytes --]

Re: [bitcoin-dev] Incentives to run full nodes

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Potentially relevant...

"Incentivizing the running of full nodes"

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/006028
.html

(However, the issue to which I referred here is now closed)

View whole thread:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/thread
.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
> 

- -- 
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

iQEcBAEBAgAGBQJV1BJLAAoJEGxwq/inSG8CUAoH/3SwFKxhRBFA8SFAj7ia2Af8
ITEOkLyNM23lxW4yUdHhxtPiHbvXDXctZ9LESgp39kmE3MEYZW7IhcmJ7WRBNNVq
sTXANa5B/o+LwYbVDdS8Rt/p8dTs+xxPWreuycLJFwoOFbhbqp8wFqdJvZb/w45F
MSTBeXUOVr65sBW5zSrindGxCzmi33b9FoTWHdZ0wQtyDInk3goixWFRJ5n95/nI
msA8iIDvPQBv0naXR9/3CiEvJz274TSBvlvhOR5IBKTv9pxamX/fjWDUe/Z6uyg1
3469EtimDb+BVhlEvcPPJBOwAOKQnRLdi2N4xVg+2csFtknBkc45uuxjvaq/yis=
=75Cp
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Incentives to run full nodes

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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/00
3791.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January/004
049.html

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/006083
.html

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-micro
- -donations/

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/0060
28
>
> 
.html
> 
> (However, the issue to which I referred here is now closed)
> 
> View whole thread:
> 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/thre
ad
>
> 
.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
> 
> 
> 

- -- 
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-----

iQEcBAEBCgAGBQJWEMsvAAoJEGxwq/inSG8CcU8IAMJ+ZYMFzjETUDEZNyUnVd3v
SJCNauufTOcqxLzQoGIj4Y66PDnk9doRy/KJUGhKNtg4vjxiEk+GGHRH02ktvnQB
6MGuDCJS+MLeGi2W2QMr1NdHl09kRo306F5ZgjtZnOqX0mhwhOrIUylpoevcBnSQ
maJ5hpmxqyhxozEyYyu50HwcMQrXeWKZ8G0VSkTqmY5wf0s98MGrFLWSujwsva0e
p4hvG6YgBH85ne7dnBSH/sySreJpRMA0aac/+1j9U3LVvMTsmuaPc71aGI791o/y
+KV+UZ8bgHldfi+NSK8wA4eRi4JQrt+ruE63XlfYl29gWINqsGeVtpW/W3jeDnI=
=KDER
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Incentives to run full nodes

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

(Note:  Due to being very tired I have issued a correction to my post
below so as to make sure I have not been misunderstood.)

odinn via 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/
00
>
> 
3791.html
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January/0
04
>
> 
049.html
> 
> 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).

(I realize the way I wrote the above paragraph made it sound like I
posted the above post at https://news.ycombinator.com/item?id=7765455
but I just want to point out here that I did not; I meant to say that
I read an interesting post which led me to explore BCN that was
published by nullc.)

> 
> 
> 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
83
>
> 
.html
> 
> 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
ro
>
> 
- -donations/
> 
> 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
0
>
>> 
28
> 
> 
> .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
e
>
>> 
ad
> 
> 
> .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
> 

- -- 
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-----

iQEcBAEBCgAGBQJWEM5PAAoJEGxwq/inSG8C48UH/A9mfVaP2h1nOD2po2yaDCLA
xJuMIhrgo81q+WAbwFk4ac3bu3R/RzLLM7yA2IWDiPJrt6gCvEgIjzsHcG7+q5Bd
s7dPEFnibPzpqXjnVh6FcfpuW/MCT3AXiSvnsKiLh99v+oz9g50fIpOMYuOTk/Sy
816xqKbDfKEHzkWzeOv5gV61AzNS7PDWjfRqRV/Om5+J/MZt/kgXJ8UqEVmYbLXM
wIOWA1Vl4BZtQBiQpyDBjBUDhU0YboVXOMIbmx+ffDXKydcErLwFOCBp3XjVOMti
y0B56kmPko5xKH4/n53WFLH32ILd7dZNtK4KzhmyPjeJ+yXdfFTmR3Ayo4wvP2s=
=UvrH
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Bitcoin XT Fork

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bitcoin XT isn't technically an implementation of BIP 101.

It's really just an attack on the bitcoin network, not a whole
different than any of a variety of attacks one could perform on the
network.

Facts are as follows.

The published implementation of BIP 101 is shown on the BIP 101 page:

https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki

at:

https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki#Implement
ation

The only text in the Implementation section is the following link:

https://github.com/bitcoin/bitcoin/pull/6341

Which is closed by Gavin.

I am wondering why this drama continues, sort of stunned (but not
surprised) by Hearn's XT-hyping, bitcoin-attacking behavior and
crazed, delusional attitude, and hoping that consensus will be reached
on something - by something, I mean one of the following as shown at
http://bipsxdevs.azurewebsites.net/ -
well before XT achieves its goals.

By the way, since http://bipsxdevs.azurewebsites.net/ doesn't yet
appear to have any developers' signatures on it (except for luke-jr),
I'd like to take a moment to ask the developers if you could please
visit that site and put your signatures to it.  (Thanks to luke-jr for
being the first one.)

- - O

On 08/20/2015 02:13 AM, Peter Todd via bitcoin-dev wrote:
> 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
> 

- -- 
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

iQEcBAEBAgAGBQJV1pSTAAoJEGxwq/inSG8Css4IAMDPeUGm0hmScg1a2vDh+Vob
oeMGzwNfJngzFYpjvc+Wg+BnSTJBTWuc/lAm1Y4Rrdra6/o8CmYx9HERKFzaMszm
gZ0JQGsB7F7FPBwcLpXW+GI2mZz+orQoDXYB38ICF5arBIL95EyjNxEIcWR7Yb3+
XHsEFSlcxSKtF2UzkZHH10VALD7exveXAfdCNFSh/C1lcS+MqrhNjQ7Cal2BdJt3
Rnz7snTOYYb7hlTphEzHMA/9ftLIaQoNJZcVKg//5xgouc+C1S29St0pnTW6dsOD
p+VAfTnXb+PCSVl3mK8twEx2YqINK8IbK3DsnjXk/+zNZPyEa5wqnntZTI/0eSg=
=nakV
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Bitcoin XT Fork

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2134 bytes --]

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.

-- 
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1418 bytes --]

>
> 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.

So the entire Bitcoin Core BIP process was followed to the letter. The net
result was this. There were, in fact, bugs in the implementation of BIP
101. They were found when Gavin submitted the code to the XT community
review process, which resulted in *actual* peer review. Additionally, there
was much discussion of technical details on the XT mailing list that
Bitcoin Core entirely ignored.

[-- Attachment #2: Type: text/html, Size: 1928 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[Jorge Timón]

On Thu, Aug 20, 2015 at 3:00 AM, GC <slashdevnull@hotmail.com> wrote:
> 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.

I should have posted that just on libbitcoin but not in bitcoin-dev.
My apologies.

Re: [bitcoin-dev] Bitcoin XT Fork

[GC]

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.

On 20/8/15 7:56 am, "Jorge Timón via bitcoin-dev"
<bitcoin-dev@lists.linuxfoundation.org> wrote:

>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

Re: [bitcoin-dev] Bitcoin XT Fork

[Eric Voskuil]

On 08/19/2015 04:27 PM, Jorge Timón wrote:
> 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.

I don't see this happening any time soon, and I'm not sure why we should
wait for it.

> 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...

You might consider this as feedback from your customer base.

> 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).

That's a false dichotomy. We never would have considered forking Bitcoin
Core, and still wouldn't. Why would we set ourselves up for this
disruption, which would inevitably lead to us factoring the consensus
portions of libconsensus out of /bitcoin at the 11th hour?

We have to operate as if it can happen at any time. Otherwise we have
relinquished control of this vote and failed our users. Given that
operating assumption, it is much safer for us to have already done this
work (which we did). [It also provides a forcing function for us to
review in detail any consensus changes that get pushed out.]

My question is why you would not embrace an independent consensus
repository? Your work to evolve it doesn't change.

>> 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.

OK

e

Re: [bitcoin-dev] Bitcoin XT Fork

[Jorge Timón]

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.

Re: [bitcoin-dev] Bitcoin XT Fork

[Simon Liu]

Yes, you're right, the Bitcoin Foundation is facing many challenges, but
that's an entirely different discussion.

The question in hand is this: was the request to remove Gavin made by an
individual of their own volition, reflecting their own personal opinion,
or was it made on behalf of the company?

If the latter, it would imply that compromise is unlikely to be reached
and thus the ecosystem should start planning immediately for the
potential hard fork, rather than waiting and hoping for things to be
resolved.


On 08/19/2015 11:13 AM, Peter Todd wrote:
> 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%
> 

Re: [bitcoin-dev] Bitcoin XT Fork

[Jorge Timón]

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.

Re: [bitcoin-dev] Bitcoin XT Fork

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 2691 bytes --]

[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.

e


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[Jorge Timón]

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).

Re: [bitcoin-dev] Bitcoin XT Fork

[Eric Lombrozo]

[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]

FWIW,

I would fully like to see the consensus stuff split off into a separate organization from everything else. Let XT continue to support additional p2p messages or relay policies or whatever. Let Mike and Gavin argue for their improved wallet or whatever - I have absolutely no problem with that.

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).


> 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]).


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[Jorge Timón]

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]).

Re: [bitcoin-dev] Bitcoin XT Fork

[Eric Lombrozo]

[-- Attachment #1.1: Type: text/plain, Size: 2083 bytes --]

Unfortunately, I think that from a PR angle, removing Gavin from commit privileges right now will probably play into his hand. Sadly.

Say what you will regarding Gavin and Mike’s technical merits, they’ve been quite clever on the PR front. Framing this issue as “obstructionism from the 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: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


[-- Attachment #1.2: Type: text/html, Size: 3795 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJV1NnDAAoJEGxwq/inSG8C0H0H/0ygc10hDP59Z2ktB8+wxqek
qLdMS4WbzPQzXkAAeVCu4RWzqeJjJZZ66VZ2aPBdsHHPIqOikAYAy3EaYQ2M7VIy
D6FW+AZK3ZHXX/ENVvtEPegu58ykk7QoWQkKQbH1Jqfxa0wcv3PQ5HtH92GReCNP
cNUMjnJkdI1XIVVQ8XRZ3OfOwUrJlSV7o9kKb6KRlEyXiGPRMI/myHIBBkKg5RkW
4Zc6GqRUiT7MIpQcRGV1/h5LuVyszbo70SrhX1D/w2W4B87bGScpH98hwqqKu+td
HnbI6VqLD1xMKBnj18GdpCJzKePkXoR0FHjkipcABXTjRa4Oy52AZyxU4w7luqI=
=PD5w
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Bitcoin XT Fork

[Eric Lombrozo]

> 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.

It’s good to know that Gavin still manages to keep his priorities straight. Of course, vacationing at the moment that the most controversial change in the history of Bitcoin which threatens to split the community is officially “announced” is probably exactly what he should be doing.

I’m glad to know that we’ll continue to have this amazing leadership under the XT fork.

Re: [bitcoin-dev] Bitcoin XT Fork

[Btc Drak]

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.

Re: [bitcoin-dev] Bitcoin XT Fork

[Santino Napolitano]

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.

The community will weigh the independent merit of the two points of view and that community is not as naive and uninformed as everyone on this list likes to portray them to be. Your concern for companies' welfare is appreciated but I'm confident they can manage their own independent assessments of this matter as well as seek out enough varied expert opinions such that they can make an informed decision.

19.08.2015, 19:53, "Adam Back via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>:
> 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

Re: [bitcoin-dev] Bitcoin XT Fork

[Jorge Timón]

On Wed, Aug 19, 2015 at 7:32 PM, Btc Drak via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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).

I don't know the timeline for this, but maybe he was referring to
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html
(where he is one of the few people that have participated).

Re: [bitcoin-dev] Bitcoin XT Fork

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]

On Wed, Aug 19, 2015 at 06:32:14PM +0100, Btc Drak via bitcoin-dev wrote:
> 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).

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.

That kind of comment is perfectly on topic in the pull-req review
process; deleting it harms that process by removing useful information
about the trade-offs of the pull-req, both for people now, as well as
future efforts investigating the history of Bitcoin's protocol
development.

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

-- 
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

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%

-- 
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[Btc Drak]

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).

Re: [bitcoin-dev] Bitcoin XT Fork

[Jorge Timón]

On Wed, Aug 19, 2015 at 6:53 PM, Adam Back via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> (and that in a hard fork it is not a miner vote really
> as in soft-forks).

I think calling it "miner vote" was the first mistake: miner's
shouldn't have a "voting power" the rest of the users lack.
I prefer to call it "miner upgrade confirmation" and in BIP99 the
recommendation is to use 95% for both uncontroversial softforks and
uncontroversial hardforks (the uncontroversial harforks also have a
minimum height before starting the miner confirmation/voting to give
users additional time to upgrade).
To me it's no different that the mechanism is used for uncontroversial
softforks or hardforks, the main question is that it is NOT a "miners'
democracy/oligopoly".
If you expect everyone (including all miners) to upgrade, I don't
think any less than 95% makes sense. On the other hand, 100% makes it
relatively cheap for an attacker to block uncontroversial consensus
changes.

For a Schism hardfork, bip99 doesn't recommend to use miner's
confirmation/vote at all. Miners could be against the change, for
example in an ASIC-reset Schism hardfork or in a "hardfork" (it cannot
be a softfork if miners oppose to it) to reduce the block size), but
that shouldn't stop the hardforkers if they think dividing the
currency in 2 is the best solution to whatever is the problem at hand
(which I don't think it's the case now).

Of course, BIP99 is still a draft and can still be changed. But I
would really like that we focused on "how to do hardforks in general"
first and only then focus on how to make a blocksize hardfork
concretely.

Re: [bitcoin-dev] Bitcoin XT Fork

[Simon Liu]

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



> 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

Re: [bitcoin-dev] Bitcoin XT Fork

[Adam Back]

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:
>>
>> -----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
>

Re: [bitcoin-dev] Bitcoin XT Fork

[Btc Drak]

[-- Attachment #1: Type: text/plain, Size: 3702 bytes --]

I see no problem with Satoshi returning to participate in peer review.
Bitcoin development has long since migrated from a single authority figure
to a system of technical peer review consensus. What is more of a problem
is this list has degenerated to a generalised discussion forum where any
academic or technical debate is drowned out by noise.

I joined this list so I keep be abreast of bitcoin's technical development
and proposals. I am sure many ecosystem stakeholders and participants also
once used this list to keep abreast of technical developments and academic
research. It would be splendid indeed if we could return to some semblance
of decorum that once existed.

Do you think we could have a "bitcoin-discuss" list where specifically
non-technical discussion can happen leaving this list for more academic and
technical debate together with setting a clear mandate about what is on
topic for this list?


On Tue, Aug 18, 2015 at 12:52 PM, Micha Bailey via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
>
>

[-- Attachment #2: Type: text/html, Size: 4857 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[Dave Scotese]

[-- Attachment #1: Type: text/plain, Size: 4820 bytes --]

At
http://media.scmagazine.com/documents/127/virtual_currency_rules_31557.pdf,
section 200.3(c)(2) lists "consumers that utilize Virtual Currency solely
for the purchase or sale of goods or services or for investment purposes"
as "Persons [who] are exempt from the licensing requirements".

Who else is left?




On Mon, Aug 17, 2015 at 1:24 PM, Theo Chino via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
>
>


-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto

[-- Attachment #2: Type: text/html, Size: 7644 bytes --]

Re: [bitcoin-dev] Bitcoin XT Fork

[Theo Chino]

[-- Attachment #1: Type: text/plain, Size: 3639 bytes --]

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
>
>

[-- Attachment #2: Type: text/html, Size: 5421 bytes --]