Discussion:
[bitcoin-dev] Bitcoin XT Fork
Satoshi Nakamoto via bitcoin-dev
2015-08-15 17:43:54 UTC
Permalink
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
jl2012 via bitcoin-dev
2015-08-15 19:10:26 UTC
Permalink
Sign with the key 5EC948A1 or shut up, you scammer
Post by 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
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Laszlo Hanyecz via bitcoin-dev
2015-08-15 19:08:58 UTC
Permalink
Sounds legit.
Post by 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
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Oliver Egginger via bitcoin-dev
2015-08-17 11:40:13 UTC
Permalink
Post by 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
Jorge Timón via bitcoin-dev
2015-08-17 11:44:59 UTC
Permalink
On Aug 17, 2015 1:40 PM, "Oliver Egginger via bitcoin-dev" <
Post by Oliver Egginger via bitcoin-dev
That made it to the news and is now discussed in various places. Could
you please delete Satoshis old email addresses from the list and block
them? Sorry to post this to all members but I can't find an owner for
this list.
Why should we block any email address?
Oliver Egginger via bitcoin-dev
2015-08-17 11:51:11 UTC
Permalink
Post by Jorge Timón via bitcoin-dev
On Aug 17, 2015 1:40 PM, "Oliver Egginger via bitcoin-dev"
Post by Oliver Egginger via bitcoin-dev
That made it to the news and is now discussed in various places. Could
you please delete Satoshis old email addresses from the list and block
them? Sorry to post this to all members but I can't find an owner for
this list.
Why should we block any email address?
To avoid such discussions.

