Bitcoin Forum
December 07, 2016, 08:51:59 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   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 ... 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 1427 1428 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1805456 times)
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


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

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.

1481100719
Hero Member
*
Offline Offline

Posts: 1481100719

View Profile Personal Message (Offline)

Ignore
1481100719
Reply with quote  #2

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

Posts: 1481100719

View Profile Personal Message (Offline)

Ignore
1481100719
Reply with quote  #2

1481100719
Report to moderator
1481100719
Hero Member
*
Offline Offline

Posts: 1481100719

View Profile Personal Message (Offline)

Ignore
1481100719
Reply with quote  #2

1481100719
Report to moderator
tvbcof
Legendary
*
Offline Offline

Activity: 1988


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

...
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
 #27543

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: 1988


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

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
 #27545

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: 714



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

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
 #27547

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: 1064



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

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
 #27549

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?

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
June 26, 2015, 08:28:42 PM
 #27550


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 believe you are referring to the usury model that likely funds the large ASIC farms. Interest compounding is an exponential function and thus can't go on forever unless the money supply expands at the same or greater exponential rate also (and even that can't go on forever because it misallocates real capital and resources).

The article does not address the fact that the State has the motive to censor transactions to enforce KYC up to the level of cost it can extract from society, because this is the only way the Industrial Age society can continue to parasite on the Knowledge Age with the NWO.

Thus if you want to defend against the takeover of Bitcoin to effectively a fiat currency, you need essentially the hashrate that extracts more value from society than the State can. This is why I decided that the security of Bitcoin (and all derivative altcoins including Monero) was a eugenics paradigm and doomed to fail.

Thus I set myself about finding the solution to the problem. And I did! Coming soon to a cinema near you...

tvbcof
Legendary
*
Offline Offline

Activity: 1988


View Profile
June 26, 2015, 08:30:37 PM
 #27551

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?

If your node cannot understand something, it should not verify the subset of transactions which fall into this category.  I think (but am not certain) that this would be one of the definitions of a hard-fork vs. a soft-fork.  That is to say, if a node can be fooled in following the rules coded into it into verifying as true a transaction which is false, that would be a hard-fork.

Note that 'verifying true what is false' is NOT the same thing as 'failing to verify'.

If your node is 'turning into an SPV client' than it's probably an indication that it's time to patch your software.  If you are ejected from the network if you do not do so, it's an indication that a hard-fork has happened.


Odalv
Legendary
*
Offline Offline

Activity: 1064



View Profile
June 26, 2015, 08:33:41 PM
 #27552

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?

Evaluating NOP as doing nothing is what current nodes do. :-) NOPs are there just for this reason. => add new functionality in case it is required. :-)
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
June 26, 2015, 08:36:09 PM
 #27553

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?

If your node cannot understand something, it should not verify the subset of transactions which fall into this category.  I think (but am not certain) that this would be one of the definitions of a hard-fork vs. a soft-fork.  That is to say, if a node can be fooled in following the rules coded into it into verifying as true a transaction which is false, that would be a hard-fork.

Note that 'verifying true what is false' is NOT the same thing as 'failing to verify'.

If your node is 'turning into an SPV client' than it's probably an indication that it's time to patch your software.  If you are ejected from the network if you do not do so, it's an indication that a hard-fork has happened.

I wasn't claiming an old version full node would verify what it can't.

If your old version full node can't verify any transaction, then it is equivalent to a SPV node.

Derivative transactions is a virus that eventually spreads to all transactions.

Thus you could put an undocumented opcode out there and eventually force all full nodes to be SPV nodes by spending in derivative transactions to normal opcodes and spreading out your dust into as many places as possible.

kazuki49
Sr. Member
****
Offline Offline

Activity: 350



View Profile
June 26, 2015, 08:46:03 PM
 #27554


Please transport that to me within 10 minutes via my laptop's 3G (often dropping down to 56 kbps) wireless connection.

Yep, the naivete around here is astounding.
tvbcof
Legendary
*
Offline Offline

Activity: 1988


View Profile
June 26, 2015, 08:49:52 PM
 #27555


I wasn't claiming an old version full node would verify what it can't.

If your old version full node can't verify any transaction, then it is equivalent to a SPV nodes.

Only if you trust and/or mis-read what it is telling you.


Derivative transactions is a virus that eventually spreads to all transactions.

Thus you could put an undocumented opcode out there and eventually force all full nodes to be SPV nodes by spending in derivative transactions to normal opcodes and spreading out your dust into as many places as possible.

Sure.  Just get miners to accept it.  As I say, this tends not to happen without going through the BIP process (onerous though it may be.)  At least until Hearn get's his 'benevolent dictator' upgrade popularized sufficiently which will hopefully be never.

This is one of the reasons why there is a dichotomy between how those who are 'into' Bitcoin enough to be contributors an those who are players at a different level have such a difference of opinion on the XT project I think.  It's probably why Matonis seems to indicate that XT would kill Bitcoin.


TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
June 26, 2015, 08:55:19 PM
 #27556


I wasn't claiming an old version full node would verify what it can't.

If your old version full node can't verify any transaction, then it is equivalent to a SPV nodes.

Only if you trust and/or mis-read what it is telling you.

Please stop trying to weasel words away from the logic that the full node is relegated to being the same as any other SPV node.


Derivative transactions is a virus that eventually spreads to all transactions.

Thus you could put an undocumented opcode out there and eventually force all full nodes to be SPV nodes by spending in derivative transactions to normal opcodes and spreading out your dust into as many places as possible.

Sure.  Just get miners to accept it.

But your argument was that by default miners ignore and accept opcodes they don't parse (aka not a hard fork), thus no need to convince miners to accept your undocumented opcode (aka a soft fork). Please make up your mind which functionality you are arguing miners do by default in the old version. You are moving the goal posts.

Odalv
Legendary
*
Offline Offline

Activity: 1064



View Profile
June 26, 2015, 08:56:36 PM
 #27557

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?

If your node cannot understand something, it should not verify the subset of transactions which fall into this category.  I think (but am not certain) that this would be one of the definitions of a hard-fork vs. a soft-fork.  That is to say, if a node can be fooled in following the rules coded into it into verifying as true a transaction which is false, that would be a hard-fork.

Note that 'verifying true what is false' is NOT the same thing as 'failing to verify'.

If your node is 'turning into an SPV client' than it's probably an indication that it's time to patch your software.  If you are ejected from the network if you do not do so, it's an indication that a hard-fork has happened.

I wasn't claiming an old version full node would verify what it can't.

If your old version full node can't verify any transaction, then it is equivalent to a SPV node.

Derivative transactions is a virus that eventually spreads to all transactions.

Thus you could put an undocumented opcode out there and eventually force all full nodes to be SPV nodes by spending in derivative transactions to normal opcodes and spreading out your dust into as many places as possible.

99,9% of transactions are simplest (move coins from adress A to address B and C) ... but single bitcoin transaction can be much more complex
luigi1111
Legendary
*
Offline Offline

Activity: 1050



View Profile
June 26, 2015, 09:26:53 PM
 #27558


Derivative transactions is a virus that eventually spreads to all transactions.

Thus you could put an undocumented opcode out there and eventually force all full nodes to be SPV nodes by spending in derivative transactions to normal opcodes and spreading out your dust into as many places as possible.

Sure.  Just get miners to accept it.

But your argument was that by default miners ignore and accept opcodes they don't parse (aka not a hard fork), thus no need to convince miners to accept your undocumented opcode (aka a soft fork). Please make up your mind which functionality you are arguing miners do by default in the old version. You are moving the goal posts.

I *think* he was saying that you need to get (a) miner(s) to accept it so that it can get placed into a block, which would be necessary to create a situation like you're discussing.

Might not be what he meant though.

Edit: meaning, I think, that "miners" (same as other full nodes) would accept/ignore codes they don't know IF they are included in a block, but would not accept them for inclusion into their own blocks.
chessplayer99z
Newbie
*
Offline Offline

Activity: 1


View Profile WWW
June 26, 2015, 09:29:03 PM
 #27559

Very good info thanks! Smiley
Odalv
Legendary
*
Offline Offline

Activity: 1064



View Profile
June 26, 2015, 09:36:26 PM
 #27560

Edit: meaning, I think, that "miners" (same as other full nodes) would accept/ignore codes they don't know IF they are included in a block, but would not accept them for inclusion into their own blocks.

+1 .. this is soft fork
Pages: « 1 ... 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 1427 1428 ... 1560 »
  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!