Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis
16 messages, 24 to 25 Jul 2015. Started by Dave Scotese.
Dave Scotese (3), Slurms MacKenzie (3), Eric Lombrozo (3), Peter Todd (2), Mike Hearn, Thomas Zander, Adam Back, Simon Liu, +1 more
I used Google to establish that there is not already a post from 2015 that mentions "roadmap" in the subject line. Such would be a good skeleton for anyone new to the list (like me).
1. Increase the 7 Tx per second - by increasing block size.
2. Do something about the trend toward centralization. This is really two issues in my mind: A) Mining is falling to an ever shrinking number of businesses with the infrastructure to run a datacenter. B) The protocol as it is will soon make common computing machines inadequate for running full nodes, and as a result they will not be able to contribute to the ecosystem in meaningful ways.
Feel free to copy and then remove or alter any of that.
It's worth noting that even massive companies with $30M USD of funding don't run a single Bitcoin Core node, which is somewhat against the general concept people present of companies having an incentive to run their own to protect their own wallet.
Quoted text (6 lines)
> Sent: Friday, July 24, 2015 at 4:57 AM > From: "Dave Scotese via bitcoin-dev" <bitcoin-dev@lists•linuxfoundation•org> > To: bitcoin-dev@lists•linuxfoundation•org > Subject: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis > > B) The protocol as it is will soon make common computing machines inadequate for running full nodes, and as a result they will not be able to contribute to the ecosystem in meaningful ways.
Quoted text (3 lines)
> > It's worth noting that even massive companies with $30M USD of funding > don't run a single Bitcoin Core node
This has nothing to do with block sizes, and everything to do with Core not directly providing the services businesses actually want.
The whole "node count is falling because of block sizes" is nothing more than conjecture presented as fact. The existence of multiple companies who could easily afford to do this but don't because they perceive it as valueless should be a wakeup call there.
On Friday 24. July 2015 05.37.30 Slurms MacKenzie via bitcoin-dev wrote:
Quoted text (2 lines)
> It's worth noting that even massive companies with $30M USD of funding don't > run a single Bitcoin Core node,
I assume you mean that they don't have a Bitcoin Core node that is open to incoming connections. Since that is the only thing you can actually test, no?
Most companies are still terrified of accepting incoming connections from the scary Internet. So I'm not entirely surprised by this conclusion. I would be very surprised if companies don't actually have a node at all.
(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
On Fri, Jul 24, 2015 at 4:38 AM, Mike Hearn <hearn@vinumeris•com> wrote:
Quoted text (12 lines)
> It's worth noting that even massive companies with $30M USD of funding >> don't run a single Bitcoin Core node > > > This has nothing to do with block sizes, and everything to do with Core > not directly providing the services businesses actually want. > > The whole "node count is falling because of block sizes" is nothing more > than conjecture presented as fact. The existence of multiple companies who > could easily afford to do this but don't because they perceive it as > valueless should be a wakeup call there. >
Regardless of why node count is falling, many people who used to run a full node stopped doing so. To mitigate that, their chances of getting something out of it have to be greater. What if propagating a valid transaction generated a small chance of earning a piece of the fee?
Would a 1MB increase to 2MB, as outlined in BIP 102, be considered a "modest" increase?
On 07/24/2015 07:09 AM, Adam Back via bitcoin-dev wrote:
Quoted text (5 lines)
> 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.
On 7/23/2015 10:57 PM, Dave Scotese via bitcoin-dev wrote:
Quoted text (3 lines)
> I used Google to establish that there is not already a post from 2015 > that mentions "roadmap" in the subject line. Such would be a good > skeleton for anyone new to the list (like me).
Just a point about terminology:
Roadmap - A plan of proposed changed used to meet some sort of goal. If the goal is increased scaling then you list a series of changes that need to be done to achieve that goal.
Baseline - That is the "If We Do Nothing" Analysis. Each proposed change will generally have one or more alternatives which are compared to the "baseline."
those would be 2 different documents.
Russ
On Fri, Jul 24, 2015 at 07:09:13AM -0700, Adam Back via bitcoin-dev wrote:
Quoted text (13 lines)
> (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.
FWIW, blockchain.info is obviously *not* running a full node as their wallet was accepting invalid confirmations on transactions caused by the recent BIP66 related fork; blockchain.info has $30m in funding.
Coinbase also was not running a full node not all that long ago, instead running a custom Ruby implementation that caused their service to go down whenever it forked. (and would have also accepted invalid confirmations) I believe right now they're running that implementation behind a full node however.
Quoted text (5 lines)
> 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!
Actually I've been trying to get the CCSS standard to cover full nodes, and have been getting push-back:
https://github.com/CryptoConsortium/CCSS/issues/15
tl;dr: Running a full node is *not* required by the standard right now at any certification level.
This is of course completely ridiculous... But I haven't had much much time to put into getting that changed so maybe we just need some better explanations to the others maintaining the standard. That said, if the standard stays that way, obviously I'm going to have to ask to have my name taken off it.
Quoted text (9 lines)
> 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.
I would point out that lack of understanding of how Bitcoin works, as well as a lack of understanding of security engineering in general, is probably a significant contributor to these problems. Furthermore Bitcoin and cryptocurrencies in general are still small enough that many forseeable low probability but high impact events haven't happened, making it difficult to explain to non-technical stakeholders why they should be listening to experts rather than charlatans and fools.
After a few major centralization related failures have occured, we'll have an easier job here. Unfortunately there's also a good chance we only get one shot at this due to how easy it is to kill PoW systems at birth...
On Fri, Jul 24, 2015 at 03:39:08PM +0200, Thomas Zander via bitcoin-dev wrote:
Quoted text (6 lines)
> On Friday 24. July 2015 05.37.30 Slurms MacKenzie via bitcoin-dev wrote: > > It's worth noting that even massive companies with $30M USD of funding don't > > run a single Bitcoin Core node, > > I assume you mean that they don't have a Bitcoin Core node that is open to > incoming connections. Since that is the only thing you can actually test, no?
We can test the fact that blockchain.info's wallet and block explorer has behaved in a way consistent with not running a full node - they have shown invalid data that any full node would reject on multiple occasions, most recently invalid confirmations during the BIP66 fork.
Thanks for bringing up the CCSS, Adam and Peter.
I was actually working on a post inviting everyone in this mailing list to come and participate…but you guys beat me to it. :)
The CCSS is an open standard, born out of the belief that sharing the industry's best practices amongst each other and with the community at large benefits everyone.
To read more about it and how you can contribute, please visit http://blog.cryptoconsortium.org/contributing-to-the-ccss/ <http://blog.cryptoconsortium.org/contributing-to-the-ccss/>
The standard: https://cryptoconsortium.github.io/CCSS/ <https://cryptoconsortium.github.io/CCSS/>
The github repository: https://github.com/CryptoConsortium/CCSS <https://github.com/CryptoConsortium/CCSS>
- Eric
Quoted text (22 lines)
> On Jul 24, 2015, at 10:43 AM, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote: > > On Fri, Jul 24, 2015 at 03:39:08PM +0200, Thomas Zander via bitcoin-dev wrote: >> On Friday 24. July 2015 05.37.30 Slurms MacKenzie via bitcoin-dev wrote: >>> It's worth noting that even massive companies with $30M USD of funding don't >>> run a single Bitcoin Core node, >> >> I assume you mean that they don't have a Bitcoin Core node that is open to >> incoming connections. Since that is the only thing you can actually test, no? > > We can test the fact that blockchain.info's wallet and block explorer > has behaved in a way consistent with not running a full node - they have > shown invalid data that any full node would reject on multiple > occasions, most recently invalid confirmations during the BIP66 fork. > > -- > 'peter'[:-1]@petertodd.org > 000000000000000006baf20e289b563e3ec69320275086169a47e9c58d4abfba > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Quoted text (46 lines)
> On Jul 24, 2015, at 10:40 AM, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote: > > On Fri, Jul 24, 2015 at 07:09:13AM -0700, Adam Back via bitcoin-dev wrote: >> (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. > > FWIW, blockchain.info is obviously *not* running a full node as their > wallet was accepting invalid confirmations on transactions caused by the > recent BIP66 related fork; blockchain.info has $30m in funding. > > Coinbase also was not running a full node not all that long ago, instead > running a custom Ruby implementation that caused their service to go > down whenever it forked. (and would have also accepted invalid > confirmations) I believe right now they're running that implementation > behind a full node however. > >> 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! > > Actually I've been trying to get the CCSS standard to cover full nodes, > and have been getting push-back: > > https://github.com/CryptoConsortium/CCSS/issues/15 > > tl;dr: Running a full node is *not* required by the standard right now > at any certification level. > > This is of course completely ridiculous... But I haven't had much much > time to put into getting that changed so maybe we just need some better > explanations to the others maintaining the standard. That said, if the > standard stays that way, obviously I'm going to have to ask to have my > name taken off it.
For the record, there’s pretty much unanimous agreement that running a full node should be a requirement at the higher levels of certification (if not the lower ones as well). I’m not sure exactly what pushback you’re referring to.
Quoted text (30 lines)
>> 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. > > I would point out that lack of understanding of how Bitcoin works, as > well as a lack of understanding of security engineering in general, is > probably a significant contributor to these problems. Furthermore > Bitcoin and cryptocurrencies in general are still small enough that many > forseeable low probability but high impact events haven't happened, > making it difficult to explain to non-technical stakeholders why they > should be listening to experts rather than charlatans and fools. > > After a few major centralization related failures have occured, we'll > have an easier job here. Unfortunately there's also a good chance we > only get one shot at this due to how easy it is to kill PoW systems at > birth... > > -- > 'peter'[:-1]@petertodd.org > 000000000000000014438a428adfcf4d113a09b87e4a552a1608269ff137ef2d > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Peter, it’s a work in evolution, it’s not complete yet. It’s still missing a bunch of stuff - please feel free to contribute.
Quoted text (83 lines)
> On Jul 24, 2015, at 1:28 PM, Eric Lombrozo <elombrozo@gmail•com> wrote: > >> >> On Jul 24, 2015, at 10:40 AM, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote: >> >> On Fri, Jul 24, 2015 at 07:09:13AM -0700, Adam Back via bitcoin-dev wrote: >>> (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. >> >> FWIW, blockchain.info is obviously *not* running a full node as their >> wallet was accepting invalid confirmations on transactions caused by the >> recent BIP66 related fork; blockchain.info has $30m in funding. >> >> Coinbase also was not running a full node not all that long ago, instead >> running a custom Ruby implementation that caused their service to go >> down whenever it forked. (and would have also accepted invalid >> confirmations) I believe right now they're running that implementation >> behind a full node however. >> >>> 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! >> >> Actually I've been trying to get the CCSS standard to cover full nodes, >> and have been getting push-back: >> >> https://github.com/CryptoConsortium/CCSS/issues/15 >> >> tl;dr: Running a full node is *not* required by the standard right now >> at any certification level. >> >> This is of course completely ridiculous... But I haven't had much much >> time to put into getting that changed so maybe we just need some better >> explanations to the others maintaining the standard. That said, if the >> standard stays that way, obviously I'm going to have to ask to have my >> name taken off it. > > For the record, there’s pretty much unanimous agreement that running a full node should be a requirement at the higher levels of certification (if not the lower ones as well). I’m not sure exactly what pushback you’re referring to. > > >>> 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. >> >> I would point out that lack of understanding of how Bitcoin works, as >> well as a lack of understanding of security engineering in general, is >> probably a significant contributor to these problems. Furthermore >> Bitcoin and cryptocurrencies in general are still small enough that many >> forseeable low probability but high impact events haven't happened, >> making it difficult to explain to non-technical stakeholders why they >> should be listening to experts rather than charlatans and fools. >> >> After a few major centralization related failures have occured, we'll >> have an easier job here. Unfortunately there's also a good chance we >> only get one shot at this due to how easy it is to kill PoW systems at >> birth... >> >> -- >> 'peter'[:-1]@petertodd.org >> 000000000000000014438a428adfcf4d113a09b87e4a552a1608269ff137ef2d >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
They do not run anything but BitcoinJ (evidenced by them blindly following invalid chains), so no proper consensus checking going on here at all. Connected to my nodes is a bad peer (doesn’t relay inventory but downloads everything) from 37.187.136.15, with the user agent /BitcoinJ:0.12SNAPHOT/Satoshi:0.2.0/ which is owned by blockchain.info. You can also submit an invalid transaction through their /pushtx interface and get a mixture of noise and BitcoinJ error messages out of it as well.
If even the people who have to their claim hundreds of thousands of wallets are relying on their security don’t bother running even a single node to sanity check against, who are we really going to expect people to in the future if the load goes 8x, 16x, 32x higher? Like CoinBase and others, these are the companies which are claimed will be the ones supporting the network with ludicrous sized blocks because they have a financial incentive to.
Well, they don't even do it now when it could be achieved with a $5 VPS.
Quoted text (9 lines)
> Sent: Friday, July 24, 2015 at 8:43 PM > From: "Peter Todd via bitcoin-dev" <bitcoin-dev@lists•linuxfoundation•org> > To: "Thomas Zander" <thomas@thomaszander•se> > Cc: bitcoin-dev@lists•linuxfoundation•org > Subject: Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis > We can test the fact that blockchain.info's wallet and block explorer > has behaved in a way consistent with not running a full node - they have > shown invalid data that any full node would reject on multiple > occasions, most recently invalid confirmations during the BIP66 fork.
Incentivize investigations for public consumption. The people on this list are the ones who probably care the most.
When I looked up that IP address, the Whois info names "OVH" and "Octave Klaba" (who founded OVH, according to Wikipedia) as the owner. " blockchain.info" appears in the HTML header as retrieved by the "Anti-Hacker Alliance" ( http://anti-hacker-alliance.com/index.php?details=37.187.136.15). Blockchain.info itself returns IP addresses managed by CloudFlare whenever I try it.
On Fri, Jul 24, 2015 at 2:12 PM, Slurms MacKenzie via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (35 lines)
> They do not run anything but BitcoinJ (evidenced by them blindly following > invalid chains), so no proper consensus checking going on here at all. > Connected to my nodes is a bad peer (doesn’t relay inventory but downloads > everything) from 37.187.136.15, with the user agent > /BitcoinJ:0.12SNAPHOT/Satoshi:0.2.0/ which is owned by blockchain.info. > You can also submit an invalid transaction through their /pushtx interface > and get a mixture of noise and BitcoinJ error messages out of it as well. > > If even the people who have to their claim hundreds of thousands of > wallets are relying on their security don’t bother running even a single > node to sanity check against, who are we really going to expect people to > in the future if the load goes 8x, 16x, 32x higher? Like CoinBase and > others, these are the companies which are claimed will be the ones > supporting the network with ludicrous sized blocks because they have a > financial incentive to. > > Well, they don't even do it now when it could be achieved with a $5 VPS. > > > > Sent: Friday, July 24, 2015 at 8:43 PM > > From: "Peter Todd via bitcoin-dev" < > bitcoin-dev@lists•linuxfoundation•org> > > To: "Thomas Zander" <thomas@thomaszander•se> > > Cc: bitcoin-dev@lists•linuxfoundation•org > > Subject: Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" > Analysis > > We can test the fact that blockchain.info's wallet and block explorer > > has behaved in a way consistent with not running a full node - they have > > shown invalid data that any full node would reject on multiple > > occasions, most recently invalid confirmations during the BIP66 fork. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
The answer to that is a less illegal than probing other peoples web servers. Up until recently the reverse name lookup for that IP address was markets.blockchain.info, which I resolve when I log incoming connections in an attempt to filter out some abusive clients coming from university connections.
Other people have noticed these abusive clients too. There’s mentions of other connections running the same version of BitcoinJ coming from sources that appear to be blockchain.info which display similar behavior. A user in #bitcoin-dev was complaining about this client hammering closed ports with connections when they are kicked off.
http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/02/09#l1423513396.0
Quoted text (5 lines)
> Sent: Saturday, July 25, 2015 at 4:23 AM > From: "Dave Scotese via bitcoin-dev" <bitcoin-dev@lists•linuxfoundation•org> > To: bitcoin-dev@lists•linuxfoundation•org > Subject: Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis > When I looked up that IP address, the Whois info names "OVH" and "Octave Klaba" (who founded OVH, according to Wikipedia) as the owner. "blockchain.info[http://blockchain.info]" appears in the HTML header as retrieved by the "Anti-Hacker Alliance" (http://anti-hacker-alliance.com/index.php?details=37.187.136.15[http://anti-hacker-alliance.com/index.php?details=37.187.136.15]). Blockchain.info itself returns IP addresses managed by CloudFlare whenever I try it.