Gold collapsing. Bitcoin UP.

yrral86

Active Member
Sep 4, 2015
148
271
I am still so disgusted by this that is it hard to get excited about bitcoin finally re-entering a bull phase.

What is also disgusting is how Peter and the rest of the BS crew are now happily talking on reddit about forking bitcoin to include their new op codes, op codes for which there neither is consensus for or full understanding on the implications. But they get to claim consensus because they've banned/censored everyone on reddit and the bitcoin-dev board.

Since this happened a few months ago I've started to re-read about various points in history when a minority of a population was able to radically re-form a society and crush all opposition. It is always the same, a small 5% somehow are able to claim authority, they then use that authority to silence/kill/drive away the 5-10% that is willing to fight back, and the other 90% just go along. The Russian revolution and following White emigre is one example, the Iranian revolution and following emigration of secular intellectuals is another (there are many more in just the past 150 years).

it makes me believe that accepting this path is the wrong thing to do, and that the right thing is to not just go along with dictators but to continue to fight back (i.e. not emigrate away or go along). I am more and more seriously considering creating a client that appears as the standard bitcoin core, but silently rejects all blocks with unknown op codes. If you spin up enough nodes on the network with this behavior miners will see significantly higher orphan rates if they include the transactions and be more financially motivated to not go along. Maybe I am being too sensitive, but it is one thing to read about a historical period when all dissent was crushed, it's another to see it in action (even if it's at a much smaller scale...)
Your attack won't work. In practice, large miners all have direct connections to each other and do not rely on the non-mining nodes for block propagation.
 

sickpig

Active Member
Aug 28, 2015
926
2,541
@yrral86 what if a significant portion of full nodes do not rely blocks containing such txs and txs them selfs before they will be included into a blk?
 

yrral86

Active Member
Sep 4, 2015
148
271
@sickpig
Not relaying the transactions themselves might increase the time it takes for such transactions to confirm. I suppose not relaying the blocks would put more strain on those that do. However, the orphan rate would not be effected, so it would not influence the economics of mining such transactions. This is because miners have direct connections, plus most use the Bitcoin Relay Network. There's not much you can do to stop a soft fork unless we hard fork to disallow undefined opcodes. If we did that, all forks would be hard forks.
 

rocks

Active Member
Sep 24, 2015
586
2,284
The exchanges want larger blocks, that has been made clear.

The silence from other major bitcoin stakeholders has been interesting. It is not clear if they feel strongly one way or another but prefer to take a politically neutral stance so as to not alienate business (which is wise), or if they don't have strong preferences.

If they do have strong preferences, I'd have to believe something in the background is in the works. We are getting closer to the limit and that holds everyone back....
[doublepost=1445814089][/doublepost]
Your attack won't work. In practice, large miners all have direct connections to each other and do not rely on the non-mining nodes for block propagation.
Yeah, it's why I haven't done that yet. It shows the strength of the security model. Bitcoin is hard to attack :)
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
@rocks maybe this apply to what you just described

the problem with this analogy is that it applies to a minority "with skin in the game".

i'd argue from historical experience and close observations of guys like gmax that the opposite is true; he and the other Blockstream core devs have very little skin in the "Bitcoin" game due to long term bearishness on Bitcoin proper elucidated many times over at BCT in the form of what i consider incorrect views of increasing centralization in mining and full nodes and inability to scale.

of course, centralization is debatable but this interesting post by foolish_austrian in regards to a decentralization in mining is one i agree with:

https://www.reddit.com/r/Bitcoin/comments/2o71hh/physics_and_economics_will_distributed_mining_im/
 
Last edited:

Justus Ranvier

Active Member
Aug 28, 2015
875
3,746
The exchanges want larger blocks, that has been made clear.
I agree that question is fairly clear.

What's still up in the air is whether or not they agree with soft forks as a valid upgrade strategy.

I really do think Mike Hearn has the strongest argument here in terms of the desirability of defining entirely new opcodes instead of redefining exist ones.

Redefining the behavior of an opcode that has been used anywhere in the blockchain is effectively changing the terms of other people's contracts. If the meaning of scripts in the blockchain is not fixed and inviolate, then Bitcoin's utility is much lower than what many people expect.
 

theZerg

Moderator
Staff member
Aug 28, 2015
1,012
2,327
Looks like we are settling on unlimited defaults with ability to configure. But we should come up quickly with some formal decision making process both to put issues to rest and so rocks can see that his point of view is considered by all. After all I think we are all here because this did not happen in core.
So does anyone other than AdrianX think that some kind of decision making process is important? Or shall we just wing it?
 
  • Like
Reactions: AdrianX

Peter R

Well-Known Member
Aug 28, 2015
1,398
5,595
There is a quote from Greg Maxwell taken from this email that has been cited a lot recently by the small block side of the debate. The quote suggests that fees will not add to network security without an artificial constraint on block size. However, the argument is wrong:
Greg Maxwell said:
For fees to achieve this purpose [added security], there seemingly must be an effective scarcity of capacity. The fact that verifying and transmitting transactions has a cost isn't enough, because all the funds go to pay that cost and none to the POW "artificial" cost; e.g., if verification costs 1 then the market price for fees should converge to 1, and POW cost will converge towards zero because they adapt to whatever is being applied.
It is easy to show that this is wrong with a simple diagram. The fee revenue goes to three things: miners' profit, orphaning cost, and increased security. The exact mix between profit, orphaning cost and increased security depends on the competitiveness of the market and the concavity of the two curves. The point is that fee revenue will always add to security and will never subtract from it.



