Hi bitsko, I'm a mod there too and I want to clarify your statement and add actual facts to it. There were only three users banned in regards to the issue you are referencing, where all three banned users all have been unbanned to give them a second chance. Everyone is welcome to post in that sub and nobody is censored, but it is moderated for spam and trolls.recently on /r/btc a moderator banned several users and told one to go have a snickers, and also, in the past, Roger denied sharing of any links.
Please open a new topic to discuss. This is an AMA thread and not appropriate for this discussion. Thanks.Thank you for the reply, bitcoinxio. It was getting lonely under the rug.
I am wondering what you mean though, calling your facts 'actual'?
Several is more than 2, but not many. Jstofi is a bitcoin sceptic, and edmundedgar and imaginary_username are anything but trolls.
Furthermore, how can a refusal to share links be seen as anything but an attempt to direct the masses to those places which benefit Mr. Ver solely, whether or not it's for the best in regard to those masses?
I have come to think it's a very relevant question and you can better weight people's opinions having an idea of how many Bitcoins they hold (or do not hold.) So Instead of asking their opinion on bitcoin, I'm now asking every participants the same question:"Never ask anyone for their opinion [...] Just ask them what they have -or don't have- in their portfolio"
Hi AndrewI will be answering questions starting at 10AM EST (3PM UTC) on Tuesday December 8.
We have produced a fork of Bitcoin Core that has some interesting features. For example, the Bitcoin Unlimited client chooses the "most-work" chain as the active chain regardless of block size, yet allows clients to "discourage" excessively large blocks.
Wow this sounds pretty interesting.
When did you start getting interested in bitcoin? How did you start getting interested in bitcoin? What aspect of bitcoin most attracted you to the space?
What are some of the plans of Bitcoin unlimited in the next month, next couple months and next year?
Yes, BU ideas are the product of many individual contributions.Hello sir. Is it true that bitcoin unlimited came together in the bitco.in forums, specifically 'gold collapsing bitcoin up'?
Yes. BU recognises that people who are not developers have important perspectives that need to be included in determining the future of Bitcoin.That forum seems to be a good place for free discussion... recently on /r/btc a moderator banned several users and told one to go have a snickers, and also, in the past, Roger denied sharing of any links.
Is this evidence that power corrupts, the risk of roger's new push ending up the same place those who left theymos' forums wanted to avoid...
What, if anything, can be done to make sure bitcoin unlimited doesnt fall victim to an ambitious, power seeking person to the detriment of bitcoin as a whole?
Edit: http://www.bitcoinunlimited.info/articlesOfFederation
My personal interests are absolutely aligned with the long term success of Bitcoin. I hold more bitcoins than financial advisors would deem appropriate. I don't hold on margin, and my salary is in an unrelated field so I'm not looking for a quick pump, which results ofc in the inevitable dump.Hello Andrew
I was re-reading Antifragile by iconoclast thinker Nassim Taleb recently. He writesI have come to think it's a very relevant question and you can better weight people's opinions having an idea of how many Bitcoins they hold (or do not hold.) So Instead of asking their opinion on bitcoin, I'm now asking every participants the same question:"Never ask anyone for their opinion [...] Just ask them what they have -or don't have- in their portfolio"
- Do you mind to tell us which percentage of your personal net worth and/or liquid assets you hold in Bitcoins ?
You can throw anything into the set of consensus rules but that does not mean it must or should be there. I believe that block size should be part of the network layer, not the consensus layer. In protocol design, there is a aphorism "Be lenient about what you accept, and careful about what you produce". We can apply this to the block size. BU will accept (but discourage) very large blocks, and generate (mine) with a much more conservative block size.Hi Andrew,
Thanks for doing the AMA and driving this initiative forward. Two questions:
1. Many of the #bitcoin-wizards claim that all nodes must have exactly the same consensus rules. However, I understand that BitcoinUnlimited nodes can somehow adjust their individual block size limit, but still be guaranteed to track consensus. Can you explain this in more detail? Why do people like maaku, nullc, adam3us, kanzure, etc., claim that this is impossible? Have you proven that your technique works empirically?
I forget who came up with the name; you can look at the history of the bitco.in GCBU thread to find out!2. Why did you choose the name "Bitcoin Unlimited"? I understand that the block size limit is not necessarily unlimited.
This is an excellent question and it reflects the concern of many engineers who are used to being able to control operating parameters in great detail. However this kind of control is not possible in untrusted loosely coupled distributed computing and sometimes this is an advantage rather than a liability.Hi Andrew --
With unlimited block sizes, aren't you concerned that a few extra-large blocks will get included, that are near the threshold of what the network can currently tolerate? Wouldn't this put an undue strain on the network since all nodes would then have to "swallow" these lumps to even start running (and every time they wanted to re-index the chain)? Wouldn't many otherwise perfectly adequate nodes be unable to participate?
Thank you!
It is truly unfortunate that some people choose to argue this using underhanded methods. And let me include in this pile the "scalability testing" spam that was probably generated by someone who wanted larger blocks. But I do not think we should spend a lot of time pre-emptively fighting against these underhanded methods -- especially the ones that encourage "mutually assured destruction".Hi theZerg
I expect that those in the bitcoin network who will face attempt to lift or remove the block size limit will face a huge denial of service attack from different forces of destruction. That is what we saw happen in August to those who adopted Bitcoin CT. The attackers won that battle. My main idea for dealing
Comments?
The 3 problem with this is:Second, do you see any ways a bitcoin owner can use his bitcoins to "vote" for a bigger block size?
Third, I fear some of the "smarter" bitcoin scaling solutions risk taking away the profitability of mining in the other end of the life cycle of the bitcoin system, ie when miners will need to earn large transaction fees to be profitable. That will only be possible if the miners get to include a large volume of transactions in their blocks. A small transaction fee from a huge number of transactions can still become a large income. If the miners are deprived of most of the transaction volume mining will not be profitable unless most miners leave the business. That will make the bitcoin network very vulnerable and might ultimately kill bitcoin. The solution is to let the block size grow and avoid implementing ”smarter” bitcoin scaling which risk undermining the long term profitability of bitcoin mining. Do you agree?
Best Regards
Bitcoinsteffen
http://bitcoinsteffen.com/en/
The Unlimited client lets each user configure the "excessive" block size. If a block is bigger than this size, it does not become part of the active chain (its not fully accepted by your client) until the rest of the network has essentially indicated that it accepts this block size by mining N (the user picks N) blocks on top of it. At that point the Unlimited client accepts the excessive block and the block is added to the active chain.Hi Andrew
Thanks for doing this.
Can you give some more detail, (preferably not too technical) on how the Unlimited client discourages large blocks. How does this incentive work in practice? There seems to be quite some talk of removing the block size limit altogether and leaving it to the free market, but the main argument against this is 'mining decentralization', in your mind how does this play out?
That sounds awesome! It's like we can have the benefits of a limit and the benefits of NO limit at the same time.You can throw anything into the set of consensus rules but that does not mean it must or should be there. I believe that block size should be part of the network layer, not the consensus layer. In protocol design, there is a aphorism "Be lenient about what you accept, and careful about what you produce". We can apply this to the block size. BU will accept (but discourage) very large blocks, and generate (mine) with a much more conservative block size.Hi Andrew,
Thanks for doing the AMA and driving this initiative forward. Two questions:
1. Many of the #bitcoin-wizards claim that all nodes must have exactly the same consensus rules. However, I understand that BitcoinUnlimited nodes can somehow adjust their individual block size limit, but still be guaranteed to track consensus. Can you explain this in more detail? Why do people like maaku, nullc, adam3us, kanzure, etc., claim that this is impossible? Have you proven that your technique works empirically?
The way this works in Bitcoin Unlimited is that the generated (mined) maximum block size is separated from that of the received block size. And the received block size limit is replaced with the concept of an "excessive" block. An excessive block is bigger than this node's operator desires that the network produce.
What happens is that Bitcoin Unlimited tracks the "most work" chain. Let's say the current active chain tip is block N. If block N+1a is an "excessive" block, that block is essentially considered a fork. The active chain stays at N. If the "excessive" fork grows beyond a parameter we call the "acceptance depth" (A), then it (N+A) becomes the active chain. If people ignore the excessive block and mine a block N+1b then that becomes the active chain tip and the excessive block N+1a is orphaned. The BU client "helps" the network ignore the excessive block by refusing to relay it -- this allows the client to essentially "vote" for its block size preference.
I have triggered these excessive block forks and rejoins on regtest (its essentially your own private blockchain), and Bitcoin Unlimited clients have been involved in the fracas on testnet, including mining both < 1MB and > 1MB blocks. On testnet I unwound over 1000 blocks on the < 1MB fork and switched to the > 1MB fork. This situation is unlikely to happen on mainnet and I'll be honest it needs optimization -- 100% CPU for many hours.
I haven't heard any Core devs offer an opinion one way or another.That sounds awesome! It's like we can have the benefits of a limit and the benefits of NO limit at the same time.
You can throw anything into the set of consensus rules but that does not mean it must or should be there. I believe that block size should be part of the network layer, not the consensus layer. In protocol design, there is a aphorism "Be lenient about what you accept, and careful about what you produce". We can apply this to the block size. BU will accept (but discourage) very large blocks, and generate (mine) with a much more conservative block size.
The way this works in Bitcoin Unlimited is that the generated (mined) maximum block size is separated from that of the received block size. And the received block size limit is replaced with the concept of an "excessive" block. An excessive block is bigger than this node's operator desires that the network produce.
What happens is that Bitcoin Unlimited tracks the "most work" chain. Let's say the current active chain tip is block N. If block N+1a is an "excessive" block, that block is essentially considered a fork. The active chain stays at N. If the "excessive" fork grows beyond a parameter we call the "acceptance depth" (A), then it (N+A) becomes the active chain. If people ignore the excessive block and mine a block N+1b then that becomes the active chain tip and the excessive block N+1a is orphaned. The BU client "helps" the network ignore the excessive block by refusing to relay it -- this allows the client to essentially "vote" for its block size preference.
I have triggered these excessive block forks and rejoins on regtest (its essentially your own private blockchain), and Bitcoin Unlimited clients have been involved in the fracas on testnet, including mining both < 1MB and > 1MB blocks. On testnet I unwound over 1000 blocks on the < 1MB fork and switched to the > 1MB fork. This situation is unlikely to happen on mainnet and I'll be honest it needs optimization -- 100% CPU for many hours.
But I'm still confused on why the Core devs disagree with you about this. I thought I've even heard some of them say that it's impossible for nodes to come to consensus without all having the EXACT same rules--even bug-for-bug compatibility. Is the idea just too new and perhaps they haven't properly understood it, or thought about it enough?
If BU exceeds regular Bitcoin in censorship resistance, I would hope that BU becomes the 'primary reserve currency'; otherwise, people will have to first interface with a possibly centralized cryptocurrency (settlement layers, etc) before interacting with the BU ecosystem.I am not at all concerned about fragmentation of value. The market for digital currencies follows a power-law distribution (also known as a long-tail). Most of the value (90%) will be in 2-3 coins, with the other 10% divided among hundreds or thousands of coins.
In fact, alt-coins benefit bitcoin. Bitcoin is the primary reserve currency that supports all alt-coins. Want to buy an alt-coin? You have to spend bitcoin! All this ends up creating more liquidity and investment in bitcoin, as much as it fragments the value.
Bitcoin Unlimited is not an altcoin or a fork; its a bitcoin client like XT and Core. The difference is that it tracks the most-work blockchain regardless of block size. So if bitcoin forks, BU will follow the fork with the mining majority. That could be the < 1MB core fork, or it could be some > 1MB fork. It does this because we agree with Satoshi that the consensus algorithm appropriate for the blockchain is also appropriate for consensus on these issues. The final sentence of the Bitcoin white paper states:Elsewhere Andreas wrote this:
If BU exceeds regular Bitcoin in censorship resistance, I would hope that BU becomes the 'primary reserve currency'; otherwise, people will have to first interface with a possibly centralized cryptocurrency (settlement layers, etc) before interacting with the BU ecosystem.I am not at all concerned about fragmentation of value. The market for digital currencies follows a power-law distribution (also known as a long-tail). Most of the value (90%) will be in 2-3 coins, with the other 10% divided among hundreds or thousands of coins.
In fact, alt-coins benefit bitcoin. Bitcoin is the primary reserve currency that supports all alt-coins. Want to buy an alt-coin? You have to spend bitcoin! All this ends up creating more liquidity and investment in bitcoin, as much as it fragments the value.
Given these assumptions, how would you envision the BU ecosystem scaling in such a way to facilitate the transfer of wealth from a more centralized system to one which is free and censorship resistant - the ideal to which I presume BU aspires?
Thank you!
So unless an altcoin overtakes bitcoin, the Bitcoin Unlimited client will likely be on the Blockchain that today's Bitcoin exchanges are using.They [nodes/miners] vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism. (emphasis added)
I believe that the market should be making the decision of what should be on the Blockchain based on transaction fee, not Gregory Maxwell.Since Bitcoin is an electronic cash, it _isn't_ a generic database;
the demand for cheap highly-replicated perpetual storage is unbounded,
and Bitcoin cannot and will not satisfy that demand for non-ecash
(non-Bitcoin) usage, and there is no shame in that. Fortunately, Bitcoin
can interoperate with other systems that address other applications,
and--with luck and hard work--the Bitcoin system can and will satisfy
the world's demand for electronic cash.
I haven't thought about it; don't really think it matters so long as it is > a half dozen or so.@Andrew, thanks for all you are doing in the space...
So, I think we have a few core clients now; Bitcoin Core, BitcoinXT, Bitcore, LibBitcoin, BitcoinJ... is that about right? and so now we have Bitcoin Unlimited (thanks to you!!).
Questions:
So how many clients would you like to see out there?
The choice of language should emerge from your goal in writing a new node. Performance? Serving web clients? Blockchain analysis? Its easier to accomplish different tasks with different languages.If I were to write a full authoritative node, what language would you suggest?
This is an interesting question. I would say both. What I mean is that I feel like the "wallet" functionality of full node clients is not so important any more. However I would love to see a full node and lightweight client co-developed... the lightweight client is essentially the "wallet" for the full node, but can fall back on standard SPV protocols in a pinch. With such an architecture you could do a lot of interesting things and add node -> client features rapidly. I think the mycelium client is FOSS so I would start there.Is it worth developing another client or should efforts be focused on light weight clients?
We are currently carefully limiting the feature set to Bitcoin Core + unlimited blocks & optional traffic shaping. So it hasn't taken long. The organizational stuff took longer. We are just getting started.How long did the fork take?
The client has code AcceptBlock that returns True/False. The biggest trick was expanding that to return True/False/Maybe and dealing with the effects of blocks that are not yet accepted but also not rejected.What was the biggest hurdle(s)?
That's what an engineer who is not used to thinking adversarially might say....even if they were included in in the active chain they will consume resources that result in smaller subsequent blocks, resulting in a maximum network-wide average txn throughput via a process I will describe in a forthcoming paper.
Return to “AMA - Ask Me Anything”
Users browsing this forum: No registered users and 9 guests