Gold collapsing. Bitcoin UP.

theZerg

Moderator
Staff member
Aug 28, 2015
1,012
2,327
It is optional and off by default... ok PLEASE post over in the BUIP!!! PLEASE... I think I need to refuse to answer questions over here! ;-)
 
  • Like
Reactions: awemany

Zangelbert Bingledack

Well-Known Member
Aug 29, 2015
1,485
5,585
The flipside of "if Core doesn't get moving they will lose their stranglehold" is "if Core does provide something nice for the interim they will like maintain their stranglehold."

Assuming it delivers on its promise, "segwit+small cap increase" may be enough for them to keep power for another 6 months to a year, unless they get increasingly tyrannical of course. I think they're going to milk their temporary control for all its worth, like any good political opportunists. However, it may not be as bad as it looks, because sure they can push Bitcoin in various directions but only in directions the market accepts. Maybe they can even get most As soon as big blocks are the only way forward and they refuse, their control is zapped.
 
Last edited:

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
@cypherdoc, all:

Another way to do proof-of-stake voting on the blocksize, but without any risk to cold storage coins, would be to simply, optionally attach a vote to a transaction. Like a new opcode "BLKVOTE x", with x being the desired block value.

Weight all votes for the last 52560 blocks by the input values of the transaction that they appeared in, take the median, and let that be the new blocksize, make 1MB the lowest floor. If there are no votes in the last 52560 blocks (the exceedingly unlikely but theoretically possible scenario), take 1MB as blocksize.

I would also think doing it this way would be a quite balanced approach. Miners and exchanges will move a lot of money, are important players, and so will have quite a say in block size. Users who do many small transactions will have their vote, too (possibly for a cost).
The only people excluded are those that store their coins really long term, but they also don't need a lot of TXN rate for those coins. And if they decide to move them, they immediately have a voice - or could still simply vote by moving.

Thoughts?
 
Last edited:

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
This is significant.

Greg is (indirectly) accepting a proof-of-stake vote. I just got this PM from him:



So lets organize this!

Edit: Further exchange:


EDIT2:
 
Last edited:

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
Hmm. I may have stumbled onto a major reason as to why we might want to go with 101 instead of SW. Follow this conversation. I still have yet to answer his last reply until I can get to a keyboard but my reasoning is already there. We need to encourage the growth of mining outside of China by simply changing a single constant in the current code (101). Note the only way he can counter is with threats utilizing the exact reasons we need to do this:

 
Last edited:

Zarathustra

Well-Known Member
Aug 28, 2015
1,439
3,797
"I think that right now capacity is high enough and the needed capacity is low enough that we don't immediately need these proposals, but they will be critically
important long term."


http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
Seems to be less than a 2x performance boost:

> On Mon, Dec 07, 2015 at 10:02:17PM +0000, Gregory Maxwell wrote:
> > If widely used this proposal gives a 2x capacity increase
> > (more if multisig is widely used),
So from IRC, this doesn't seem quite right -- capacity is constrained as

base_size + witness_size/4 <= 1MB

rather than

base_size <= 1MB and base_size + witness_size <= 4MB

or similar. So if you have a 500B transaction and move 250B into the
witness, you're still using up 250B+250B/4 of the 1MB limit, rather than
just 250B of the 1MB limit.

In particular, if you use as many p2pkh transactions as possible, you'd
have 800kB of base data plus 800kB of witness data, and for a block
filled with 2-of-2 multisig p2sh transactions, you'd hit the limit at
670kB of base data and 1.33MB of witness data.

That would be 1.6MB and 2MB of total actual data if you hit the limits
with real transactions, so it's more like a 1.8x increase for real
transactions afaics, even with substantial use of multisig addresses.

The 4MB consensus limit could only be hit by having a single trivial
transaction using as little base data as possible, then a single huge
4MB witness. So people trying to abuse the system have 4x the blocksize
for 1 block's worth of fees, while people using it as intended only get
1.6x or 2x the blocksize... That seems kinda backwards.

