Bitcoin Forum
November 21, 2017, 10:56:48 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes
2.  no

Pages: « 1 ... 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 [1376] 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2010677 times)
rocks
Legendary
*
Offline Offline

Activity: 1149


View Profile
June 26, 2015, 04:49:06 PM
 #27501

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.
1511261808
Hero Member
*
Offline Offline

Posts: 1511261808

View Profile Personal Message (Offline)

Ignore
1511261808
Reply with quote  #2

1511261808
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511261808
Hero Member
*
Offline Offline

Posts: 1511261808

View Profile Personal Message (Offline)

Ignore
1511261808
Reply with quote  #2

1511261808
Report to moderator
1511261808
Hero Member
*
Offline Offline

Posts: 1511261808

View Profile Personal Message (Offline)

Ignore
1511261808
Reply with quote  #2

1511261808
Report to moderator
Erdogan
Hero Member
*****
Offline Offline

Activity: 826


View Profile
June 26, 2015, 04:54:55 PM
 #27502

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
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 26, 2015, 04:57:44 PM
 #27503

whoops, $DJT going negative again.
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
June 26, 2015, 05:05:50 PM
 #27504

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

Activity: 826


View Profile
June 26, 2015, 05:07:00 PM
 #27505

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
Legendary
*
Offline Offline

Activity: 2324


View Profile
June 26, 2015, 05:22:38 PM
 #27506

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
Legendary
*
Offline Offline

Activity: 1372



View Profile
June 26, 2015, 06:20:57 PM
 #27507

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?

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
tvbcof
Legendary
*
Offline Offline

Activity: 2324


View Profile
June 26, 2015, 06:45:08 PM
 #27508


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
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 26, 2015, 07:01:07 PM
 #27509


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
Sr. Member
****
Offline Offline

Activity: 420


View Profile
June 26, 2015, 07:02:13 PM
 #27510

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
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 26, 2015, 07:14:12 PM
 #27511

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
Sr. Member
****
Offline Offline

Activity: 420


View Profile
June 26, 2015, 07:21:16 PM
 #27512

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
Legendary
*
Offline Offline

Activity: 2324


View Profile
June 26, 2015, 07:23:35 PM
 #27513

...
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
Sr. Member
****
Offline Offline

Activity: 420


View Profile
June 26, 2015, 07:26:57 PM
 #27514

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
Legendary
*
Offline Offline

Activity: 2324


View Profile
June 26, 2015, 07:34:32 PM
 #27515

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
Sr. Member
****
Offline Offline

Activity: 420


View Profile
June 26, 2015, 07:49:36 PM
 #27516

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.  Roll Eyes

Erdogan
Hero Member
*****
Offline Offline

Activity: 826


View Profile
June 26, 2015, 07:55:26 PM
 #27517

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.


TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
June 26, 2015, 08:06:17 PM
 #27518

Soft forking.

...

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

Yes that is what I thought must happen with new opcodes also. The alternative is to open a massive security hole as I explained. Thus tvbcof must be incorrect. A majority of the hashrate must adopt the soft fork, else it dies. Which is the way it should be. But isn't that a hard fork then?

Edit: http://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork

The above definition of a soft fork appears to be flawed because it doesn't seem to weigh the fact that if the new version is more restrictive in a way that old versions can't verify, then the soft fork is effectively a virus which turns all old version full nodes into SPV clients over time. Surely I am not the first person to point this out?

Odalv
Legendary
*
Offline Offline

Activity: 1260



View Profile
June 26, 2015, 08:08:31 PM
 #27519

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.  Roll Eyes

It is not true. Miner who do not understand op-code will not include transaction in block b/c he risks that his block will be ignored in case a transaction is invalid. But in case that other miners added this transaction into block  he will ignore  new op-code as it is NOP (no operation) instruction. (this mean, he will not verify if coins can be moved)
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
June 26, 2015, 08:14:10 PM
 #27520

It is not true. Miner who do not understand op-code will not include transaction in block b/c he risks that his block will be ignored in case a transaction is invalid. But in case that other miners added this transaction into block  he will ignore  new op-code as it is NOP (no operation) instruction. (this mean, he will not verify if coins can be moved)

Then it is a virus that turns every old version full node into an SPV client over time as the derivative transactions can't be fully verified from the root.

Did I just invent a new insight?

Pages: « 1 ... 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 [1376] 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 ... 1558 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!