- oliver
Jorge Timón via bitcoin-dev
2015-08-17 16:32:20 UTC
Permalink
Post by Oliver Egginger via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
On Aug 17, 2015 1:40 PM, "Oliver Egginger via bitcoin-dev"
Post by Oliver Egginger via bitcoin-dev
That made it to the news and is now discussed in various places. Could
you please delete Satoshis old email addresses from the list and block
them? Sorry to post this to all members but I can't find an owner for
this list.
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?
Oliver Egginger via bitcoin-dev
2015-08-17 17:01:10 UTC
Permalink
Post by Jorge Timón via bitcoin-dev
Post by Oliver Egginger via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
On Aug 17, 2015 1:40 PM, "Oliver Egginger via bitcoin-dev"
Post by Oliver Egginger via bitcoin-dev
That made it to the news and is now discussed in various places. Could
you please delete Satoshis old email addresses from the list and block
them? Sorry to post this to all members but I can't find an owner for
this list.
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
Jorge Timón via bitcoin-dev
2015-08-17 17:15:39 UTC
Permalink
Post by Oliver Egginger via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
Post by Oliver Egginger via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
On Aug 17, 2015 1:40 PM, "Oliver Egginger via bitcoin-dev"
Post by Oliver Egginger via bitcoin-dev
That made it to the news and is now discussed in various places. Could
you please delete Satoshis old email addresses from the list and block
them? Sorry to post this to all members but I can't find an owner for
this list.
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).
Btc Drak via bitcoin-dev
2015-08-17 17:30:53 UTC
Permalink
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.
Gregory Maxwell via bitcoin-dev
2015-08-17 17:18:02 UTC
Permalink
On Mon, Aug 17, 2015 at 11:51 AM, Oliver Egginger via bitcoin-dev
Post by Oliver Egginger via bitcoin-dev
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.
Peter Todd via bitcoin-dev
2015-08-17 19:14:40 UTC
Permalink
Post by Gregory Maxwell via bitcoin-dev
On Mon, Aug 17, 2015 at 11:51 AM, Oliver Egginger via bitcoin-dev
Post by Oliver Egginger via bitcoin-dev
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>
Post by Gregory Maxwell via bitcoin-dev
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
Jeff Garzik via bitcoin-dev
2015-08-17 17:28:54 UTC
Permalink
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.
Warren Togami Jr. via bitcoin-dev
2015-08-17 19:03:45 UTC
Permalink
On Mon, Aug 17, 2015 at 4:40 AM, Oliver Egginger via bitcoin-dev <
Post by Oliver Egginger via bitcoin-dev
That made it to the news and is now discussed in various places. Could
you please delete Satoshis old email addresses from the list and block
them? Sorry to post this to all members but I can't find an owner for
this list.
- oliver
This bitcoin-dev list restarted with an empty subscriber list on June 21st,
2015. So whoever posted from ***@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
Oliver Egginger via bitcoin-dev
2015-08-17 20:37:57 UTC
Permalink
Post by Warren Togami Jr. via bitcoin-dev
This bitcoin-dev list restarted with an empty subscriber list on June
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
Gregory Maxwell via bitcoin-dev
2015-08-18 05:16:08 UTC
Permalink
On Mon, Aug 17, 2015 at 8:37 PM, Oliver Egginger via bitcoin-dev
Post by Oliver Egginger via bitcoin-dev
Would we discuss his
posting if he would not claim to be Satoshi? There are a lot of smart
people on this list, which publish occasionally quite useful ideas.
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.
Warren Togami Jr. via bitcoin-dev
2015-08-18 09:15:31 UTC
Permalink
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
Post by Oliver Egginger via bitcoin-dev
Post by Warren Togami Jr. via bitcoin-dev
This bitcoin-dev list restarted with an empty subscriber list on June
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
Micha Bailey via bitcoin-dev
2015-08-18 11:52:50 UTC
Permalink
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 <
Post by Warren Togami Jr. via bitcoin-dev
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
Post by Warren Togami Jr. via bitcoin-dev
This bitcoin-dev list restarted with an empty subscriber list on June
verified the address
Post by Warren Togami Jr. via bitcoin-dev
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
Oliver Egginger via bitcoin-dev
2015-08-18 18:57:41 UTC
Permalink
Post by Warren Togami Jr. via bitcoin-dev
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
Anon Moto via bitcoin-dev
2015-08-18 20:59:57 UTC
Permalink
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 <
Post by Oliver Egginger via bitcoin-dev
Post by Warren Togami Jr. via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Sergio Demian Lerner via bitcoin-dev
2015-08-19 01:03:53 UTC
Permalink
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 <
Post by Anon Moto via bitcoin-dev
And this is how the powers that be compromise bitcoin. They can't stop
TCP/IP, but they sure can take over the development team. It's a good thing
that no one from the CIA has had any conversations with anyone from the
bitcoin development team. Phew...
On Tue, Aug 18, 2015 at 11:57 AM, Oliver Egginger via bitcoin-dev <
Post by Oliver Egginger via bitcoin-dev
Post by Warren Togami Jr. via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Anon Moto via bitcoin-dev
2015-08-17 19:02:18 UTC
Permalink
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 <
Post by 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
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Marcel Jamin via bitcoin-dev
2015-08-17 19:40:55 UTC
Permalink
His account on that website was also compromised.

