Gold collapsing. Bitcoin UP.

[cypherdoc]

the divergence deepens:

 

[cypherdoc]

no wonder Trace Mayer has been sounding more urgent:

https://bitcointalk.org/index.php?topic=1219010.msg12811257#msg12811257

folks, i've said forever, just invest in the currency unit. it's much safer and your returns much greater.

 

[molecular]

this is cool:

https://www.steelpasswordmanager.org/steel.1.html

It's probably cool and the code can be audited, but the name 'steel' in combination with the fact that they're targeting bitcoiners... ;-)

 

[Justus Ranvier]

no wonder Trace Mayer has been sounding more urgent:

https://bitcointalk.org/index.php?topic=1219010.msg12811257#msg12811257

I really don't think they've thought this through.

Every bitcoin thief in the world wants there to be centralized list of cold storage users (who presumably have more bitcoins available to be stolen than the average user).

Once that list exists, and once those users are convinced to accept a closed source Bitcoin wallet, it it makes the potential payoff sufficiently high that the skilled thieves will be willing to invest a lot of time compromising Armory, more than they'd be willing to invest if they couldn't target individual known users and had a greater chance of getting caught.

 

[cypherdoc]

haha, no rate hike FOMC. quelle surprise.

stocks whipping around like a hooked fish (straight down for now).
[doublepost=1446055839][/doublepost]gold totally giving up it's massive pump from this morning. silver following.

buy Bitcoin.

 

[cypherdoc]

huge $30 whipsaw from high to low in gold after FOMC.

ZSL still looking good:

 

[cypherdoc]

great chart:

 

[cypherdoc]

what a recovery in the $DJI by end of day.

 

[rocks]

@theZerg
my concern is one of political palatability. less could be more in this situation.

the way i've come to look at this is that block size was only made a pseudo-technical issue by core dev b/c of the political issue of COI. if we remove the limit completely, it no longer becomes an issue at_all since it should be completely handled by the free mkt. therefore making configurability a non-issue. it would certainly play well with the masses (and even ourselves) as we can always say "hey, look at us, we're offering block size configurability!" but does it really matter given how the issue evolved politically in the first place and that we always could set it at the CLI?

If you look at the moderated bitcoin-dev mailing list, it is apparent that the core devs are not going to address the blocksize issue, prior to blocks becoming full and blocksize becoming an issue. They are going to try and force an artificial fee market that the market will lot like.

The opportunity for BU is to be a waiting and ready alternative for people to look at and adopt as the artificial limit becomes more and more painful and limiting.

As cyperdoc said, what is needed is to make this as apolitical as possible. This is important because if you look at XT, the core devs used every strawman argument and piece of FUD they could come up with to attack XT. They accused Hearn and Gavin of inserting unknown code for this own benefit, of XT implementing things other than blocksize, of false incompatibilities with core, of being closed source, etc etc etc.

To counter this, BU should have the fewest changes possible only limited to blocksize, and to be easily and clearly diff'able in github from the main core code. i.e. the diff shows only 10 lines changed, to vote for BIP101/100 and remove the limit.

This removes their ability to make false statements and scare people. It is now easy to show everyone that BU is the exact same thing, just with the limit removed. It forces all discussion to be on blocksize (which the market will be feeling pain from) and eliminates attempts at using FUD to stall adoption.

If it is done any other way, they are going to use every scare tactic and source of FUD, just as they did with XT.

Our goal should be to offer a BU alternative that is as difficult as possible to falsely attack with FUD. I understand the sentiment to fix a bunch of other things, but that confuses the main issue and gives them a vector to attack BU. By keeping BU as simple as possible with minimal changes from core, we reduce this.

 

[cypherdoc]

as an ordinary investor in GoPro, you didn't even have a chance to get out. how many times have i shown this exact chart over the years of an after hours selloff of 20% or more?:

 

[theZerg]

Its a strong argument. And I can't really claim any skill or expertise in anticipating how others think. How about we have a base release that just removes the limit and a branch on top of that that adds configurability? We will "officially" release the base to everyone, but point to the configurable release for power users who want to tweak and optimise... kind of like ubuntu vs lubuntu or ubuntu MATE

 

