|
The so called 'powerful new attack' happens if you give your master public key AND you use a scrappy prng.
No new research at all. just fud.
|
|
|
|
Someone should do a best of the blockchain. Some whacked scripts are in there.  |
|
|
|
|
The reference client has received some pretty negative comments. Bad code style, lack of innovation, not enough contributions, etc. I feel it remains the #1 used full node implementation because of it is name.
How many of you are willing to choose a different code base or do you think that it is good enough?
And how many think that running a full node is not worth the trouble?
|
|
|
|
|
I'm not using bitcoin core and my code is performing cross block full validation. In fact, Bitcoin core is taking longer without doing validation.
I know my desktop is not underpowered but 24h+ is not the same as 5 mn. Just saying that validation is not such a big deal.
|
|
|
|
Just signature and Merkle tree analysis of the whole blockchain (which is disabled by checkpoints) would take ~24+ hours of modern CPU processing power. These need to be performed by every user in a trustless environment. Optimizations are beneficial to every user, whether by utilization of available hardware resources, algorithmic shortcuts, or even hand-tuned x64/SSE assembly code routines.
It isn't so bad. On a i7 desktop ivy bridge 8-core machine, I could validate all the scripts up to block #295000 in just about 5 1/2 mn. Succeeded #36249675
Failed #0
Elapsed 334s
I don't have a more recent bootstrap file, but by interpolating it shouldn't take more than 10 mn to do the complete chain. |
|
|
|
Unless I'm reading it wrong, it's not necessary for all copies to have bit rot, just the canonical copy that either Palatinus or Marsee had. Perhaps you are correct if by 'downgrading' it means the existing nodes out there--the 10000 copies you mention--would, by nature of the P2P network, becomes the majority again, but it's not clear since the mere fact that Palatinus and Marsee uploaded their nodes with a post-0.8 chain made the chain unstable. So it implies that two people--Palatinus and Marsee--had control of the entire bitcoin network by virtue of having a canonical node(s). Thus if these two nodes had bit rot, they would break the system.
No, because that's where the mining process comes in. Every block is validated with the hashes. Any "rot" would invalidate one person's chain and someone else's copy of the chain would be used. Perhaps another way of looking at this problem is the gitbhub thread below. If, as the chief scientist G.A. claims, it was only due to the heroic efforts of two people to downgrade to a earlier version of the BTC blockchain that saved the bitcoin P2P network from disaster, then it stands to reason that bitrot could cause a repeat of this incident, in that a 'buggy' version of the bitchain is adopted (namely, one with bitrot) and if there's no heroic people to step in, the system crashes. Another way of looking at it: RAID systems have on rare occasions had bit rot that propagates, bringing down the whole system. In theory this is impossible, but in practice it is not. Might the same thing happen with bitcoin? Time will tell. I'll leave the last word to somebody else. TonyT The blockchain has anti-tempering code embedded inside. It protects it from easy modification. One has to spend a significant computing power in order to add a block. This catches any sort of modification: whether voluntarily or accidental. A bit rot is a random change - it will be detected and rejected. The event you mentioned is of a different nature. Half of nodes were running an incompatible version of the software and were actively pushing a blockchain that the other half would reject. In one case, it's an isolated incident that can be caught by the hash. In the other case, it's a widespread software bug that affects a large number of nodes - as if they all went crazy. We don't have to worry about bit-rot. On the other hand software bugs can be a real threat. These guys run mining pools. They represented a big portion of the hashing power at the time. They were running the good version but downgraded to the bad one so that the majority would be clear. In any case, it is not a single machine. PS: RAID drives are not as well protected as the blockchain. It's a trade off between performance, space and cost. They could detect bit-rot better but they would run slower. |
|
|
|
Thanks, turned out my mistake was somewhere else. Regarding the last script, OP_FALSE 3045022015bd0139bcccf990a6af6ec5c1c52ed8222e03a0d51c334df139968525d2fcd20221009f9efe325476eb64c3958e4713e9eefe49bf1d820ed58d2112721b134e2a1a5303
30460221008431bdfa72bc67f9d41fe72e94c88fb8f359ffa30b33c72c121c5a877d922e1002210089ef5fc22dd8bfc6bf9ffdb01a9862d27687d424d1fefbab9e9c7176844a187a01
52483045022015bd0139bcccf990a6af6ec5c1c52ed8222e03a0d51c334df139968525d2fcd20221009f9efe325476eb64c3958e4713e9eefe49bf1d820ed58d2112721b134e2a1a5303210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c7153ae
The first signature is in the redeem script and has to be removed before it is inserted into the transaction to sign. I was missing this part since for a standard tx, the signature is in the input script. |
|
|
|
|
Cool but how can they be valid? They have disabled op codes.
|
|
|
|
|
Are they allowed to include invalid transactions?
|
|
|
|
There are a few Pay2SH transactions that I can't validate. For example, https://blockchain.info/tx/567a53d1ce19ce3d07711885168484439965501536d0d0294c5d46d46c10e53bThe script hash matches but the script uses OP_RIGHT. OP_1 OP_RIGHT 6e879169907c9087 OP_RIGHT s a disabled op code. Shouldn't the script fail? It's not the only example. We have 6 other scripts that use disabled opcodes and yet are part of the blockchain. Another one, harder for me to understand https://blockchain.info/tx/5df1375ffe61ac35ca178ebb0cab9ea26dedbd0e96005dfcee7e379fa513232fOf all the P2SH cases in the blockchain, my tool only rejects this one. It looks like a standard 2 of 3 multisig. The 2nd signature is a SIGHASH_SINGLE but the first one is a regular SIGHASH_ALL. Yet, none of the provided public keys seems to match the first one either. There must be something wrong with my tool but I don't see where. I could run another client but it will take hours before it catches up to this point. A standalone verifier would be great. Because usually, the issue is in the way I built the transaction to sign. Is there such a tool available? I tried decoderawtransaction - it doesn't give much information. {
"txid" : "5df1375ffe61ac35ca178ebb0cab9ea26dedbd0e96005dfcee7e379fa513232f",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "b5b598de91787439afd5938116654e0b16b7a0d0f82742ba37564219c5afcbf9",
"vout" : 0,
"scriptSig" : {
"asm" : "30450221008dd619c563e527c47d9bd53534a770b102e40faa87f61433580e04e271ef2f960220029886434e18122b53d5decd25f1f4acb2480659fea20aabd856987ba3c3907e01 022b78b756e2258af13779c1a1f37ea6800259716ca4b7f0b87610e0bf3ab52a01",
"hex" : "4830450221008dd619c563e527c47d9bd53534a770b102e40faa87f61433580e04e271ef2f960220029886434e18122b53d5decd25f1f4acb2480659fea20aabd856987ba3c3907e0121022b78b756e2258af13779c1a1f37ea6800259716ca4b7f0b87610e0bf3ab52a01"
},
"sequence" : 4294967295
},
{
"txid" : "ab9805c6d57d7070d9a42c5176e47bb705023e6b67249fb6760880548298e742",
"vout" : 0,
"scriptSig" : {
"asm" : "0 3045022015bd0139bcccf990a6af6ec5c1c52ed8222e03a0d51c334df139968525d2fcd20221009f9efe325476eb64c3958e4713e9eefe49bf1d820ed58d2112721b134e2a1a5303 30460221008431bdfa72bc67f9d41fe72e94c88fb8f359ffa30b33c72c121c5a877d922e1002210089ef5fc22dd8bfc6bf9ffdb01a9862d27687d424d1fefbab9e9c7176844a187a01 52483045022015bd0139bcccf990a6af6ec5c1c52ed8222e03a0d51c334df139968525d2fcd20221009f9efe325476eb64c3958e4713e9eefe49bf1d820ed58d2112721b134e2a1a5303210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c7153ae",
"hex" : "00483045022015bd0139bcccf990a6af6ec5c1c52ed8222e03a0d51c334df139968525d2fcd20221009f9efe325476eb64c3958e4713e9eefe49bf1d820ed58d2112721b134e2a1a53034930460221008431bdfa72bc67f9d41fe72e94c88fb8f359ffa30b33c72c121c5a877d922e1002210089ef5fc22dd8bfc6bf9ffdb01a9862d27687d424d1fefbab9e9c7176844a187a014c9052483045022015bd0139bcccf990a6af6ec5c1c52ed8222e03a0d51c334df139968525d2fcd20221009f9efe325476eb64c3958e4713e9eefe49bf1d820ed58d2112721b134e2a1a5303210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c7153ae"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 0.00100000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_HASH160 d8dacdadb7462ae15cd906f1878706d0da8660e6 OP_EQUAL",
"hex" : "a914d8dacdadb7462ae15cd906f1878706d0da8660e687",
"reqSigs" : 1,
"type" : "scripthash",
"addresses" : [
"3MTdzi2J1qqge4MsGykL7K461JuSwNqwko"
]
}
}
]
}
Thanks for your help |
|
|
|
|
You have it reversed. The client is the one sending the filter (with the filterload message) and the server is scanning the transactions. Of course, what you described could work but it is not the current protocol.
|
|
|
|
|
Thanks - that makes perfect sense.
|
|
|
|
Thanks. If a node prunes spent transactions, a hierarchical wallet will not 'see' the empty transactions anymore and it will stop scanning after the gap limit is passed.
Nodes might prune transactions but maintain a bloom filter of addresses they saw. A bloom filter cannot do that. An invertible bloom filter might but it is not decided yet if it is going to used (cf Gavin's message). false positives only extend the scan. All funds would be found. BTW, an invertible bloom filter is not a bloom filter. You seem to be pretty sure of what you say but I really don't see how it would work. The client sends the filter parameters and the server creates a filter per session. The server scans its blocks. If the spent tx are removed from the server, how would it know how to match the filter? I'm ok being wrong but could you describe the actual process? |
|
|
|
Electrum uses a 3rd party server, which if you connect to a cancer server, then you can be fooled to think you have bitcoins you really may not.
This is wrong. Electrum verifies all transactions in its history using SPV. Yes but it could be fooled by omitting some transactions. I switched to Electrum from Armory. I still think it's the best solution at the moment for someone who doesn't want to spend hours downloading the blockchain but it's not suitable for a merchant. Back to topic, In my opinion, there should be a client that lets you: - use a bootstrap file to catchup to a recent checkpoint - catchup the remaining part of the blockchain by downloading simultaneously from multiple peers (bitcoin core uses 1 peer) - performs validation in parallel and progressively as the chain gets reconstructed - prunes the spent transactions locally. It could also prune the blocks if it doesn't care about relaying the blockchain. If we are allowed to change the protocol, let there be a way to transfer a verifiable list of spent transactions and real transactions. I think this is what Gavin talks about in his post but I need to see more detail to be sure. |
|
|
|
Thanks. If a node prunes spent transactions, a hierarchical wallet will not 'see' the empty transactions anymore and it will stop scanning after the gap limit is passed.
Nodes might prune transactions but maintain a bloom filter of addresses they saw. A bloom filter cannot do that. An invertible bloom filter might but it is not decided yet if it is going to used (cf Gavin's message). |
|
|
|
|
It happens hundreds of times. I was wondering if it was on purpose and if so, why?
|
|
|
|
|
It's decentralized, not parallel. Every full node has to verify the whole blockchain.
|
|
|
|
You guys say that hard drives are cheap but you still have to scan the block chain at first. It takes a very long time to do but is the only trust less solution, isn't it?
Yes, today. But not at some point in the future. Please read about "UTXO commitments" in https://bitcoinfoundation.org/2014/10/a-scalability-roadmap/It's good to know there is a plan out there to have ultra pruned tree verification. The hashes you mentioned are going to incorporated in Merkle trees? I thought that the Bloom filter mechanism was going to be extended to skip over used tx. In any case, would it be compatible with deterministic wallets? Without the used txs, they will stop scanning for addresses too early. A deterministic wallet is simply a way of generating addresses. Bitcoin classically generates new private keys using a true random number generator for each address. When a new address is needed to request a payment, it is generated at random and is not related to any other key. A deterministic wallet instead uses a pseudo-random number formula to create addresses, with only the initial seed state being a generated random number. This prevents the wallet backup from becoming obsolete, because any past or future address you created can be recreated from the seed backup. Pruning is a technique for reducing blockchain disk space consumption, and is unrelated to your wallet addresses. We assume that the blockchain history has already been thoroughly validated by many miners after it is buried under many blocks and that every transaction in it was properly signed by the owner. Therefore, as long as the hash chain in the headers is correct, we don't need to verify the chain-of-ownership of every single bitcoin amount back to its original creation for our own security. This allows an individual client to remove the spent transactions from the blockchain, potentially freeing hard drive space, and even may enable a 'pruned network' p2p client to exchange a lightweight blockchain between peers. The "plan out there" for pruning was put forth in the original Bitcoin paper: http://we.lovebitco.in/how-bitcoin-works/bitcoin-paper/#ch7 - it is just that nobody has written a complete client implementation that does this yet. Thanks. If a node prunes spent transactions, a hierarchical wallet will not 'see' the empty transactions anymore and it will stop scanning after the gap limit is passed. |
|
|
|
|
Show Posts