2015-08-17 21:02 GMT+02:00 Anon Moto via bitcoin-dev <
Post by Anon Moto via bitcoin-dev
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 <
Post by 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
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Hector Chu via bitcoin-dev
2015-08-17 19:16:04 UTC
Permalink
On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev <
Post by Satoshi Nakamoto via bitcoin-dev
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.
Gregory Maxwell via bitcoin-dev
2015-08-17 19:28:01 UTC
Permalink
On Mon, Aug 17, 2015 at 7:16 PM, Hector Chu via bitcoin-dev
Post by Hector Chu via bitcoin-dev
On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev
Post by Satoshi Nakamoto via bitcoin-dev
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.
Post by Hector Chu via bitcoin-dev
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.
Jorge Timón via bitcoin-dev
2015-08-17 19:39:08 UTC
Permalink
On Mon, Aug 17, 2015 at 9:28 PM, Gregory Maxwell via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Post by Hector Chu via bitcoin-dev
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?
Theo Chino via bitcoin-dev
2015-08-17 20:24:29 UTC
Permalink
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 :


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 <
Post by Btc Drak via bitcoin-dev
For the record I would like to share my technical analysis of the Satoshi
email which I wrote in a pastebin (http://pastebin.com/Ct5M8fa2) a few
days ago.
1. The email is the one used by Satoshi to announce Bitcoin in the first
place.
http://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html
2. The email was not spoofed, it actually originated from vistomail's
server. The email headers show the email originated from 190.97.163.93
and the SPF records show this as an authorised sender for the email. This
does not prove the account wasn't hacked of course, or that the account
might have expired and be re-registered by someone else (vistomail is a
paid for email provider).
3. While the email is not signed, and there are a number of PGP keys
listed on key servers for him (to vary addresses), he didnt sign any emails
with any PGP keys.
It is therefore not possible to outright dismiss the email's authenticity
as the email originates from an authentic source. The only questions is
whether the webmail service was hacked or commandeered somehow.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Dave Scotese via bitcoin-dev
2015-08-18 04:56:47 UTC
Permalink
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 <
Post by Theo Chino via bitcoin-dev
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
http://youtu.be/7y1xJAVZxXg
At this time, I am waiting for the License issue to walk its course in New
York State.
- 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 <
Post by Btc Drak via bitcoin-dev
For the record I would like to share my technical analysis of the Satoshi
email which I wrote in a pastebin (http://pastebin.com/Ct5M8fa2) a few
days ago.
1. The email is the one used by Satoshi to announce Bitcoin in the first
place.
http://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html
2. The email was not spoofed, it actually originated from vistomail's
server. The email headers show the email originated from 190.97.163.93
and the SPF records show this as an authorised sender for the email.
This does not prove the account wasn't hacked of course, or that the
account might have expired and be re-registered by someone else (vistomail
is a paid for email provider).
3. While the email is not signed, and there are a number of PGP keys
listed on key servers for him (to vary addresses), he didnt sign any emails
with any PGP keys.
It is therefore not possible to outright dismiss the email's authenticity
as the email originates from an authentic source. The only questions is
whether the webmail service was hacked or commandeered somehow.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
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
Peter Todd via bitcoin-dev
2015-08-17 21:29:12 UTC
Permalink
Post by Satoshi Nakamoto via bitcoin-dev
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
Chris Pacia via bitcoin-dev
2015-08-17 21:44:56 UTC
Permalink
On Aug 17, 2015 5:29 PM, "Peter Todd via bitcoin-dev" <
bitcoin-***@lists.linuxfoundation.org> wrote:
From the point of view of a
Post by Peter Todd via bitcoin-dev
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.
Joseph Poon via bitcoin-dev
2015-08-18 00:20:02 UTC
Permalink
Hi Chris, I don't speak for Peter, but here's my opinion on the matter
anyway.
Post by Chris Pacia via bitcoin-dev
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
odinn via bitcoin-dev
2015-08-19 05:21:15 UTC
Permalink
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
Post by Chris Pacia via bitcoin-dev
On Aug 17, 2015 5:29 PM, "Peter Todd via bitcoin-dev"
point of view of a
Post by Peter Todd via bitcoin-dev
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
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
odinn via bitcoin-dev
2015-10-04 06:46:07 UTC
Permalink
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
Post by odinn via bitcoin-dev
Potentially relevant...
"Incentivizing the running of full nodes"
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/0060
28
.html
Post by odinn via bitcoin-dev
(However, the issue to which I referred here is now closed)
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/thre
ad
.html#6028
Post by odinn via bitcoin-dev
Post by Chris Pacia via bitcoin-dev
On Aug 17, 2015 5:29 PM, "Peter Todd via bitcoin-dev"
point of view of a
Post by Peter Todd via bitcoin-dev
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
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
odinn via bitcoin-dev
2015-10-04 06:59:27 UTC
Permalink
(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.)
Post by Theo Chino via bitcoin-dev
Hello,
Some background on this....
A very long while ago I posted to the bitcoin-development mailing
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-December/
00
3791.html
Post by Theo Chino via bitcoin-dev
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January/0
04
049.html
Post by Theo Chino via bitcoin-dev
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.)
Post by Theo Chino via bitcoin-dev
Anyway, some long while ago this discussion came up about
"Incentives to run full nodes," and the last post in the thread was
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/0060
83
.html
Post by Theo Chino via bitcoin-dev
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/
Post by Theo Chino via bitcoin-dev
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
Post by odinn via bitcoin-dev
Potentially relevant...
"Incentivizing the running of full nodes"
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/006
0
28
Post by Theo Chino via bitcoin-dev
.html
Post by odinn via bitcoin-dev
(However, the issue to which I referred here is now closed)
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/thr
e
ad
Post by Theo Chino via bitcoin-dev
.html#6028
Post by odinn via bitcoin-dev
Post by Chris Pacia via bitcoin-dev
On Aug 17, 2015 5:29 PM, "Peter Todd via bitcoin-dev"
point of view of a
Post by Peter Todd via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________ bitcoin-dev mailing
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

odinn via bitcoin-dev
2015-08-19 02:54:23 UTC
Permalink
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
Post by 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
_______________________________________________ bitcoin-dev mailing
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
Angel Leon via bitcoin-dev
2015-08-19 02:59:01 UTC
Permalink
"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 <
-----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
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.
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
Post by 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
_______________________________________________ bitcoin-dev mailing
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Btc Drak via bitcoin-dev
2015-08-19 08:25:23 UTC
Permalink
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 <
Post by Micha Bailey via bitcoin-dev
My interpretation is that he's saying Satoshi wouldn't be welcome to
return as Satoshi, because whatever he did/said would inevitably end up
being treated with authority, which shouldn't be the case.
On Tuesday, August 18, 2015, Warren Togami Jr. via bitcoin-dev <
Post by Warren Togami Jr. via bitcoin-dev
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
Post by Oliver Egginger via bitcoin-dev
Post by Warren Togami Jr. via bitcoin-dev
This bitcoin-dev list restarted with an empty subscriber list on June
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Adam Back via bitcoin-dev
2015-08-19 16:53:13 UTC
Permalink
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
Post by Angel Leon via bitcoin-dev
"How then to end this XT madness?"
Instead of bashing on someone that has actually put a solution forward, make
your own fork and see if your ideas on how to solve the issue are any
better.
As of now, 1Mb blocks are pure madness, and people are voting over an 8mb
block increase every day that passes, even with a "useless project" like you
call it.
Go out there and see how bitcoin is actually used.
http://twitter.com/gubatron
On Tue, Aug 18, 2015 at 10:54 PM, odinn via bitcoin-dev
-----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
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.
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
Post by 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
_______________________________________________ bitcoin-dev mailing
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Simon Liu via bitcoin-dev
2015-08-19 17:22:32 UTC
Permalink
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
Post by Adam Back via bitcoin-dev
I find it quite notable that Gavin and Mike have been radio silent on
the bitcoin-dev list and yet we see a stream of media articles, blog
posts, pod casts, and from what I can tell ongoing backroom lobbying
of companies to run bitcoin-XT without trying AT ALL to offer a
neutral or balanced or multi proposal information package so that
companies technical people can make a balanced informed decision.
That is what the workshops are trying to provide.
Gavin, Mike - anything to say here?
Adam
Peter Todd via bitcoin-dev
2015-08-19 18:13:30 UTC
Permalink
Post by Simon Liu via bitcoin-dev
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
Simon Liu via bitcoin-dev
2015-08-19 23:37:17 UTC
Permalink
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.
Post by Peter Todd via bitcoin-dev
Post by Simon Liu via bitcoin-dev
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%
Jorge Timón via bitcoin-dev
2015-08-19 17:28:38 UTC
Permalink
On Wed, Aug 19, 2015 at 6:53 PM, Adam Back via bitcoin-dev
Post by Adam Back via bitcoin-dev
(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.
Btc Drak via bitcoin-dev
2015-08-19 17:32:14 UTC
Permalink
On Wed, Aug 19, 2015 at 5:53 PM, Adam Back via bitcoin-dev
Post by Adam Back via bitcoin-dev
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).
Peter Todd via bitcoin-dev
2015-08-19 18:20:11 UTC
Permalink
Post by Btc Drak via bitcoin-dev
On Wed, Aug 19, 2015 at 5:53 PM, Adam Back via bitcoin-dev
Post by Adam Back via bitcoin-dev
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
Btc Drak via bitcoin-dev
2015-08-19 19:15:44 UTC
Permalink
Post by Peter Todd via bitcoin-dev
Normal GitHub users submitting pull-reqs to Bitcoin Core can't delete
other users' comments on their own pull-reqs...
IMO that's an abuse of the pull-req process, and in turn, Gavin
Andresens's commit access rights for the Bitcoin Core repo.
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%
Post by Peter Todd via bitcoin-dev
I think this should weigh in favor of Gavin Andresen not having commit
privileges for the Bitcoin Core repository.
It's time.
odinn via bitcoin-dev
2015-08-19 19:32:19 UTC
Permalink
re. Gavin and commit access
Post by Btc Drak via bitcoin-dev
Post by Peter Todd via bitcoin-dev
Normal GitHub users submitting pull-reqs to Bitcoin Core can't
delete other users' comments on their own pull-reqs...
IMO that's an abuse of the pull-req process, and in turn, Gavin
Andresens's commit access rights for the Bitcoin Core repo.
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%
Post by Peter Todd via bitcoin-dev
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.
Post by Btc Drak via bitcoin-dev
_______________________________________________ bitcoin-dev mailing
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
Eric Lombrozo via bitcoin-dev
2015-08-19 19:48:05 UTC
Permalink
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.
Signed PGP part
re. Gavin and commit access
Post by Btc Drak via bitcoin-dev
Post by Peter Todd via bitcoin-dev
Normal GitHub users submitting pull-reqs to Bitcoin Core can't
delete other users' comments on their own pull-reqs...
IMO that's an abuse of the pull-req process, and in turn, Gavin
Andresens's commit access rights for the Bitcoin Core repo.
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%
Post by Peter Todd via bitcoin-dev
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.
Post by Btc Drak via bitcoin-dev
_______________________________________________ bitcoin-dev mailing
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Jorge Timón via bitcoin-dev
2015-08-19 19:58:55 UTC
Permalink
On Wed, Aug 19, 2015 at 9:48 PM, Eric Lombrozo via bitcoin-dev
[...]
core devs” and relying on the fact that many people out there can’t seem to
tell the difference between a source code fork and a blockchain fork.
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]).
Eric Lombrozo via bitcoin-dev
2015-08-19 20:04:16 UTC
Permalink
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).
Post by Jorge Timón via bitcoin-dev
On Wed, Aug 19, 2015 at 9:48 PM, Eric Lombrozo via bitcoin-dev
Post by Eric Lombrozo via bitcoin-dev
[...]
core devs” and relying on the fact that many people out there can’t seem to
tell the difference between a source code fork and a blockchain fork.
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]).
Jorge Timón via bitcoin-dev
2015-08-19 22:00:09 UTC
Permalink
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).
Eric Voskuil via bitcoin-dev
2015-08-19 23:07:01 UTC
Permalink
[cross-posted to libbitcoin]

