path: root/a1/5f9c137363bfde04f3e2e5bab9f758e1519e24

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <adam@cypherspace.org>) id 1Z5sVX-0001JB-L3
	for bitcoin-development@lists.sourceforge.net;
	Fri, 19 Jun 2015 09:22:43 +0000
X-ACL-Warn: 
Received: from mout.perfora.net ([74.208.4.197])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1Z5sVW-0003rD-7C
	for bitcoin-development@lists.sourceforge.net;
	Fri, 19 Jun 2015 09:22:43 +0000
Received: from mail-qk0-f181.google.com ([209.85.220.181]) by
	mrelay.perfora.net (mreueus003) with ESMTPSA (Nemesis) id
	0Md5dc-1ZMr7u1ldS-00IFxR for
	<bitcoin-development@lists.sourceforge.net>; 
	Fri, 19 Jun 2015 11:22:36 +0200
Received: by qkbp125 with SMTP id p125so53716907qkb.2
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 19 Jun 2015 02:22:35 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.31.161 with SMTP id f30mr12651899qgf.23.1434705755816;
	Fri, 19 Jun 2015 02:22:35 -0700 (PDT)
Received: by 10.96.20.164 with HTTP; Fri, 19 Jun 2015 02:22:35 -0700 (PDT)
Date: Fri, 19 Jun 2015 11:22:35 +0200
Message-ID: <CALqxMTGCkTZAs74bXk57L6JWK29Xzbn1ZUkWN_NuBp+EufjEQg@mail.gmail.com>
From: Dr Adam Back <adam@cypherspace.org>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:FipUIyRrAxIDsvSDizBf2qwidDfsaDKRQ98QFDrGic9nW4ku/+O
	DeXfPAC+Xm+jScCUBzmFkXJsU8oqM1AIfF9uDz0yW/Fl0McoG+h2UNwu7LxVmjMM4n2cBI5
	Cwlq6eAercUOxJOqF/uQ9tBmKdN5ryAlR2ALHI4yX1gj+D/A1J4/wzkWhXsbKdlqLx0ldP6
	Oi9VTWGQgbvSWs50JVAwQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:PYos4vVMyL0=:OSEt9rtUovE6P6oa7UA3Y2
	lwhp/3A/MWMaBPJKfpiOeMJAE2J8MEKzRgK63kqvhIc3fD9f71gvzRIqpTJczeugAky+UbF4E
	1NO32lVvkCuLv6wvfS+01vokq6G1/seN9JS1Cnyio/jRtfoIsmeHJ9dptMcRb5CIzAM1rEG3t
	6d9chc9w/0EEgF7xOJQzvlf7vnYTYgLFw23yUYDrJByUuH9oeVhwEwtTG0s/3Nx8w7CKfYO3r
	ssEaYTn5Fs1rm68ye5PjIkW7dTlXtOoi0yG2ZFcBhI4HGKMmyDZCVMh1stl9ddupi9UebbQ7d
	MpCS7Qk0KkGHTqi4bZZoKym4jwacXk+cEbJIGcOSkI0dSeRNVGcebPoxyjK8CAxuvfIK1lMaW
	nRAwY/yCeIO5QK+vd9yLizwpwfI4gaAn46eD662a7gcteSuEfH7WZPDdLGxxLOqTKDiUFq/b0
	2SMwrhabxawLzaM2v0kkkBv0T2pLVAKwlAO4ceHaFBvFLvwOnxAu6n3EcEI4cjqTWoBHdtuhJ
	8SVT/KM6VUtJffKTUeUdI7XnKJJaUZlSr+VzJJamO093E0rTabg6ufUEch02J81VNsZ5xUFWv
	XUDP2piDOzE9rL1lLFZUyEHCEcs0Q2q8uu6TQDbuUE+Jr91ItFMWPlG85E7AuFlwl2rV0wnrn
	BErg/HSleyUw+uclvsiViJcaH4bp1xtICN9E8RdLNPcbhRQ==
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [74.208.4.197 listed in list.dnswl.org]
	-0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
	0.0 T_HK_NAME_DR           T_HK_NAME_DR
X-Headers-End: 1Z5sVW-0003rD-7C
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] improving development model (Re: Concerns
 Regarding Threats by a Developer to Remove Commit Access from Other
 Developers
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2015 09:22:43 -0000

Nicely put Eric.  Relatedly my initial experience with Bitcoin in
trying to improve bitcoin in fungibility, privacy & decentralisation,
I found some interesting things, like Confidential Transactions (that
Greg Maxwell has now optimised via a new generalisation of the
hash-ring signature construct he invented and with Pieter made part of
the alpha side-chain release) and a few other things.

As I went then to discuss and learn: a) what are the characteristics
needed for inclusion (clearly things need to fit in with how things
work, not demand massive rewrites to accommodate and to not conflict
with existing important design considerations), so that I could make
proposals in a practically deployable way, and then b) the
practicality of getting a proposed change that say people found
clearly useful.  Then I bumped into the realisation that this is
actually really high risk to change, and consensus critical coding
security is very complex and there are some billion $ resting on
getting this rigidly correct under live conditions, so that deployment
must be cautious and incremental and rigorously tested.

So then I focussed instead on question of whether we could improve
bitcoins development model: how could we allow bitcoin to more rapidly
and agilely test beta features or try novel things to see how they
would work (as someone might do in a feature branch of a normal FOSS
project, to code and test a proposal for later addition), but with
criteria we want real bticoins so there is economic incentive as that
is actually part of the bitcoin protocol so you've not validated
something unless you're run it in a real network with money.  I was
hypothesising therefore we need a way to run bitcoin beta network.
There's a thread about this here stretching back to may 2013.

