Blocks overrule the memorypool. That's the whole point of using proof-of-work, right? A miner who wants to maximize fees paid in block he mines would include fee-paying transaction into a block even if it conflicts with non-final memory pool transaction. Miner can always pretend that he haven't seen that non-final transaction, you can't know for sure that he violated thus rule intentionally. So this rule appears pointless, it is neither strictly enforced nor economically motivated. Once the locktime expires, all of the versions of the transaction become valid, and any of them can be mined. The whole scheme needs a lot of thought. Currently, I don't think that the stock client handles any transaction replacement at all, mostly because no one is sure how it should work. |
|
|
|
Such a transition wouldn't need to be sudden. For mining, which will probably never be broken, there is no reason why we couldn't accept two different hash schemes with a sunset of the old hash scheme many years in the future.
Do you mean a rule like: the block is valid if it has sha256 proof-of-work of difficulty x OR SHA3 proof-of-work of difficulty y? That would not make much sense in the supposed case of sha256 being broken. True, it wouldn't make much sense in that case. But I'll bet you every single bitcoin that I own that there will not be a catastrophic break in SHA256 that makes a change in the mining scheme urgent on a timeline of less than a decade. MD5 is hopelessly broken, but none of the attacks would help with mining. I am very, very, very confident that SHA256 will not suffer a catastrophic break even worse than what has been found with two decades of work on MD5. |
|
|
|
Yes. You are right.
One question though.
Can you mine a block that double spends inputs from txns in the memory pool. Is this block rejected by miners who saw the nLockTime txn first?
Blocks overrule the memorypool. |
|
|
|
|
I thought about backing it for $200 to get the 64-core one, just for giggles, but there was no way they were going to hit the $3M stretch goal for that.
|
|
|
|
Hmm, nope, didn't help. bitcoind signrawtransaction 0100000001fbf9aa4434c561f25dd0510f5f1f5c4a945a2efe61868fc4ac20665bf5d2bcbe0100000000ffffffff0180969800000000001976a914ae56b4db13554d321c402db3961187aed1bbed5b88ac00000000 '[{"txid":"bebcd2f55b6620acc48f8661fe2e5a944a5c1f5f0f51d05df261c53444aaf9fb","vout":1,"scriptPubKey":"a914b34f5c13be2c394ca52dcddfee832b9a95e0701087","redeemScript":"524104360d5036b9a0e94187f3224b77a190a477788ab2f4b18366ff4b48dd63721219248f50b5afbae6c3111b091e1af083b0d5117966a96ce74963469664a04ee3eb4104ee69cafbb8f24ffe969b4c1310269eb0d896440aa858436bb58775bb5a5d5909e6cb8a65b4de24dd9770c6bf44d2183a1bd311bafaaa95c04cad2aa979d740694104cc8525385180a8e2a3fac4490de35d7f5da8ffb10860039c04648e6ed11a0c11c4769a2a0cd8fbe625119d907f77c0e6c28d45206b2cc5b18a8520256333545553ae"}]' '["5HqmKC5TvQnE8oKJfbtqxpqRPKuu6Qvqzpt3k3wDyEExExqyu3y"]'
{
"hex" : "0100000001fbf9aa4434c561f25dd0510f5f1f5c4a945a2efe61868fc4ac20665bf5d2bcbe01000000cc004cc9524104360d5036b9a0e94187f3224b77a190a477788ab2f4b18366ff4b48dd63721219248f50b5afbae6c3111b091e1af083b0d5117966a96ce74963469664a04ee3eb4104ee69cafbb8f24ffe969b4c1310269eb0d896440aa858436bb58775bb5a5d5909e6cb8a65b4de24dd9770c6bf44d2183a1bd311bafaaa95c04cad2aa979d740694104cc8525385180a8e2a3fac4490de35d7f5da8ffb10860039c04648e6ed11a0c11c4769a2a0cd8fbe625119d907f77c0e6c28d45206b2cc5b18a8520256333545553aeffffffff0180969800000000001976a914ae56b4db13554d321c402db3961187aed1bbed5b88ac00000000",
"complete" : false
}
I get the same hex out no matter which of the three keys I use, or even if I use all three keys. If I try to feed that hexout back in with a different key, I always get this: bitcoind signrawtransaction "0100000001fbf9aa4434c561f25dd0510f5f1f5c4a945a2efe61868fc4ac20665bf5d2bcbe01000000cc004cc9524104360d5036b9a0e94187f3224b77a190a477788ab2f4b18366ff4b48dd63721219248f50b5afbae6c3111b091e1af083b0d5117966a96ce74963469664a04ee3eb4104ee69cafbb8f24ffe969b4c1310269eb0d896440aa858436bb58775bb5a5d5909e6cb8a65b4de24dd9770c6bf44d2183a1bd311bafaaa95c04cad2aa979d740694104cc8525385180a8e2a3fac4490de35d7f5da8ffb10860039c04648e6ed11a0c11c4769a2a0cd8fbe625119d907f77c0e6c28d45206b2cc5b18a8520256333545553aeffffffff0180969800000000001976a914ae56b4db13554d321c402db3961187aed1bbed5b88ac00000000" '[{"txid":"bebcd2f55b6620acc48f8661fe2e5a944a5c1f5f0f51d05df261c53444aaf9fb","vout":1,"scriptPubKey":"a914b34f5c13be2c394ca52dcddfee832b9a95e0701087","redeemScript":"524104360d5036b9a0e94187f3224b77a190a477788ab2f4b18366ff4b48dd63721219248f50b5afbae6c3111b091e1af083b0d5117966a96ce74963469664a04ee3eb4104ee69cafbb8f24ffe969b4c1310269eb0d896440aa858436bb58775bb5a5d5909e6cb8a65b4de24dd9770c6bf44d2183a1bd311bafaaa95c04cad2aa979d740694104cc8525385180a8e2a3fac4490de35d7f5da8ffb10860039c04648e6ed11a0c11c4769a2a0cd8fbe625119d907f77c0e6c28d45206b2cc5b18a8520256333545553ae"}]' '["Second Key Goes Here"]'
{
"hex" : "0100000001fbf9aa4434c561f25dd0510f5f1f5c4a945a2efe61868fc4ac20665bf5d2bcbe01000000ce0000004cc9524104360d5036b9a0e94187f3224b77a190a477788ab2f4b18366ff4b48dd63721219248f50b5afbae6c3111b091e1af083b0d5117966a96ce74963469664a04ee3eb4104ee69cafbb8f24ffe969b4c1310269eb0d896440aa858436bb58775bb5a5d5909e6cb8a65b4de24dd9770c6bf44d2183a1bd311bafaaa95c04cad2aa979d740694104cc8525385180a8e2a3fac4490de35d7f5da8ffb10860039c04648e6ed11a0c11c4769a2a0cd8fbe625119d907f77c0e6c28d45206b2cc5b18a8520256333545553aeffffffff0180969800000000001976a914ae56b4db13554d321c402db3961187aed1bbed5b88ac00000000",
"complete" : false
}
The only difference is that the second one has three placeholders for signatures, while the first has only one. |
|
|
|
|
Such a transition wouldn't need to be sudden. For mining, which will probably never be broken, there is no reason why we couldn't accept two different hash schemes with a sunset of the old hash scheme many years in the future.
|
|
|
|
I just submitted a pull request to fix this: https://github.com/bitcoin/bitcoin/pull/1818This pull request makes three functional changes: - Adds "redeemScript" to listunspent output, when listing a p2sh/multisig output
- Adds "redeemScript" to signrawtransaction's second argument (list of previous transaction outputs)
- Adds a new RPC command, "createmultisig" that is just like "addmultisigaddress" but instead of adding the multisig address/redeemScript to the wallet, returns them in a JSON object.
It also includes new unit tests for the raw transaction API argument checking code (and refactors some argument checking to remove some code duplication). I just pulled in 1818 and compiled it on my box. Having some problems... kjj@inana# bitcoind signrawtransaction 0100000001473d8d74be3bf15aa2fad193535fca18e0be4c04387db1d043895e48a649a1770100000000ffffffff0180969800000000001976a914ae56b4db13554d321c402db3961187aed1bbed5b88ac00000000 '[{"txid":"77a149a6485e8943d0b17d38044cbee018ca5f5393d1faa25af13bbe748d3d47","vout":1,"redeemScript":"5241043c29e1fb734da2011303cd179917777372b6c31a188d61a3631d6eab0a95093e8aefea89aed984558c740fe01fb0eef296c940dd5fd78efeecd483a07b9402d8410489ad17da02ee59f7956264a22ee75dc6e0524aacc16a19eeeaa91abca24f08c6a5051f94c61f20f4fcab0fce9e8faab1e4f306d4cc92128cc434ce5ebd2fde6941041edfba4d6adf731c2eff112ab01524c0ee60fb882d093d445811448b4f58d9c0bf482e356a05fb6281293e11dd28d0d352a1a37edcaf10513386b56a514c830853ae","scriptPubKey":"a9142cde97168f599d9add3d4ab2e30b88d04aa2dbfe87"}]'
{
"hex" : "0100000001473d8d74be3bf15aa2fad193535fca18e0be4c04387db1d043895e48a649a17701000000cc004cc95241043c29e1fb734da2011303cd179917777372b6c31a188d61a3631d6eab0a95093e8aefea89aed984558c740fe01fb0eef296c940dd5fd78efeecd483a07b9402d8410489ad17da02ee59f7956264a22ee75dc6e0524aacc16a19eeeaa91abca24f08c6a5051f94c61f20f4fcab0fce9e8faab1e4f306d4cc92128cc434ce5ebd2fde6941041edfba4d6adf731c2eff112ab01524c0ee60fb882d093d445811448b4f58d9c0bf482e356a05fb6281293e11dd28d0d352a1a37edcaf10513386b56a514c830853aeffffffff0180969800000000001976a914ae56b4db13554d321c402db3961187aed1bbed5b88ac00000000",
"complete" : false
}
kjj@inana# bitcoind signrawtransaction 0100000001473d8d74be3bf15aa2fad193535fca18e0be4c04387db1d043895e48a649a1770100000000ffffffff0180969800000000001976a914ae56b4db13554d321c402db3961187aed1bbed5b88ac00000000 '[{"txid":"77a149a6485e8943d0b17d38044cbee018ca5f5393d1faa25af13bbe748d3d47","vout":1,"redeemScript":"5241043c29e1fb734da2011303cd179917777372b6c31a188d61a3631d6eab0a95093e8aefea89aed984558c740fe01fb0eef296c940dd5fd78efeecd483a07b9402d8410489ad17da02ee59f7956264a22ee75dc6e0524aacc16a19eeeaa91abca24f08c6a5051f94c61f20f4fcab0fce9e8faab1e4f306d4cc92128cc434ce5ebd2fde6941041edfba4d6adf731c2eff112ab01524c0ee60fb882d093d445811448b4f58d9c0bf482e356a05fb6281293e11dd28d0d352a1a37edcaf10513386b56a514c830853ae","scriptPubKey":"a9142cde97168f599d9add3d4ab2e30b88d04aa2dbfe87"}]' '["5KMsiwRcYLVHp59rf6FtfbAzC4xRZ2Pmxy1KznF9mHtDvV6ix7g"]'
{
"hex" : "0100000001473d8d74be3bf15aa2fad193535fca18e0be4c04387db1d043895e48a649a17701000000cc004cc95241043c29e1fb734da2011303cd179917777372b6c31a188d61a3631d6eab0a95093e8aefea89aed984558c740fe01fb0eef296c940dd5fd78efeecd483a07b9402d8410489ad17da02ee59f7956264a22ee75dc6e0524aacc16a19eeeaa91abca24f08c6a5051f94c61f20f4fcab0fce9e8faab1e4f306d4cc92128cc434ce5ebd2fde6941041edfba4d6adf731c2eff112ab01524c0ee60fb882d093d445811448b4f58d9c0bf482e356a05fb6281293e11dd28d0d352a1a37edcaf10513386b56a514c830853aeffffffff0180969800000000001976a914ae56b4db13554d321c402db3961187aed1bbed5b88ac00000000",
"complete" : false
}
The privkey shown is for one of the three pubkeys in the multisig address, none of which are in the wallet. To save a little time, the transaction I'm trying to redeem is 77a149a6485e8943d0b17d38044cbee018ca5f5393d1faa25af13bbe748d3d47 and the multisig address is 35nGJpcQr4pYVyFVR3BPbdaWUSk6NBryUD. The multisig info can be found with: bitcoind createmultisig 2 '["043c29e1fb734da2011303cd179917777372b6c31a188d61a3631d6eab0a95093e8aefea89aed984558c740fe01fb0eef296c940dd5fd78efeecd483a07b9402d8","0489ad17da02ee59f7956264a22ee75dc6e0524aacc16a19eeeaa91abca24f08c6a5051f94c61f20f4fcab0fce9e8faab1e4f306d4cc92128cc434ce5ebd2fde69","041edfba4d6adf731c2eff112ab01524c0ee60fb882d093d445811448b4f58d9c0bf482e356a05fb6281293e11dd28d0d352a1a37edcaf10513386b56a514c8308"]'
{
"address" : "35nGJpcQr4pYVyFVR3BPbdaWUSk6NBryUD",
"redeemScript" : "5241043c29e1fb734da2011303cd179917777372b6c31a188d61a3631d6eab0a95093e8aefea89aed984558c740fe01fb0eef296c940dd5fd78efeecd483a07b9402d8410489ad17da02ee59f7956264a22ee75dc6e0524aacc16a19eeeaa91abca24f08c6a5051f94c61f20f4fcab0fce9e8faab1e4f306d4cc92128cc434ce5ebd2fde6941041edfba4d6adf731c2eff112ab01524c0ee60fb882d093d445811448b4f58d9c0bf482e356a05fb6281293e11dd28d0d352a1a37edcaf10513386b56a514c830853ae"
}
Ooh, just had a thought. I used addmultisigaddress to add this multisig to the wallet, but the private keys are not in the wallet. Could it be ignoring the command-line provided keys because it thinks it owns that address? I'll create a fresh batch of keys tomorrow to check that. |
|
|
|
yes. any limit (that is a limit order not market order) order of any price will always execute at the highest possible price available.
A limit order of 100 BTC @ $X doesn't mean "sell 100 BTC @ $x" it means "sell 100 BTC but don't accept a price BELOW $X".
Please note that the actual price that you get is a matter of exchange policy, not a law of mathematics. Do not set X below the least amount that you are willing to accept for them. If you tell the exchange: "sell 100 BTC for not less than $0.01 each", you can't get upset if your sale only nets you $1.00, even if it usually gets you over a grand. So, there's no guarantee that Mt. Gox will actually match your order with the highest price? In your opinion, would this be a bad method for insuring my coins will get sold at market price? I understand the mathematical aspect of it, but in it's real world application is it really risky? I would speak to them. They have dealt with this issue, I presume, several times over the years, But a statement from them will necessarily be more useful than any third-hand quotes that you collect from these forums. |
|
|
|
yes. any limit (that is a limit order not market order) order of any price will always execute at the highest possible price available.
A limit order of 100 BTC @ $X doesn't mean "sell 100 BTC @ $x" it means "sell 100 BTC but don't accept a price BELOW $X".
Please note that the actual price that you get is a matter of exchange policy, not a law of mathematics. Do not set X below the least amount that you are willing to accept for them. If you tell the exchange: "sell 100 BTC for not less than $0.01 each", you can't get upset if your sale only nets you $1.00, even if it usually gets you over a grand. |
|
|
|
To be clear, I'm not anti-asic. I'm not anti-greed. I'm not anti-elitism. I aim to be a socialist but living in a capitalist world requires me to make money to survive. Money, greed and elitism are a fact of life in a capitalist society. Sometimes pointing out the obvious makes it appear as if you're complaining.
That puts you in rare company here. Most of us regard "greed" as a good thing, the force that drives progress. The OP and many others claim that bitcoin takes the power away from the elite. There was a time when this was true but it is becoming less true. The introduction of ASIC eliminates quite a lot of people from the mining scene creating an elite class of miners. The BitCoin Foundation is another example of elitism.
ASICs were inevitable. You might as well complain that the sun sets in the evening. The few people (Atlas) attempting to have a discussion about this and other issues (or non issues) are marginalized and ridiculed. Again, I'm not anti-bitcoin foundation either.
The only thing I am certainly going on-and-on about is the shut-the-fuck-up-DIAF, attitudes of people who have a dissenting opinion. Bitcoin is most often advertised in a way that suggests elitism is reduced by the ability for any schmuck to be able to be a player. It shouldn't shock anyone that it has attracted people who would be offended by marginalizing or outright elimination of those schmucks.
Atlas is a special case. He really does need to STFU/DIAF. Or at least have his psychiatrist adjust his meds. As to other dissenting opinions, I haven't seen any real hostility. Sadly, most of the dissenting opinions start with premises that are not widely considered to be true here, and the arguments raised by the dissenters rarely rise above the level of repeating their assumptions. For example, your opening paragraph makes it pretty clear that you feel that "money, greed and elitism" are bad things. Most of us disagree, and no matter how self-evident their badness may be to you, if you just assert your position over and over again, we'll get annoyed. (See Atlas...) In the end, bitcoin seems doomed to be something more like fiat when viewing it from an end user perspective. Some elite group of people controlling it, manipulating it, and deciding who gets to be a player with the only real advantage being that you can buy drugs online and gamble online with it. That, of course, is a completely different discussion. Would bitcoin survive elimination of these spending avenues?
Money is not wealth. I bolded it because it is a superbly important concept, and one that most people fail to understand. Money is a means to facilitate trades of wealth across time and space. If you were hoping that bitcoin was going to steal the wealth of those that produced it and give it to those that did not, then yeah, bitcoin will be a "failure" in those terms, just as fiat has been. |
|
|
|
|
Catastrophic breaks in hashes are pretty much unheard of these days. What happens is that they get weaker gradually, with plenty of warning. For example, MD5 is considered to be totally broken now, and should never be used. On the other hand, if it was used in bitcoin transactions, those transactions would still be totally safe, for at least a few more years, because all of the attacks require conditions that can't be met in the bitcoin system. As in, if we changed one of the NOPx opcodes to OP_LOL_CHECKMD5SIG which used MD5(MD5(key)) instead of RIPE-MD160(SHA256(key)), it would still take decades to crack, probably centuries.
And your estimate of how long a brute force attack on SHA-256 would take is wrong, it isn't centuries, it is billions and billions of years, minimum. If you converted the entire mass of the sun into energy, and used all of that energy to increment a counter using the absolute limit of physics for minimum energy used to flip a bit, you'd get to around 2225. You'd need 231 suns of similar mass to finish just iterating through all of the possible inputs. So, billions of stars, or trillions or quadrillions if you want to actually perform the hashes too.
There are no "plans" exactly, on what to do next, but it is widely understood that we can swap out the primitive operations when needed. We might not be alive then, why should we presume that the people that will actually be doing the work want to follow our plans instead of making their own?
|
|
|
|
Here is the transaction. 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000 Can you get this from the API? Or did you pull it from the source code? The "format" of blk000x.dat is very simple. 4 bytes for the magic code, "f9beb4d9". 4 bytes for the block size. 80 bytes for the header. [size-80] bytes for the block body. And the block body is very simple too, a varint that says how many transactions follow, and then the transactions themselves. What I pasted above is nearly the whole block. f9beb4d9 <-- magic
1d010000 <-- size = 285
0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c <-- header
0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000 <-- body (the initial 01 is the number of transactions, the rest is the genesis transaction)
|
|
|
|
For what it's worth, I decoded it by hand, and saw nothing unusual. 01000000 Version
01 Number of TXIns
00000000000000000000000000000000 Hash of input (0x00 for generate)
00000000000000000000000000000000 Hash of input (0x00 for generate)
ffffffff TxOutIndex (0xffffffff for generate)
4d length (77 bytes)
04ffff001d0104455468652054696d65 16
732030332f4a616e2f32303039204368 32
616e63656c6c6f72206f6e206272696e 48
6b206f66207365636f6e64206261696c 64
6f757420666f722062616e6b73 77 bytes, "Arbitrary Data"
ffffffff nSequence
01 number of TXOuts
00f2052a01000000 value =50*100000000
43 length of output script (67 bytes)
41 Push 65 bytes
04 key type
678afdb0fe5548271967f1a67130b710 16 X
5cd6a828e03909a67962e0ea1f61deb6 32 X
49f6bc3f4cef38c4f35504e51ec112de 48 Y
5c384df7ba0b8d578a4c702b6bf11d5f 64 Y
ac OP_CHECKSIG
00000000 nLockTime
|
|
|
|
Here is the transaction. 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000 You can feed that to decoderawtransaction and get: {
"txid" : "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"coinbase" : "04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73",
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 50.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f OP_CHECKSIG",
"hex" : "4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac",
"reqSigs" : 1,
"type" : "pubkey",
"addresses" : [
"1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa"
]
}
}
]
}
|
|
|
|
Pics or none of this is true.
  |
|
|
|
I recently started flagging addresses in the wallet properties that were created solely for change. Hidden by default with checkbox to show/hide could be nice! Addresses cannot be linked unless you know the chaincode, which is stored in both full wallets and watching-only wallets. Without access to at least the watching-only wallet, there is no way for anyone to associate two addresses or public keys. The strength of this non-linkage is as strong as the inability for someone to derive your private key from your public key. If generated address is not dependent on previously generated address in any way than it might be OK. Many so called "attacks" against crypto algorithms require related keys. Not a math expert myself I don't know if this is applicable to Armory generated address. But the blockchain transactions might be somewhat compromised if the addresses can be linked using this method. Basically then You cannot then just say "sorry officer, I sold all those Bitcoins I purchased from my MtGox account to someone else I don't personally know. I did not know he will be ordering drugs from you straight away!" The solution might be a non-deterministic wallet possibility. It might be available under "Advanced" options where currently crypto options are located with appropriate warnings that paper backup is not possible with such type of wallets. The deterministic type must be the default type of wallet because users who use Armory over other clients and front-ends are probably because they need the deterministic property and paper backup functionality. And Thank You for creating Armory! It is a great job, it functions well enough and offline wallets and offline signing are easy to use and probably only way to not lose precious Bitcoins to hacking. The EC math used to generate the keys is pretty much the same as the EC math used to perform the digital signatures in transactions. As in, if you can run the key sequence backwards and find the root key, you probably don't need to. |
|
|
|
How about a try/catch block? <?php
ini_set("display_errors", TRUE);
include('./jsonRPCClient.php');
try{
$bitcoin = new jsonRPCClient('http://bla:bla@111.111.111.111:8332/');
$getinfo = $bitcoin->getinfo();
echo "online";
}catch(Exception $e){
echo "offline: $e";
}
?>
|
|
|
|
Blocks are oddly sized
Makes sense. and their locations within the block files are pretty much arbitrary.
Even for someone starting from block 0? Yup, it is a consequence of the odd block sizes. Reading a single block may involve several disk reads. And getting the file offset to read will also take several reads in the index file. |
|
|
|
I'm test-running 0.7.1rc1 (self-compiled with libdb5.1 and without upnp on linux)
and found it drop dead already twice after sending it commands in the debug-console.
This (2nd) time it was the "move" command.
I instantly saw the mining-activity stop (cpu-meter in the panel), and the move
command didn't return a response. When it happened, I could still type more commands
in the console (though without getting an answer), but meanwhile also the debug-widget
has dropped dead and doesn't redraw anymore. I'll leave it stuck for a while and will look
back in this thread for debugging instructions before killing&restarting it...
PS: gdb says, it's stuck in pthreads_cond_wait in boost::unique_lock
in AddressTableModel::labelForAddress(QString)
in TransactionTableModel::lookupAddress(string,bool)
Interesting. One of my nodes has been doing the same thing in response to the RPC move command. |
|
|
|
this data is the precisely the same data you see on the P2P network.
Then how is this different than connecting to high-speed bitcoin peers? Blocks are oddly sized, and their locations within the block files are pretty much arbitrary. If you don't have enough RAM to cache the whole thing, serving them as blocks one by one will thrash the hell out of your disks. Also, the way the stock client does the download now, it asks the first node it connects to for the whole chain, block by block. Bittorrent, on the other hand, doesn't understand the data at all, so it serves it in chunks that are always the same size, which are always aligned with the filesystem blocks. It also can manage multiple connections, grabbing different chunks from here and there. The result is that torrents are much more efficient at bulk transfer. They are faster for the client, and less stressful for the server. But, for various reasons, we don't like that we have to use an outside distribution method. The long term goal is to improve the software to make the initial block download faster and smarter. The bootstrap and torrent are just a temporary thing to lighten the load while work continues. |
|
|
|
|
Show Posts
