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.