If you're going to argue that the "original" has some kind of terribly weight to it, then you need to come to grips with all the other ways it was originally broken.
what other things did Satoshi get wrong?
Topic: Gold collapsing. Bitcoin UP. - page 238. (Read 2032248 times)
what other things did Satoshi get wrong?
I don't believe anyone who claims to be concerned with centralization in Bitcoin.
In general, I don't take claims about motives at face value, because people can and do lie about their motivations (usually to themselves first).
So when somebody claims to care about X, the first thing I ask myself is, "is their behavior consistent with caring about X?"
In the case of people who claim to be concerned about centralization, if that's what they care about then they should show the most concern regarding the areas of highest centralization.
There are thousands of nodes.
There are about half a dozen core developers
99% of the nodes are running on a single code base (Bitcoin Core)
Even if larger blocks reduced the node count from the thousands to the hundreds, the Bitcoin Core monoculture and development monopoly would still represent more centralization.
Anybody who expresses concern about the centralization which may or may not occur with 20 MB blocks who isn't panicking about the lack of implementation and developer diversity is motivated by something other than a preference for decentralization.
In general, I don't take claims about motives at face value, because people can and do lie about their motivations (usually to themselves first).
So when somebody claims to care about X, the first thing I ask myself is, "is their behavior consistent with caring about X?"
In the case of people who claim to be concerned about centralization, if that's what they care about then they should show the most concern regarding the areas of highest centralization.
There are thousands of nodes.
There are about half a dozen core developers
99% of the nodes are running on a single code base (Bitcoin Core)
Even if larger blocks reduced the node count from the thousands to the hundreds, the Bitcoin Core monoculture and development monopoly would still represent more centralization.
Anybody who expresses concern about the centralization which may or may not occur with 20 MB blocks who isn't panicking about the lack of implementation and developer diversity is motivated by something other than a preference for decentralization.
I hate the fact that politics must be played. But after this debacle, sidechains had better be more awesome than the second coming of Satoshi if they want to make mods that are so much more complicated than changing a constant that there is simply no comparative basis.
My guess is that they want to delay blocksize so they can cram sidechain mods into the same fork as a negotiated compromise. But this is turning into a huge mistake. They are burning all the goodwill they had, and making us suspect them of not wanting what's best for bitcoin. This reputation is going to badly affect their ability to get consensus in the future.
My guess is that they want to delay blocksize so they can cram sidechain mods into the same fork as a negotiated compromise. But this is turning into a huge mistake. They are burning all the goodwill they had, and making us suspect them of not wanting what's best for bitcoin. This reputation is going to badly affect their ability to get consensus in the future.
The opposition to Gavin's 2000% jump proposal comes unanimously from every active technical contributor to Bitcoin Core who has spoken up. This should suggest to you that your understanding of the comparative basis likely miscalibrated. Though there is no comparative basis, 2WP sidechains are something that just requires non-broken smart contracts, it's not something that needs a hard-fork (and the centralized fedpeg sidechain stuff is indistinguishable, uncensorable, and unblockable: you can't prevent people from using it no matter how much you think you should be able to tell them that they can manage their funds).
Considering how often cypherdoc brags about his thread here being filled with economic wisdom, it's surprising to see views like "changing a constant simple and safe", after all 21 million bitcoins is merely a constant (and, pedantically, one the system didn't originally enforce....). Try another strawman.
MV = PT
A hard cap on the supply "M" was always the intent.
During my time spent immersed in Bitcoin never was the intent to limit Velocity or Transactions too be enforced by the Bitcoin protocol.
The idea of limiting Velocity or Transactions is a radical one, M is intentionally limited in the Bitcoin experiment, not V or T. Thinking it's OK to move Bitcoins V or T to a shidechain that is managed by the same incentives scheme that preserves the Bitcoin protocol is as radical as increasing "M" in the Bitcoin experiment.
and to think there is no difference between "2WP sidechains are something that just requires non-broken smart contracts" in effect Sidechain Elements, a fantastic achievement by the way, and doing the same thing without a trust or a distributed server enforced by Bitcoin protocol to manipulate V or T off the Bitcoin blockchain is an expression of macro economic ignorance.
Well stated.
gmaxwell, trying to conflate the supply limit and blocksize limit as equivalent "constants" and thus implying that changing the blocksize is as impactful as changing the supply is absurd. Changing the supply limit fundamentally destroys bitcoin, but increasing the blocksize limit is absolutely needed to make it successful.
There are 2 basic economic truths that you, Peter, LukeJr, etc have misrepresented for the past several weeks IMHO.
1) To ensure there are enough long-term fees to support and protect Bitcoin after the inflation rate levels off, it is necessary to significantly increase the blocksize and tps. More available transactions, in turn drives more usage of Bitcoin, increasing the overall value of the system. Additionally it is the minimum fee structure that will generate fees over many transactions, not supply pressure forcing higher fees over a small number of transactions as the blockstream devs have been promoting.
2) Significantly increased blocksizes in absolutely no manner reduces Bitcoin's decentralization. Bitcoin's decentralization is the mining security process which anyone can participate in. Miners work through pools and blocksize has no effect on them. We could go to 1TB blocks tomorrow and miners would not notice. At the same time pools are already centralized to the point that they can handle whatever blocksize is needed. There will still always be enough pools that if any misbehave, miners would leave the abuser in droves and switch to an honest pool.
The only reason Satoshi added the 1MB limit was to prevent a bad actor from quickly bloating the blockchain prior to SPV-type wallets. That was the only reason. Now that most people have SPV-type light wallets, the limit does not really matter. Those still running a full node can manage it.
Bitcoin is first and foremost an economic system, the basic crypto used in Bitcoin are just tools. The entire position you and the others have taken have demonstrated that either: a) you guys do not understand the economics behind Bitcoin and it's security mechanism or b) you do but Blockstream has completely corrupted your ability to view the situation properly. In either case I have found the arguments you and the others have used to be lacking and more to the point seem to intentionally confuse the issues here.
The most beautiful aspect of Bitcoin is it's voluntary consensus mechanism. This means there is no group of "experts" to dictate terms to any of us, and anyone can choose the branch of their own choosing. You can be sure I am following the branch and view of Bitcoin's future that aligns to wide scale usage, and from the voting patterns I've seen at reddit and elsewhere most others will as well.
It is crazy this thread is still going. 
I remember posting in it like a month ago.
I remember posting in it like a month ago.wow, that's a LONG time ago!
guys, i think it's pretty clear that Greg isn't even going to consider Jeff's proposal as viable, unless you'd like to say otherwise Greg. your non-response to my query says so not to mention your rhetoric.
I did respond to your query! Jeff's proposal is a bit underdefined right now, but to the extent that it isn't it's a good step forward. (Have you read it? It makes many of the points I've been making that you so vigorously have disagreed with...)btw, you can now stop saying that Gavin is the only core dev who advocates 20MB block incs. that's distorting the argument. or maybe that's what you want to do. he's continues to negotiate in good faith with modifications of now 8MB and also is ok with Jeff's new proposal. and it's now 2 core devs in favor of an inc, Gavin and Jeff, and Mike. since you and Pieter apparently give lip service to inc blocks, altho we wouldn't know it given your rhetoric, perhaps you should make your own counter proposal commitment with hard numbers. wouldn't that be the right thing to do?
It is crazy this thread is still going. I remember posting in it like a month ago.
I remember posting in it like a month ago. guys, i think it's pretty clear that Greg isn't even going to consider Jeff's proposal as viable, unless you'd like to say otherwise Greg. your non-response to my query says so not to mention your rhetoric.
I did respond to your query! Jeff's proposal is a bit underdefined right now, but to the extent that it isn't it's a good step forward. (Have you read it? It makes many of the points I've been making that you so vigorously have disagreed with...)i've read the salient parts of it and i don't agree with all of his assumptions. such as the part about large blocks causing centralization. i think the dynamic is inc blocks-->inc users-->inc merchants-->inc full nodes-->inc value-->inc price. the reason full node #'s should actually inc, not dec, is the growth dynamic that will encourage more merchants to fund their own nodes for security reasons and that they can write them off thru the business. it's ok to push most full nodes up one level to merchants and/or supernodes. users in foreign countries or behind Tor don't need to run full nodes. the value of the network will grow with the square of the user numbers. in fact, centralization is exacerbated with 1MB blocks. that's so clearly obvious as tx's are pushed off network onto centralized services like CB. plus, the small niche community of user geeks is a much easier target for law enforcement. diffusing Bitcoin and the user base out into developing countries is also where Bitcoin stands the greatest chance to really take hold and entrench itself. i guarantee you a little African kid is more likely to say FU to his gvt than you would be to the USG from the use of Bitcoin.
guys, i think it's pretty clear that Greg isn't even going to consider Jeff's proposal as viable, unless you'd like to say otherwise Greg. your non-response to my query says so not to mention your rhetoric.
I did respond to your query! Jeff's proposal is a bit underdefined right now, but to the extent that it isn't it's a good step forward. (Have you read it? It makes many of the points I've been making that you so vigorously have disagreed with...)
guys, i think it's pretty clear that Greg isn't even going to consider Jeff's proposal as viable, unless you'd like to say otherwise Greg. your non-response to my query says so not to mention your rhetoric.
thus, we all have to make our own plans whether or not to support XT. i know i will be.
edit: oh btw, since Sidechains Whitepaper release in October? $380 to where we are today. Ahem.
thus, we all have to make our own plans whether or not to support XT. i know i will be.
edit: oh btw, since Sidechains Whitepaper release in October? $380 to where we are today. Ahem.
If you're going to argue that the "original" has some kind of terribly weight to it, then you need to come to grips with all the other ways it was originally broken. The limitation to 1MB was intentional, not a bug. Nor was the additional temporary soft limits below 1MB. No one in the technical community is arguing that it should by 1MB forever, other than a panic end run around the process, breaking up consensus, and a huge leap thats completely out of proportion with safe operation or current demand just doesn't make sense.
Every single one explicitly predicts features that require more transactions than can fit in 1MB. The promise was NEVER "someday, you'll never use bitcoins but your bank will".
Good thing then that there is no one in the technical sphere saying that.meanwhile:
Yea, well, got a chart of Bitcoin since Monday? Ahem.I hate the fact that politics must be played. But after this debacle, sidechains had better be more awesome than the second coming of Satoshi if they want to make mods that are so much more complicated than changing a constant that there is simply no comparative basis.
My guess is that they want to delay blocksize so they can cram sidechain mods into the same fork as a negotiated compromise. But this is turning into a huge mistake. They are burning all the goodwill they had, and making us suspect them of not wanting what's best for bitcoin. This reputation is going to badly affect their ability to get consensus in the future.
My guess is that they want to delay blocksize so they can cram sidechain mods into the same fork as a negotiated compromise. But this is turning into a huge mistake. They are burning all the goodwill they had, and making us suspect them of not wanting what's best for bitcoin. This reputation is going to badly affect their ability to get consensus in the future.
The opposition to Gavin's 2000% jump proposal comes unanimously from every active technical contributor to Bitcoin Core who has spoken up. This should suggest to you that your understanding of the comparative basis likely miscalibrated. Though there is no comparative basis, 2WP sidechains are something that just requires non-broken smart contracts, it's not something that needs a hard-fork (and the centralized fedpeg sidechain stuff is indistinguishable, uncensorable, and unblockable: you can't prevent people from using it no matter how much you think you should be able to tell them that they can manage their funds).
Considering how often cypherdoc brags about his thread here being filled with economic wisdom, it's surprising to see views like "changing a constant simple and safe", after all 21 million bitcoins is merely a constant (and, pedantically, one the system didn't originally enforce....). Try another strawman.
I'm tired of your pedantic FUD. The system originally had a 30+MB implicit limit which was then reduced. AFAIK the fact that the system didn't enforce the 21million was a bug. The intention was always sound money.
Seriously, look at ANY Bitcoin pitch. Every single one explicitly predicts features that require more transactions than can fit in 1MB. The promise was NEVER "someday, you'll never use bitcoins but your bank will". At the same time from the very beginning Satoshi even said that as the network grows, the full nodes would become more centralized. But he understood that that does not matter because membership is STILL permissionless. Yes, it might require more money to buy a bigger computer and network but anyone can still join. Just like it requires more money to mine today.
You have a problem with 20MB, fine. So propose 8, 4 or something that is not just "wait and see". However, I never saw a post from you guys about how you tried it with 20MB and it didn't work. But I saw a careful analysis by Gavin showing how it DID work.
And scalability is harming the network RIGHT NOW, because developers aren't going to base all their work on something that won't work (or won't work without who-knows-how-high fees).
As Cypherdoc will attest, I was Blockstream and sidechain's biggest supporter on this topic. But now I say he was right. I no longer trust that you guys aren't trying to steal all Bitcoin's value into a sidechain.
I am a Monero Pimp & I love Bitcoin conflict
meanwhile:
If there is excess space, there is someone somewhere who will try to use it to store their data... be it some outlawed pornography they want to try to make censorship resistant or just 0 BTC payments to advertise to people. A single while loop is an effectively infinite capacity demand, and a price of zero thats what we would have.
aren't these non std tx's?
Quote
There have been a half dozen attempted companies trying to do "data archival in the blockchain", yadda yadda-- turns out globally replicated storage that other people pay for is pretty attractive!. Though the traditional hard limit isn't necessary to block out crap like the unsolicited commercial advertising, but I'm personally very uncomfortable with putting ourselves in the position where the health of the network depends on miners censoring transactions-- I much prefer the politically neutral economics of competing for the available resources with fees.
i disagree with this. in a perfect world, the miners and users should be negotiating fees btwn them with you as core dev leaving any fee manipulating mechanisms (speed limits) out of the protocol. that is what Jeff brought up in his BIP and represents insight you should consider.
As Jeff pointed out in his writeup, blocks have long been '100% full' relative to to whatever limit is being applied. If there is excess space, there is someone somewhere who will try to use it to store their data... be it some outlawed pornography they want to try to make censorship resistant or just 0 BTC payments to advertise to people. A single while loop is an effectively infinite capacity demand, and a price of zero thats what we would have. There have been a half dozen attempted companies trying to do "data archival in the blockchain", yadda yadda-- turns out globally replicated storage that other people pay for is pretty attractive!. Though the traditional hard limit isn't necessary to block out crap like the unsolicited commercial advertising, but I'm personally very uncomfortable with putting ourselves in the position where the health of the network depends on miners censoring transactions-- I much prefer the politically neutral economics of competing for the available resources with fees.
all valid concerns and points, too bad all the pro-forkers see is unwarranted noise between them and mass adoption™, people pushing for hard-forks right now look very retarded and desperate, look at the derpness:
coffee-heads are going to destroy Bitcoin and I'll love to watch the show.
now contrast with some wisdom:
I hate the fact that politics must be played. But after this debacle, sidechains had better be more awesome than the second coming of Satoshi if they want to make mods that are so much more complicated than changing a constant that there is simply no comparative basis.
My guess is that they want to delay blocksize so they can cram sidechain mods into the same fork as a negotiated compromise. But this is turning into a huge mistake. They are burning all the goodwill they had, and making us suspect them of not wanting what's best for bitcoin. This reputation is going to badly affect their ability to get consensus in the future.
My guess is that they want to delay blocksize so they can cram sidechain mods into the same fork as a negotiated compromise. But this is turning into a huge mistake. They are burning all the goodwill they had, and making us suspect them of not wanting what's best for bitcoin. This reputation is going to badly affect their ability to get consensus in the future.
The opposition to Gavin's 2000% jump proposal comes unanimously from every active technical contributor to Bitcoin Core who has spoken up. This should suggest to you that your understanding of the comparative basis likely miscalibrated. Though there is no comparative basis, 2WP sidechains are something that just requires non-broken smart contracts, it's not something that needs a hard-fork (and the centralized fedpeg sidechain stuff is indistinguishable, uncensorable, and unblockable: you can't prevent people from using it no matter how much you think you should be able to tell them that they can manage their funds).
Considering how often cypherdoc brags about his thread here being filled with economic wisdom, it's surprising to see views like "changing a constant simple and safe", after all 21 million bitcoins is merely a constant (and, pedantically, one the system didn't originally enforce....). Try another strawman.
MV = PT
A hard cap on the supply "M" was always the intent.
During my time spent immersed in Bitcoin never was the intent to limit Velocity or Transactions too be enforced by the Bitcoin protocol.
The idea of limiting Velocity or Transactions is a radical one, M is intentionally limited in the Bitcoin experiment, not V or T. Thinking it's OK to move Bitcoins V or T to a shidechain that is managed by the same incentives scheme that preserves the Bitcoin protocol is as radical as increasing "M" in the Bitcoin experiment.
and to think there is no difference between "2WP sidechains are something that just requires non-broken smart contracts" in effect Sidechain Elements, a fantastic achievement by the way, and doing the same thing without a trust or a distributed server enforced by Bitcoin protocol to manipulate V or T off the Bitcoin blockchain is an expression of macro economic ignorance.
so it sounds to me that you aren't willing to even talk to Gavin on this issue, is that right?
In public, sure and I have. It's just that I think there is unlikely to be an agreement there. As far as I can tell Gavin and Mike have a vision of a future where Bitcoin is "decenterlized" in the way the existing central banking system is-- rather than being secured by a decenteralized proof of work consensus (or similar) where the rules dominate the system instead of politics; or at a lest that its okay to become that way now and then maybe worry about it later if we don't like it. It's not a view I share, and with such different objectives its difficult to agree on the the foundations needed for agreement when a true trade-off must be made. Mike thinks that transactions should be completely free forever and that the system has failed if they're not.. well you can see the perspective differences outlined here, probably better than I am going to explain it right now: https://medium.com/@allenpiscitello/what-is-bitcoin-s-value-proposition-b7309be442e3
the important part of their conclusion is that they acknowledge that organic growth of tx volume doesn't necessarily immediately ramp to the block limit; it is in fact controlled by market forces and adoption by users. even if tx volume did ramp to the max i actually wouldn't be afraid of a scenario like this. that's b/c i'd bet dollars to donuts that exchange price would ramp with it thus allowing me personally to have some extra fun running a "supernode".
As Jeff pointed out in his writeup, blocks have long been '100% full' relative to to whatever limit is being applied. If there is excess space, there is someone somewhere who will try to use it to store their data... be it some outlawed pornography they want to try to make censorship resistant or just 0 BTC payments to advertise to people. A single while loop is an effectively infinite capacity demand, and a price of zero thats what we would have. There have been a half dozen attempted companies trying to do "data archival in the blockchain", yadda yadda-- turns out globally replicated storage that other people pay for is pretty attractive!. Though the traditional hard limit isn't necessary to block out crap like the unsolicited commercial advertising, but I'm personally very uncomfortable with putting ourselves in the position where the health of the network depends on miners censoring transactions-- I much prefer the politically neutral economics of competing for the available resources with fees.at this pt, you'd have to propose a concrete commitment plan and present it to Gavin to prove yourself. no more talk.
LOL. Present it to Gavin? You realize that Gavin hasn't actually tendered a specific proposal-- it's all talk and political maneuvering with the general public, right? No BIP draft, no pull request, no development thread (except for the one created days after by opponents of his move in shock by the approach). As far as I can tell the whole situation was specifically constructed to be a big show and justify a "governance" crisis and land-grab (a belief also supported by the emails Mike was sending the gmx account a year ago). That noise about the XT hardfork? No commits on the repository for months, and except for two patches even the months old stuff is just copying Bitcoin Core-- the work of all these other people who are so easily disrespected now. Sound and fury, signifying nothing. Meanwhile, beyond making proposals, creating simulations, oh yea and developing bunch of highly useful new free software for Bitcoin, the rest of the people who actually do the work continuing to truck on. In any case-- these things have been proposed in the usual forums. Gavin seems unwilling to consider anything other than a massive uncontrolled jump in blocksize as far as I can tell, fortunately Jeff isn't interested in the same kind of purely political end run.And here again we find that you say something untrue (that I hadn't made proposals related to block size), it's corrected (no, in fact I've tried several specific proposals), then the bar moves.
so it sounds to me that you aren't willing to even talk to Gavin on this issue, is that right?
Greg, would you want to be lead core dev?
hadn't seen this simulation from the btcd folks before. looks promising:
Conclusions
Aside from the obvious network and storage constraints of running a full Bitcoin node at large block sizes, it appears the Bitcoin network is capable of handling a substantially higher transaction volume than it does currently. The CPU time being dominated by ECDSA signature checks at high transaction rates suggests a clustered full node architecture could process credit-card-like transaction rates by using a load balancing / offload approach to ECDSA signature checking, e.g. a full node with a 10 machine cluster would top out at >2,000 tps.
The resources and know-how required to run a clustered node like this may impose a significant centralizing force on Bitcoin. Backpressure against the centralization of Bitcoin may well drive alternative solutions to having all transactions on-chain. Alternatively, it may end up that Bitcoin adoption grows slowly enough that the computing power of a single node grows quickly enough to avoid requiring a clustered full node architecture.
Do note that btcsim does nothing to address the current issues with block propagation time and block size. These are serious issues that are already being addressed by Gavin and the other Core developers.
https://blog.conformal.com/btcsim-simulating-the-rise-of-bitcoin/
maybe offchain for profit companies are pursuing the wrong strategy by limiting block sizes on MC if they truly want to push tx's to their products?
the important part of their conclusion is that they acknowledge that organic growth of tx volume doesn't necessarily immediately ramp to the block limit; it is in fact controlled by market forces and adoption by users. even if tx volume did ramp to the max i actually wouldn't be afraid of a scenario like this. that's b/c i'd bet dollars to donuts that exchange price would ramp with it thus allowing me personally to have some extra fun running a "supernode".
Conclusions
Aside from the obvious network and storage constraints of running a full Bitcoin node at large block sizes, it appears the Bitcoin network is capable of handling a substantially higher transaction volume than it does currently. The CPU time being dominated by ECDSA signature checks at high transaction rates suggests a clustered full node architecture could process credit-card-like transaction rates by using a load balancing / offload approach to ECDSA signature checking, e.g. a full node with a 10 machine cluster would top out at >2,000 tps.
The resources and know-how required to run a clustered node like this may impose a significant centralizing force on Bitcoin. Backpressure against the centralization of Bitcoin may well drive alternative solutions to having all transactions on-chain. Alternatively, it may end up that Bitcoin adoption grows slowly enough that the computing power of a single node grows quickly enough to avoid requiring a clustered full node architecture.
Do note that btcsim does nothing to address the current issues with block propagation time and block size. These are serious issues that are already being addressed by Gavin and the other Core developers.
https://blog.conformal.com/btcsim-simulating-the-rise-of-bitcoin/
maybe offchain for profit companies are pursuing the wrong strategy by limiting block sizes on MC if they truly want to push tx's to their products?
the important part of their conclusion is that they acknowledge that organic growth of tx volume doesn't necessarily immediately ramp to the block limit; it is in fact controlled by market forces and adoption by users. even if tx volume did ramp to the max i actually wouldn't be afraid of a scenario like this. that's b/c i'd bet dollars to donuts that exchange price would ramp with it thus allowing me personally to have some extra fun running a "supernode".
at this pt, you'd have to propose a concrete commitment plan and present it to Gavin to prove yourself. no more talk.
LOL. Present it to Gavin? You realize that Gavin hasn't actually tendered a specific proposal-- it's all talk and political maneuvering with the general public, right? No BIP draft, no pull request, no development thread (except for the one created days after by opponents of his move in shock by the approach). As far as I can tell the whole situation was specifically constructed to be a big show and justify a "governance" crisis and land-grab (a belief also supported by the emails Mike was sending the gmx account a year ago). That noise about the XT hardfork? No commits on the repository for months, and except for two patches even the months old stuff is just copying Bitcoin Core-- the work of all these other people who are so easily disrespected now. Sound and fury, signifying nothing. Meanwhile, beyond making proposals, creating simulations, oh yea and developing bunch of highly useful new free software for Bitcoin, the rest of the people who actually do the work continuing to truck on. In any case-- these things have been proposed in the usual forums. Gavin seems unwilling to consider anything other than a massive uncontrolled jump in blocksize as far as I can tell, fortunately Jeff isn't interested in the same kind of purely political end run.And here again we find that you say something untrue (that I hadn't made proposals related to block size), it's corrected (no, in fact I've tried several specific proposals), then the bar moves.
Jump to: