One of the famous false prophecy of Karl Marx is that the free market mechanism would be lead to the monopoly of few corporations (thanks to economy of scale) that would end up controling the world production.
In other world, he tought unconstrained competition would allow for large entities to capture the economy.
This is already realized in many countries, a few large enterprises controlled the production of almost everything in a country. And the best example is the fiat money creation, totally dominated by a few reserve banks, while from the beginning any kind of private currency is allowed to circulate And the block size limit has nothing to do with free market, it is just a measure to prevent spam attacks, without this limit, a bank can jam the traffic on bitcoin network for months, so that no transaction can be done at all It is very interesting that the longer you work with bitcoin, the more you understand that in such a decentralized system, true free market does not really work, it is in fact very socialized, since everyone's interest is tied to the strongest chain in the end. You can fork what ever chain you like but the value of that chain will be minimal (since it break the most important promise of bitcoin - limited total supply, any fork is inflation, bring in more money supply) thus make that move meaningless market wise |
|
|
|
Hey Johnyj: I don't come here nearly as much since Theymos began his reign of censorship and shut down our discussion thread. I'd like to invite you to join the discussion at https://bitco.in/forum/ . "Gold Collapsing. Bitcoin UP" is our usual chit-chat thread, and there is also a sub-forum dedicated to Bitcoin Unlimited. There are also a lot more people than just me that would like to try to answer your questions. Best, Peter I don't support censorship, but I think the current political differences are already too much, we need more shared and united view, not working towards different directions, it does not help to reach consensus |
|
|
|
|
If I understand it correctly, it split the broadcasting of the block data into 4 small pieces so that they don't arrive at the same time. So instead of one block which is 1MB, you have 4 weak blocks, each 250KB, broadcasted at 2.5 minutes interval
The question is, if both node A and node B mined a weak block at the same time, I suppose that they would continuously build on their own subchain while ignore the other's subchain, at the same time, they need to keep other's subchain just in case a new full block is mined from that chain. And I think a smaller block interval will dramatically increase the orphan rate due to lower difficulty (Who has the orphan rate data of litecoin?), so there will be several different subchains coexisting before the full block is mined
I think IBLT is a cleaner approach since it does not have such small check points
|
|
|
|
I think Peter R did not consider the fact that the block size limit is first a spam filter, and the attackers never follow the market based behavior
This is exactly what I considered in Section 9 (page 11). I was able to calculate the cost of spam attacks at various values for the network propagation impedance: It has nothing to do with cost An attacker has only one single purpose that is to disable the network so that no transaction can be done at all.... If an attacker had unlimited funds to spend, then I would agree that he might eventually succeed in injecting a large block if there were no block size limit (and nodes attempted to process all blocks regardless). I'm not sure if people realize this, but there is a block size limit in Bitcoin Unlimited. It's just that it is an emergent phenomenon of the network and the decisions of node operators and miners. I'm getting a lot of questions about how this works, so I hope to put together some convincing visuals and documentation over the coming months. Bitcoin Unlimited believes that the protocol should be governed through a "bottom up" organic process. On the other hand, Bitcoin Core believes that the protocol should be governed by a select group of developers through a "top down" process. You don't need unlimited funds, just a bit more than what coinwallet.eu spent then you will really cause some trouble if the block size has no limit I agree that the protocol should have change management, no change goes in without a formal approval process, and the approval should be based on a vote by the majority of the stakeholders But in practical, how to vote? Everyone sign a vote with their node? A private key that contains 1 bitcoin? Sign the vote with hash power? It seems the rich guys will always buy the most vote, so bitcoin will serve the interest of enterprise and capitalists in the end |
|
|
|
|
Chinese rates are lower, it is obviously manipulated by whales on Chinese Exchanges
|
|
|
|
I think Peter R did not consider the fact that the block size limit is first a spam filter, and the attackers never follow the market based behavior
This is exactly what I considered in Section 9 (page 11). I was able to calculate the cost of spam attacks at various values for the network propagation impedance: It has nothing to do with cost An attacker has only one single purpose that is to disable the network so that no transaction can be done at all. In order to achieve this, they are more likely to use the coinwallet.eu spam trick, combining thousands of small outputs linked to thousands of small outputs in one single transaction, and make this transaction as large as the block. In this case, a 3.2MB block would take 10 minutes for a decent server to verify, and 8MB will take several hours to verify, which means all the nodes will fail to keep up with the new block generation and the network split into segments Currently there is 1MB limit, so the worst case scenario is 30 seconds, still won't cause a panic in the network, but blocksize without limit will definitely cause serious problem |
|
|
|
|
OP's concern is valid. What if your old wallet format does not get recognized by new clients and the old clients are not able to send transactions after 2 years? (private key is relatively safe but still... see below)
In fact, in today's bitcoin design, nothing is guaranteed. A new protocol that is accepted by majority of the nodes can even spend your coins without your private key. Of course such a situation will almost never happen because of the decentralized nature of bitcoin: Existing stakeholders have many reasons to deny such kind of protocol change, since it basically ruins people's trust in bitcoin
However, if the protocol change is coming from a malicious actor or sybil attack, then old coins might still get lost in a compromised environment
The most important is to be aware that unlike gold, no rule of bitcoin is fixed by law of nature, they are just rules made by human and maintained by consensus among its participants. So you can expect that different clients have different rules, but usually you don't get enough details about these rules unless you are familiar with source code inspection and build the client by yourself each time
|
|
|
|
It seems the whole bitcoin ecosystem is like a country, you can not fork at will (that will immediately destroy the weaker fork economically). So some of the concept of managing a country can be borrowed Separation of power: You vote for legislation (BIPs), and someone else ensure the implementation (coding and commit), and someone works as judge (miners) https://docs-of-freedom.s3.amazonaws.com/uploads/image/attachment/37/Ch_1_-_separation_of_power.jpgThe key here is the BIPs must be based on user vote, not decided by programmers, and it is also similar in today's IT industry: You receive change request or trouble report from end user and start to hold meetings to decide if they are acceptable, then assign to programmers to implement So, if lots of users complain about the high fee and low transaction capacity, then corresponding BIPs can be made and start to be voted by users, not like today, anyone is writing their own BIP and no one else cares |
|
|
|
And the fee market regulated by orphan rate is worth debating.
And it has been debated, and the theory promoted by Peter R didn't hold well. Spherical cows stuff. I didn't check if he revised his paper since then, though. I think Peter R did not consider the fact that the block size limit is first a spam filter, and the attackers never follow the market based behavior |
|
|
|
BU's article of federation have some very positive energy. And the fee market regulated by orphan rate is worth debating. I don't like those President things though  |
|
|
|
Found it. https://www.youtube.com/watch?v=TgjrS-BPWDQ&feature=youtu.be&t=3h05m Mark Freidenbach (?) near the end of the morning session at day 2 of the Scaling Bitcoin conference.
eta: ^ did you sneak an edit in with the link while I was off looking for it?So during the slide you had a pic of above, he was talking about a non-standard block that aggregated as much dust as F2Pool was able to fit in a single block. Note that those transactions that went into that block are already unrelayable under standard rules. In summary remarks he indicated that 'blocksize is a poor indicator of the resource consumption required to process a block'. It is indeed a special transaction, but you can not prevent an attacker from broadcasting this kind of block In fact coinwallet.eu's last round of attack consists exactly of this kind of dust outputs, and in the name of coin give away so that hundreds of people tried to construct a huge transaction to claim the coins in their address. You can search for the post in this forum and this time I won't edit the link  |
|
|
|
Satoshi did build a lot of extensibility and op codes within the original design so bitcoin could grow, evolve, and use layers like the lightning network. While I do respect Satoshi we shouldn't worship him and treat everything he has done as sacrosanct as he has made many mistakes. What is more important is us respecting the investment contract we have all agreed to over the years about respecting the core fundamentals that makes bitcoin unique. Satoshi can always sign a PGP key and jump and and make a comment if he has some serious concerns as well.
It is not worship, more like respect the intellectual property of the original designer What makes bitcoin valuable? The idea tested by time. You could have more refined design than bitcoin like Ethereum, but without the test of time, any code is just a piece of open source software which worth almost nothing. Overtime, many people little by little build up the trust and value of bitcoin, obviously its architecture is part of this value Imagine that if you redesign an altcoin with SW architecture, would it get any value? Almost none of course. However, if you put this design as a soft fork of bitcoin, trying to slowly seek its way into the bitcoin ecosystem and become part of it. This kind of action is very alike virus or trojan, highly malicious. If your design is really genius and excellent, you should ask for major approval and implement it as a hard fork. Being a soft fork just feels shady If anything that scales bitcoin can be accepted, I'm sure we will have Cisco/Ericsson/VISA bitcoin architecture that can scale much better than SW, anyway their engineers are dealing with traffic of millions of nodes, bitcoin level of petty traffic would make them laugh, their engineering team will totally replace bitcoin core devs, right? |
|
|
|
Bitcoin itself is a huge "Economic Change Event" in the wider context of the existing monetary systems (i think this is where Jeff probably got the idea from) ... fees coming online for bitcoin TX is a storm in a teacup by comparison.
During July and September coinwallet.eu attack, all the blocks were full for at least a week, but you just need to raise the fee to 0.0005 btc to get a confirmation in 10 minutes, how is that a storm in a teacup? Concerns of a Fee Market Event may be valid. The coinwallet.eu attack would only briefly fill blocks during a few moment here and there and never created sustained filled blocks for a long period of time. We have no idea what will happen if a there is sustained Fee event -- This is why Garzik defines such fee event as FE - "Fee Event", the condition where main chain MSG_BLOCK is 95+% to hard limit for 7 or more days in row, "blocks generally full" https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011973.htmlBitcoin has never seen this before and we don't know what will happen. It is easy to predict from each individual user point of view: If I'm currently doing one transaction per day and it cost 0.0001 btc for fee, if the transaction capacity gets full, I will combine 2 transactions and do one transaction every 2 days and pay 0.0002 btc for fee If everyone is doing this, then the number of transactions will be cut by half, all the blocks become half-empty In old times, when banks are closed during weekends, people will do their withdraw early and they withdraw much more to deal with the transaction capacity stop, and they won't give up using banks |
|
|
|
This is indeed true and is included in the FAQ backed by most of the developers and something I was unaware of as well. I haven't done the math but appears that a 2 MB block with heavy P2SH that can extend validation time to those lengths with certain nodes. It is likely representative as a worst case scenario but does support an idea of how even a modest increase can bring down nodes in an already delicate environment where we have too much centralization.
If this is true then SW is not a good idea since it increased the effective block size, and when you have signature and transactions separated, shouldn't it take longer time to verify? If a 3.2MB block takes 10 minutes to verify then the SW will not work at all since it bumps it to 4MB, attackers only need to send out such specifically constructed blocks to stall the network |
|
|
|
Bitcoin itself is a huge "Economic Change Event" in the wider context of the existing monetary systems (i think this is where Jeff probably got the idea from) ... fees coming online for bitcoin TX is a storm in a teacup by comparison.
During July and September coinwallet.eu attack, all the blocks were full for at least a week, but you just need to raise the fee to 0.0005 btc to get a confirmation in 10 minutes, how is that a storm in a teacup? |
|
|
|
Other changes required: Even a single-line change such as increasing the maximum block size has effects on other parts of the code, some of which are undesirable. For example, right now it’s possible to construct a transaction that takes up almost 1MB of space and which takes 30 seconds or more to validate on a modern computer (blocks containing such transactions have been mined). In 2MB blocks, a 2MB transaction can be constructed that may take over 10 minutes to validate which opens up dangerous denial-of-service attack vectors. Other lines of code would need to be changed to prevent these problems.
The average non-developer likely naturally assumes that 2MB blocks is a safe change to make and conservative, but a targeted DDOS attack exploiting that 10 minute validation delay(up from 30 seconds for 1MB ) would be disastrous. I must admit that I am guilty of such an assumption. Time linear with block size seems rational on the surface before looking into the matter. Are you asserting that the worst cast for a 1MB block size today is less than 30 seconds on the same hardware that would have a worst case of 10 minutes if the only variable is a blocksize doubled to 2MB? What are the characteristics of such an aberrant block?  I heard that some new libs can dramatically increase the verification speed, this might not be a large concern by then |
|
|
|
I understand it and don't hate the core developers. Seg wit is a thoughtful solution, but not an elegant one. IMHO, it's just more spackle over the cracks and a further delay to increasing block size.
Good observation In change management, the first question is not about if a change is good or bad, it is why must we make this change. It is always the motivation behind the change worth looking It seems SegWit is invented to temporary circumvent the hard coded 1MB limitation of the block size, so that the traffic can still grow without trigger a fee event So the next question will be: Why are we so fear of a fee event? Jeff gave some answer here: *Key observation: A Bitcoin Fee Event (see def. at top) is an Economic
Change Event.*
An Economic Change Event is a period of market chaos, where large changes
to prices and sets of economic actors occurs over a short time period.
A Fee Event is a notable Economic Change Event, where a realistic
projection forsees higher fee/KB on average, pricing some economic actors
(bitcoin projects and businesses) out of the system.
I don't think this so called "chaos" is convincing enough, so the next question: Who are these bitcoin projects and businesses, and is bitcoin's goal to benefit average people or serve these projects/businesses? Although institutions have large capital and influence in the industry, I don't think bitcoin's purpose is to become banks' another payment network (Banks being the highest form of business, a business large enough will start to do banking) In fact, businesses can always pass the fee cost to customer, and those customers are not fee sensitive (Statistics showed that majority of users come to bitcoin and use it for long term value store and high value international remittance, both are not very sensitive to fee and transaction frequency) So a higher fee will not affect business either. And large businesses can establish clearing channel to dramatically reduce the fee cost, this is a common practice in financial world, they don't need to change bitcoin architecture to do that So I think the motivation behind the architecture change of bitcoin is still not enough convincing. Since no one have seen a fee event, it might not be the "chaos" that is predicted by Jeff, so people must see it with their own eyes to be convinced that it is a problem that really need to be solved. What if it is not a problem at all? Banks are still closed during weekends and holiday, is that a problem for our financial system? Even a fee event negatively affect majority of the user experience, the way to future scaling should still follow Satoshi's vision as much as possible. Anyway this is his invention, no one except him have the right to change it to something totally different |
|
|
|
Jeff and Gavin are not in the list. I had a feeling that block size limit has long become a political weapon for each faction to take control of the development process thus realize their own vision of bitcoin And this is a result when lots of money is involved In today's society, when you are talking about a project worth $6.6 billion in an enterprise, developers has no decision making right at all. It is the biggest shareholder make decisions at board level, and technical solution is only a small part of the decision making process However in a decentralized open source project like bitcoin, there is no board, no one knows how it is going to work That means it's time to start to write Bitcoin Protocole in stone. Or devs with death threats, subponea or money interests will try to fuck it. Bitcoin is fine now to be gold 2.0 For the rest, fork it. It's about independance, not fast free tx. Forget the coffees. There is huge difference between a free software open source project (Linux) and a decentralized monetary system (Bitcoin). Imagine that if an enterprise or a group of programmers could take over the control of Federal Reserve, how many people would like to give it a try? Bitcoin currently does not have self validation, it does not detect the change at protocol level and reject it, and miners only make sure the blocks are authenticate, not software itself, this makes its rule very flexible and constantly changing, a point of weakness If some kind of code that make the validation of the client is also built in the blocks and pushed into thousands of nodes, then no one would be able to change the protocol without a hard fork. (I'm not sure if this is achievable since it is a chicken and egg problem) This is the opposite direction of a soft fork, hardening the bitcoin thus make all the future improvements off-chain, can also be considered if no consensus can be reached upon core devs, or the risk that core devs become compromised is too large |
|
|
|
Concern over validationless mining is incentivized by SepSig https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012103.html# Segregated witnesses and validationless mining With segregated witnesses the information required to update the UTXO set state is now separate from the information required to prove that the new state is valid. We can fully expect miners to take advantage of this to reduce latency and thus improve their profitability. We can expect block relaying with segregated witnesses to separate block propagation into four different parts, from fastest to propagate to slowest: 1) Stratum/getblocktemplate - status quo between semi-trusting miners 2) Block header - bare minimum information needed to build upon a block. Not much trust required as creating an invalid header is expensive. 3) Block w/o witness data - significant bandwidth savings, (~75%) and allows next miner to include transactions as normal. Again, not much trust required as creating an invalid header is expensive. 4) Witness data - proves that block is actually valid. This part concerns me: Although from individual miner's point of view, producing an invalid header is expensive, but if a malicious user want to attack the network by broadcasting invalid header, he doesn't need to process large amount of hash power, maybe even 1% is enough to cause large scale of orphan for the network every day So from this point of view, I guess even in a SW architecture, all the data must be broadcasted as one single package and full nodes need all of them to validate the block. And SPV miners will have to pay for the orphan cost by themselves if they use header-only validation |
|
|
|
|
Show Posts
