Topic: Gold collapsing. Bitcoin UP. - page 182. (Read 2032248 times)
Very good info thanks!
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.
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
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.
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.
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.
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.
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. :-)
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.
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...
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?
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.
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)
Soft forking.
...
If you want to mine a block larger than the commonly accepted size, proceed with caution.
...
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?
Soft forking.
If this happens in your node:
... 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.
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.
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.
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.
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.
...
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.
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.
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.
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.
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.
Jump to: