From: Adam Back <adam@cypherspace•org>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis
Date: Fri, 24 Jul 2015 07:09:13 -0700 [thread overview]
Message-ID: <CALqxMTFWfvc7LL5UgOMNnzNCxwbgyGRXgdV7wt1LYGGZ9h4XWw@mail.gmail.com> (raw)
In-Reply-To: <CA+w+GKS91NWB9ffysD4qEvAm+r1PswMePq6dirshbcZzpFg6Cg@mail.gmail.com>
(Claim of large bitcoin ecosystem companies without full nodes) this
says to me rather we have a need for education: I run a full node
myself (intermittently), just for my puny collection of bitcoins. If
I ran a business with custody of client funds I'd wake up in a cold
sweat at night about the security and integrity of the companies full
nodes, and reconciliation of client funds against them.
However I'm not sure the claim is accurate ($30m funding and no full
node) but to take the hypothetical that this pattern exists, security
people and architects at such companies must insist on the company
running their own full node to depend on and cross check from
otherwise they would be needlessly putting their client's funds at
risk.
The crypto currency security standards document probably covers
requirement for fullnode somewhere
https://cryptoconsortium.github.io/CCSS/ - we need some kind of basic
minimum bar standard for companies to aim for and this seems like a
reasonable start!
Reducing custody in my opinion should also be an aim eg 2 of 2
multisig + timelock seems like a more prudent approach, transaction
throughput permitting. Right now exchange volume wouldnt fit on
chain, once bitcoin scaling has improved, perhaps it can. I am
optimistic that within a year Bitcoin scaling and decentralisation
will look much better with current active work on decentralisation,
layer 2 scaling solutions. As part of that I could see a modest
blocksize increase to smooth out the transition to layer 2.
In terms of a constructive discussion, I think it's interesting to
talk about the root cause and solutions: decentralisation (more
economically dependent full nodes, lower miner policy centralisation),
more layer 2 work. People interested in scaling, if they havent,
should go read the lightning paper, look at the github and participate
in protocol or code work. I think realistically we can have this
running inside of a year. That significantly changes the dynamic.
Similarly a significant part of mining centralisation is artificial
and work is underway that will improve that.
What I mean about decentralisation is if decentralisation simple
metrics were in a healthy place, it would be a simple conversation to
make use of bandwidth improvements (in the range of 15%/year per Cisco
numbers) to get more throughput. I do think flexcap is interesting as
a way to add one more control variable such that we can have
economically validated scaling. Pushing fees to zero and increasing
centralisation to levels that weaken security with economically weak
payments is probably not desirable. Without flexcap it seems the next
best thing we can do is rely on miners to balance user utility against
mining revenue, and it seems plausible that they would in extremis but
to my mind there are factors suggesting this could be problematic
incrementally: miners have not often been responsive to editing
defaults, or reacting to security or soft-fork upgrades; miners may
have some conflict of interest of users, eg they could use switching
cost economics to optimise for miner profit at the expense of user
utility, or attack each other in selfish-miner or other variants as
miners are also pitted against each other while being held honest by
economically dependent full nodes.
Adam
next prev parent reply other threads:[~2015-07-24 14:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-24 2:57 Dave Scotese
2015-07-24 3:37 ` Slurms MacKenzie
2015-07-24 11:38 ` Mike Hearn
2015-07-24 14:09 ` Adam Back [this message]
2015-07-24 15:22 ` Simon Liu
2015-07-24 17:40 ` Peter Todd
2015-07-24 20:28 ` Eric Lombrozo
2015-07-24 20:31 ` Eric Lombrozo
2015-07-24 15:08 ` Dave Scotese
2015-07-24 13:39 ` Thomas Zander
2015-07-24 17:43 ` Peter Todd
2015-07-24 20:23 ` Eric Lombrozo
2015-07-24 21:12 ` Slurms MacKenzie
2015-07-24 15:40 ` Milly Bitcoin
2015-07-25 2:23 Dave Scotese
2015-07-25 11:19 ` Slurms MacKenzie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALqxMTFWfvc7LL5UgOMNnzNCxwbgyGRXgdV7wt1LYGGZ9h4XWw@mail.gmail.com \
--to=adam@cypherspace$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox