Gold collapsing. Bitcoin UP.

[kazuki49]

This kind of talk will be used to remove the 21m coin limit in Bitcoin.

I'm sorry if you can't see it.

[1713546301]

1713546301

[1713546301]

1713546301

[1713546301]

1713546301

[Erdogan]

This kind of talk will be used to remove the 21m coin limit in Bitcoin.

I'm sorry if you can't see it.

No, it's food for dreamers. Imaging all the people...I know I'm a dreamer, but I'm not the only one!
Lennon was a bitcoiner, obviously.

[cypherdoc]

This kind of talk will be used to remove the 21m coin limit in Bitcoin.

I'm sorry if you can't see it.

your disrespect of dedicated insightful ppl in Bitcoin is astounding.

of course, i wouldn't expect anything less from the Monero Pimp.

[rocks]

This is more of a fork than the blocksize increase, it is a fundamental change to the underlying protocol

https://www.reddit.com/r/Bitcoin/comments/3b7260/checklocktimeverify_has_been_merged_finally/

Where is the analysis that proves this change is OK? I've been told that is the hurdle. Are users asking for this? Do users have options to reject it? Why is it OK that a small group of people get to fork Bitcoin.

This change forks Bitcoin into a BlockstreamCoin, and everyone is expected to just accept it because the "Board of Directors" have said to.

[Erdogan]

Imagine if we hit the network limit in the future. To simplify, imagine we have two clusters of users, nodes and miners, connected with a starved link.

When a transactions is created in the one cluster, it may not be transfered quickly enough to the other cluster, where the next block happens to be found. Obviously, zero confirmation transactions will be of less use.

Due to the same starved link problem, a block may not propagate to a miner in the other cluster quickly enough, leading to a higher orphan rate, and may be to orphan chains of some length. That means the six confirmation safe level may have to be extended. Six confirmations have always been an advice anyway, for each confirmation the confidence increases.

In such a scenario, one cluster may prove to be the leading mining arena, and any miner must make sure that they are well connected to that cluster.

But will it take down bitcoin? No.

[cypherdoc]

whoops, $DJT going negative again.

[justusranvier]

https://bitcoinism.liberty.me/what-is-mining-why-do-we-need-it-and-how-much-is-enough/

[Erdogan]

If we get a permanent fork out of this, there will be a fierce naming duel in the blogospere. I predict the two names that come out of it are bitcoin and blockstreamcoin.

Most probably, one fork will disappear so quickly that the fork will not be permanent, but exist only hours.

[tvbcof]

If we get a permanent fork out of this, there will be a fierce naming duel in the blogospere. I predict the two names that come out of it are bitcoin and blockstreamcoin.

Most probably, one fork will disappear so quickly that the fork will not be permanent, but exist only hours.

Soft-fork.  Doesn't matter much as long as there are some nodes which understand it, and no real reason for a node operator to not just go with it except for hard-core politics.  In order to fight it one would have to patch their node to specifically drop the messages since otherwise it's just random data which would be passed not unlike the very many extensions which have been soft-forked in in the past.  One thing about a flooding network is that specific discrimination is only as effective as one's ability to get a nearly 100% majority on-board.  Miners are the choke-points for such discrimination.

TL-DR:  you lose.

Note:  Actually these are my own assumptions based on my understandings of the protocol and expectation of implementation.  Edits: minor.

[Adrian-x]

This is more of a fork than the blocksize increase, it is a fundamental change to the underlying protocol

https://www.reddit.com/r/Bitcoin/comments/3b7260/checklocktimeverify_has_been_merged_finally/

Where is the analysis that proves this change is OK? I've been told that is the hurdle. Are users asking for this? Do users have options to reject it? Why is it OK that a small group of people get to fork Bitcoin.

This change forks Bitcoin into a BlockstreamCoin, and everyone is expected to just accept it because the "Board of Directors" have said to.

I'm not sure the Bitcoin experiment survives, I trust the developers know the code works, but i have no dough they don't understand the resulting ramifications and all the externalities.

In your view what is it that you see is controversial and some examples of how it works?

[tvbcof]

https://bitcoinism.liberty.me/what-is-mining-why-do-we-need-it-and-how-much-is-enough/

Read the above long-winded, contentless, screed of cold leftovers if you like.  Or skim.  I'll be a good guy and break down the real issue right here:

Today's implementation of mining is like having a tin can tied to a horse's tail.  The fast the horse runs, the faster the can follows.  We've currently got about 6 miners (or horses so-to-speak) that make any real difference.

The main trouble with this is that each of the horses is going to hit the profitability break-even cliff at roughly the same time due to similar economics (though geo-politics could intercede.)  At that point there will be large chunks of sha256 power available since it's pointless to mine Bitcoin with it...at least for economic reasons.

The alternative is to try to match endless inflation against profitability not unlike how debt-based fiat systems work.  Bitcoin has so many sources of volatility that this would be a tough row to hoe even if it were (stupidly) chosen as a strategy.

Note that the economics of mining under our current paradigm are not even effected by block-size/fee-structure arguments.  That's a separate issue.

[cypherdoc]

https://bitcoinism.liberty.me/what-is-mining-why-do-we-need-it-and-how-much-is-enough/

Read the above long-winded, contentless, screed of cold leftovers if you like.  Or skim.  I'll be a good guy and break down the real issue right here:

Today's implementation of mining is like having a tin can tied to a horse's tail.  The fast the horse runs, the faster the can follows.  We've currently got about 6 miners (or horses so-to-speak) that make any real difference.

The main trouble with this is that each of the horses is going to hit the profitability break-even cliff at roughly the same time due to similar economics (though geo-politics could intercede.)  At that point there will be large chunks of sha256 power available since it's pointless to mine Bitcoin with it...at least for economic reasons.

The alternative is to try to match endless inflation against profitability not unlike how debt-based fiat systems work.  Bitcoin has so many sources of volatility that this would be a tough row to hoe even if it were (stupidly) chosen as a strategy.

Note that the economics of mining under our current paradigm are not even effected by block-size/fee-structure arguments.  That's a separate issue.

I don't even have to read his article yet to see that you don't have the faintest clue how bitcoin works. That's always been the case though.

[TPTB_need_war]

Imagine if we hit the network limit in the future. To simplify, imagine we have two clusters of users, nodes and miners, connected with a starved link.

When a transactions is created in the one cluster, it may not be transfered quickly enough to the other cluster, where the next block happens to be found. Obviously, zero confirmation transactions will be of less use.

Due to the same starved link problem, a block may not propagate to a miner in the other cluster quickly enough, leading to a higher orphan rate, and may be to orphan chains of some length. That means the six confirmation safe level may have to be extended. Six confirmations have always been an advice anyway, for each confirmation the confidence increases.

In such a scenario, one cluster may prove to be the leading mining arena, and any miner must make sure that they are well connected to that cluster.

But will it take down bitcoin? No.

Moar nonsense from someone who apparently has insufficient experience in software engineering. Sorry to make this personal (especially with someone who has expressed some appreciation for my input on the forum yet with reservations about my etiquette), but some of you guys have no self-restraint. Some of you (and you know who you are) go on and on and on posting about technical issues without even the slightest bit of reticence nor shame that you might be totally-fucking-wrong. The reason this thread is not in the Development & Technical Discussion board, is because many of the posts in this thread would likely be deleted by the moderator there to prevent the promulgation of misinformation.

Hey n00bs, a starved link means it can never catch up with the transaction rate. Infinite confirmations won't help you. The two clusters will diverge as two forks with the BTC money supply effectively doubled if every HODLer can access both clusters.

The only way to deal with this situation is treat each of the clusters as pegged side chains of each other, then lock the value for each coin on one of the clusters (which is something plausible on a starved link such as a short wave radio feed). This is yet another reason I am excited about Blockstream's work.

[cypherdoc]

Look how the 1MB down vote gang goes after my simple non threatening request to vote here in the above poll:

http://reddit.com/r/Bitcoin/comments/3aykzr/btcchina_we_think_gavins_proposal_is_a/csh5nnd

This means a lot of things since it gives them equal opportunity to come here and vote too:

1. They are afraid of the results.
2. They don't like me
3. They are a bunch of thugs.
4. They want to hide the truth

All the above apply.

[TPTB_need_war]

In order to fight it one would have to patch their node to specifically drop the messages since otherwise it's just random data which would be passed not unlike the very many extensions which have been soft-forked in in the past.  One thing about a flooding network is that specific discrimination is only as effective as one's ability to get a nearly 100% majority on-board.

I have not studied the code, but I can't fathom that you are correct because if so it would mean anyone could introduce new opcodes into the block chain.

Also I can't understand how this can be a soft fork, when the miners need to understand the opcode in order to keep their UXTO updated. Effectively the miners that did not adopt the opcode would delegate the full node verification to the nodes which adopt the opcode. Then inserting an undocumented opcode would be a trojan horse. Sorry even without seeing the code, I can reason out that what you claim can't be the case, unless I've missed some way of handling it.

[tvbcof]

...
The only way to deal with this situation is treat each of the clusters as pegged side chains of each other, then lock the value for each coin on one of the clusters (which is something plausible on a starved link such as a short wave radio feed). This is yet another reason I am excited about Blockstream's work.

pegged x-over is not something I thought of (since I was focused on how to exploit the douchbags who are trying to fuck up Bitcoin instead.)  WRT defensibly, maybe we are not as divergent as I imagined (recent NooNooPol thread post) after all.

I suppose that if I can somewhat understand and respect your goals even if my priorities are different, the reciprocal could apply.  I don't retract my statement that you are going to have to 'piss or get of the pot' one of these days with your ideas though.  If your ideas are worth a shit, I'm hopeful that they will at least pop up under the Blockstream banner one of these days.

[TPTB_need_war]

I don't retract my statement that you are going to have to 'piss or get of the pot' one of these days with your ideas though.  If your ideas are worth a shit, I'm hopeful that they will at least pop up under the Blockstream banner one of these days.

Serious shit is happening now. It is not only me any more. 'nuf said.

Edit: the reason I am still reading here, is just to see if I can extract any caveats or good ideas. Some say that greatness can be extracted from crap sometimes.

[tvbcof]

In order to fight it one would have to patch their node to specifically drop the messages since otherwise it's just random data which would be passed not unlike the very many extensions which have been soft-forked in in the past.  One thing about a flooding network is that specific discrimination is only as effective as one's ability to get a nearly 100% majority on-board.

I have not studied the code, but I can't fathom that you are correct because if so it would mean anyone could introduce new opcodes into the block chain.

Why couldn't they?  Anyone can apply any patch they want and people do it all the time.

Most of the patches which get traction currently go through the BIP process.  That's one of the 'deficiencies' that Hearn wants to 'move Bitcoin beyond' as it were.

Also I can't understand how this can be a soft fork, when the miners need to understand the opcode in order to keep their UXTO updated. Effectively the miners that did not adopt the opcode would delegate the full node verification to the nodes which adopt the opcode. Then inserting an undocumented opcode would be a trojan horse. Sorry even without seeing the code, I can reason out that what you claim can't be the case, unless I've missed some way of handling it.

Nodes that don't understand an opcode have two choices:  1) drop it and 2) transmit it.  Neither one stops soft-forks from working though it could degrade certain classes of messages somewhat.  If one is not demanding that a transaction must get into the next block (or be real-time) a great deal of degradation is fine, and on top of a flooding network it would be extremely difficult to obtain enough of a majority to make much of a difference.  The inefficiencies are outweighed by the robustness (in my opinion and for this use-case.)

Satoshi was not a wasteful designer.  When one sees inefficiency it would be a mistake to immediately write it off to thoughtlessness.  That's my read.

[TPTB_need_war]

Nodes that don't understand an opcode have two choices:  1) drop it and 2) transmit it.

Every full node must verify every transaction. It can not verify what it can't parse. Thus afaics it delegates its full node responsibility to the other nodes which can parse the opcode, i.e. it becomes effectively a SPV client for those and all derivative transactions of those. Meaning that eventually all full nodes become SPV clients if the don't adopt every undocumented opcode (that is why I said it would a trojan horse security hole).

And iCe thinks I am not a software engineer. 

[Erdogan]

Soft forking.
If this happens in your node:

Code:

Error 100: Large block incoming, unable to reserve memory, giving up.

... you might not see any more blocks on your chain, and you have to give up your node or change implementation.


... or the miner who mined the large block, might experience that noone builds upon it, and he has just wasted 10 minutes of the network hashrate.

If you want to mine a block larger than the commonly accepted size, proceed with caution.