[Peter R]

If you look at the moderated bitcoin-dev mailing list, it is apparent that the core devs are not going to address the blocksize issue, prior to blocks becoming full and blocksize becoming an issue. They are going to try and force an artificial fee market that the market will lot like.

The opportunity for BU is to be a waiting and ready alternative for people to look at and adopt as the artificial limit becomes more and more painful and limiting.

As cyperdoc said, what is needed is to make this as apolitical as possible. This is important because if you look at XT, the core devs used every strawman argument and piece of FUD they could come up with to attack XT. They accused Hearn and Gavin of inserting unknown code for this own benefit, of XT implementing things other than blocksize, of false incompatibilities with core, of being closed source, etc etc etc.

To counter this, BU should have the fewest changes possible only limited to blocksize, and to be easily and clearly diff'able in github from the main core code. i.e. the diff shows only 10 lines changed, to vote for BIP101/100 and remove the limit.

This removes their ability to make false statements and scare people. It is now easy to show everyone that BU is the exact same thing, just with the limit removed. It forces all discussion to be on blocksize (which the market will be feeling pain from) and eliminates attempts at using FUD to stall adoption.

If it is done any other way, they are going to use every scare tactic and source of FUD, just as they did with XT.

Our goal should be to offer a BU alternative that is as difficult as possible to falsely attack with FUD. I understand the sentiment to fix a bunch of other things, but that confuses the main issue and gives them a vector to attack BU. By keeping BU as simple as possible with minimal changes from core, we reduce this.

OK, I think I'm starting to agree (for the record, I still love the meta-cognition stuff but perhaps that can come later or from a different repo as @theZerg mentioned).

But do we set the static variable MAX_BLOCK_SIZE to INFINITY? Or do we change it to a dynamic variable max_block_size with INFINITY as default, but still adjustable with a command line argument upon launch? I think either way would involve only minor code changes.

Edit: by INFINITY I mean a big number like 2^30 or something.

 

[cypherdoc]

I'd like to return the block size to what it was before satoshi capped it at 1MB. As far as I know that was a static limit of infinity. The reason for this is I'd like to be able to point to the code and say, "look, they simply restored the code to what satoshi originally envisioned. No more, no less".

I'd like to minimize the code line diff at github to the smallest number possible, again for the same reason. Thus, I'd leave out any references to 100 & 101 and certainly no personal projects. If like to be able to say, "look they only changed 8 lines of code for block size".

I'd also save the configurable overlay for later. That's if BU takes off, which we'll be lucky as is. But if lucky, core devs like @theZerg will be in a great position to effect change.

We need more core devs, like Gavin, if possible. We need diversification of ownership of the website assets.

 

[theZerg]

@cypherdoc If we set the max block size to VERY large it will probably be fewer code changes than eliminating it entirely. The current code is structured kind of like:

MAX_BLOCK = 100000

Then in various places:

if (blockSize > MAX_BLOCK) ...

So if we just bump MAX_BLOCK up to 2^63 that is the only change. But if we eliminate the check entirely we need to comment out the "if" statements.

I thought that BU was additionally going to vote for 100 & 101. Is that also out of the baseline?

 

[Peter R]

It's been awhile since I looked at that code. Isn't MAX_BLOCK set with a #define statement? If so, I still think we should consider doing something like:

#define INFINITY 1073741824 // 2^30

uint64_t max_blocksize = INFINITY;

and then

if (blockSize > max_blocksize) ...

and somewhere else in the start up code

if(custom_blocksize_flag) max_blocksize = custom_blocksize;

 

[cypherdoc]

what does this do?:

if(custom_blocksize_flag) max_blocksize = custom_blocksize;

 

[Peter R]

It would be part of the code to support user-configurable block size limits (if we want to do that). We would add blocksize limits to the command-line options described here.

For example, if you launched bitcoind like:

./bitcoind