On 08/19/2015 03:00 PM, Jorge Timón via bitcoin-dev wrote:> On Wed, Aug
Post by Jorge Timón via bitcoin-dev
Post by Eric Lombrozo via bitcoin-dev
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).
Post by Jorge Timón via bitcoin-dev
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
Post by Jorge Timón via bitcoin-dev
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
Post by Jorge Timón via bitcoin-dev
Post by Eric Lombrozo via bitcoin-dev
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
Jorge Timón via bitcoin-dev
2015-08-19 23:27:51 UTC
Permalink
Post by Eric Voskuil via bitcoin-dev
[cross-posted to libbitcoin]
On 08/19/2015 03:00 PM, Jorge Timón via bitcoin-dev wrote:> On Wed, Aug
Post by Jorge Timón via bitcoin-dev
Post by Eric Lombrozo via bitcoin-dev
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).
Post by Jorge Timón via bitcoin-dev
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
Post by Jorge Timón via bitcoin-dev
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
Post by Jorge Timón via bitcoin-dev
Post by Eric Lombrozo via bitcoin-dev
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.
Post by Eric Voskuil via bitcoin-dev
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).
Post by Eric Voskuil via bitcoin-dev
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.
Jorge Timón via bitcoin-dev
2015-08-19 23:56:02 UTC
Permalink
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.
GC via bitcoin-dev
2015-08-20 01:00:50 UTC
Permalink
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"
Post by Jorge Timón via bitcoin-dev
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.
"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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Jorge Timón via bitcoin-dev
2015-08-20 01:17:48 UTC
Permalink
Post by GC via bitcoin-dev
Can this anecdote and similar be removed from the mailing list.
Possibly one of the reddits is a better place for this kind of thing.
I should have posted that just on libbitcoin but not in bitcoin-dev.
My apologies.
Eric Voskuil via bitcoin-dev
2015-08-20 00:08:30 UTC
Permalink
Post by Jorge Timón via bitcoin-dev
Post by Eric Voskuil via bitcoin-dev
[cross-posted to libbitcoin]
On 08/19/2015 03:00 PM, Jorge Timón via bitcoin-dev wrote:> On Wed, Aug
Post by Jorge Timón via bitcoin-dev
Post by Eric Lombrozo via bitcoin-dev
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).
Post by Jorge Timón via bitcoin-dev
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
Post by Jorge Timón via bitcoin-dev
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
Post by Jorge Timón via bitcoin-dev
Post by Eric Lombrozo via bitcoin-dev
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.
Post by Jorge Timón via bitcoin-dev
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.
Post by Eric Voskuil via bitcoin-dev
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.
Post by Jorge Timón via bitcoin-dev
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.
Post by Jorge Timón via bitcoin-dev
Post by Eric Voskuil via bitcoin-dev
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
Jorge Timón via bitcoin-dev
2015-08-19 18:22:17 UTC
Permalink
On Wed, Aug 19, 2015 at 7:32 PM, Btc Drak via bitcoin-dev
Post by Btc Drak via bitcoin-dev
On Wed, Aug 19, 2015 at 5:53 PM, Adam Back via bitcoin-dev
Post by Adam Back via bitcoin-dev
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).
Santino Napolitano via bitcoin-dev
2015-08-19 19:12:56 UTC
Permalink
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.
Post by Adam Back via bitcoin-dev
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
 "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
 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
 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.
 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
 > 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
 > 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
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
 _______________________________________________
 bitcoin-dev mailing list
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Eric Lombrozo via bitcoin-dev
2015-08-19 19:28:09 UTC
Permalink
Post by Santino Napolitano via bitcoin-dev
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.
Mike Hearn via bitcoin-dev
2015-08-20 09:00:14 UTC
Permalink
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.
Peter Todd via bitcoin-dev
2015-08-20 09:13:34 UTC
Permalink
Post by Mike Hearn via bitcoin-dev
It is just that no one else is reckless enough to bypass the review process
I keep seeing this notion crop up.
- 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
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
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
odinn via bitcoin-dev
2015-08-21 03:01:40 UTC
Permalink
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 Thu, Aug 20, 2015 at 11:00:14AM +0200, Mike Hearn via
Post by Mike Hearn via bitcoin-dev
Post by Adam Back via bitcoin-dev
It is just that no one else is reckless enough to bypass the
review process
I keep seeing this notion crop up.
- 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
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
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
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
Continue reading on narkive:
Loading...