l love the logos! Do you want to skin www.bitcoinunlimited.info? Its a Meteor site.
Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
It's my opinion that the those orphaned blocks is a good example of how block propagation is important, and mitigating risk to gain network consensus is fundamental to how bitcoin works, not just consensus among miners. The fact that the blocks were orphaned indicates to me the network is working as designed and the dominant fork won out.
I'm not yet convinced that BU is better if it would have chosen to go with the wrong fork, and if there were enough implementations they would have influenced the outcome and possibly prevented the empty blocks form orphaning.
[doublepost=1447798338][/doublepost]re: skinning www.bitcoinunlimited.info at a pinch I can help out but I'm not all that efficient at that stuff.
Love the graphics!! Especially the "infinity" sign in the shadowsI think the logo should be very close to the existing bitcoin logo. We are building on the existing Bitcoin Brand nothing is relay changing, you are just removing a software bug that limits block size, and adding a user defined limit for those who think the bug is not a bug. I think it has to be ultra conservative I agree with cyphor the less deviation the better.
Here is my take on what it could look like. It may be too much but my though was same old bitcoin just new and shiny.
I have a fiew launch screan images and a bunch of icon images of verious sizes @theZerg if you want to include them in a GUI.
[doublepost=1447795581][/doublepost]
so you can't force small blocks forever, but @Peter R why wouldn't all BU implementations start flowing the longest chain after 7 empty blocks were mined, The last time this happen they were orphaned, would that happen again if BU was the dominant implementation?
BitcoinUnlimited would not have followed the longest chain when the 7 empty blocks were mined. The "meta-cog" stuff only forks to the longest chain for transport-layer protocol uncertainty. Bitcoin U would have known that the 7-empty block chain was invalid so it would not have forked over.
Right now, I think the meta-cog stuff is *only* intended to work for block size limit uncertainty (but could later by used for max_sig_ops and max_bytes_hashed, etc.). For example, if somehow a chain that had a double-spend grew to be 10 blocks deep, Bitcoin U would *never* accept it.
Last edited:
@Peter R and @AdrianX Yes BU currently only follows the longest chain for block size. We might choose other attributes that it also makes sense to do this for. However, it should be obvious that there are other attributes (such as the coin limit, double spends, and a bunch of unintelligible garbage for example) where the client would not follow the longest chain.
@AdrianX You seem pretty good to me! But ok I'll ping you if there are no other volunteers. But meanwhile, can you start a topic over in development and stick all the work you've done in there?
@AdrianX You seem pretty good to me! But ok I'll ping you if there are no other volunteers. But meanwhile, can you start a topic over in development and stick all the work you've done in there?
I also prefer KISS - just removing the cap and supporting BIP 101 flags. flowed by user adjusted cap and your node falls out of consensus if the limit is inappropriately set.
Don't bother. Who cares? And the more they obviously deviate from their own supposed "rules" the more people see that there ARE no actual rules.
@AdrianX : My concern without the meta-cognition stuff is that people will FUD over the "network split attack" that becomes possible during a "spontaneous consensus" event when the effective block size limit steps upwards. I think what we're proposing is the only design where nodes can both discourage "excessive" blocks and be guaranteed to track consensus.
Last edited:
Also, WRT the discussion with jonny1000, consensus follows the "most difficult" chain which is often but not always the longest. So in your talk, it would be better to use "most difficult" rather than longest.
Second, @jonny1000 you seem to think that our approach reduces convergence to consensus. But actually, it allows the BU node to maintain consensus with the majority of miners in the face of a blockchain fork (and has no effect otherwise).
It has no technical effect on the event that first breaks consensus. It may have a social effect by illuminating how many people are on the large block side, and therefore encouraging the first >1MB block which will either force Bitcoin Core to change their stance or fork the blockchain.
Second, @jonny1000 you seem to think that our approach reduces convergence to consensus. But actually, it allows the BU node to maintain consensus with the majority of miners in the face of a blockchain fork (and has no effect otherwise).
It has no technical effect on the event that first breaks consensus. It may have a social effect by illuminating how many people are on the large block side, and therefore encouraging the first >1MB block which will either force Bitcoin Core to change their stance or fork the blockchain.
I keep coming back to the idea that anything user-selectable should be fine* because that's the endgame, I mean, someone is going to offer it eventually via a mod or something, so Bitcoin should be robust enough to allow users to choose. With that in mind, defaulting to infinite seems fine. In theory, the only thing to watch out for when giving users choice is that you don't accidentally push them toward some bad choice.
As per Peter's thought experiment where users can adjust the block reward, too, why not? There may be some radically unforeseen eventually where it becomes necessary and then users would just upgrade to some new version to effect that change. Why not give them as many options as possible so they don't have to upgrade? Otherwise we are tacitly assuming trusting the user with user-friendly setting of parameters is too dangerous, and thereby tacitly assuming Bitcoin's future downfall when there are easy mods floating around to let people do such things without technical know-how.
*maybe not tactically though
As per Peter's thought experiment where users can adjust the block reward, too, why not? There may be some radically unforeseen eventually where it becomes necessary and then users would just upgrade to some new version to effect that change. Why not give them as many options as possible so they don't have to upgrade? Otherwise we are tacitly assuming trusting the user with user-friendly setting of parameters is too dangerous, and thereby tacitly assuming Bitcoin's future downfall when there are easy mods floating around to let people do such things without technical know-how.
*maybe not tactically though
Just reading jonny1000, I tend to agree there will be lots of FUD, I think just doing what it says on the can is a better option. Unlimited (and user adjustable) is easy to understand. It's the investors (the network of bitcoin users) that decide. If a bitcoin fork actual happens, (where Core refuse to change) its going to be short lived, people are going to be spending coins (scamming) the one fork to death whether that happens in a prediction market or not.
I don't think we need to tread lightly around that process happening in an uncontrolled way BIP101 already has a notice period and this fork is going to be big. Reporters are going to lap this up a 3-4 year conflict coming to a resolution, users taking control of bitcoin direction, the mainstream media are going to embark on a bitcoin education drive and are going to help fill those bigger blocks.
I don't think we need to tread lightly around that process happening in an uncontrolled way BIP101 already has a notice period and this fork is going to be big. Reporters are going to lap this up a 3-4 year conflict coming to a resolution, users taking control of bitcoin direction, the mainstream media are going to embark on a bitcoin education drive and are going to help fill those bigger blocks.
Last edited:
@Zangelbert Bingledack: I strongly feel that the block reward stuff is best left as a thought experiment. Since the vast majority of holders are happy with the block reward schedule, why even go there? People will just use that option as an attack vector. I don't think the community is ready to understand that it was never the code in the first place--instead, they've been the ones in control all along.
Pindar (Hong Kong Scaling Bitcoin Chair) just called me and we had a pleasant 40 min chat. It was very nice to hear that he was worried about people harassing me both online and at the conference (e.g., face to face or over IRC), given that my views challenge those of some of the other presenters. He said that it was very important to create an environment where all technical ideas could be presented openly and without fear of backlash. I think the "no debating" rule is actually good, as it allows people to get their thoughts and entire arguments out without being bullied by aggressors.
WRT reward schedule, theoretically you may be right but politically its suicide and technically its wasting time coding and testing a feature that has almost 0 likelihood of being used. Also, I would not want my name associated in any way with that kind of change so I won't be the one implementing it...
albin
Active Member
- Nov 8, 2015
- 931
- 4,008
This is the Bitcoin that I thought we all signed up for in the first place, but somehow this message has gotten extremely diluted over time.
@Peter R
Please keep fighting.
I for one support your ideas but most of your supporters imo are the ones that arent out extremeists and more sensible.
Please keep fighting.
I for one support your ideas but most of your supporters imo are the ones that arent out extremeists and more sensible.
albin
Active Member
- Nov 8, 2015
- 931
- 4,008
I don't know if this is a good analogy, but I feel like changing the 21 million coins is kind of like changing the definition of the meter. It could be done, but the network effects of having that common standard are so useful, and the number is fairly arbitrary, that there would have to be an extremely compelling reason to get momentum for that kind of change. Whereas the max blocksize is maybe more like a pragmatic social norm, such as the inappropriateness of entering a retail establishment and dumping thousands of pennies to pay, or the expectation of standing on a certain side of an escalator so that people who want to pass can walk up the other side.
lunar
Well-Known Member
- Aug 28, 2015
- 1,001
- 4,290
This was mine concern. Though I haven't voiced it, because I wasn't sure if it was valid?
Does this not open up a new economic attack vector?
Say some entity launches thousands of nodes, 60 000 for example 100x the current network levels. Then sets a super small blocksize. Does this not end up holding the network hostage and thus also the blocksize cap?
Re the point above wouldn't this make bitcoin vulnerable to a Sybil attack?
And on a positive note the tide is turning Bitcoin is looking more resident than prior to the debate.
https://www.reddit.com/r/btc/comments/3t665f/block_size_limit_considered_harmful_to/
And on a positive note the tide is turning Bitcoin is looking more resident than prior to the debate.
https://www.reddit.com/r/btc/comments/3t665f/block_size_limit_considered_harmful_to/
WRT luke-jr: if 51% of the miners want smaller blocks they can have them today without BU. Just don't produce bigger ones. Its a command line option. And the max block size to accept is a constant. So 1 simple line of code needs to be changed to ignore blocks bigger than N.
RE: Sybil attack. Yes, the network is vulnerable to this kind of attack with our without BU. In fact you can see this happening today on testnet WRT bitcoin-xt. There are so many 1 MB nodes relative to the # of XT nodes that we have to explicitly connect our nodes to each other (of course, that's pretty easy to do). And BTW, if you have the resources and desire to launch 60000 nodes, a few changes to the source code will not put you off -- having access to BU is irrelevant.
Part of the point of Bitcoin Unlimited is that nodes HAVE this power today. Ignoring this fact is sticking your head in the sand... and so we might as well use this power for positive feedback on the network's capacity rather than pretend that it does not exist.
[doublepost=1447818554][/doublepost]Does any block explorer have an API and store time of receipt along with the block's timestamp?
- Aug 22, 2015
- 1,558
- 4,693
@AdrianX really nice work.
I took your inspiration and made a mock-up of a block settings pane (realise this is not the dev thread, but on the current topic of general interest...).
The bandwidth tracking is defaulted to BIP101 settings (annual increase percentage is rounded up). Miner voting is greyed out as BIP100 does not yet exist.
[doublepost=1447822840,1447821773][/doublepost]With respect to Johnny1000's double-spending concern, I agree with @Peter R that this is overblown.
The reality is that the network would quickly converge on a "consensus" block limit and miners would tip-toe higher as each time a block-size record occurs the orphaning risk would be fairly high. Users are unlikely to reduce their selected block limit very often so the trend should be punctuated increases which occur infrequently.
A double-spend is a risk only to the receiver of the bitcoins. If that user is expecting a payment and is in the rare situation of finding a recent excessively large block and a fork situation, then waiting for six or more confirmations before delivering the goods becomes a sensible option.
I took your inspiration and made a mock-up of a block settings pane (realise this is not the dev thread, but on the current topic of general interest...).
The bandwidth tracking is defaulted to BIP101 settings (annual increase percentage is rounded up). Miner voting is greyed out as BIP100 does not yet exist.
[doublepost=1447822840,1447821773][/doublepost]With respect to Johnny1000's double-spending concern, I agree with @Peter R that this is overblown.
The reality is that the network would quickly converge on a "consensus" block limit and miners would tip-toe higher as each time a block-size record occurs the orphaning risk would be fairly high. Users are unlikely to reduce their selected block limit very often so the trend should be punctuated increases which occur infrequently.
A double-spend is a risk only to the receiver of the bitcoins. If that user is expecting a payment and is in the rare situation of finding a recent excessively large block and a fork situation, then waiting for six or more confirmations before delivering the goods becomes a sensible option.