I need to give credit to @Mengerian because he originally made a similar diagram months ago in the locked thread.
 

rocks

Active Member
Sep 24, 2015
586
2,284
Redefining the behavior of an opcode that has been used anywhere in the blockchain is effectively changing the terms of other people's contracts. If the meaning of scripts in the blockchain is not fixed and inviolate, then Bitcoin's utility is much lower than what many people expect.
This is really a fantastic point.

The soft fork method only works if you repurposed an unused op code (nop or other). If all the op codes are used by outstanding transactions then there are only 2 methods to create a new op code:
1) Repurpose an existing op code and retroactively invalidate a valid transaction, or
2) Gain consensus for a hard fork to add a new op code.

The blockstream soft fork method only works if there are unused op codes. Which leads to the following question:

What happens if all the available op codes are used?

If we create a valid but nonstandard transaction and get a mimer to include it in a block, then blockstream will have to invalid that transaction to implement a soft fork. They will cry foul, but a valid transaction is a valid transaction.

Nonstandard (but valid) transactions are no longer relayed, but some miners will include them if you send it to them directly. I am very tempted to try this now
 

yrral86

Active Member
Sep 4, 2015
148
271
My concern would be that there are a limited number (1 byte, so 8 bits -> 256) of opcodes. I suppose it would be possible to upgrade from an 8 bit instruction set to a 16 bit instruction set. To do so would increase the size of every transaction, unless we allowed both 8 and 16 bit instructions with a special prefix that indicates that the next 8 bits are also part of the opcode... That would get us an additional 256 opcodes per current opcode we allocated. Still, to go that route, we need to have at least 1 opcode left that hasn't been fucked with. I would be careful about letting that genie out of the bottle if it is in fact possible to create nonstandard transactions that break our ability to redefine opcodes.
 

AdrianX

Well-Known Member
Aug 28, 2015
2,097
5,797
bitco.in
So does anyone other than AdrianX think that some kind of decision making process is important? Or shall we just wing it?
I'm happy to wing it, I just think it needs to be different from Core. The default process is akin to the feudal system. Where one "Mike H" sits at the helm of each implementation.

I think if we what to take it to the next level the implementation that is knowledge driven, that takes a holistic approach will gain wide support.
 

Justus Ranvier

Active Member
Aug 28, 2015
875
3,746
we need to have at least 1 opcode left that hasn't been fucked with.
If the Bitcoin wiki is to be believed, there should be no examples of 0x65 or 0x66 used in the blockchain since those are supposed to make the transaction invalid in all cases.

As long there's one opcode available it can behave like a varint continuation bit. Then you could define the continuation bytes as varints so that running out of numbers won't be a problem any more.
 
  • Like
Reactions: AdrianX

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
Hey guys, so I haven't really followed the whole discussion for a while, was too busy and am hopefully up-to-date again..

@theZerg, are you intending to start a BU fork soon?

About the defaults in BU:

I argued in mine and Peter's very early draft about making BSL configurable to just have an empty, but mandatory-to-be-filled edit box (for the GUI) and a mandatory command line argument (for the CLI). Without any defaults whatsoever.

That would mean that every single user simply has to think about what value to put in there. I think it is the strongest signal a developer can send to the user: "We do not know what the correct limit is and you have to decide for yourself".
 

ladoga

Member
Sep 17, 2015
50
63
You can set the soft maximum from the command line with -blockmaxsize=<n> flag. (all config options also work from ~/.bitcoin/bitcoin.conf)
 

sickpig

Active Member
Aug 28, 2015
926
2,541
the problem with this analogy is that it applies to a minority "with skin in the game".

i'd argue from historical experience and close observations of guys like gmax that the opposite is true; he and the other Blockstream core devs have very little skin in the "Bitcoin" game due to long term bearishness on Bitcoin proper elucidated many times over at BCT in the form of what i consider incorrect views of increasing centralization in mining and full nodes and inability to scale.

of course, centralization is debatable but this interesting post by foolish_austrian in regards to a decentralization in mining is one i agree with:

https://www.reddit.com/r/Bitcoin/comments/2o71hh/physics_and_economics_will_distributed_mining_im/
yep you're right they've not bought thousands of bitcoin when values was a lot lower than 10$. They could have, but they didn't.

This doesn't mean they've not "skin in the game", on the contrary.

In fact Blockstream's success is strongly linked to the one of bitcoin. If they are able to force their vision upon the community, BS probably will be an extremely successful endeavour.
 

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
You can set the soft maximum from the command line with -blockmaxsize=<n> flag. (all config options also work from ~/.bitcoin/bitcoin.conf)
Yes. I was talking about the 1MB hard-coded limit, though. And making it mandatory, so users simply have to choose - and have the (simple) choice.
[doublepost=1445863772,1445862993][/doublepost]
yep you're right they've not bought thousands of bitcoin when values was a lot lower than 10$. They could have, but they didn't.

This doesn't mean they've not "skin in the game", on the contrary.

In fact Blockstream's success is strongly linked to the one of bitcoin. If they are able to force their vision upon the community, BS probably will be an extremely successful endeavour.
Bitcoin is the tree and BS the misteltoe. The latter without the ascribed mythical properties, though...