Having a cost function rather than separate limits does make it easier to
build blocks (approximately) optimally, though (ie, just divide the fee by
(base_bytes+witness_bytes/4) and sort). Are there any other benefits?

But afaics, you could just have fixed consensus limits and use the cost
function for building blocks, though? ie sort txs by fee divided by [B +
S*50 + W/3] (where B is base bytes, S is sigops and W is witness bytes)
then just fill up the block until one of the three limits (1MB base,
20k sigops, 3MB witness) is hit?

(Doing a hard fork to make *all* the limits -- base data, witness data,
and sigop count -- part of a single cost function might be a win; I'm
just not seeing the gain in forcing witness data to trade off against
block data when filling blocks is already a 2D knapsack problem)

Cheers,
aj


http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011869.html
 

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
Hey, so further on stakeholder voting:

I have this idea, and I wonder what you guys think about this:

How about making a short draft proposal to decide blocksize on per-transaction stakeholder vote (as I proposed above) and then putting that onto bitcoinocracy.com for voting?

I would be surprised, due to the nature of the voting itself, if that wouldn't get widespread support.

EDIT: So here is a draft, just a tad more formalized:

Code:
Draft outline for a straight-forward proof-of-stake voting on maximum block size
--------------------------------------------------------------------------------

Define a new opcode VOTEMAXBLOCKSIZE. This opcode will take one argument,
a maximum blocksize vote amount (MBVA), an unsigned integer of at least 50 bit size.
The vote is in units of bytes of maximum block size.

This opcode can be put into any transaction transaction. Only one opcode is allowed per transaction.

Maximum block size is to be determined in phase with difficulty (at the same block boundary that difficulty is recalculated, at block-number mod 2016 = 0), using the following scheme:

For each difficulty interval (2016 blocks) that exists, collect all MBVAs and calculate
the weighted median Mhm. (half-monthly block size vote)
Weight with the total sum of all inputs to the transaction containing the MBVA.

For the preceding last 26 difficulty intervals, calculate the simple median My of the
weighted medians Mhm.

The accepted maximum blocksize for the current difficulty interval is this median of medians,
Mhm.

Should there be no votes in a single difficulty interval, assume that the
weighted median is equal to 1000000 bytes. (1MB blocks)
Past difficulty intervals before implementation of this proposal do not contain any
blocks with a block size votes and thus also will have an assigned Mhm median
value of 1000000.

This ensures a smooth start from 1MB.
 
Last edited:
  • Like
Reactions: majamalu

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
  • Hmm. I may have stumbled onto a major reason as to why we might want to go with 101 instead of SW. Follow this conversation. I still have yet to answer his last reply until I can get to a keyboard but my reasoning is already there. We need to encourage the growth of mining outside of China by simply changing a single constant in the current code (101). Note the only way he can counter is with threats utilizing the exact reasons we need to do this:

    I knew this would catch their attention:

 

yupup

New Member
Dec 8, 2015
1
0
Greg Maxwell's bitcoin address is 161y6Du7T2gTKrTSKMoaxGatqXvMh24k29, right?

This is significant.

Greg is (indirectly) accepting a proof-of-stake vote. I just got this PM from him:



So lets organize this!

Edit: Further exchange:


EDIT2:
 

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
@cypherdoc: Just a random thought: Could it be that part of Greg's rejection of larger maximum blocksize is that he has this beef with you?

I doubt that's more than just a part of the story (the major one is surely Blockstream's misaligned incentives), but it surely is interesting how he brings this up every damn time.
 
  • Like
Reactions: majamalu

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
hot diggity!





just as a side note, i've seen so many short squeeze ramps like the one Friday's 350 pt short squeeze after that Employment Report, that it just seems so manipulated. esp when i linked to Hussman's source that it is a lagging indicator. probably not 1 in a thousand know that but i still can't help thinking the machines try to careen the price wildly in various directions trying to create as many losers as possible on the way down, while esp trying to shake off the Bears. and they say Bitcoin is volatile? what a scam US markets are. that's why i used Friday's rally to set the last tranches of my DXD short as i've seen this game so many times. remember how i said i was looking for one more ramp?

having said that i could still be wrong. but so far so good.
 
Last edited:

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
@cypherdoc: Just a random thought: Could it be that part of Greg's rejection of larger maximum blocksize is that he has this beef with you?

I doubt that's more than just a part of the story (the major one is surely Blockstream's misaligned incentives), but it surely is interesting how he brings this up every damn time.
i wouldn't presume to be that important to him but he clearly sees my advocation of bigger blocks as a direct challenge to his power. it's pretty clear i've been dumped into the same hit bin as Hearn and Gavin. he and his other character assassins, MOA, iCE, midnightmagic, brg444 have happily climbed onboard. but you have to remember that i had problems with him well before the blocksize debate with Press Center and their formation of Blockstream:

mid 2013: Adam Back gets into Bitcoin.

Blockstream formed in Jan 2014:

http://opendatacanada.com/corporation.php?id=8425345

i first object to Blockstream infiltration of core dev in July 2014:


their SC's WP came out Oct 2014. brg444 enters the old thread precisely at the same time to troll every comment i make on SC's.

blocksizes became an high profile issue Spring 2015. they immediately jump all over me once they identify me as a big blockist as they've been on high alert about me already re: SC's and start using the #CuzHashfastClawback ad hom relentlessly.

note the end of our convo last night. he just fades away after direct questioning on my part. that's b/c he's lying:

[doublepost=1449590316][/doublepost]this is why ProHashing is right. do we really want to be stuck under the same regime after whatever change we make?
 

davecgh

Member
Nov 30, 2015
28
51
It's pretty clear i've been dumped into the same hit bin as Hearn and Gavin. he and his other character assassins, MOA, iCE, midnightmagic, brg444 have happily climbed onboard.
This gave me a good chuckle because I too have been the target of more than one of those (in particular midnightmagic) in regards to the btcd project and "character assassins" is a perfect term to describe the behavior. Lots of FUD, twisting of facts, outright spreading of false information trying to blame btcd for some things happening on testnet it had nothing to do with, etc.
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
furthermore, i didn't make any friends with devs like Odalv, et al with statements like this i made several years ago:

"The geeks fail to understand that which Satoshi hath created"

that severely pissed them off but seriously, i think it's true. after having directly engaged with many of them since early 2011, i began to realize most of what they were saying when it came down to economics and money was pure bullshit reflecting a severe lack of experience. i've been on them ever since and they hate me for it. but it's true, Bitcoin is not only about code. it's an intersection of economics, game theory, math, code, probability theory, etc. no one has all the skills. that is why so many skeptics exist with some of the most vehement coming from the geek crowd, like Dan Kaminsky and now i dare say gmax, Todd, Lukejr, and Back.

they hate me for this outlook.
 

Zangelbert Bingledack

Well-Known Member
Aug 29, 2015
1,485
5,585
@cypherdoc

I don't know if they hate you for it (I believe I saw Gmax acknowledge Bitcoin's multidisciplinary nature in an exchange with @Peter R on reddit a few weeks ago) but it's certainly true that most of the engineers fail to understand what Satoshi created. Adam Back getting in in mid-2013 when like everyone and their mother was getting in is just embarrassing, especially given he invented hashcash (which is just Bitcoin minus inflation;)). Just goes to show how much our preconceptions can blind us, and again underscores the multidisciplinary nature of Bitcoin. To really get it, you have avoid pitfalls of understanding in all the relevant fields, or you will walk away thinking it's fairy dust or unworkable.

The lack of economic understanding is palpable in the Core/BS team discussions; there's no need to wonder if maybe they actually get it. They don't. They're just not used to thinking like economists, which after all is quite a counterintuitive way of thinking, let alone like good economists, which is what is needed to apprehend and address such complex and novel issues.
 
Last edited:

Aquent

Active Member
Aug 19, 2015
252
667
I do apologise. This turned into a far longer post than I envisaged. Tl;dr is at the bottom.

So, what happens now?

From what we are reading it seems clear that no developer "consensus" can be reached for a blocksize increase which defacto means a settlement system and, as we all expected, nothing has come out of the conference except for a small increase to 2mb or so in about six months or so.

In a public conversation in the workshop IRC channel I had with wangchung, the F2Pool admin, he publicly stated that he would support BIP101 but starting at 2mb, then doubling every two years for the next two decades. Not ideal, of course, that would mean 2mb immediately, then 4mb in 2018, 8 in 2020 and so on, but with SW improvements and if it closes the debate then perhaps it may be a necessary compromise.

The miners however have publicly suggested that they are followers, not leaders. Therefore seem unwilling to take the initiative themselves even where their majority agrees, as in the case of BIP100. So we have a situation here where the developers are unable or unwilling to reach an agreement, and the miners are unwilling to make a decision, so it is left to the economic majority to conclude the debate.

Now, I'm just throwing ideas here for discussion in the spirit of exploratory enquiry without suggesting any course of action and I highly welcome comments to try and answer this very important governance/decision-making question:

Where the developers are unwilling or unable to reach a conclusion either due to genuine or corrupted opinions and the miners consider themselves to not be the "jury", how does the economic majority make a decision and act upon it, thus conclude the debate?

That is a general question, not specific to the debate at hand, but since the hardfork is the main issue I suppose it might be helpful to propose some specific assumptions regardless of whether they are actually true or not.

Let us suppose that the developers can never reach an agreement, thus taking them out of the decision making process. Let us further suppose that the miners will not act unless the developers reach an agreement, thus taking them out of the decision making process too. Let us suppose that if the economic majority does not act we de facto get a settlement system (as well as perhaps crown some emperor) and, quite importantly, let us suppose that the economic majority strongly supports bip101.

With the economic majority being the only party that has made a positive decision in the above scenario and the only stakeholder with consensus amongst their rank, how do they act upon this decision and conclude the debate?

To satisfactorily answer that question seems to me a difficult endeavour. To illustrate, Brian Armstrong recently stated that it is for the miners to "vote", while the miners are saying it is not for them to be the jury/voters. It is not clear to me who the miners think is the jury. With the economic majority having expressed their opinion quite clearly, and the miners still not following their decision, how does the economic majority act to enforce the only positive (in the sense of making an active/passive choice rather than good/bad) decision made so far?

The economic majority can of course implement BIP101, but with the miners not moving over there is no activation. I suppose the economic majority can wait for the miners to move over, but with the miners following the developers who are disagreeing whether due to genuine beliefs or corruption/sabotage with no likelihood of an agreement in sight, the economic majority is no longer making a positive decision. This would set a terrible precedence in my view as it would allow 1 or 2 developers to veto any changes as well as place the developers in a position of power and control, thus eventually create a hierarchy within the developers with one of them being the defacto emperor.

Unless someone smarter than me can suggest any other option/s, the only way for the economic majority to act upon its decision seems to me to be the nuclear option of forking with the mining algo changed.

I don't think anyone would want to exercise that option lightly nor am I knowledgeable enough to know how it would play out. Practically speaking security would be lower, but I would think for only a short time as the race heats up for more and more hashshare. The older chain would continue and the older miners would have no option but to continue mining it. We can expect at least 1 exchange to hold out, perhaps btcc considering its mining investment. Then there is the individual vote.

Coins can only be sold once, in each chain. Therefore the rational investor, if he takes any action at all, will sell the chain they objectively think will lose because if they sell the wrong chain then they have effectively sold their bitcoin at the market price which may at the time be far lower than once the voting war is over.

In our case, the mpex crowed has threatened to sell the bip101 chain regardless of who they think will win. If they carry out their action, they will effectively sell their coins at a, probably, far below market price. That would be an irrational decision as they would effectively be burning their own money, thus many of them would hesitate if they objectively think that bip101 would win, therefore the threat is probably a bluff. If it is not, as the economic majority would be in favour of bip101, I would think there would be plenty of buyers for their very cheap coins. Thus, at best, they would only cause some volatility to the rest, while committing suicide for themselves.

On the other hand, Roger Ver et all will prob sell the 1mb chain. As it has less than 20% public support, I doubt there would be many buyers for the 1mb coins, thus economically crippling the 1mb chain and it's miners with it.

The speculators, of course, will do their, probably decisive, part in concluding with one winning chain while the vast majority would probably just wait until the dust settles with one coin being obviously the loser and the price of the wining coin stabilising or perhaps moon landing. Thereafter, the decision having been made, we can finally move on having set an incredibly powerful precedent.

Since nukes were invented we have had to only use them once, to show their power, and in now more than 70 years have never used them again and one would hope they never are. To fork with a changed algo burns hundreds of millions, if not billions, in mining investment and would likely create some high short term price volatility.

One would think, however, that a credible threat of a serious consideration of this option would be sufficient for miners to listen to the jury/voters of the economic majority and adopt bip101 or a likewise proposal perhaps starting at 4mb or so without the need to actually go through with it.

Such credible threat perhaps can be started by some small player creating the changed algo client which necessarily would attract a lot of cpu/gpu miners, and then it may be sufficient for coinbase/bitstamp to just propose the idea of shifting to this client to place the miners on a conclusive decision mode.

Otherwise, through inaction, we are effectively concluding the debate by following a path that is being laid towards a settlement system without a white paper on how such system would work in its entirety, how miners are incentivised, how nodes are incentivised, it's usability for mum and pop, the advantages of bitcoin against other payment systems to mom and pop if we take out free or very cheap, instant, permissionless, and if we take out smart contracts as well as proof of work itself which is the whole point of bitcoin.

It may well be that some individuals who hold influential positions hold genuine beliefs in holding against scaling proof of work, but by showing the economic majority powerless to take positive action, miners as easily made to follow by some dissent, and thus developers (who can be counted by hand) as effectively the decision makers, a dangerous precedent is set for the developers themselves who become targets and for bitcoin who would be shown to easily be centrally controllable.

Thus, it is decision time for bitcoin. After almost a full year of debating all the imaginable points, two conferences, and the positions having been fully laid out by all sides at this point, the ball is on the economic majority, who is the only stakeholder that can conclude the debate, to decide whether they wish to take positive action in favour of their within rank consensus decision, or take a passive decision and thus forever give up it's power. Both have ramifications, yet only one is the choice.

TLDR: Where the developers are unable to reach an agreement, the miners are unwilling to be the jury and the economic majority has consensus for a certain action, the economic majority's only choice of acting upon it's decision, and thus enforcing it's will, may be the nuclear option of forking with a changed algo. Such option may only need to be used once for it forever to suffice as a credible threat to anyone who wishes to centrally control bitcoin.
 
Last edited:

79b79aa8

Well-Known Member
Sep 22, 2015
1,031
3,440
Hmm. I may have stumbled onto a major reason as to why we might want to go with 101 instead of SW. Follow this conversation. I still have yet to answer his last reply until I can get to a keyboard but my reasoning is already there. We need to encourage the growth of mining outside of China by simply changing a single constant in the current code (101).
The point should be emphasized that the GFC is a restriction on the freedom of information and communication that should be resisted, not accommodated. At the moment BTC mining reveals one obvious way in which the PRC's ham-fisted attempts to control data flow are self-defeating, as it puts chinese miners at a disadvantage, and overall hinders the country's entry into the economy of the future. The market will exploit this disadvantage, and this will be a way of resisting the wall.