[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

[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

[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

[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

[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

[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

[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

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

[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

[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

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

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

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