the program would skip that "if" statement and max_blocksize would remain set to INFINITY. However, if you launched bitcoind like this:

./bitcoind -customblocksizelimit=8000000

then the "if" statement would be triggered* and max_blocksize would be set to 8000000.

*A bit more code would be required to process the extra optional command line argument but I think the code changes would still be very minimal and easily understandable.

 

[AdrianX]

@cypherdoc If we set the max block size to VERY large it will probably be fewer code changes than eliminating it entirely. The current code is structured kind of like:

MAX_BLOCK = 100000

Then in various places:

if (blockSize > MAX_BLOCK) ...

So if we just bump MAX_BLOCK up to 2^63 that is the only change. But if we eliminate the check entirely we need to comment out the "if" statements.

I thought that BU was additionally going to vote for 100 & 101. Is that also out of the baseline?

BIP 100 is a hot potato, BIP101 is a real solution, one I can get behind.

I'm also happy supporting 33.5MB with the understanding it was the original limit set by Satoshi, and only use it as a place holder until a cross disciplinary solution is uncovered. Having a limit may garner criticism as it’s not Unlimited Block size, maybe Unlimited represents entry and exist points in the network (the users as the most important metric).

Having a limit to the block size may also appeal to those who feel unlimited block size is undesirable but just want to raise the limit.

As for maximizing the use base I think we need to come up with a list of UX improvements.

The big one for me is governance, I'm not keen on doing anything if it’s going to end up like Core.

Another one is easy instillation. There must be hundreds of users who have old computers lying around willing to do a fresh install of Ubuntu and install a full node. (This was not easy for me and I don't consider myself computer noob. Installing XT on a fresh Ubunto setup is not easy. - After trying to install Bitcoin.XT.0.11C on top of 11B I have broken my node, not a good experiences at all given my available time. Now I've given up running XT because of it.

 

[rocks]

@theZerg
I like the idea of a base minimal change client, which later multiple extension clients can be built on top of (such as your configurable concept). This would in effect make the BU base the new core client where common code is implemented, and enable a more open and competitive market of extensions beyond the core code that individuals can freely make and adopt.

@cypherdoc
It would be cleanest to just drop the limit, but a problem with just dropping the limit is it is risky from an upgrade path and would kick off users who didn't upgrade without any warning. This is why previous upgrade paths followed either of these: 1) "at block XXX behavior changes this way" or "once X number of blocks announce a new version number behavior changes this way". BIP101 took the second approach.

What is nice about BIP101 is it seems straightforward to implement in a minimal impact manner. BIP100 does not have a real proposal yet and seems more extensive to implement.

My vote (although everyone is free to disagree) would be to implement BIP101 as the BU chosen path since it:
1) has a clean upgrade path for the whole network
2) has a fully proposed BIP definition
3) has working code in XT as a guide
4) has minimal changes required (I think)

To implement BIP101 it seems only the following is needed, please correct this if wrong:
a) A loop to count the number of XT block versions in the most recent 1000 blocks
b) Code that sets the MAX_BLOCK variable to the XT schedule if a) above is above 749, and 1MB otherwise

Another option is to just have a few lines of code along the lines of: "if(BLOCK_HEIGHT > XXX) MAX_BLOCK = MAX_INT; else MAX_BLOCK = 1000000" and have BU force a hard fork by some specific time. This has various pros and cons.

 

[Peter R]

@cypherdoc: We would just be adding one more option to these already-existing options (that control the min and max size of blocks a node will attempt to build):

-maxblocksize=<n> Set block size limit in bytes (default: INFINITY [=1073741824])
-blockminsize=<n> Set minimum block size in bytes (default: 0)
-blockmaxsize=<n> Set maximum block size in bytes (default: 750000)
-blockprioritysize=<n> Set maximum size of high-priority/low-fee transactions in bytes (default: 50000)

[doublepost=1446080424][/doublepost]@rocks: My understanding is that Bitcoin Unlimited would be unlimited from Day #1. That is, if for some reason the longest chain included a block > 1 MB, BU nodes would follow it. There would be no need to "wait" for some event to trigger.