Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
@lunarboy @cypherdoc if the text files provided by @awemany are in computer parsable format it's just a matter of @Bloomie tranform them in a xenforo compatible format and putting it in the forum database. Maybe a little bit tricky but doable.
Christoph Bergmann
Active Member
Hello, Christoph Bergmann here, editor of bitcoinblog.de.
While I try to stay balanced on the whole scaling-issue, I think there is no bitcoin-media that covered this debate as closely as bitcoinblog.de
About one week before the release of bitcoin unlimited I watched the blocks and the unconfirmed transactions. Based on the fact that there are some times thousands or ten-thousands of trancactions waiting for confirmations while blocks are not full I came to the conclusion, that there needs to be a natural, non-artificial limit for the block size (the orphans).
I was excited that Bitcoin Unlimited uses this mechanism to let the market decide about the blocksize. I need further research to decide, if unlimited really is a practicable solution or if it is a open door for attacks ... but I like it. It gives me hope we can come over this mess.
Please excuse me, I can't resist to give you some feedback.
- I like the picture and the color-scheme, even if it's unclear what the message of the picture is.
- you should work with headlines and <bolds>. So it's a wall of text.
- with media like this you should save every letter. Why "oftentimes" instead of "often"? Why not make it stronger: "mostly" or "usually"?
"Usually, the simplest solution is the most elegant and best solution."
Besides: in line 3 of the main block "them" is to near to the white leave of the flower.
While I try to stay balanced on the whole scaling-issue, I think there is no bitcoin-media that covered this debate as closely as bitcoinblog.de
About one week before the release of bitcoin unlimited I watched the blocks and the unconfirmed transactions. Based on the fact that there are some times thousands or ten-thousands of trancactions waiting for confirmations while blocks are not full I came to the conclusion, that there needs to be a natural, non-artificial limit for the block size (the orphans).
I was excited that Bitcoin Unlimited uses this mechanism to let the market decide about the blocksize. I need further research to decide, if unlimited really is a practicable solution or if it is a open door for attacks ... but I like it. It gives me hope we can come over this mess.
Please excuse me, I can't resist to give you some feedback.
- I like the picture and the color-scheme, even if it's unclear what the message of the picture is.
- you should work with headlines and <bolds>. So it's a wall of text.
- with media like this you should save every letter. Why "oftentimes" instead of "often"? Why not make it stronger: "mostly" or "usually"?
"Usually, the simplest solution is the most elegant and best solution."
Besides: in line 3 of the main block "them" is to near to the white leave of the flower.
With BU there is no "we" that can compromise and no object to compromise on. Each individual sets his/her excessive size (with is not a limit) as he/she sees fit.
Having said that, I would agree to create a BUIP that suggests setting the default excessive block size to 2MB for a period of 1 year.
- Aug 28, 2015
- 517
- 1,679
Thanks for the feedback Christoph. As far as i know @Windowly generated the graphic and deserves the attribution and credit. I will suggest some changes based upon your suggestions.Hello, Christoph Bergmann here, editor of bitcoinblog.de.
While I try to stay balanced on the whole scaling-issue, I think there is no bitcoin-media that covered this debate as closely as bitcoinblog.de
About one week before the release of bitcoin unlimited I watched the blocks and the unconfirmed transactions. Based on the fact that there are some times thousands or ten-thousands of trancactions waiting for confirmations while blocks are not full I came to the conclusion, that there needs to be a natural, non-artificial limit for the block size (the orphans).
I was excited that Bitcoin Unlimited uses this mechanism to let the market decide about the blocksize. I need further research to decide, if unlimited really is a practicable solution or if it is a open door for attacks ... but I like it. It gives me hope we can come over this mess.
Please excuse me, I can't resist to give you some feedback.
- I like the picture and the color-scheme, even if it's unclear what the message of the picture is.
- you should work with headlines and <bolds>. So it's a wall of text.
- with media like this you should save every letter. Why "oftentimes" instead of "often"? Why not make it stronger: "mostly" or "usually"?
"Usually, the simplest solution is the most elegant and best solution."
Besides: in line 3 of the main block "them" is to near to the white leave of the flower.
Bitcoin Unlimited is a grassroots response to this bitcoin crisis moment led by the commenter above this post TheZerg.
- Aug 19, 2015
- 510
- 803
99% impossible without theymos sharing his MySQL files with us.
It seems like one of the r/bitcoin mods is going rougue and is leaking mod logs on r/btc.
Bitcoin drama never ceases to amaze...
Bitcoin drama never ceases to amaze...
Given how many times I've had to change a password over there because someone waltzed through the site's security, surely it can't be that hard to get a copy of those files.
The 2MB comment was referring to other BIP's BTW, not BIP101/Xt/Bitcoin Unlimited.
Christoph Bergmann
Active Member
Hallo, you're welcome
I'm lurking this thread for some time, so I think I'm up to date, but didn't find the time on christmas to meditate about technical posts and to make my newly installed ubuntu to run unlimited (I know there is a thread in this forum about this, but problem is more my completely unteachedness with ubuntu than anything else).
But I wrote about the unlimited release and brought 36 readers to the projects website (hehe, german bitcoin community is small and like christmas at home)
What I don't understand: If any core dev comments on unlimited (it seems to happen rarely), it's like "can't work" or "is madness". While this unexplained downvote is typical for the ungood mentality riding us into a civil war I'd like to find a summary about things people think are risks and your counter-argument.
The name "unlimited" looks at first like "Let's just make the blocksize infinite". I know, it's more behind, but most people will think "Infinite blocks? Ha. There is not even a consensus about 8 MB blocks. This is madness".
So your claim should more be like "Let the user set the block limit".
Just some thoughts about that.
- Aug 19, 2015
- 510
- 803
Hah true, but I don't want to steal their crap. When the last intelligent person leaves Bitcointalk, theymos might come here asking for a part-time position and we can ask for the files then.
Yes, I wish the same to everyone!
One thing that I'd like to point out is that the serif font looks a little bit odd on that site. But I also have to say I personally do not care too much...
Oh, and: Thank you for doing this!
I still like to keep a somewhat lower profile and I feel I am just another Bitcoiner adding a little bit of input. At some point I might go full name maybe. Until then, please keep it just 'awemany'
@Taek:
A very warm welcome to this place from me, too. With all us zealous bigblockers around
, we might have the danger of turning into an echo chamber. So non-trolling critical voices are very much welcome!I was going to write you a lengthy response, but then saw that others such as @Peter R. covered most of the points I was going to say.
Two more things: 1. The fact that we have an 1MB limit now shows that there is resistance against increasing blocksize and BU doesn't remove that but adds channels to express it in better and hopefully more productive ways. I think some of it is real concern, but a lot of is the broken communication channel that is Bitcoin Core. I think a decentralized approach like BU will at least help in creating additional and better communication channels for determining the effective block size limit.
I am personally also fine with higher requirements for full nodes, the scenario 'bigger full node in data centers' is fine with me - and it was clearly the same for Satoshi.
Let me further add here that I told GMaxwell (on reddit) - as the prominent, quintessential and leading smallblocker - that I'd be fine with 1000 full nodes worldwide long term - and gave him a dead-simple calculation on how much the operation per transaction of these 1000 full nodes would cost (in the tens of microdollar range...). He replied that I am surprisingly forthright as a bigblocker about my Bitcoin vision, and said that it is a vision he does not share at all. Yet he didn't counter with his own vision at all. Something that he now did for all of us, I guess, with his roadmap post. At least the fronts are pretty clear now and it should also be noted that BIP-101 (which I'd be fine with in terms of possible growth rate) is still likely to keep full node operation within reach of a band of hobbyists. It took a long while to get the whole discussion to a point where the differences in blocksize opinion are that clear. I think this is a good example of broken communication through the 'Bitcoin Core channel' - almost from a position of 'underdogs', a large fraction of the Bitcoin ecosystem (I still suspect the vast majority) argued with a stalling Core team for bigger blocks and this was by no means an effective way of coming to a compromise - and it also finally failed.
2. The whole blockside discussion focused way too much on the supply side of blockspace. In addition to the argument that a growing Bitcoin transaction rate is expected by many (including myself) to be strongly correlated with coin price, there is another whole field worth of investigation IMO, and that is transaction brokerage. Signed transactions are worth something! Local nodes (and here there might be a speed-of-light-advantage for doing so, too) or local full miners might pop up that collect transactions and forward for a small cut/mine them. I could imagine that there is at least a slight decentralizing force that pulls towards wherever transactions are actually made.
@cypherdoc: Regarding the logs, before we put stuff up here, we should make sure that it is o.k. copyright-wise. robots.txt didn't argue against crawling GCBU on BCT, but I am not yet sure whether it is ok to reproduce the full thread here. IANAL...
@all: Finally, let me add that I pondered an idea that I had (and others probably, too...) before about BU and a 'minimum changeset' big block client.
The minimum change to core to support bigger blocks would be just a change of the blocksize constant. One could create a script that takes the core git, and cycles the MAXBLOCKSIZE constant by patching the source through an exponential ramp of .0625MB, .125MB, .25MB, .5MB, 1MB, 2MB, ... .
Binaries could be built for all such MAXBLOCKSIZE settings and be published on a website.
This is, of course, not trying to torpedo BU. I see it as just yet another possible way of letting express their wish for blocksize - and it would be the absolute minimum changeset needed for larger blocks.
Last edited:
lunar
Well-Known Member
- Aug 28, 2015
- 1,001
- 4,290
@Bloomie and @cypherdoc
They seem to have a copy here. Would that be of any use?
https://bitcointa.lk/threads/gold-collapsing-bitcoin-up.47680/
They seem to have a copy here. Would that be of any use?
https://bitcointa.lk/threads/gold-collapsing-bitcoin-up.47680/
here we go again. sorting by controversial:
https://www.reddit.com/r/Bitcoin/comments/3yj74h/lets_raise_the_block_at_2_mb_so_we_can_stop_this/
https://www.reddit.com/r/Bitcoin/comments/3yj74h/lets_raise_the_block_at_2_mb_so_we_can_stop_this/
@cypherdoc
Yes it's impressive! It looks like we (#13) are ahead of Luke-jr's implementation (#21), BitCore (#20 + #27) and bctd (#33) as well.
I believe we are now in third place (haha but with only 1.4% node share).
Yes it's impressive! It looks like we (#13) are ahead of Luke-jr's implementation (#21), BitCore (#20 + #27) and bctd (#33) as well.
I believe we are now in third place (haha but with only 1.4% node share).
Windowly
Active Member
- Dec 10, 2015
- 157
- 385
Hehe, thank you @Inca and @Christoph Bergmann. I tried to upload a new one (because I noticed that I used 'often' two times) but my internet died. (Here is the one without the extra 'often'. )
Your suggestions are good. I'll try to make a couple different versions and upload them so they can be used in different settings.
It's encouraging to see how it has taken off and fostered discussion over at r/btc. Let's all make more memes of this sort to explain key points! I really liked the spoon one as well.
[doublepost=1451347656,1451346483][/doublepost]
Hehe thank you for the complimentthis is quite elegant:
Last edited:
- Aug 28, 2015
- 517
- 1,679
I have been all over /r/bitcoin /r/btc and /r/bitcoinxt linking to the bitcoinunlimited website throughout the day to try and build up some momentum. It is great to see the node count rising upwards. We are already approaching 1.5% of the network!
lunar
Well-Known Member
- Aug 28, 2015
- 1,001
- 4,290
@theZerg
Surely the following is from something I must have read somewhere, but I can't place it? At the risk of sounding stupid, here goes anyway.
I was thinking about partial chain validation and reducing the size of the blockchain for home nodes. Would there be a way for a node to provably only validate say only 50% or 25% of the blockchain? (in each case including all related local transactions). There might even be a relay network amongst other nodes so 4 x 25% nodes could cryptographically confirm they held a 100% validated blockchain?
This idea would obviously reduce the pressure on locally stored data and remove the issue of loosing home nodes. Suppose if it were possible it could even be extended to 1000's of nodes so each could validate 5% of the chain?
Am I thinking of treechains and is there any mileage here?
Surely the following is from something I must have read somewhere, but I can't place it? At the risk of sounding stupid, here goes anyway.
I was thinking about partial chain validation and reducing the size of the blockchain for home nodes. Would there be a way for a node to provably only validate say only 50% or 25% of the blockchain? (in each case including all related local transactions). There might even be a relay network amongst other nodes so 4 x 25% nodes could cryptographically confirm they held a 100% validated blockchain?
This idea would obviously reduce the pressure on locally stored data and remove the issue of loosing home nodes. Suppose if it were possible it could even be extended to 1000's of nodes so each could validate 5% of the chain?
Am I thinking of treechains and is there any mileage here?
