Re: [bitcoin-dev] Your Gmaxwell exchange

Re: [bitcoin-dev] Your Gmaxwell exchange

[Monarch]

On 2015-08-31 19:11, Mike Hearn via bitcoin-dev wrote:
> I think your summary of what people actually want from
> decentralisation is pretty good, Justus.
> 
> 
>> I don't believe that any Bitcoin user actually cares
>> about decentralization, because none of them I've asked can define
>> that term.
> 
> +1 Insightful
> 

What is Bitcoin if not decentralized?

Bitcoin the most awkward, unprivate and damaging currencies ever
created.  It is terribly slow for general use, and it is very
difficult for users to get over the technical hurdles required to use
it safety.  It is simultaneously the least private payment system ever
conceived for general use, yet still manages to consistently help
terrorists and pedophiles.  Over half a gigawatt of power is used to
power the miners which timestamp the network, causing hundreds of
millions of tonnes of CO2 and radioactive particles to be spewed into
the atmosphere.

Perhaps we can justify these damages as the cost of decentralization,
similar to one justifying the tor anonymity network as having
significant positive effects outweighing the negative.  However if you
are truly willing to give the goal of absolute decentralization up as
unachievable or unrealistic, it would be much more sensible to replace
the entire Bitcoin network with a couple of geographically distributed
SQL servers and call it a day.

Without decentralization as an ultimate goal, Bitcoin is an
abomination that is best dismantled.

Re: [bitcoin-dev] Your Gmaxwell exchange

[Justus Ranvier]

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

On 08/31/2015 03:06 PM, Monarch via bitcoin-dev wrote:
> What is Bitcoin if not decentralized?
> 
> Bitcoin the most awkward, unprivate and damaging currencies ever
> created.  It is terribly slow for general use, and it is very
> difficult for users to get over the technical hurdles required to use
> it safety.  It is simultaneously the least private payment system ever
> conceived for general use, yet still manages to consistently help
> terrorists and pedophiles.  Over half a gigawatt of power is used to
> power the miners which timestamp the network, causing hundreds of
> millions of tonnes of CO2 and radioactive particles to be spewed into
> the atmosphere.
> 
> Perhaps we can justify these damages as the cost of decentralization,
> similar to one justifying the tor anonymity network as having
> significant positive effects outweighing the negative.  However if you
> are truly willing to give the goal of absolute decentralization up as
> unachievable or unrealistic, it would be much more sensible to replace
> the entire Bitcoin network with a couple of geographically distributed
> SQL servers and call it a day.
> 
> Without decentralization as an ultimate goal, Bitcoin is an
> abomination that is best dismantled.

You don't understand what value proof of work provides, or what features
differentiate good money from poor money, and you can't make a
defensible statement of Bitcoin's value proposition.

Because you can't do these things, you assume nobody else can do them
either and therefore the only way for Bitcoin to survive is to sweep the
problem under the rug and distract users with a word that means nothing
(and therefore means whatever the observer wants it to mean).

This is not a strategy that can be successful in the long term.

-- 
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus@openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623

[-- Attachment #1.2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 18667 bytes --]

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

Re: [bitcoin-dev] Your Gmaxwell exchange

[Monarch]

On 2015-08-31 20:27, Justus Ranvier wrote:
> You don't understand what value proof of work provides, or what 
> features
> differentiate good money from poor money, and you can't make a
> defensible statement of Bitcoin's value proposition.
> 
> Because you can't do these things, you assume nobody else can do them
> either and therefore the only way for Bitcoin to survive is to sweep 
> the
> problem under the rug and distract users with a word that means nothing
> (and therefore means whatever the observer wants it to mean).
> 
> This is not a strategy that can be successful in the long term.


Proof of work is probabilistic transaction ordering (and timestamping
by extension), the only perceivable value in it is that it is
decentralized. If you don't have that set as a requirement there are
plenty of companies around who will act as a time stamping notary for
you, just as there are many cloud services around to host the SQL-
based Bitcoin replacement.

Re: [bitcoin-dev] Your Gmaxwell exchange

[Allen Piscitello]

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

Even so, decentralization is a means to an end - not an end-goal.  It is
essential for Bitcoin to be a useful alternative, of course.

On Mon, Aug 31, 2015 at 3:48 PM, Monarch via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2015-08-31 20:27, Justus Ranvier wrote:
>
>> You don't understand what value proof of work provides, or what features
>> differentiate good money from poor money, and you can't make a
>> defensible statement of Bitcoin's value proposition.
>>
>> Because you can't do these things, you assume nobody else can do them
>> either and therefore the only way for Bitcoin to survive is to sweep the
>> problem under the rug and distract users with a word that means nothing
>> (and therefore means whatever the observer wants it to mean).
>>
>> This is not a strategy that can be successful in the long term.
>>
>
>
> Proof of work is probabilistic transaction ordering (and timestamping
> by extension), the only perceivable value in it is that it is
> decentralized. If you don't have that set as a requirement there are
> plenty of companies around who will act as a time stamping notary for
> you, just as there are many cloud services around to host the SQL-
> based Bitcoin replacement.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Your Gmaxwell exchange

[Monarch]

On 2015-08-31 21:24, Allen Piscitello wrote:
> Even so, decentralization is a means to an end - not an end-goal.  It
> is essential for Bitcoin to be a useful alternative, of course.
> 

The justification for the existence of Bitcoins hinges on it.  What is
described in the whitepaper is a system without the trust of third
parties to process electronic payments, this can not exist without
decentralization.  Absent any unforseen revelations this is a
requirement rather than a suggestion or fleeting fancy.  Below a
decentralized Bitcoin you are free to make systems as centralized as
you please without affecting the parent, below a centralized Bitcoin
there is no room to make it less.  We really only have one shot at a
properly bootstrapped, decentralized currency, and it would be a great
shame to mess up the one we have with hasty decision making for
unclear goals.

Re: [bitcoin-dev] Your Gmaxwell exchange

[Justus Ranvier]

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

On 08/31/2015 04:42 PM, Monarch wrote:
> The justification for the existence of Bitcoins hinges on it.  What is
> described in the whitepaper is a system without the trust of third
> parties to process electronic payments, this can not exist without
> decentralization.  Absent any unforseen revelations this is a
> requirement rather than a suggestion or fleeting fancy.  Below a
> decentralized Bitcoin you are free to make systems as centralized as
> you please without affecting the parent, below a centralized Bitcoin
> there is no room to make it less.  We really only have one shot at a
> properly bootstrapped, decentralized currency, and it would be a great
> shame to mess up the one we have with hasty decision making for
> unclear goals.

You keep using the word "decentralized" without explaining (and most
likely, understanding) what it means.

You say:

> a system without the trust of third parties to process electronic payments

What does it mean to use a decentralized network instead of a trusted
third party to process electronic payments? What undesirable actions can
a trusted third party perform that a decentralized network can not perform?

The answer to those questions are the *actual* goals, for which
decentralization is just one portion of a solution.

It might be helpful to organize Bitcoin's various existing, potential,
rejected, and proposed features using the Kano model:

https://en.wikipedia.org/wiki/Kano_model

Example: The ability of one entity to spend another entity's Bitcoins
without their consent is a reverse quality.

It would at least give us something objective to talk about.

-- 
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus@openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623

[-- Attachment #1.2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 18667 bytes --]

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

Re: [bitcoin-dev] Your Gmaxwell exchange

[Monarch]

On 2015-08-31 21:54, Justus Ranvier wrote:
> 
> You keep using the word "decentralized" without explaining (and most
> likely, understanding) what it means.
> 

Decentralization is a ubiquitous term within the Bitcoin, and the
definition is by no measure new or often confused.  It is realizing
that systems involving trusted third parties have undesirable
properties, be it regarding privacy, fraud, censorship, and removing
the effect of them as much as is physically possible.  WASTE and
RetroShare are examples of decentralized messaging and file
distribution systems, acknowledging the privacy problems involved with
centralized systems like AOL Instant Messenger or IRC.



> What does it mean to use a decentralized network instead of a trusted
> third party to process electronic payments? What undesirable actions 
> can
> a trusted third party perform that a decentralized network can not 
> perform?
> 

Bitcoin is a decentralized currency which allows any person the
ability to transact in a way that does not require specific trust in
any particular party.  Users can independently verify that
transactions they receive are valid and confirmed, with strong
confidence that they can not be reversed or modified.  A third party
does not hold these same properties, there is no reason to believe the
information they present other than trust they will not lie, cheat, or
violate privacy at their own will.  Given information by a trusted
third party (such as a balance or existance of transaction), a person
has no ability to independently validate their claims as you do in a
decentralized system.

Re: [bitcoin-dev] Your Gmaxwell exchange

[Justus Ranvier]

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

On 08/31/2015 05:53 PM, Monarch wrote:
> 
> Bitcoin is a decentralized currency which allows any person the
> ability to transact in a way that does not require specific trust in
> any particular party.  Users can independently verify that
> transactions they receive are valid and confirmed, with strong
> confidence that they can not be reversed or modified.  A third party
> does not hold these same properties, there is no reason to believe the
> information they present other than trust they will not lie, cheat, or
> violate privacy at their own will.  Given information by a trusted
> third party (such as a balance or existance of transaction), a person
> has no ability to independently validate their claims as you do in a
> decentralized system.

This is on the right track, but still falls short in a few areas.

It's a false dichotomy to say that our choices are: Bitcoin as it exists
today (or in some theoretical perfect state of decentralization), or an
Excel spreadsheet edited by a trusted third party who can change any
number to be any other number they want.

Imagine there was only one miner in the network. In spite of being the
sole entity creating the blockchain there would still be many actions
they could *not* do:

* Falsify ECDSA signatures
* Generate proof of work without expending energy
* Produce blocks that non-mining nodes would recognize as including
invalid transactions (including printing themselves unlimited balances)
* Force other people to purchase the coins they mine so that they can
pay their electric bills

What they *can* do is:

* Defraud recipients of transactions by including a payment transaction
in a block, then orphaning that block with another block that contains a
conflicting transaction (double spend).

There is usually*** a cost to performing this attack, so miners would
only be expected to do it if the benefit exceeds the cost.

* Prevent the inclusion of valid transactions into any block using any
criteria they want.

The worse case scenario for mining monopolization is that the risk of
profitable double spends means that transactions might require more
confirmations to be reliable, and that some entity can censor
transactions at will.

Those aren't exactly end-of-the world failure cases. They are certainly
undesirable and every means of preventing them should be investigated,
but it does mean that it should be possible to dial back on the
catastrophe language when analysing possible failure modes.

The weakest area for Bitcoin to be attacked is via censorship enforced
by miners.

The first line of defence is to improve the privacy features of wallets
to the point at which blacklists are not effective. I'm confident that
this can be achieved.

That leaves the censors with the choice of whether or not to escalate to
whitelisting, which ultimately can be countered by users switching to a
new system which does not have that particular anti-feature.

tl;dr: Bitcoin security does not lie on a one-dimensional "centralized
vs decentralized" axis. Treating it as if it does removes the clarity
that is needed in order to effectively solve problems.

***Exploring the exact conditions under which this is true is an
interesting exercise and relevant to long term discussions vis a vis the
block subsidy and transaction fees in the future.

-- 
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus@openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623

[-- Attachment #1.2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 18667 bytes --]

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

Re: [bitcoin-dev] Your Gmaxwell exchange

[Milly Bitcoin]

  > Bitcoin is a decentralized currency which allows any person the
> ability to transact in a way that does not require specific trust in
> any particular party.

Bitcoin is only a partial solution to the Byzantine general problem. 
Users do need to trust that things such as mining and development 
systems work as intended.  Once the user trusts those systems only then 
is the state of the ledger trustless.  Just because the state of ledger 
is decentralized due to mining that does not automatically mean 
everything associated with Bitcoin is "decentralized."  (Some people 
actually claim reddit is decentralized because users can vote.  That 
would mean the US government is also decentralized since there are 
elections but i don't think most people would agree with that definition.)

Centralized and decentralized system are not intrinsically good or bad. 
  Each one has it use cases just like a hammer and a screw driver. 
Claiming otherwise is treating Bitcoin a as religion rather than a 
technology.

Russ

Re: [bitcoin-dev] Your Gmaxwell exchange

[Jorge Timón]

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

On Aug 31, 2015 3:01 PM, "Justus Ranvier via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> You keep using the word "decentralized" without explaining (and most
> likely, understanding) what it means.

I believe he explained very well what he meant by decentralized, please
stop suggesting he doesn't understand his own thoughts: it is extremely
irritating.

> You say:
>
> > a system without the trust of third parties to process electronic
payments
>
> What does it mean to use a decentralized network instead of a trusted
> third party to process electronic payments? What undesirable actions can
> a trusted third party perform that a decentralized network can not
perform?

For starters, a third party (or a recuded group of miners controlling the
majority of the hashrate) can censor transactions. It doesn't matter how
benevolent that party is: it can be forced to do it by the laws of its
jurisdiction.

If you don't care about this, I suggest you start a new system without
expensive proof of work, you can replace it with block signing (it can
still be multisig). It is already coded, just fork the alpha or the
blocksigning branch in elementsProject (github).

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

Re: [bitcoin-dev] Your Gmaxwell exchange

[Peter R]

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

On 2015-08-31, at 2:24 PM, Allen Piscitello via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> Even so, decentralization is a means to an end - not an end-goal.  It is essential for Bitcoin to be a useful alternative, of course.

I agree.  What about decentralization in development?  Gavin recently said that he wants to "get to the point where there will be multiple robust implementations of the core protocol."

When I look at this image (https://i.imgur.com/zivHJvY.gif) illustrating centralization in nodes, mining and development, the biggest source of concern for me is the 85% node share around Bitcoin Core.  With this level of centralization, it may be possible in the future for a group of coders to prevent important changes from being made in a timely fashion (e.g., should their interests no longer align with those of the larger Bitcoin community).  

It is my opinion, then, that we should support multiple implementations of the Bitcoin protocol, working to reduce the network's dependency on Core.  

Best regards,
Peter R






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

Re: [bitcoin-dev] Your Gmaxwell exchange

[s7r]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Decentralization depends on the context and does not have a definition
in a form that it was demanded... I can confirm we have people in our
community which do understand decentralization, and quite good
actually, just there is no definition if the form demanded.

It is known that ~90% (at least of the nodes accepting incoming
connections) are running Bitcoin Core software. This does not mean
that Bitcoin is somehow less decentralized. Bitcoin Core is open
source, it has many contributors from all over the world and there are
many pull requests - most of them do get merged if you check the
commit history. It is widely used because the quality of the code is 5
stars. There are other implementations as well, they are just not
widely used. This does not mean one is not free to write his own
implementation of the Bitcoin protocol (assuming he follows the
consensus rules of the network). The biggest problem is convincing
users to adopt that implementation, which is a normal thing which
happens in general, not only related to software implementations.

The problem is there is no other implementation out there which comes
near the quality of the code in Bitcoin Core. I am actually eager to
try other implementations as well, but something serious, because
Bitcoin itself is a payment protocol not something to play with.

This is the reason why a lot of developers contribute to Bitcoin Core
rather than writing their own implementation. This only makes Bitcoin
Core stronger, better, and obviously the result is that it has
majority in the ecosystem for good reasons. If I'm experienced in a
certain segment related to software developing, I am better of in
contributing to Bitcoin Core just with the part I know instead of
writing from scratch my own implementation.

On 9/1/2015 2:32 AM, Peter R via bitcoin-dev wrote:
> On 2015-08-31, at 2:24 PM, Allen Piscitello via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
>> Even so, *decentralization is a means to an end* - not an
>> end-goal. It is essential for Bitcoin to be a useful alternative,
>> of course.
> 
> I agree.  What about decentralization in development?  Gavin
> recently said that he wants to "get to the point where there will
> be multiple robust implementations of the core protocol."
> 
> When I look at this image (https://i.imgur.com/zivHJvY.gif)
> illustrating centralization in nodes, mining and development, the
> biggest source of concern for me is the 85% node share around
> Bitcoin Core.  With this level of centralization, it may be
> possible in the future for a group of coders to prevent important
> changes from being made in a timely fashion (e.g., should their
> interests no longer align with those of the larger Bitcoin
> community).
> 
> It is my opinion, then, that we should support multiple
> implementations of the Bitcoin protocol, working to reduce the
> network's dependency on Core.
> 
> Best regards, Peter R
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJV5OeqAAoJEIN/pSyBJlsRRsoIAMmdyeE+Sro14NIHy6jQqTH3
JdkhUg6lg7S58tqs7ahQ/U2QGMPLaQae9yv3NidKpyqzL0YXtc2+r7RDBp0p2L4O
ieBJfJRBDwjjHYun+h7VTkPRbFGoBs/vwtTahd+uxUjwdEhiOxI2Q8pY8dLbdmJz
5lyA3TIcOVy3FjGYp3ji8aBQkw4o9OZbgmY/iCmVONgup96+81/FdR8P6wwdi3tg
Hep+4iU5Z+RHVE0sQhJDgl8Rw2oY6cmfxOCdFalRAASfZClkMfZok7eDE5yWtUbE
tn9tEP82tc3OwZCC+XvpVggVWnCp/rGZFslfTdiWXWeLXhs+JLf0hWet4/SWCT0=
=zQ9s
-----END PGP SIGNATURE-----

[bitcoin-dev] Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes

[Peter R]

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

I agree, s7r, that Bitcoin Core represents the most stable code base.  To create multiple implementations, other groups would fork Bitcoin Core similar to what Bitcoin XT did.  We could have:

- Bitcoin-A (XT)
- Bitcoin-B (Blockstream)
- Bitcoin-C (promoting BIP100)
- Bitcoin-D
- etc.

Innovation from any development group would be freely integrated by any other development group, if desired.  Of course, each group would have a very strong incentive to remain fork-wise compatible with the other implementations.  

In fact, this just gave me a great idea!  Since Wladimir has stated that he will not integrate a forking change into Core without Core Dev consensus, I suggest we work together to never reach consensus with Bitcoin Core.  This will provide impetus for new implementations to fork from Core (like XT did) and implement whatever scaling solution they deem best.  The users will then select the winning solution simply based on the code they choose to run.  The other implementations will then rush to make compatible changes in order to keep their dwindling user bases.  

This is the decentralized spirit of Bitcoin in action.  Creative destruction.  Consensus formed simply by the code that gets run.  

Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes.  

Sincerely,
Peter R


On 2015-08-31, at 4:47 PM, s7r <s7r@sky-ip.org> wrote:

> Signed PGP part
> Decentralization depends on the context and does not have a definition
> in a form that it was demanded... I can confirm we have people in our
> community which do understand decentralization, and quite good
> actually, just there is no definition if the form demanded.
> 
> It is known that ~90% (at least of the nodes accepting incoming
> connections) are running Bitcoin Core software. This does not mean
> that Bitcoin is somehow less decentralized. Bitcoin Core is open
> source, it has many contributors from all over the world and there are
> many pull requests - most of them do get merged if you check the
> commit history. It is widely used because the quality of the code is 5
> stars. There are other implementations as well, they are just not
> widely used. This does not mean one is not free to write his own
> implementation of the Bitcoin protocol (assuming he follows the
> consensus rules of the network). The biggest problem is convincing
> users to adopt that implementation, which is a normal thing which
> happens in general, not only related to software implementations.
> 
> The problem is there is no other implementation out there which comes
> near the quality of the code in Bitcoin Core. I am actually eager to
> try other implementations as well, but something serious, because
> Bitcoin itself is a payment protocol not something to play with.
> 
> This is the reason why a lot of developers contribute to Bitcoin Core
> rather than writing their own implementation. This only makes Bitcoin
> Core stronger, better, and obviously the result is that it has
> majority in the ecosystem for good reasons. If I'm experienced in a
> certain segment related to software developing, I am better of in
> contributing to Bitcoin Core just with the part I know instead of
> writing from scratch my own implementation.
> 
> On 9/1/2015 2:32 AM, Peter R via bitcoin-dev wrote:
> > On 2015-08-31, at 2:24 PM, Allen Piscitello via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> >
> >> Even so, *decentralization is a means to an end* - not an
> >> end-goal. It is essential for Bitcoin to be a useful alternative,
> >> of course.
> >
> > I agree.  What about decentralization in development?  Gavin
> > recently said that he wants to "get to the point where there will
> > be multiple robust implementations of the core protocol."
> >
> > When I look at this image (https://i.imgur.com/zivHJvY.gif)
> > illustrating centralization in nodes, mining and development, the
> > biggest source of concern for me is the 85% node share around
> > Bitcoin Core.  With this level of centralization, it may be
> > possible in the future for a group of coders to prevent important
> > changes from being made in a timely fashion (e.g., should their
> > interests no longer align with those of the larger Bitcoin
> > community).
> >
> > It is my opinion, then, that we should support multiple
> > implementations of the Bitcoin protocol, working to reduce the
> > network's dependency on Core.
> >
> > Best regards, Peter R
> >
> 


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

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

Re: [bitcoin-dev] Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes

[Gregory Maxwell]

On Tue, Sep 1, 2015 at 2:16 AM, Peter R via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> - Bitcoin-B (Blockstream)

Blockstream currently has no interest in maintaining a separate
implementation of Bitcoin.

At this time I believe doing so would have significantly negative
value; especially in light of the current climate where people are
conflating a tremendously destructive bifurcation of the Bitcoin
ledger with mere (and far more boring) alternative implementations.

Re: [bitcoin-dev] Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes

[Adam Back]

Peter this seems to be a not well thought through course of action,
fun though it maybe informally or philosophically or to tweak various
peoples sensibilities.

Bitcoin is a consensus system that does not work if there are
incompatible versions of consensus code competing on the network.
This is why work is underway on libconsensus so we can see diversity
of implementation without the risk of incompatibility arising by
software defect.  It has proven quite hard to match independent
consensus implementations bit for bit against an adaptive adversary
looking for inconsistencies in interpretation.

In terms of protocol updates it is more constructive therefore that
people with a technical interest analyse and validate others proposals
via testing, or make their own proposals so that we can arrive at a
well validated upgrade mechanism that everyone upgrades to in a
coordinated fashion.

Previous intentional upgrades to bitcoin have been
backwards-compatible (via soft-fork which can be secured reasonably
using a miner vote trigger and temporary SPV security for those who
not yet upgraded) but the current topic of a throughput increase is
non-backwards-compatible (via a hard-fork), and the way to minimise
risk of such an upgrade is for everyone to try to upgrade well in
advance of an agreed upgrade schedule, and to be all upgrading to the
*same* consensus rule change.

Encouraging nodes or miners to "vote" by running a range of different
consensus rules isnt really constructive I feel - it alarms people who
understand the risks, sets things on a path that have to be fixed
while in flight by obvious implication, and isnt collaborative - so it
risks being a politicising suggestion on what should be a purely
technical topic of choosing the best approach, where it is best to
strive to keep things non-emotive and professional and technically
focussed.  Such calls are offending the technical sensibilities of
people who understand the risks.

Anyway lets try to keep things constructive and focus on analysing proposals.

Adam

On 31 August 2015 at 19:16, Peter R via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I agree, s7r, that Bitcoin Core represents the most stable code base.  To
> create multiple implementations, other groups would fork Bitcoin Core
> similar to what Bitcoin XT did.  We could have:
>
> - Bitcoin-A (XT)
> - Bitcoin-B (Blockstream)
> - Bitcoin-C (promoting BIP100)
> - Bitcoin-D
> - etc.
>
> Innovation from any development group would be freely integrated by any
> other development group, if desired.  Of course, each group would have a
> very strong incentive to remain fork-wise compatible with the other
> implementations.
>
> In fact, this just gave me a great idea!  Since Wladimir has stated that he
> will not integrate a forking change into Core without Core Dev consensus, I
> suggest we work together to never reach consensus with Bitcoin Core.  This
> will provide impetus for new implementations to fork from Core (like XT did)
> and implement whatever scaling solution they deem best.  The users will then
> select the winning solution simply based on the code they choose to run.
> The other implementations will then rush to make compatible changes in order
> to keep their dwindling user bases.
>
> This is the decentralized spirit of Bitcoin in action.  Creative
> destruction.  Consensus formed simply by the code that gets run.
>
> Let's kill Bitcoin Core and allow the green shoots of a garden of new
> implementations to grow from its fertile ashes.

Re: [bitcoin-dev] Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes

[Chris D'Costa]

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

I think the "Kill King Bitcoin - Long Live the King" call is somewhat
inevitable, and we should expect this to happen from time-to-time, now that
the cat is out of the bag.

However, I fully agree with Adam that livenet is probably not the place to
play this game, and I'm also not convinced that testnet is either.

I often wondered if there is any appetite for a no-holds-barred, anything
goes, bitcoin fork that would allow for the kind of valuable
experimentation that Peter R is suggesting? This is a different concept
than an alt-coin because it would be undoubtedly unstable until consensus
is reached - and that is the whole idea. It hopefully would inform future
decisions about what gets rolled into Core. One problem I see with doing
this, is the lack of incentive.

Chris

On 1 September 2015 at 10:42, Adam Back via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Peter this seems to be a not well thought through course of action,
> fun though it maybe informally or philosophically or to tweak various
> peoples sensibilities.
>
> Bitcoin is a consensus system that does not work if there are
> incompatible versions of consensus code competing on the network.
> This is why work is underway on libconsensus so we can see diversity
> of implementation without the risk of incompatibility arising by
> software defect.  It has proven quite hard to match independent
> consensus implementations bit for bit against an adaptive adversary
> looking for inconsistencies in interpretation.
>
> In terms of protocol updates it is more constructive therefore that
> people with a technical interest analyse and validate others proposals
> via testing, or make their own proposals so that we can arrive at a
> well validated upgrade mechanism that everyone upgrades to in a
> coordinated fashion.
>
> Previous intentional upgrades to bitcoin have been
> backwards-compatible (via soft-fork which can be secured reasonably
> using a miner vote trigger and temporary SPV security for those who
> not yet upgraded) but the current topic of a throughput increase is
> non-backwards-compatible (via a hard-fork), and the way to minimise
> risk of such an upgrade is for everyone to try to upgrade well in
> advance of an agreed upgrade schedule, and to be all upgrading to the
> *same* consensus rule change.
>
> Encouraging nodes or miners to "vote" by running a range of different
> consensus rules isnt really constructive I feel - it alarms people who
> understand the risks, sets things on a path that have to be fixed
> while in flight by obvious implication, and isnt collaborative - so it
> risks being a politicising suggestion on what should be a purely
> technical topic of choosing the best approach, where it is best to
> strive to keep things non-emotive and professional and technically
> focussed.  Such calls are offending the technical sensibilities of
> people who understand the risks.
>
> Anyway lets try to keep things constructive and focus on analysing
> proposals.
>
> Adam
>
> On 31 August 2015 at 19:16, Peter R via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > I agree, s7r, that Bitcoin Core represents the most stable code base.  To
> > create multiple implementations, other groups would fork Bitcoin Core
> > similar to what Bitcoin XT did.  We could have:
> >
> > - Bitcoin-A (XT)
> > - Bitcoin-B (Blockstream)
> > - Bitcoin-C (promoting BIP100)
> > - Bitcoin-D
> > - etc.
> >
> > Innovation from any development group would be freely integrated by any
> > other development group, if desired.  Of course, each group would have a
> > very strong incentive to remain fork-wise compatible with the other
> > implementations.
> >
> > In fact, this just gave me a great idea!  Since Wladimir has stated that
> he
> > will not integrate a forking change into Core without Core Dev
> consensus, I
> > suggest we work together to never reach consensus with Bitcoin Core.
> This
> > will provide impetus for new implementations to fork from Core (like XT
> did)
> > and implement whatever scaling solution they deem best.  The users will
> then
> > select the winning solution simply based on the code they choose to run.
> > The other implementations will then rush to make compatible changes in
> order
> > to keep their dwindling user bases.
> >
> > This is the decentralized spirit of Bitcoin in action.  Creative
> > destruction.  Consensus formed simply by the code that gets run.
> >
> > Let's kill Bitcoin Core and allow the green shoots of a garden of new
> > implementations to grow from its fertile ashes.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes

[Monarch]

On 2015-09-01 10:16, Chris D'Costa via bitcoin-dev wrote:
> However, I fully agree with Adam that livenet is probably not the
> place to play this game, and I'm also not convinced that testnet is
> either. 
> 
> I often wondered if there is any appetite for a no-holds-barred,
> anything goes, bitcoin fork that would allow for the kind of valuable
> experimentation that Peter R is suggesting? This is a different
> concept than an alt-coin because it would be undoubtedly unstable
> until consensus is reached - and that is the whole idea. It hopefully
> would inform future decisions about what gets rolled into Core. One
> problem I see with doing this, is the lack of incentive.
> 

You are describing the essence of sidechains.  You might want to check
out Elements Alpha, which has some outrageous experimental changes to
transaction structure.  It's a technical Bitcoin sandbox which doesn't
require launching yet another altcoin.

Re: [bitcoin-dev] Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes

[Wladimir]

On Tue, Sep 1, 2015 at 4:16 AM, Peter R via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I agree, s7r, that Bitcoin Core represents the most stable code base.  To

What about the people that like stability, that appreciate bitcoin as
a "digital gold", and like all this 'excitement' like a hole in the
head?

Instead of creating hardforks and all the drama around it I'd
encourage to do your experiments on sidechains, or altcoins. Forks of
the bitcoin chain wil needlessly confuse matters, especially if they
all gain their share of users. In theory an hardfork would be no
different than an altcoin with shared history, but without proper
measures "crosstalk" between forks of the same chain can make for a
messy separation.
(A fact often ignored, because those proposing forks assume they can
just run over people on the other side of the fork by sake of their
popularity)

Also please don't confuse alternative implementations of the node
software - btcd, obelisk, etc - that try to implement the consensus
rules as faithfully as they can, or even use bitcoin core's consensus
code directly - with deliberate rule changes as done in bitcoin XT.
The former can cause an accidental fork (which will probably be
repaired), the latter exist to split off their chain.

Wladimir

Re: [bitcoin-dev] Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes

[s7r]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

That would be very wrong and cause a lot of problems and 'political
chaos' without solving at least one (technical) problem in exchange.

Bitcoin Core is a good quality code. It is open source and free.
Anyone can contribute and submit small changes, improvements.
Controversial changes are not easily merged not because the
maintainers do not want, but because they represent a threat to the
entire ecosystem, one way or the other. We have to very carefully
balance the gains and the risks. If we try to never reach a consensus
on purpose, this will only cause instability, and a possible result
could be that we will end up having many more weaker implementations
running in the network, decreasing the security overall and for everyone.

While I do agree with some of your points of view and I am happy to
see you advocate for 'more decentralization', please let me point you
in a better direction (I think): there is a much bigger problem than >
~90% of the full nodes running Bitcoin Core software - it is
*centralized mining (e.g. a lot of hashing power behind a single full
mining node)*.

On 9/1/2015 5:16 AM, Peter R wrote:
> I agree, s7r, that Bitcoin Core represents the most stable code
> base. To create multiple implementations, other groups would fork
> Bitcoin Core similar to what Bitcoin XT did.  We could have:
> 
> - Bitcoin-A (XT) - Bitcoin-B (Blockstream) - Bitcoin-C (promoting
> BIP100) - Bitcoin-D - etc.
> 
> Innovation from any development group would be freely integrated by
> any other development group, if desired.  Of course, each group
> would have a very strong incentive to remain fork-wise compatible
> with the other implementations.
> 
> In fact, this just gave me a great idea!  Since Wladimir has stated
> that he will not integrate a forking change into Core without Core
> Dev consensus, *I suggest we work together to never reach consensus
> with Bitcoin Core.  *This will provide impetus for new
> implementations to fork from Core (like XT did) and implement
> whatever scaling solution they deem best.  The users will then
> select the winning solution simply based on the code they choose to
> run.  The other implementations will then rush to make compatible
> changes in order to keep their dwindling user bases.
> 
> This is the decentralized spirit of Bitcoin in action.  Creative 
> destruction.  Consensus formed simply by the code that gets run.
> 
> *Let's kill Bitcoin Core and allow the green shoots of a garden of 
> new implementations to grow from its fertile ashes.  *
> 
> Sincerely, Peter R
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJV5iFqAAoJEIN/pSyBJlsRMvIH/RiE8BhlXPbNOQW01HBJTBOD
3H4bgaZoXuxSq2B1F4zKa/FvKJKtq7BGR3hLEj5tascqZTE2YsksRqmEednFNvbL
XOliCjees6nI/oz/aYFuz9rFoKH4cxA7bJmbvieqGSOqDt7rtClaO2JzBycilngS
F5pVGjKlprprTn4XUS8R40rfYVFbYyxaMnWBOnkgEpEAbtEvNRcASSW4HQoxuGRL
6E8mzp8f23zAv6ENxKEfQoIf5SBBfYf8v2xV+YY9JcFjwh4MAQ7zFazsChh83D42
eI01jfuh58f0DS6qGmjb++N+a/mbgmQhIC4yV4iRZKiIHp9o2xKlSv4NyEJIHlM=
=JnYI
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Your Gmaxwell exchange

[Monarch]

On 2015-08-31 23:47, s7r via bitcoin-dev wrote:
> The problem is there is no other implementation out there which comes
> near the quality of the code in Bitcoin Core. I am actually eager to
> try other implementations as well, but something serious, because
> Bitcoin itself is a payment protocol not something to play with.
> 

I don't think code quality is of a particular problem in alternate
implementations, the difficulty of getting it right is simply
astronomical.  If you attempt to re-implement just transaction
signature verification you run into edge cases remarkably quickly,
most use of Bitcoin today barely scratches the surface of what was
added to Bitcoin for future expansion.

https://jonasnick.github.io/blog/2015/05/09/fuzzing-bitcoin-consensus/

Re: [bitcoin-dev] Your Gmaxwell exchange

[Monarch]

On 2015-08-31 23:32, Peter R wrote:
> On 2015-08-31, at 2:24 PM, Allen Piscitello via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 

> It is my opinion, then, that we should support multiple
> implementations of the Bitcoin protocol, working to reduce the
> network's dependency on Core.
> 

That would be incredibly foolish given the history, where even heroic
attempts at making consensus compatible re-implementations have ended
rather poorly.  bitcoin-ruby and btcd have collectively had numerous
consensus failures, some only recently found by fuzzing the scripting
environment.  There are more failures than publicly disclosed, and
almost any failure can be leveraged to split the network and steal
money.   Ethereum attempted to create four clients, written to a
defined specification, and even with all the money in the world has
managed to have numerous consensus failures due to misunderstanding or
implementation.


> I agree. What about decentralization in development? Gavin recently
> said that he wants to "get to the point where there will be multiple
> robust implementations of the core protocol."
> 

Gavin clearly hasn't kept up with the ridiculousness of that task.

Re: [bitcoin-dev] Your Gmaxwell exchange

[Dave Collins]

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

I'd be interested to know about these supposed btcd mainnet forks that
have occurred due to a consensus failure since it came out of alpha.
I'll go ahead and save you some research time - there hasn't been one.
I'm not claiming there will never be one as that would be just as
foolish as claiming Bitcoin Core won't have any more either.

As you alluded to, there was a _potential_ instance found due to fuzzing
which prompted a thorough audit of the code base.  It was fixed before
any problems occurred and resulted in improved test coverage in Bitcoin
Core as well.

On the other hand, Bitcoin Core has had actual forks on mainnet during
the same period.  I'm not casting stones at Bitcoin Core here, because
as I've said many times, none of us are perfect.  No matter how careful
everyone is, it is bound to happen from time to time.

Until this community decides to get serious about facing the reality
that an infrastructure built on a single implementation with no real
disaster prevention measures for unintentional incompatibilities between
different versions of that implementation is incredibly fragile, there
will continue to be more unintentional hard forks regardless of the
existence of alternative implementations.

It has not ended poorly by any means.  It has already led to several
improvements such as improved test coverage and more robust and modular
code.


On 9/1/2015 6:11 AM, Monarch via bitcoin-dev wrote:
> That would be incredibly foolish given the history, where even heroic
> attempts at making consensus compatible re-implementations have ended
> rather poorly.  bitcoin-ruby and btcd have collectively had numerous
> consensus failures, some only recently found by fuzzing the scripting
> environment.  There are more failures than publicly disclosed, and
> almost any failure can be leveraged to split the network and steal
> money.   Ethereum attempted to create four clients, written to a
> defined specification, and even with all the money in the world has
> managed to have numerous consensus failures due to misunderstanding or
> implementation.


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

Re: [bitcoin-dev] Your Gmaxwell exchange

[Monarch]

On 2015-09-01 15:59, Dave Collins via bitcoin-dev wrote:
> I'd be interested to know about these supposed btcd mainnet forks that
> have occurred due to a consensus failure since it came out of alpha.
> I'll go ahead and save you some research time - there hasn't been one.
> I'm not claiming there will never be one as that would be just as
> foolish as claiming Bitcoin Core won't have any more either.
> 

For the purposes of the conversation this was only brought up to re-
enforce my claim that this is outrageously difficult software
development, irrespective of the quality of the code being produced in
alternate implementations.  Sorry if that came across as an attack
against your software in particular, it wasn't intended.


> On the other hand, Bitcoin Core has had actual forks on mainnet during
> the same period.  I'm not casting stones at Bitcoin Core here, because
> as I've said many times, none of us are perfect.  No matter how careful
> everyone is, it is bound to happen from time to time.
> 

The point I was trying to make is that this is simply a hard
development situation to be working in, we don't know what behavior is
inferred by the use of CPP and even more so OpenSSL (as the DER
encoding consensus failure made abundantly clear).  There's almost
certainly more problems lying around given how generally dusty a lot
of the transaction environment is, it's very easy to get off the
beaten track with Bitcoin script.

Re: [bitcoin-dev] Your Gmaxwell exchange

[Eric Voskuil]

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

On 09/01/2015 09:51 AM, Monarch via bitcoin-dev wrote:
> On 2015-09-01 15:59, Dave Collins via bitcoin-dev wrote:
>> I'd be interested to know about these supposed btcd mainnet forks that
>> have occurred due to a consensus failure since it came out of alpha.
>> I'll go ahead and save you some research time - there hasn't been one.
>> I'm not claiming there will never be one as that would be just as
>> foolish as claiming Bitcoin Core won't have any more either.
>
> For the purposes of the conversation this was only brought up to re-
> enforce my claim that this is outrageously difficult software
> development, irrespective of the quality of the code being produced in
> alternate implementations.  Sorry if that came across as an attack
> against your software in particular, it wasn't intended.

Whether intended or otherwise this is an attack on the idea of
decentralized bitcoin development. The option to fork or roll your own
is open source, not decentralization. Decentralization requires
*actually doing so*. One step down that path, even for a fork, is a
major commitment.

Common consensus check code is now available in several bitcoin
implementations. The claim that this is outrageously difficult is
misleading. It's just engineering work that needs to get done if Bitcoin
is to survive.

>> On the other hand, Bitcoin Core has had actual forks on mainnet during
>> the same period.  I'm not casting stones at Bitcoin Core here, because
>> as I've said many times, none of us are perfect.  No matter how careful
>> everyone is, it is bound to happen from time to time.
> 
> The point I was trying to make is that this is simply a hard
> development situation to be working in, we don't know what behavior is
> inferred by the use of CPP and even more so OpenSSL (as the DER
> encoding consensus failure made abundantly clear).  There's almost
> certainly more problems lying around given how generally dusty a lot
> of the transaction environment is, it's very easy to get off the
> beaten track with Bitcoin script.

These are issues that affect the satoshi client as much as other
implementations, and therefore don't support your premise.

e


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

Re: [bitcoin-dev] Your Gmaxwell exchange

[Monarch]

On 2015-09-01 18:37, Eric Voskuil wrote:
> Whether intended or otherwise this is an attack on the idea of
> decentralized bitcoin development. The option to fork or roll your own
> is open source, not decentralization. Decentralization requires
> *actually doing so*. One step down that path, even for a fork, is a
> major commitment.
> 
> Common consensus check code is now available in several bitcoin
> implementations. The claim that this is outrageously difficult is
> misleading. It's just engineering work that needs to get done if 
> Bitcoin
> is to survive.
> 

There's no requirement for there to be multiple interpretations of the
consensus code, this is why libbitcoinconsensus exists.  Why do you
think Bitcoins survival is predicated on reimplementation?


> These are issues that affect the satoshi client as much as other
> implementations, and therefore don't support your premise.
> 

I'm aware that these problems apply to Bitcoin Core.

Re: [bitcoin-dev] Your Gmaxwell exchange

[Gregory Maxwell]

On Sun, Aug 30, 2015 at 1:43 AM, Peter R <peter_r@gmx.com> wrote:
> Dear Greg,
>
> I am moving our conversation into public as I've recently learned that
> you've been forwarding our private email conversation verbatim without
> my permission [I received permission from dpinna to share the email
> below that proves this fact].

Unfortunately, your work extensive as it was made at least two
non-disclosed or poorly-disclosed simplifying assumptions and a significant
system understanding error which, I believe, undermined it completely.

In short these were:

* You assume miners do not have the ability to change their level
centralization.

 -- In fact they do, not just in theory but in pratice have responded
    to orphaning this way in the past; and it is one of the major
    concerns in this space.

* You assume the supply of bitcoin is infinite (that subsidy never
declines)

 -- It declines geometrically, and must if the 21m limit is to be upheld.
    (Though I think this is not equally important as the other concerns)

* You argue, incorrectly, that amount of information which must be
transmitted at the moment a block is discovered is proportional to the
block's size.

 -- Instead the same information can be transmitted _in advance_, as
 has been previously proposed, and various techniques can make doing
 so arbitrarily efficient.

[I would encourage anyone who is interested to read the posted off-list
discussion]

I contacted you in private as a courtesy in the hope that it would be
a more productive pathway to improving our collective understanding; as well
as a courtesy to the readers of the list in consideration of traffic levels.

In one sense, this was a success: Our conversation concluded with you
enumerating a series of corrective actions that you would take:

--------
> 1.  I will make it more clear that the results of the paper hinge on
> the assumption that block solutions are propagated across channels,
> and that the quantity of pure information communicated per solution
> is proportional to the amount of information contained within the block.
>
> 2.  I will add a note [unless you ask me not to] something to the effect
> of "Greg Maxwell challenges the claim that the coding gain cannot
> be infinite…" followed by a summary of the scenario you described.
> I will reference "personal communication."  I will also run the note
> by you before I make the next revision public.
>
> 3.  I will point out that if the coding gain can be made spectacularly
> high, that the propagation impedance in my model will become very small,
> and that although a fee market may strictly exist in the asymptotic
> sense, such a fee market may not be relevant (the phenomena in the paper
> would be negligible compared to the dynamics from some other effect).
>
> 4. [UNRELATED] I also plan to address Dave Hudson's objections in my
> next revision (the "you don't orphan your own block" point).
>
> Lastly, thank you for the note about what might happen when fees >
> rewards.  I've have indeed been thinking about this.  I believe it is
> outside the scope of the present paper, although I am doing some work
> on the topic.  (Perhaps I'll add a bit more discussion on this topic
> to the present paper to get the reader thinking in this direction).
--------

To the best of my knowledge, you've taken none of these corrective
actions in the nearly month that has passed.  I certainly understand being
backlogged, but you've also continued to make public comments about your
work seemingly (to me) in contradiction with the above corrective actions.

Today I discovered that another author spent their time extending your
work and wasn't made aware of these points.  A result was that the other
author's work may require significant revisions.

I complained about this to you, again privately, and your (apparent)
response was to post to that thread stating that there was a
details-unspecified academic disagreement with me and "I look forward
to a white paper demonstrating otherwise!", in direct contradiction to
your remarks to me three weeks ago in private correspondence: In private
you said that your model may only hold in an asymptotic sense and that
"the phenomena in the paper (may) be negligible compared to the dynamics
from some other effect"; but in public you said /my/ position was
"academic".

At this point I thought continuing to withhold this information from
the other author was unreasonable and no longer justified by courtesy
to you, and I forwarded our complete discussion to the other author
with the comment "I'll forward you a set of private correspondence
that I've had with Peter R.  I would recommend you take the time to
read it and consider it.".

I apologize if in doing so I've breached your confidence, none of the
material we discussed was a sort that I would have ordinarily considered
private, and you had already talked about making the product of our
communication published as part of your corrective actions.
I do not think it would be reasonable to demand that I spent time
repeating the same discussion again with the other author, or deprive
them of your side of it and/or the corrective actions which you had
said you would take but have not yet taken.

(In fact, I would argue that you were already obligated to share at least the
substance of the discussion  with the other author, both as part of your
commitment to me as well it being necessiary for intellectual progress.)

As you say, 'we are all here trying to learn about this new amazing
thing called Bitcoin'; and I'm not embarrassed to error towards doing
that and aiding others in doing so, but at the same time I am sorry
to have done so in a way which caused you some injury.

In any case, your prior proposed corrective actions seemed sufficient to me.

It surprises me, greatly, that you are failing to see the extreme
practicality of what I described to you, and that it does not meaningfully
diminish miner control of transaction selection-- but even without it your
remark that the proportionality could be arbitrarily small (Rather than
0, as I argue) is an adequate correction to your work, in my view.

I believe my time would be better spent actually _implementing_ improved
relaying described (and describe what was implemented) than continue
a purely academic debate with you over the (IMO) inconsequential difference
between epsilon and zero.

Cheers,

Re: [bitcoin-dev] Your Gmaxwell exchange

[Peter R]

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

Hi Greg,

> Unfortunately, your work extensive as it was made at least two
> non-disclosed or poorly-disclosed simplifying assumptions and a significant
> system understanding error which, I believe, undermined it completely.
> 
> In short these were:
> 
> * You assume miners do not have the ability to change their level
> centralization.
> 
> -- In fact they do, not just in theory but in pratice have responded
>    to orphaning this way in the past; and it is one of the major
>    concerns in this space.

I agree that miners may change their level of centralization.  This neither affects the model nor the results presented in the paper.

> * You assume the supply of bitcoin is infinite (that subsidy never
> declines)
> 
> -- It declines geometrically, and must if the 21m limit is to be upheld.
>    (Though I think this is not equally important as the other concerns)

No I don't.  I assume the inflation rate is R/T, where R is a variable.  

The last paragraph of the conclusion speaks to the paradox of what happens when R -> 0 as an area for future research. 


> * You argue, incorrectly, that amount of information which must be
> transmitted at the moment a block is discovered is proportional to the
> block's size.
> 
> -- Instead the same information can be transmitted _in advance_, as
> has been previously proposed, and various techniques can make doing
> so arbitrarily efficient.

I assume, very reasonably, that the block solutions contain information about the transactions included in the block.  This is the case today, this is the case using the relay network, and this would be the case using any compression scheme I can personally imagine actually occurring in the future.  

(I've always agreed that if block solutions can be communicated to all of the hash power in such a way that they don't include any information about the transactions they contain, then the conditions for a healthy fee market would not be met [this would be gamma --> infinity in my model]). 


> [I would encourage anyone who is interested to read the posted off-list
> discussion]

As would I.  

> I contacted you in private as a courtesy in the hope that it would be
> a more productive pathway to improving our collective understanding; as well
> as a courtesy to the readers of the list in consideration of traffic levels.

I appreciated the discussion we were having and I thought we had come to some kind of an understanding.  I acknowledged that when I made the other corrections to my paper that I would further clarify the assumptions (I agreed that the presentation could be improved).      

What was not courteous was that you forwarded the entire private email chain to other people without my permission.

> In one sense, this was a success: Our conversation concluded with you
> enumerating a series of corrective actions that you would take:
> 
> --------
>> 1.  I will make it more clear that the results of the paper hinge on
>> the assumption that block solutions are propagated across channels,
>> and that the quantity of pure information communicated per solution
>> is proportional to the amount of information contained within the block.
>> 
>> 2.  I will add a note [unless you ask me not to] something to the effect
>> of "Greg Maxwell challenges the claim that the coding gain cannot
>> be infinite…" followed by a summary of the scenario you described.
>> I will reference "personal communication."  I will also run the note
>> by you before I make the next revision public.
>> 
>> 3.  I will point out that if the coding gain can be made spectacularly
>> high, that the propagation impedance in my model will become very small,
>> and that although a fee market may strictly exist in the asymptotic
>> sense, such a fee market may not be relevant (the phenomena in the paper
>> would be negligible compared to the dynamics from some other effect).
>> 
>> 4. [UNRELATED] I also plan to address Dave Hudson's objections in my
>> next revision (the "you don't orphan your own block" point).
>> 
>> Lastly, thank you for the note about what might happen when fees >
>> rewards.  I've have indeed been thinking about this.  I believe it is
>> outside the scope of the present paper, although I am doing some work
>> on the topic.  (Perhaps I'll add a bit more discussion on this topic
>> to the present paper to get the reader thinking in this direction).

I stand by all of these four points.  My paper wasn't perfectly presented.  Making these clarifications will strengthen the manuscript by showing how strong the claim "a healthy transaction fee market exists without a block size limit" is.  


> To the best of my knowledge, you've taken none of these corrective
> actions in the nearly month that has passed.  I certainly understand being
> backlogged, but you've also continued to make public comments about your
> work seemingly (to me) in contradiction with the above corrective actions.

My public comments have been factual.  I've even gone out of my way in several public threads to point out your objection that the coding gain could be zero (even though I think it is flawed "black-and-white thinking" about an academic scenario that will never unfold and might actually be physically impossible without Bitcoin already being centralized).

I'll end by saying that I am the one describing things as the presently are.  You are talking about a hypothetical future that may or may not exist (and may not even be possible).  The results of my paper logically follow from the assumptions made. You think the assumption that "block solutions contain information about the transactions included in the block" will not hold in the future.  Can you show:

(a) Under what assumptions/requirements your communication scheme is physically possible.

(b) That such a configuration is not equivalent to a single entity[1] controlling >50% of the hash power.

(c) That the network moving into such a configuration is plausible.

Best regards,
Peter





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

Re: [bitcoin-dev] Your Gmaxwell exchange

[Gregory Maxwell]

On Sun, Aug 30, 2015 at 4:13 AM, Peter R <peter_r@gmx.com> wrote:
> I agree that miners may change their level of centralization.  This neither
> affects the model nor the results presented in the paper.

It has tremdous significance to the real-world impact of your results.

If not for the other errors in your work, this point would make the
take away of your work not "a healthy transaction fee market exists
without a block size limit" but rather "a decenteralized bitcoin
cannot exist"-- as, accepting the other errors as fact your model
shows that centralizing mining is always strictly more profitable at
any level of fee demand; because your model equivilent shows that for
any level of fee demand and gamma miners could increase their income
by centeralizing further.

I absolutely agree that simplifications are useful and essential, but
it is critically important to call them out before someone mistakes
theoretical work as useful motivation for policy in the non-simplified
system.

> -- Instead the same information can be transmitted _in advance_, as
> has been previously proposed, and various techniques can make doing
> so arbitrarily efficient.
>
> I assume, very reasonably, that the block solutions contain information
> about the transactions included in the block.  This is the case today, this
> is the case using the relay network, and this would be the case using any
> compression scheme I can personally imagine actually occurring in the
> future.

This assumption is unreasonable, and does not-- in fact-- accurately
reflect the situation today.

For example it does not reflect how hashers return work to pools
_today_ (and since 2011) as they so to only by referencing the merkel
root... the pool already knows the  transaction set. In that
particular case it knows it because it selected it to begin with, but
the same behavior holds if the hasher selects the transaction set and
sends it first.

It only _very_ weakly reflects how the relay protocol works (only the
selection and permutation is communicated; not the transaction data
itself; for already known transactions). Even if you assume nothing
more than that (in spite of the existing reality) you have not shown
that the compressed data must be linear in the size of the block.

It does not reflect how P2Pool works (which also sends the
transactions in advance).

There is a simple, and intuitive understanding that does not require
any complex supposition:  You argue that the information must be
transfered when a block is found, thus delaying it.  I point out, no,
any required information (to the extent that there is any at all after
efficient encoding) can be sent in advance of the block.

I believe that you've allowed the fact that the specifc example block
relay protocol doesn't bother sending _all_ information in advance to
confuse it for mere compression.

> My public comments have been factual.  I've even gone out of my way in
> several public threads to point out your objection that the coding gain
> could be zero (even though I think it is flawed "black-and-white thinking"
> about an academic scenario that will never unfold and might actually be
> physically impossible without Bitcoin already being centralized).

I believe my reponses are firmly grounded in the physical reality of
actually deployed systems and constructable protocols.

By comparison, even if I were to agree that the bound is not actually
exactly 0 proporionality  you have already agreed that with
"compression" the amount sent could be arbritarily low. The result
being that the behavior you're describing would only be asymptoic and
have no relationship to the actual Bitcoin system that exists in a
finite universe.

But you continue to demand debate over this meaningless point.

> I'll end by saying that I am the one describing things as the presently are.
> You are talking about a hypothetical future that may or may not exist (and
> may not even be possible).  The results of my paper logically follow from
> the assumptions made. You think the assumption that "block solutions contain
> information about the transactions included in the block" will not hold in
> the future.  Can you show:
>
> (a) Under what assumptions/requirements your communication scheme is
> physically possible.

Pratically every block today is mined under a protocol which does not
need to communicate anything but constant data when a block is found.

I am getting a little tired of people suggesting things which are
widely deployed are not physically possible.

Yes, that particular example is not the most powerful form of that
idea-- but it has the benefit of _universal_ use.

> (b) That such a configuration is not equivalent to a single entity[1]
> controlling >50% of the hash power.

I find this a little amusing. Even in this messsage you defend
ignoring of centeralization considerations in your paper. But here ask
that I address concerns which you refused to suggest. Why do you
demand my correction use weaker assumptions than your work?

That said-- I already gave you a fairly concrete description of a
pratical protocol which would accomplish your requirement ( (a) reduce
the information transmitted in a latency critical way at block
discovery time to O(1) network wide, (b) without creating
centeralization in chain or transaction selection). I believe my
description in the messages was adequate that anyone working on
Bitcoin Core could go implement a version of it, at least.  You appear
to have simply ignrored it.

If the actual technical details made your eyes glaze over I also
offered a simple intutive understanding:  The no proportional
information need be transfered at the latency critical time, because
it can be transfered in _advance_. Everything beyond that is just
efficiency optimizations to reduce the cost of doing the advanced
transmission.

> (c) That the network moving into such a configuration is plausible.

That it already uses advanced information techniques in every widely
used mining protocol, that the relay protocol was rapidly adopted, and
that your own model would suggest significant profits from any such
improvement would seem to remove any doubt related to (c)... and again
here you hold me to a higher bar than your own work: as nowhere do you
show that the "limits" your model erroniously extracts are plausable
as limits, and in private you seemed to admit to me that they may well
not be.

Re: [bitcoin-dev] Your Gmaxwell exchange

[Adam Ritter]

I don't really see any problem with the paper:
All it states is that having the assumption that miners don't
centralize, transaction fees don't go to zero even without the
blocksize limit. I think we can accept this as a nice academic
research, and I believe that it's true.
Still, it doesn't have anything that is practical for me as an user of
the Bitcoin network (I use it for storing long-term purchase value, as
most of the people who I know): it doesn't help me if I still need to
pay transaction fees after the blocksize limit is gone. My (and other
users') main concern is about centralization, which has nothing to do
with transaction fees. I would be OK with $100 transaction fee as
well, as long as the network is fair and secure (which comes from
decentralization).

Re: [bitcoin-dev] Your Gmaxwell exchange

[Justus Ranvier]

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

On 08/30/2015 01:38 AM, Adam Ritter via bitcoin-dev wrote:
> Still, it doesn't have anything that is practical for me as an user of
> the Bitcoin network (I use it for storing long-term purchase value, as
> most of the people who I know): it doesn't help me if I still need to
> pay transaction fees after the blocksize limit is gone. My (and other
> users') main concern is about centralization, which has nothing to do
> with transaction fees. I would be OK with $100 transaction fee as
> well, as long as the network is fair and secure (which comes from
> decentralization).

I don't believe that any Bitcoin user actually cares about
decentralization, because none of them I've asked can define that term.

"decentralization" has become a placeholder word for "features or ideas
that I like" and it's long past time to drag the discussion back into
the realm of concrete and achievable goals.

I think there are a few specific things we can surmise about what users
might mean when they say they want Bitcoin to be "decentralized":

* They should own their bitcoins, meaning that they retain exclusive
control over their balances. Even more precisely, the network must
always honour the conditions of the scripts associated with unspent outputs.

* Their fraction of the Bitcoin ledger must not be diluted.

* When they decide to spend their coins, they will be able to do so
without requiring permission from a third party.

A decentralized architecture in certain parts of the network can be
helpful for achieving those goals, but it is not always necessary, nor
is it always sufficient to achieve them.

-- 
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus@openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623

[-- Attachment #1.2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 18667 bytes --]

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

Re: [bitcoin-dev] Your Gmaxwell exchange

[Mike Hearn]

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

I think your summary of what people actually want from decentralisation is
pretty good, Justus.


> I don't believe that any Bitcoin user actually cares
> about decentralization, because none of them I've asked can define that
> term.
>

+1 Insightful

It's been quite impressive to see so many Bitcoin users and developers
saying, "Bitcoin is totally decentralised because it's open source and
nobody is in charge...... oh nooooooo we didn't mean you could change *those
lines! *If you want to change *those lines* then *we* must agree first!"

Believing simultaneously that:

1. Bitcoin is decentralised

2. Nobody should modify the code in certain ways without the agreement of
me and my buddies

is just doublethink.

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

Re: [bitcoin-dev] Your Gmaxwell exchange

[Wladimir J. van der Laan]

On Mon, Aug 31, 2015 at 01:55:43PM -0500, Justus Ranvier via bitcoin-dev wrote:

> * They should own their bitcoins, meaning that they retain exclusive
> control over their balances. Even more precisely, the network must
> always honour the conditions of the scripts associated with unspent outputs.
> 
> * Their fraction of the Bitcoin ledger must not be diluted.
> 
> * When they decide to spend their coins, they will be able to do so
> without requiring permission from a third party.

All of these properties are contingent on the system being decentralized. Asking random end-users if they care if bitcoin is decentralized is like asking random people if they care if their drinking water is dihydrogen monoxide.

Both miner and full node over-centralization could result in

- Permission requirements to submit transactions (miners can be pressured to adhere to KYC rules)

- Transactions being reversed without consent (reorgs by the miner cartel)

- ...even dilution of their fraction of their ledger (if changing the rules becomes normal, I'm sure some smoothtalker could come up with arguments to raise the 21M cap. Another option would be to force the remaining people that are able to run full nodes to comply)

Bitcoin's properties don't come from magic. All its attractive properties are derived from decentralization, on spreading responsibility as widely globally as possible. Without that, it's just an inefficient ledger database.

Wladimir

Re: [bitcoin-dev] Your Gmaxwell exchange

[Justus Ranvier]

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

On 09/01/2015 03:29 PM, Wladimir J. van der Laan wrote:
> On Mon, Aug 31, 2015 at 01:55:43PM -0500, Justus Ranvier via bitcoin-dev wrote:
> 
>> * They should own their bitcoins, meaning that they retain exclusive
>> control over their balances. Even more precisely, the network must
>> always honour the conditions of the scripts associated with unspent outputs.
>>
>> * Their fraction of the Bitcoin ledger must not be diluted.
>>
>> * When they decide to spend their coins, they will be able to do so
>> without requiring permission from a third party.
> 
> All of these properties are contingent on the system being decentralized.

That is not true, unless you are using a definition of the word
"decentralized" which is so broad as to convey no information whatsoever.

Saying that Bitcoin's security depends on decentralization is like
saying that a bridge's structural integrity depends on good materials.

Statements like that convey zero relevant information. Potential users
of a bridge want to know about the maximum working load of the bridge,
and under which conditions it is safe to use. At what wind speed should
the bridge be closed? Is it ok to keep using it after a magnitude 4
earthquake, or should it be closed for inspection?

Repeatedly asserting that bridges need to be made of good materials as
an alternative to answering those kinds of questions would be easily
recognized as useless in that context, but for some reason people seem
to accept it in this one.


-- 
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus@openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623

[-- Attachment #1.2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 18667 bytes --]

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

Re: [bitcoin-dev] Your Gmaxwell exchange

[Oliver Petruzel]

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

>>>I would be OK with $100 transaction fee

Unless you're relying upon some hypothetical hyper-inflation of the USD,
how does one accept or justify such fees given the title (and intentions)
of Satoshi's own white paper and corresponding software?

I believe the key words "cash system" must be kept in mind throughout all
of these discussions and developments, or else we risk turning Bitcoin into
something other than cash.

Bitcoin will no longer be a P2P cash system if the fees make transactions
prohibitively expensive for all but the wealthiest of individuals and
corporations.

I understand that a careful balance must be struck between (measurable?)
decentralization and Bitcoin's use as an actual cash system; however, those
who are willing to annihilate the latter to maintain ONLY the former must
at least be honest with everyone that they really don't care if Bitcoin
becomes something entirely different than Satoshi's original invention and
intention.

Call it a necessary transformation or reinvention, and by a new name, if
you will; because, with exorbitant fees, it may no longer be accurate or
appropriate to call it Bitcoin: A Peer-to-peer Electronic CASH System.

Respectfully,
Oliver
On Aug 30, 2015 2:38 AM, "Adam Ritter via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I don't really see any problem with the paper:
> All it states is that having the assumption that miners don't
> centralize, transaction fees don't go to zero even without the
> blocksize limit. I think we can accept this as a nice academic
> research, and I believe that it's true.
> Still, it doesn't have anything that is practical for me as an user of
> the Bitcoin network (I use it for storing long-term purchase value, as
> most of the people who I know): it doesn't help me if I still need to
> pay transaction fees after the blocksize limit is gone. My (and other
> users') main concern is about centralization, which has nothing to do
> with transaction fees. I would be OK with $100 transaction fee as
> well, as long as the network is fair and secure (which comes from
> decentralization).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Your Gmaxwell exchange

[Peter R]

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

Hi Greg,

>> I agree that miners may change their level of centralization.  This neither
>> affects the model nor the results presented in the paper.
> 
> It has tremdous significance to the real-world impact of your results.

The paper makes no claims about "miners changing their level of centralization."  Whether it is or is not significant, it is outside the scope of the paper and irrelevant to the result that a fee market exists without a block size limit (given the assumption that some information about the transactions included in a block is communicated between miners during block solution propagation).      

> If not for the other errors in your work,

Again, what you are calling "errors" are assumptions--in fact very reasonable assumptions that we know are valid for the network as a whole right now.  You are proposing that maybe they won't be valid in the future if the miners move to some hypothetical configuration that you worry may be possible.  I say prove it: show rigorously what the network would look like in a case where information about the transactions contained in a block is never communicated with the block solution.  How do you get the miners to agree (assuming such a configuration is even physically possible)?  Do you need all the miners to agree or only a portion of them?  How reasonable is it that the systems moves into such a configuration?  I know you spoke to this in your last response, but I mean really prove it...with a mathematical model, with diagrams and charts, with equations, with your assumptions clearly stated so that they can be put to the test--not by waving your hands on the bitcoin-dev mailing list.    

This is an exciting field of research and we should encourage people to continue to explore these questions.   

> this point would make the
> take away of your work not "a healthy transaction fee market exists
> without a block size limit" but rather "a decenteralized bitcoin
> cannot exist"-- as, accepting the other errors as fact your model
> shows that centralizing mining is always strictly more profitable at
> any level of fee demand; because your model equivilent shows that for
> any level of fee demand and gamma miners could increase their income
> by centeralizing further.

OK, I actually sort of agree with your very last sentence above.  My paper indeed suggests that the most "profitable" configuration is one where there is only one "super pool." Is that likely to happen?  I personally don't think so because of the game theory involved.  But regardless of my opinion or your opinion on that matter, whether it is or isn't likely to happen is outside the scope of my paper.  It is irrelevant to the result that a fee market exists without a block size limit given the assumption that there is more than a single miner.

> I absolutely agree that simplifications are useful and essential, but
> it is critically important to call them out before someone mistakes
> theoretical work as useful motivation for policy in the non-simplified
> system.

I do call them out.  Furthermore, I've already agreed with you to further clarify these assumptions when I make the other corrections to the paper.  Doing so will make the paper stronger.  

I'm not going to address the remainder of your email because I believe that we are now talking past each other.  I do appreciate the interest and attention that you've paid to my work on the Transaction Fee Market, and I also recognize the important contributions you've made such as coinjoin and HD wallets.  

Best regards,
Peter


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