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.
Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
@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.
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.
If the exchanges won't accept their chains as valid, then no miner will produce those blocks because they won't be able to pay their expenses with their newly-mined coins.
Yes, persuading the exchanges to take your position would be the most effective course of action.
The exchanges being proxies for investors, who are the ones who actually decide which changes are accepted and which ones are rejected.
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]
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]
Yeah, it's why I haven't done that yet. It shows the strength of the security model. Bitcoin is hard to attack
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:
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.
So does anyone other than AdrianX think that some kind of decision making process is important? Or shall we just wing it?
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:
I need to give credit to @Mengerian because he originally made a similar diagram months ago in the locked thread.
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.Greg Maxwell said:
I need to give credit to @Mengerian because he originally made a similar diagram months ago in the locked thread.
Is there someway to make it so that BU is just "Unlimited" (in which case there are really no contentious decisions to be made) but that people can downloaded various "transport layer rules" from third parties?
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
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.
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.
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.
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".
@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".
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.
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]
Bitcoin is the tree and BS the misteltoe. The latter without the ascribed mythical properties, though...