Or similarly to run in parallel kind of subnets with different
trade-offs or features that are not easy to merge or high risk to
apply all at once to bitcoin with the inflight billions in capital and
transactions on it.

Anyway I thought that was a productive line of thinking, and generally
people seemed to agree and problem statement of 2wp: then 1wp
mechanism was proposed and then Greg extracted a concept from his
SNARK witness idea (which encapsulates a snark variant of a 2wp) but
now without snarks, then 2wp a conservative crypto 2wp proposal was
made.  This was dec 2013 I think on wizards channel.  The sidechain
alpha release now makes this a (alpha quality and so testnet coin, and
without DMMS peg) reality.  I could imagine others who have a desire
to try things could elect to do so and copy that patch-set and make
more side-chains.

This is inherently non-coercive because you largely do not directly
change bitcoin by doing this, people elect to use which ever chain
suits them best given their usecase.  If the sidechain is really early
stage it should have test-net coins in it not bitcoins in it, but
still its caveat emptor kind of beta chain, with good testing but
non-trivial to soft-fork on bitcoin but managable refactor a sidechain
to integrate something novel or try some existing feature (like the
segregated witness which robustly addresses malleability for example)

So I dont want to say side-chains are some magical solution to
everything, but its a direction that others may like to consider for
how to test or even run alternative trade-offs bitcoin side-chains in
parallel.  For example it could hypothetically allow 10MB blocks on
one chain and 100kB blocks on the main chain.  People say complexity,
scary.  Sure I am talking longer term, but we have to also make
concrete forward progress to the future or we'll be stuck here talking
about perilously large constant changes in 5 years time!

This approach also avoids the one-size fits all problem.

Extension-blocks are an in-chain sub-net type of thing that has a
security boost by being soft-fork enforced (relative to side-chains
which are looser coupled and so more flexible relative to the simplest
form of extension-blocks)

Adam

On 19 June 2015 at 07:59, Eric Lombrozo <elombrozo@gmail.com> wrote:
> I don=E2=80=99t think the issue is between larger blocks on the one hand =
and things
> like lightning on the other - these two ideas are quite orthogonal.
>
> Larger blocks aren=E2=80=99t really about addressing basic scalability co=
ncerns -
> for that we=E2=80=99ll clearly need architectural and algorithmic improve=
ments=E2=80=A6and
> will likely need to move to a model where it isn=E2=80=99t necessary for =
everyone to
> validate everyone else=E2=80=99s latte purchases. Larger blocks might, at=
 best, keep
> the current system chugging along temporarily - although I=E2=80=99m not =
sure that=E2=80=99s
> necessarily such a great thing=E2=80=A6we need to create a fee market soo=
ner or
> later, and until we do this, block size issues will continue to crop up
> again and again and economic incentives will continue to be misplaced. It
> would be nice to have more time to really develop a good infrastructure f=
or
> this=E2=80=A6but without real market pressures, I=E2=80=99m not sure it w=
ill happen at all.
> Necessity is the mother of invention, after all. The question is how to
> introduce a fee market smoothly and with the overwhelming consensus of th=
e
> community - and that's where it starts to get tricky.
>
> =E2=80=94=E2=80=94
>
> On a separate note, as several others have pointed out in this thread (bu=
t I
> wanted to add my voice to this as well), maintenance of source code
> repositories is NOT the real issue here. The bitcoin/bitcoin project on
> github is a reference implementation of the Satoshi protocol=E2=80=A6but =
it is NOT
> the only implementation=E2=80=A6and it wasn=E2=80=99t really meant to be.=
 Anyone is free to
> fork it, extend it, improve upon it, or create an entirely new network wi=
th
> its own genesis block=E2=80=A6a separate cryptoledger.
>
> The real issue regarding XT is NOT the forking of source code nor issues
> surrounding commit access to repositories. The real issue is the *forking=
 of
> a cryptoledger*.
>
> Open source repositories are meant to be forked - in fact, it is often
> encouraged. It is also encouraged that improvements be submitted for revi=
ew
> and possibly merged back into the parent repository=E2=80=A6although this=
 doesn=E2=80=99t
> always happen.
>
> However, we currently have no mechanisms in place to support merging of
> forked cryptoledgers. Software, and most other forms of digital content,
> generally increases in value with more copies made. However, money is
> scarce=E2=80=A6by design. The entire value of the assets of a decentraliz=
ed
> cryptoledger rests on the assumption that nobody can just unilaterally fo=
rk
> it and change the rules. Yes, convincing other people to do things a cert=
ain
> way is HARD=E2=80=A6yes, it can be frustratingly slow=E2=80=A6I=E2=80=99v=
e tried to push for many
> changes to the Bitcoin network=E2=80=A6and have only succeeded a very sma=
ll number
> of times. And yes, it=E2=80=99s often been quite frustrating. But trying =
to
> unilaterally impose a change of consensus rules for an existing cryptoled=
ger
> sets a horrendous precedent=E2=80=A6this isn=E2=80=99t just about things =
like block size
> limits, which is a relatively petty issue by comparison.
>
> It would be very nice to have a similar workflow with consensus rule
> evolution as we do with most other open source projects. You create a for=
k,
> demonstrate that your ideas are sound by implementing them and giving oth=
ers
> something that works so they can review them, and then merge your
> contributions back in. However, the way Bitcoin is currently designed, th=
is
> is unfortunately impossible to do this with consensus rules. Once a fork,
> always a fork - a.k.a. altcoins. Say what you will about how most altcoin=
s
> are crap - at least most of them have the decency of starting with a clea=
n
> ledger.