What is Plan B if just trusting miners/merchants/users to do the right thing doesn't work?
Big-picture it is easy: Schedule a soft-fork that imposes some network-rule-upper-limit, with whatever formula seems right to correct whatever problem crops up.
Small-picture: hard to see what the "right" formula would be, but I think it will be much easier to define after we run into some actual practical problem rather than guessing where problems might crop up.
Your "plan" reminds me of an old joke about the difference between programmers and engineers: A mechanical engineer, an electrical engineer and a computer programmer were on their way to a meeting in Switzerland. They had just passed the crest of a high mountain pass when suddenly the brakes on their car failed. The car careened almost out of control down the road, bouncing off the crash barriers, until it miraculously ground to a halt scraping along the guardrail.
The car's occupants, shaken but unhurt, now had a problem: they were still stuck at the top of a mountain in a car with no brakes. What were they to do?
"I know," said the mechanical manager, "Let's check under the car for leaks - chances are a hydraulic line burst."
"No, no," said the electrical engineer, "This is a new car with sensors everywhere - let me hook up my multimeter to the hydraulic line pressure sensor output and see if it reads low first."
"Well," said the programmer, "Before we do anything, I think we should push the car back up the road and see if it happens again."
|
|
|
|
|
I changed my timestamper to set nLockTime on every transaction it creates to the current block height. Every 10 minutes it checks if any timestamps are pending, and if so, creates a timestamp transaction; from the point of view of block creation the timestamps are created randomly. I also changed it to randomly set the fees between 2 and 5mBTC for each timestamp, which works out to a range of 5mBTC/KB to 12.5mBTC/KB.
Note that I have not changed the sequence numbers from MAXINT, so the nLockTime thing is informational only and won't affect propagation.
I seem to be getting a dozen timestamp requests per day at what appear to be random intervals, and I added some temporary code to create some additional dummy ones. Over time it could be an interesting data source, albeit one with an unusual transaction form.
54e243ffb097f5b6acd6ea4a55925fddba4078ca750b4aef4142b837ffdff2b8 is an example transaction; they all have 13MH4zmU4UT4Ct6BhoRFGjigC8gN9a9FNn as the first multisig address. (the second is the tip of the merkle tree of submitted digests to be timestamped)
|
|
|
|
I think this shows great consideration and judgement because I note and emphasize the following: 100% of the last 1000 blocks is a straw-man; the actual criteria would probably be different ... since this change means the first valid greater-than-MAX_BLOCK_SIZE-block immediately kicks anybody running old software off the main block chain.
What I think is of greatest value in Gavin's quote is that it's inclusive of data from the field. It's not him unilaterally saying the new size will be X, deal with it. Instead he essentially says the new size can be X if Y and Z are also true. It appears he has a regard for the ability of the market to decide. Indeed no change remains an option and is actually the default. Think through this voting proposal carefully: can you think of a way to game the vote? I completely disagree. Think how easily this issue could have been solved if in 2009 Satoshi implemented a rule such as Jeff suggests here: My off-the-cuff guess (may be wrong) for a solution was: if (todays_date > SOME_FUTURE_DATE) { MAX_BLOCK_SIZE *= 2, every 1 years } [Other devs comment: too fast!] That might be too fast, but the point is, not feedback based nor directly miner controlled.
I think the above could be a great solution (though I tend to agree it might be too fast). However, implementing it now will meet resistance from someone feeling it misses their views. If Satoshi had implemented it then it wouldn't be an issue now. We would simply be dealing with it and the market working around it. Now however there is a lot of money tied up in protocol changes and many more views about what should or shouldn't be done. That will only increase, meaning the economic/financial damage possible from ungraceful changes increases as well. There was some heated IRC discussion on this point - gmaxwell made the excellent comment that any type of exponentially increasing blocksize function runs into the enormous risk that the constant is either too large, and the blocksize blows up, or too small, and you need the off-chain transactions it was supposed to avoid anyway. There is very little room for error, yet changing it later if you get it wrong is impossible due to centralization. I also note early in Jeff's post he says he reversed his earlier stance, my point here being people are not infallible. I actually agree with his updated views, but what if they too are wrong? Who is to say? So the same could apply to Gavin. That's why I think it's wise he appears to include a response from the market in any change, and no change is the default.
Same here. I read Satoshi's predictions about achieving scalability through large blocks about two years ago, and simply accepted it as inevitable and ok. It was only much, much later, that I thought about the issue carefully and realized how dangerous the implications would be to Bitcoin's decentralization. I am already concerned about the centralization seen in mining. Only a handful of pools are mining most of the blocks, so decentralization is already being lost there. Work is needed in two areas before the argument for off-chain solutions becomes strong: first blockchain pruning, secondly, initial propagation of headers (presumably with associated utxo) so that hashing can begin immediately while the last block is propagated and its verification done in parallel. These would help greatly to preserve decentralization.
(snip)
You mention your background in passing, so I will just mention mine. I spent many years at the heart of one of the largest TBTF banks working on its equities proprietary trading system. For a while 1% of the shares traded globally (by value) was our execution flow. On average every three months we encountered limitations of one sort or another (software, hardware, network, satellite systems), yet every one of them was solved by scaling, rewriting or upgrading. We could not stand still as the never-ending arms race for market-share meant that to accept a limitation was to throw in the towel.
It's good that you have had experience with such environments, but remember that centrally run systems, even if the architecture itself is distributed, are far, far easier to manage than truly decentralized systems. When your decentralized system must be resistant to attack, the problem is even worse. As an example, consider your (and Mike's) proposal to propagate headers and/or transaction hash information, rather than full transactions. Can you think of a way to attack such a system? Can you think of a way that such a system could make network forking events more likely? I'll give you a hint for the latter: reorganizations. It's my impression that the 2009 Satoshi implementation didn't have a block size limit - that it was a later addition to the reference client as a temporary anti-spam measure, which was left in until it became the norm.
Is this impression incorrect?
Bitcoin began with a 32MiB blocksize limit, which was reduced to 1MB later by Satoshi. |
|
|
|
+1 to the private UDP broadcast idea.
Further, there has been talk off and on (by myself, and others) about a "backbone network" where Big Players privately and directly interconnect, for reasons similar to this.
I'd also suggest Tor hidden services, and using private hidden service URLs that are different for each partner. The URL's don't give any information about the network topology, and if any individual URL is compromised and DoS attacked the individual URL can easily be taken down. Even URL's for individual high-volume traders would be feasible, although, keep in mind I'm no Tor expert so someone who knows more should weigh in before doing this. In particular what the Tor developers think of the attention and attacks it may attract. In some cases using Amazon's infrastructure could work too. Amazon Simple Notification Service is essentially a DoS-resistant broadcast medium. Of course, it's central infrastructure, so not appropriate for every use, but there is a lot of public information like price tickers that could use it. In any case information should be distributed though multiple methods. Regardless of what is done, an important first step is to sign and timestamp all public information broadcasts so that regardless of where you got the data, you can verify it as being genuine; the current API does not appear to authenticate pricing information other than via https. |
|
|
|
Of course that services have a strong interest in staying on the branch that's more professionally supported by developers, so yeah, if most of the core team goes to one side, we could predict most of these services would too.
FWIW currently the majority of the core team members, Gregory Maxwell, Jeff Garzik and Pieter Wuille, have all stated they are against increasing the blocksize as the solution to the scalability problem. Each has different opinions and degrees of course on exactly what that position constitutes, but ultimately all of them believe off-chain transactions need to be the primary way to make Bitcoin scale. EDIT: to be clear no-one, including myself, thinks the blocksize must never change. Rather achieve scalability first through off-chain transactions, and only then do you consider increasing the limit. I made a rough guess myself that it may make sense to raise the blocksize at a market cap of around 1 trillion - still far off in the future. Fees in this scenario would be something like $5 per transaction, or $1billion/year of proof of work security. (not including the inflation subsidy) That's low enough to be affordable for things like payroll, and is still a lot cheaper than international wire transfers. Hopefully at that point Bitcoin will need less security against takedowns by authority, and/or technological improvements make it easier to run nodes. As far as I know Wladimir J. van der Laan and Nils Schneider haven't stated an opinion, leaving Gavin Andresen. I think Jeff Garzik's post on the issue is apropos, particularly his last point: That was more than I intended to type, about block size. It seems more like The Question Of The Moment on the web, than a real engineering need. Just The Thing people are talking about right now, and largely much ado about nothing.
The worst that can happen if the 1MB limit stays is growth gets slowed for awhile. In the grand scheme of things that's a manageable problem. |
|
|
|
I have no idea if that is technically possible, but could a lightweight bitcoin client be integrated in a mastercard chip?
Essentially yes, but they can do something far more interesting than just a client - Mastercard or Visa have the trust and knowhow required to make that smartcard chip guarantee that it will A: keep the private keys secure, and B: never double-spend. Thus allowing for very safe zero-confirmation transactions, provided they come from such a card. They can also go the next step beyond that, and make the whole system off-chain as well, allowing Bitcoin card holders to avoid blockchain transaction fees entirely. Of course this can be done as a hybrid system, with the card using either method to make a payment, depending on the circumstances. There is no reason to expect any of Visa, Mastercard, PayPal etc. to stay out of Bitcoin forever. With the 1MB blocksize limit they can all offer off-chain transaction services, and at the same time, if the limit is raised they can also all offer zero-conf transaction services, as well as run the expensive validating nodes that will be required and mining pools. |
|
|
|
Well, one thing seems clear to me by now. No amount of continued arguments will change entrenched views here. So, on to the next question. What do we actually do?
In negotiations where parties are far apart and demonstrably unwilling to move the only solution AFAIK is one where nobody gets what they want entirely, but instead uses something all can live with.
In my opinion that would be a change that appears most "safe". That seems like raising the limit by some safe appearing amount and seeing how things go. I estimate that would be raising the limit to something like 5-10MB.
Raising the limit as the first response to scalability problems sets a precedent that the limit will be simply raised again and again as Bitcoin grows. Why spend the effort solving the problem, when you can simply accept less security and punt the issue another year into the future? Fast growing internet startups aren't exactly known for their long-term planning. I think it's pretty clear who would win this battle if it came down to a fork. The one with cheap payments.
Bitcoin as a payment system is interesting in that as it becomes easier and faster to complete the fiat->Bitcoin->fiat loop required to make a payment, the economic influence of that use becomes less and less important, all things being equal. The reason is simple: the faster you can complete that loop, the fewer Bitcoins are tied up making payments, and thus the demand for Bitcoins for that application goes down. Similarly those users care less about what the value of Bitcoin is at any given moment. Conversely your investors, the people holding Bitcoins who believe they will maintain their value in the long run, perform far fewer transactions, yet constitute the economic majority and for now are the people paying for the security of Bitcoin. (via the still large inflation subsidy) This group has every reason to oppose changes that will sacrifice the security of their investment just so people can make cheap transactions. |
|
|
|
Accepting this as true, for which you present a strong case in your thread on trusted banks, then this is indeed a complementary service which may well attract a significant user base in the future. It may even succeed in handling 90% of the transaction volume which would otherwise hit the main blockchain. Is that your optimistic scenario?
However, and correct me if I am wrong, but such a trusted banking service does not exist yet. Not even in a prototype form, let alone one that can rapidly substitute for blockchain transactions. Acceptance of new services like this will take some time, at least a few years, surely. The people on this forum are ahead of the masses on bitcoin usage, yet they universally appreciate that their holding is stored on thousands of nodes worldwide. How many of us would quickly and permanently move our bitcoin holding to one single service instead of having it stored directly on the main chain?
We already have off-chain transactions, for instance Mt. Gox, and AurumXchange's code systems. Similarly web wallets allow for transfers from one user to another directly; MPOE reports that quite large amounts of BTC are exchanged between users every day. The Silk Road is another example of off-chain transactions - deposits go into a big shared wallet and transfers within the system are totally off-chain. In that case there are significant privacy advantages, not to mention how it makes implementing escrow easy. There isn't going to be a single service that does this, that's my whole point: if you achieve scalability by just raising the blocksize, you wind up with all your trust is in a tiny number of validating nodes and mining pools. If you achieve scalability through off-chain transactions, you will have many choices and options. I'm sure the users of the Silk Road have very different ideas about who they can trust than users of BitPay... You use the word "trust", but it takes time to earn it. It has taken Bitcoin four years to earn the trust that is fueling its success today. I argue that there is not enough time left for that level of trust to be earned by complementary services before the 1MB arbitrary constant becomes as effective as any ddos attack in the history of bitcoin. Please consider this chart and let us know, in your considered opinion, whether trusted banks will be fully ready, with a proven track record, before its blue line reaches 345,600. https://blockchain.info/charts/n-transactions?showDataPoints=false&show_header=true&daysAverageString=7×pan=&scale=1&address=Off-chain transactions aren't something that will be implemented in one big go. Like I said above, the markets can naturally adjust bit by bit gradually moving uses of Bitcoin from on-chain to off-chain as the fees gradually increase. At worst growth in the least important, lowest value, parts of the Bitcoin economy is slowed while off-chain tx solutions catch up. On the other hand, if the blocksize is raised and it leads to centralization, Bitcoin as a decentralized currency will be destroyed forever. It might not be sexy and exciting, but like it or not leaving the 1MB limit in place for the foreseeable future is the sane, sober and conservative approach. Exactly what I want from the developers of the brand-new and still poorly understood technology underpinning Bitcoin's $1.5billion market cap. For that matter, I personally have a good chunk of my wealth tied up in Bitcoins and want them to be valuable in the long run. You know, I work in engineering at a company filled with ex-aerospace guys, guys who are careful and try not to get people killed by things they don't understand. They all find my work on Bitcoin interesting, and a big part of that is because of how crazy high-stakes it is. If anything Bitcoin is kinda like being given alien technology that happens to be able to make a plane that never has to land, and unfortunately doesn't even even seem to be able to land. It's brilliant at moving passengers around, although the current plane can only fit 1000 of them. It's also the only one we have so if you want to change anything you have to do a bit of wing walking and be careful not to get any body parts near the props. Oh, and not to mention, it's currently raining cats and dogs, well, actually mostly dead puppies... Now, under those circumstances do you think I'd go up to my boss and say "Gee, I dunno, how about I climb out that access hatch at the back and add some sheet metal until the plane is long enough to shove 200,000 passengers in there?" Fuck no. For one thing this plane of ours damn near fell out of the sky a month ago, and it only took 700 passengers to make that happen. We also don't really understand why it flies at all; we've all got our own theories and some of the theories are probably even right, but we've never flown this plane in serious turbulence, let alone been attacked by those monocled guys in airships off in the distance. Heck, we got worried enough when one of them sent us a nasty telegram the other day about how shabby our records were or something. No, instead I'd be told to work on some prototypes and write some papers and see if maybe I could make some small nimble plane that could fly along-side our hulking monolith. Preferably a plane that can land for maintenance. |
|
|
|
Assuming equivalent UIs, what theoretical advantages to your third party off-chain service provide have that zero confirmation Bitcoin transactions don't already provide?
Privacy, and the best way to achieve that, chaum signatures, is inherently irreversible and instant as well. |
|
|
|
Peter, what is your opinion here:
Should complementary off-chain solutions develop organically on their own merits, taking loading off the Bitcoin blockchain, or should Bitcoin be crippled in the hope and expectation that complementary services develop around it faster?
Making the blocksize large as a solution will cripple Bitcoin with centralization and lack of anonymity. The most revolutionary thing about Bitcoin is that it is a truly decentralized store of value; 1MB will be enough to act as a store of value for the forseeable future. I'm not attacking anyone and I'm not anyone's opponent. I'm looking at all possible avenues - cap, no cap, dynamic cap, etc. - objectively. However, I think it's also helpful to put all information, including suspicions on opinions, out in the open. Please feel free to do the same for me, for example.
If you want to sink to that level, fine. What does Mike's employer, Google, stand to gain from large blocks that only large companies can afford to process and validate? What does Google stand to gain from a system where every last transaction is recorded on a public blockchain, ripe for datamining? Mike after all works for a company that has a "real names" policy and actively tries to ensure users can-not use its services anonymously. Keep in mind Mike is also being paid by Google to work on Bitcoin; 20% time projects, while often speculative, are approved by management and must relate to Google's business interests in some fashion. |
|
|
|
You know, it says a lot when your opponents resort to attacking you rather than your ideas: Honestly Peter, to be blunt I long ago concluded you're just working backwards from your preferred outcome. You don't want Bitcoin to scale up, and you will continue to invent ever more convoluted and baseless theories as to why it can't, until the end of time. Convincing you doesn't seem to be possible.
You know before I read this I had a question mark pop up when Peter brought up chaum signatures in one of these threads. I didn't see an immediate connection to a solution. Considering he wrote a detailed post on Chaum banks I wondered if personal preference was part of his outlook for the block size issue. |
|
|
|
Not much?
In the event that some jurisdictions with aggressive regulators try to impede mining, it will migrate elsewhere. Only if all mining is made illegal everywhere would it be a problem, and that's equivalent to a worldwide ban on Bitcoin, at which point it doesn't matter anymore.
So, in the countries where mining, and presumably Bitcoin in general, has been banned, do you think Bitcoins will have any value? I was referring to the gathering of transactions stage, which is arguably the expensive part, bandwidth wise. If blocks are represented efficiently (eg, list of hashes or deltas against remote expected blocks) then almost all your bandwidth would go on receiving transaction broadcasts, and that doesn't require Tor.
...which means if I want to prevent mining behind Tor, all I have to do is fill my blocks with transactions that I haven't relayed to them. On the other hand, if it's a rule that you only mine to extend blocks if the transactions were broadcast first, anything that even makes transaction propagation slower, like a bunch of fake nodes, but far from 100%, causes orphan rates to jump. Not to mention I can make it very risky, due to orphaning, to mine blocks containing transactions that a large fraction of the nodes out there have decided to blacklist for whatever reason. You also create new forking risks if transaction propagation is ever prevented, when block propagation isn't. |
|
|
|
|
Mike, lets suppose for a second that I am correct, and Tor bandwidth and other anonymity technologies do not scale with the bandwidth possible at VPN/co-location providers, and thus running mining (not hashing) operations is not possible anonymously.
What do you expect to happen?
|
|
|
|
That requires collusion, though, just like a 51% attack. Any attacker that can convince a significant percentage of miners to behave a certain way can disrupt Bitcoin. That happened recently when Gavin played the role of attacker and convinced enough miners to introduce forking software (aka version 0.8 ).
"God damn it, why won't that 5% of miners stop putting '1MB' in their coinbases. They're holding up progress! Fine, lets just block those stuck pigs, we're not colluding or anything." I don't see how you get that. Not that I have anything to do with Silk Road but I, for example, have wallet addresses that can't be linked to me in any possible way, no matter how much you analyze block-chain info. Regulating miners can't change that.
"FinCEN: From now on miners are money transmitters and must report all unusual transactions. FinCEN: From now on miners must not mine transactions over xBTC if they satisfy the criteria of unusual. FinCEN: From now on miners must also not build upon blocks that have transactions that they themselves would not be able to mine due to our regulations." VPN's and offshore jurisdiction are irrelevant in this scenario - Bitcoin hasn't been banned so we can fully expect mining pools to stay in the US and other visible, regulated, countries to take advantage of the cheap high-bandwidth internet connections required to run a pool. tl;dr: Don't be naive. |
|
|
|
...which means an attacker has strong incentives to buy, rent, or coerce hashing power to vote for a blocksize increase.
I don't believe that would work, at least not any more than an attacker doing the same thing to engineer a 51% attack. It doesn't work by amassing enough 'yes' votes (it's assumed resourceful miners always want an increase). Rather it polls to see if there are significant 'no' votes. It's impossible to ask for a significant minority of 'no' votes to be your decision point, because a majority of 'yes' votes can decide to only mine on top of blocks that do not vote 'no' All you can measure is a majority either way. ... inherently on-chain transactions vs. off-chain meet their goals of financial transparency and restricting privacy.
Really? I wouldn't think so considering the success of Silk Road. On-chain have some privacy, and privacy that can be taken away by regulating miners. Off-chain with chaum tokens can have mathematically provable privacy simply unattainable by on-chain transactions. |
|
|
|
... so the arguments to keep the blocksize small to allow for anonymous mining are clearly valid; even 1MB blocks are a bit marginal with Tor.
Well, that works under my proposed solution, which is a dynamic cap that increases only if there isn't significant objection from the field of miners to an increase. That way as more bandwidth becomes available in the future, even for Tor users, the cap can be raised as opposition to increased size would die down. ...which means an attacker has strong incentives to buy, rent, or coerce hashing power to vote for a blocksize increase. For instance in FinCEN was devious, part of regulating mining would be forcing miners to vote for a blocksize increase; inherently on-chain transactions vs. off-chain meet their goals of financial transparency and restricting privacy. Or this may be something as subtle as funneling money to tx fees for lots of low-value tx's, perhaps with unspendable but non-prunable outputs to further increase the cost of running a mining node well into the future. Fundamentally miners are not representative of Bitcoin and the choice of what the blocksize needs to be must not be under their control. |
|
|
|
Guys we really need some semblance of a solution forming. I have a feeling it will get far more crowded around here soon.
Note how the recent run-up in price, and in particular the media coverage about it, has been focusing on Bitcoin as a store of value rather than Bitcoin as a payment system. The media has correctly identified what makes Bitcoin truly special, and it's not by being a irrevocable version of PayPal. We're an order of magnitude away from filling up blocks without crowding out the low-value stuff yet at all, and rudimentary off-chain transaction stuff already exists in multiple forms. At the same time it's clear that FinCEN may in the future decide to regulate mining directly, so the arguments to keep the blocksize small to allow for anonymous mining are clearly valid; even 1MB blocks are a bit marginal with Tor. |
|
|
|
The fundamental security assumption of bitcoin is that information is easy to copy, and hard to censor. Thus there should exist multiple ways of distributing the information that comprises the blockchain to ensure that criteria is met. In particular blockheaders provide critical information about what chain the majority of hash power is working on, and themselves are self validating with some assumptions. Thus I have developed two alternate blockheader distribution systems to be used in addition to the current p2p network. The first, blockheaders via DNS. Headers are just eighty bytes, thus it takes just five 16 byte AAAA records to distribute one header. The advantage of using AAAA records is resistance to censorship: it can be expected that even most badly behaved DNS resolvers will pass AAAA records correctly. Equally AAAA records do not need special reaolvers, requiring just the standard gethostaddr() type calls supported by a plethora of languages. DNS also has the advantage of built in caching to reduce the load on the central header server. A test implementation is available: blk(num)-(0-4).blkhdrs.bitcoin.petertodd.org It should be running in this auspicious day - if not I will give the server a kick later tonight. (I just crawled out of a cave in rural West Virginia) The second method I have developed needs no explanation: http://twitter.com/blockheaders |
|
|
|
Holy crap... they have $1000 in coins, and they spend $300 to send $700... yikes.
Transactions larger than 100K are non-standard now, so I doubt the big transaction was ever broadcast. Almost certainly the transaction belonged to the miner, and they paid the fees to themself. There are enough old nodes still running on the network to get 100k txs propagated to miners if you start with a well connected node. |
|
|
|
|
Show Posts
