* [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
@ 2015-06-19 9:22 Dr Adam Back
2015-06-19 10:45 ` Dr Adam Back
0 siblings, 1 reply; 10+ messages in thread
From: Dr Adam Back @ 2015-06-19 9:22 UTC (permalink / raw)
To: Eric Lombrozo; +Cc: Bitcoin Dev
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’t 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’t really about addressing basic scalability concerns -
> for that we’ll clearly need architectural and algorithmic improvements…and
> will likely need to move to a model where it isn’t necessary for everyone to
> validate everyone else’s latte purchases. Larger blocks might, at best, keep
> the current system chugging along temporarily - although I’m not sure that’s
> necessarily such a great thing…we need to create a fee market sooner 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 for
> this…but without real market pressures, I’m not sure it will 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 the
> community - and that's where it starts to get tricky.
>
> ——
>
> On a separate note, as several others have pointed out in this thread (but 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…but it is NOT
> the only implementation…and it wasn’t really meant to be. Anyone is free to
> fork it, extend it, improve upon it, or create an entirely new network with
> its own genesis block…a 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 review
> and possibly merged back into the parent repository…although this doesn’t
> 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…by design. The entire value of the assets of a decentralized
> cryptoledger rests on the assumption that nobody can just unilaterally fork
> it and change the rules. Yes, convincing other people to do things a certain
> way is HARD…yes, it can be frustratingly slow…I’ve tried to push for many
> changes to the Bitcoin network…and have only succeeded a very small number
> of times. And yes, it’s often been quite frustrating. But trying to
> unilaterally impose a change of consensus rules for an existing cryptoledger
> sets a horrendous precedent…this isn’t 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 fork,
> demonstrate that your ideas are sound by implementing them and giving others
> something that works so they can review them, and then merge your
> contributions back in. However, the way Bitcoin is currently designed, this
> 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 altcoins
> are crap - at least most of them have the decency of starting with a clean
> ledger.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
2015-06-19 9:22 [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers Dr Adam Back
@ 2015-06-19 10:45 ` Dr Adam Back
2015-06-19 11:35 ` Bryan Bishop
` (4 more replies)
0 siblings, 5 replies; 10+ messages in thread
From: Dr Adam Back @ 2015-06-19 10:45 UTC (permalink / raw)
To: Dr Adam Back; +Cc: Bitcoin Dev
A lot of people think a layer2 is needed, that has a higher
(algorithmic) scale in use of layer1 block-space but preserves
functionality and uplifts security from layer1. An example would be
lightning or similar.
But there are many things that could be done. Pure offchain is a weak
form of layer2. Its running today and maybe its handling 90-99% range
of all transactions right now (mostly in exchanges for example). This
layer can be incrementally hardened. It can also have standardised
APIs across vendors of custodians, and opt-in support of those APIs in
wallets. This would provide a convenience choice. Greenaddress also
for low-mid assurances solves the unconfirmed transactions. It's
probably not reasonable to expect bitcoin directly solve fast
unconfirmed transactions. Probably intermediate configurations in
complexity somewhere between greenaddress (2 of 2 + timelocked 1 sig)
and lightning may exist also. The internet doesnt stop at layer1.
(Which would then leave people who are uninterested in changing client
software to handle layer2, as "layer1 will always be enough die-hards"
(in the refusing the future and facing the O(n^2) scaling wall or
centralisation death with perplexing optimism :) Ok, not so
constructive but maybe a gentle reminder that it is not constructive
in the reverse direction either to throw around often false
characterisations. We're here now to improve bitcoin so lets do that.
What I said here seemed like it maybe subject to misinterpretation so
to clarify:
On 19 June 2015 at 11:22, Dr Adam Back <adam@cypherspace•org> wrote:
> 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!
I should clarify that I meant there I was assuming we do one increase
within the next 12 months frame that gives buffer for 5 years r&d to
improve things and build layer2.
But if we do no R&D on layer2, and insist that clients can never
change to become layer2 aware, and layer2 is too hard etc then our
risk would be we'd be back in the discussion of kicking the can afresh
again in some years with some even more centralising size change.
Sure we should make the transition and introduction to layer2 and an
intermediate crunch smoother, but "20MB now or else" isn't really
helping. It did help get the conversation revived, but at this point
its a hindrance. Seriously a big hindrance. No offence but please
find a way to gracefully stop and rejoin the constructive process.
You can disagree on factors and points and be collaborative others
disagree frequently and have done productive work cordially for years
under the BIP process.
About scaling again:
Here is what I said before in my TL;DR post about my thoughts on how
we would start on throughput short-term to have space to do layer2
development.
> I think almost everybody is on board with a combination plan:
>
> 1. work to improve decentralisation (specific technical work already
> underway, and education)
> 2. create a plan to increase block-size in a slow fashion to not cause
> system shocks (eg like Jeff is proposing or some better variant)
> 3. work on actual algorithmic scaling
>
> In this way we can have throughput needed for scalability and security
> work to continue.
>
> As I said you can not scale a O(n^2) broadcast network by changing
> constants, you need algorithmic improvements.
>
> People are working on them already. All of those 3 things are being
> actively worked on right now, and in the case of algorithmic scaling
> and improve decentralisation have been worked on for months.
Btw I wonder if Gavin or Mike would be willing to answer another
question I forgot from my TL;DR post which was:
- Did you accept payment from companies to lobby for 20MB blocks? Do
you consider that something appropriate to publicly disclose if so?
Do you consider that user rights should come above or below company
interests in Bitcoin?
FWIW on pondering that last question "should user rights come above or
below company interests" I think my view of the guiding principle is
starkly clear to me: that user rights should be the primary thing to
optimise for. Businesses are providing service to users, their
interests are secondary in so far as if they are enabled to provide
better service thats good.
Bitcoin is a user p2p currency, with a social contract and a strong
user ethos. Importing and forcing company interests would likely be
the start of a slippery slope towards an end to Bitcoin. If we allow
business rights to be paramount it seems likely that we will end back
at the status quo as bitcoin payment processors grow, conglomerate and
become paypal/bank like or actual banks and then their interests and
exposures are the same as the banks and they'll want to import their
business models into Bitcoin and erode the user ethos features that
are actually what gives Bitcoin any meaning and value in the majority.
That wont be good for the companies either, but they may not see that
until they've killed it, many companies operate on a1 or 2 year
time-horizon. They may say screw layer2, I have a runway and I need
micropayments to the wazoo and I dont have the dev resources for that.
Thats a conflict and the resolution isn't to override bitcoin's
meaning, but rather that they should do it at layer2 (eg changeTip
does this.. simple trustme layer2 which is OK given the amounts). The
world needs a neutral social contract enforcing layer1. Layer1 must
be neutral and free from policy and dispute resolution otherwise
dispute resolution costs are imported and you lose viral open
innovation growth vector the internet benefitted from. Jurisdiction
and regulation related things belong at the interfaces and at the
payment protocol layer in my view. (If thats not obvious to some
lurkers I elaborate on that argument amongst other things here:
https://www.youtube.com/watch?v=3dAdI3Gzodo )
Adam
ps the O(n^2) misunderstanding of varying assumptions was explored at
length on reddit
http://www.reddit.com/r/Bitcoin/comments/3a5f1v/mike_hearn_on_those_who_want_all_scaling_to_be/csboslb
if people are interested in that topic. I do not think O( t*n ) is a
useful metric because its predictive but only of the obvious and
internal, the useful predictive thing is resources vs users (for
nodes/users or whole-system).
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
2015-06-19 10:45 ` Dr Adam Back
@ 2015-06-19 11:35 ` Bryan Bishop
2015-06-19 12:02 ` Eric Lombrozo
` (3 subsequent siblings)
4 siblings, 0 replies; 10+ messages in thread
From: Bryan Bishop @ 2015-06-19 11:35 UTC (permalink / raw)
To: Dr Adam Back, Bryan Bishop; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 462 bytes --]
On Fri, Jun 19, 2015 at 5:45 AM, Dr Adam Back <adam@cypherspace•org> wrote:
> payment protocol layer in my view. (If thats not obvious to some
> lurkers I elaborate on that argument amongst other things here:
> https://www.youtube.com/watch?v=3dAdI3Gzodo )
>
Someone might find it more convenient to consume that in the form of text
instead:
http://diyhpl.us/wiki/transcripts/bitcoin-adam3us-fungibility-privacy/
- Bryan
http://heybryan.org/
1 512 203 0507
[-- Attachment #2: Type: text/html, Size: 1192 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
2015-06-19 10:45 ` Dr Adam Back
2015-06-19 11:35 ` Bryan Bishop
@ 2015-06-19 12:02 ` Eric Lombrozo
2015-06-19 12:48 ` Marcel Jamin
2015-06-19 12:02 ` Eric Lombrozo
` (2 subsequent siblings)
4 siblings, 1 reply; 10+ messages in thread
From: Eric Lombrozo @ 2015-06-19 12:02 UTC (permalink / raw)
To: Dr Adam Back; +Cc: Bitcoin Dev
[-- Attachment #1.1: Type: text/plain, Size: 1364 bytes --]
> On Jun 19, 2015, at 3:45 AM, Dr Adam Back <adam@cypherspace•org> wrote:
>
> That wont be good for the companies either, but they may not see that
> until they've killed it, many companies operate on a1 or 2 year
> time-horizon. They may say screw layer2, I have a runway and I need
> micropayments to the wazoo and I dont have the dev resources for that.
Exactly, Adam.
Except, I think the genie is out of the bottle - these ideas are too powerful for them to be killed forever. They will probably survive even if this scenario comes to pass…but in a different network under a different name…and Bitcoin will be relegated to the history books and walls of museums.
Most of the potential brainpower available on this Earth to make serious, profound contributions to this movement haven’t even begun to touch it. Just because you happen to run a Bitcoin startup right now…even if you’ve received millions of dollars in funding…don’t think that the whole world has low standards and is lazy! Someone WILL eventually build something better than we can presently imagine.
First mover advantage and the network effect are vastly overrated. At the risk of stating cliches, the Mac came before the Windows PC…Yahoo! came before Google…MySpace came before Facebook…Bitcoin came before <we don’t know yet>.
- Eric Lombrozo
[-- Attachment #1.2: Type: text/html, Size: 4530 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
2015-06-19 10:45 ` Dr Adam Back
2015-06-19 11:35 ` Bryan Bishop
2015-06-19 12:02 ` Eric Lombrozo
@ 2015-06-19 12:02 ` Eric Lombrozo
2015-06-19 13:43 ` Mike Hearn
2015-06-19 16:05 ` Milly Bitcoin
4 siblings, 0 replies; 10+ messages in thread
From: Eric Lombrozo @ 2015-06-19 12:02 UTC (permalink / raw)
To: Dr Adam Back; +Cc: Bitcoin Dev
[-- Attachment #1.1: Type: text/plain, Size: 1394 bytes --]
> On Jun 19, 2015, at 3:45 AM, Dr Adam Back <adam@cypherspace•org <mailto:adam@cypherspace•org>> wrote:
>
> That wont be good for the companies either, but they may not see that
> until they've killed it, many companies operate on a1 or 2 year
> time-horizon. They may say screw layer2, I have a runway and I need
> micropayments to the wazoo and I dont have the dev resources for that.
Exactly, Adam.
Except, I think the genie is out of the bottle - these ideas are too powerful for them to be killed forever. They will probably survive even if this scenario comes to pass…but in a different network under a different name…and Bitcoin will be relegated to the history books and walls of museums.
Most of the potential brainpower available on this Earth to make serious, profound contributions to this movement haven’t even begun to touch it. Just because you happen to run a Bitcoin startup right now…even if you’ve received millions of dollars in funding…don’t think that the whole world has low standards and is lazy! Someone WILL eventually build something better than we can presently imagine.
First mover advantage and the network effect are vastly overrated. At the risk of stating cliches, the Mac came before the Windows PC…Yahoo! came before Google…MySpace came before Facebook…Bitcoin came before <we don’t know yet>.
- Eric Lombrozo
[-- Attachment #1.2: Type: text/html, Size: 4596 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
2015-06-19 12:02 ` Eric Lombrozo
@ 2015-06-19 12:48 ` Marcel Jamin
2015-06-19 12:49 ` Eric Lombrozo
0 siblings, 1 reply; 10+ messages in thread
From: Marcel Jamin @ 2015-06-19 12:48 UTC (permalink / raw)
To: Eric Lombrozo; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]
> At the risk of stating cliches, the Mac came before the Windows PC…Yahoo!
came before Google…MySpace came before Facebook…
And TCP/IP came before... oh wait...
2015-06-19 14:02 GMT+02:00 Eric Lombrozo <elombrozo@gmail•com>:
>
> On Jun 19, 2015, at 3:45 AM, Dr Adam Back <adam@cypherspace•org> wrote:
>
> That wont be good for the companies either, but they may not see that
> until they've killed it, many companies operate on a1 or 2 year
> time-horizon. They may say screw layer2, I have a runway and I need
> micropayments to the wazoo and I dont have the dev resources for that.
>
>
> Exactly, Adam.
>
> Except, I think the genie is out of the bottle - these ideas are too
> powerful for them to be killed forever. They will probably survive even if
> this scenario comes to pass…but in a different network under a different
> name…and Bitcoin will be relegated to the history books and walls of
> museums.
>
> Most of the potential brainpower available on this Earth to make serious,
> profound contributions to this movement haven’t even begun to touch it.
> Just because you happen to run a Bitcoin startup right now…even if you’ve
> received millions of dollars in funding…don’t think that the whole world
> has low standards and is lazy! Someone WILL eventually build something
> better than we can presently imagine.
>
> First mover advantage and the network effect are vastly overrated. At the
> risk of stating cliches, the Mac came before the Windows PC…Yahoo! came
> before Google…MySpace came before Facebook…Bitcoin came before <we don’t
> know yet>.
>
>
> - Eric Lombrozo
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 4718 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
2015-06-19 12:48 ` Marcel Jamin
@ 2015-06-19 12:49 ` Eric Lombrozo
0 siblings, 0 replies; 10+ messages in thread
From: Eric Lombrozo @ 2015-06-19 12:49 UTC (permalink / raw)
To: Marcel Jamin; +Cc: Bitcoin Dev
[-- Attachment #1.1: Type: text/plain, Size: 2255 bytes --]
IPv4 came before IPv6…you pick up on things quickly :)
> On Jun 19, 2015, at 5:48 AM, Marcel Jamin <marcel@jamin•net> wrote:
>
> > At the risk of stating cliches, the Mac came before the Windows PC…Yahoo! came before Google…MySpace came before Facebook…
>
> And TCP/IP came before... oh wait...
>
> 2015-06-19 14:02 GMT+02:00 Eric Lombrozo <elombrozo@gmail•com <mailto:elombrozo@gmail•com>>:
>
>> On Jun 19, 2015, at 3:45 AM, Dr Adam Back <adam@cypherspace•org <mailto:adam@cypherspace•org>> wrote:
>>
>> That wont be good for the companies either, but they may not see that
>> until they've killed it, many companies operate on a1 or 2 year
>> time-horizon. They may say screw layer2, I have a runway and I need
>> micropayments to the wazoo and I dont have the dev resources for that.
>
> Exactly, Adam.
>
> Except, I think the genie is out of the bottle - these ideas are too powerful for them to be killed forever. They will probably survive even if this scenario comes to pass…but in a different network under a different name…and Bitcoin will be relegated to the history books and walls of museums.
>
> Most of the potential brainpower available on this Earth to make serious, profound contributions to this movement haven’t even begun to touch it. Just because you happen to run a Bitcoin startup right now…even if you’ve received millions of dollars in funding…don’t think that the whole world has low standards and is lazy! Someone WILL eventually build something better than we can presently imagine.
>
> First mover advantage and the network effect are vastly overrated. At the risk of stating cliches, the Mac came before the Windows PC…Yahoo! came before Google…MySpace came before Facebook…Bitcoin came before <we don’t know yet>.
>
>
> - Eric Lombrozo
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net <mailto:Bitcoin-development@lists•sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>
>
[-- Attachment #1.2: Type: text/html, Size: 5775 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
2015-06-19 10:45 ` Dr Adam Back
` (2 preceding siblings ...)
2015-06-19 12:02 ` Eric Lombrozo
@ 2015-06-19 13:43 ` Mike Hearn
2015-06-20 2:59 ` Tom Harding
2015-06-19 16:05 ` Milly Bitcoin
4 siblings, 1 reply; 10+ messages in thread
From: Mike Hearn @ 2015-06-19 13:43 UTC (permalink / raw)
To: Dr Adam Back; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 5589 bytes --]
Hi Adam,
I am still confused about whether you actually support an increase in the
block size limit to happen right now. As you agree that this "layer 2" you
speak of doesn't exist yet, and won't within the next 10-12 months (do you
agree that actually?), can you please state clearly that you will support
Gavin's patch once posted? As Gavin's work takes some ideas from BIP100 but
does/soon will have some code associated with it.
But if we do no R&D on layer2, and insist that clients can never
> change to become layer2 aware, and layer2 is too hard etc
>
I think there's been some confusion here.
I, at least, have never argued that other systems can *never* happen. Never
is a long time, and I myself maintain a payment channels implementation.
These things have their place.
The argument is solely around the need to raise the block size *now* and
not allow the existing layer 1 to gum up and fall over.
If Stroem or Lightning or other block chains or Coinbase or secure hardware
tokens or whatever take off and people start moving bitcoins around that
way - fine. If they're choosing it of their own free will I have no issue
with that, nor does anyone else, I suspect.
However you don't seem fully confident that people actually will choose
whatever is being cooked up as "layer 2", if left to their own devices.
Indeed it's impossible for anyone to know that, as no "layer 2" actually
exists. Any such implementation could have all sorts of flaws that lead to
it not gaining traction.
> No offence but please find a way to gracefully stop and rejoin the
> constructive process. You can disagree on factors and points and be
> collaborative others disagree frequently and have done productive work
> cordially for years under the BIP process.
As you know from the discussion with myself and Gavin a few days ago on
IRC, neither of us believe any such constructive process exists. There is
another thread to discuss the lack of such a process.
> - Did you accept payment from companies to lobby for 20MB blocks?
Oh please. Conspiracy theories, now, Adam? My position has been consistent
for years. I don't care whether the figure is 20 or something else (looks
like it'll be lucky 8 instead), but I have always been clear that the limit
must rise.
But for the avoidance of doubt: the answer is no.
Gavin is paid by MIT. The MIT deal gives Gavin complete independence.
I am currently self employed and most of income comes from a client that is
actually interested in Lighthouse. Luckily they have given me some leeway
to do general Bitcoin development as well, which this business falls under.
I would *much* rather be working on Lighthouse than this, and so would they.
But seeing as you've gone there - let me flip this around. Blockstream has
a very serious conflict of interest in this situation. I am by no means the
first to observe this. You are building two major products:
1. Sidechains, a very complex approach to avoid changing the Bitcoin
consensus rules to add new features.
2. Lightning, a so-called "layer two" system for transaction routing
No surprise, the position of Blockstream employees is that hard forks must
never happen and that everyone's ordinary transactions should go via some
new network that doesn't yet exist.
The problem is that rather than letting the market decide between ordinary
Bitcoin and Lightning, you are attempting to strangle the regular Bitcoin
protocol because you don't trust people to spontaneously realise that they
should be using your companies products.
I know that many of you guys had these views before joining Blockstream. I
am not saying you are being paid to have views you didn't previously have.
I realise that birds of a feather flock together.
Regardless, that conflict of interest DOES exist, whether you like it or
not, because if you succeed in running Bitcoin out of capacity your own
company stands to benefit from selling consulting and services around your
preferred solutions.
With respect to user rights: all the polling done so far suggests users who
are paying attention strongly support increasing the block size. For
example:
Q: "Should the bitcoin block size be raised in the next two years"
A: 92% yes
http://www.poll-maker.com/results329839xee274Cb0-12#tab-2
Additionally, many Bitcoin users have explicitly delegated handling the
technical details to someone else, like a payment processor or their wallet
developers. Those people are nearly all sure that the block size limit
should rise too.
So please don't engage in idle speculation about "users vs companies". They
aren't some kind of opposing forces. Companies live for their users, and
many of those companies were formed by long time Bitcoin users.
And finally, the Bitcoin social contract is not defined by whatever random
state the code was in at the time Gavin decided to focus on research. Both
Gavin and I have been working on Bitcoin longer than you, Gregory or Peter
Todd. The social contract was and still is defined by the project's
founding vision - written down in words.
Heck, if Satoshi had spent another hour or two on his original size limiter
patch this entire dispute would never have happened. He'd have put in some
kind of automatic timeout or limit riser because the plan was to remove it
all along, and then it'd be you guys arguing for putting a limit in place,
Gavin would object, it'd be controversial and nothing would happen. But
Satoshi never anticipated this bizarre attempt to turn the project into
something else and so figured he'd just remove it himself later. Too bad.
[-- Attachment #2: Type: text/html, Size: 7071 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
2015-06-19 10:45 ` Dr Adam Back
` (3 preceding siblings ...)
2015-06-19 13:43 ` Mike Hearn
@ 2015-06-19 16:05 ` Milly Bitcoin
4 siblings, 0 replies; 10+ messages in thread
From: Milly Bitcoin @ 2015-06-19 16:05 UTC (permalink / raw)
To: bitcoin-development
>- Did you accept payment from companies to lobby for 20MB blocks? Do
you consider that something appropriate to publicly disclose if so? Do
you consider that user rights should come above or below company
interests in Bitcoin? FWIW on pondering that last question "should user
rights come above or below company interests" I think my view of the
guiding principle is starkly clear to me: that user rights should be the
primary thing to optimise for. Businesses are providing service to
users, their interests are secondary in so far as if they are enabled to
provide better service thats good. Bitcoin is a user p2p currency, with
a social contract and a strong user ethos. Importing and forcing company
interests would likely be the start of a slippery slope towards an end
to Bitcoin.
I always thought is was the exact opposite. I thought it was expected
that the only incentive for developers (other than increasing the value
of coins they hold) is to lobby for changes that will benefit the
companies that fund them. That is the only way you are going to get
more full time developers on board. It focuses their efforts on
products and services people want rather than some sort philosophical
agenda that may be unrealistic. The notion that large numbers of
volunteers will do all this work at little or no pay to improve user
experience is not a realistic long term plan. I also think it is
incorrect to assume some kind of "social contract" and "strong user
ethos." While many early users are like that I think most potential
users of Bitcoin don't think that way.
Russ
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
2015-06-19 13:43 ` Mike Hearn
@ 2015-06-20 2:59 ` Tom Harding
0 siblings, 0 replies; 10+ messages in thread
From: Tom Harding @ 2015-06-20 2:59 UTC (permalink / raw)
To: Mike Hearn; +Cc: bitcoin-development
On 6/19/2015 6:43 AM, Mike Hearn wrote:
> No surprise, the position of Blockstream employees is that hard forks
> must never happen and that everyone's ordinary transactions should go
> via some new network that doesn't yet exist.
If my company were working on spiffy new ideas that required a hard fork
to implement, I'd be rather dismayed to see the blocksize hard fork
happen *before those ideas were ready*.
Because then I'd eventually have to convince people that those ideas
were worth a hard fork all on their own. It would be much easier to
convince people to roll them in with the already necessary blocksize
hard fork, if that event could be delayed.
As far as I know, Blockstream representatives have never said that
waiting for other changes to be ready is a reason to delay the blocksize
hard fork. So if this were the real reason, it would suggest they have
been hiding their true motives for making such a fuss about the
blocksize issue.
I've got no evidence at all to support thoughts like this... just the
paranoid mindset that seems to infect a person who gets involved in
bitcoin. But the question is every bit as valid as Adam's query into
your motives.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-06-20 2:59 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-19 9:22 [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers Dr Adam Back
2015-06-19 10:45 ` Dr Adam Back
2015-06-19 11:35 ` Bryan Bishop
2015-06-19 12:02 ` Eric Lombrozo
2015-06-19 12:48 ` Marcel Jamin
2015-06-19 12:49 ` Eric Lombrozo
2015-06-19 12:02 ` Eric Lombrozo
2015-06-19 13:43 ` Mike Hearn
2015-06-20 2:59 ` Tom Harding
2015-06-19 16:05 ` Milly Bitcoin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox