Thx. And sorry for double post. It only require nIn<=nOut
That's right. But what if nIn=2 and nOut=1 - like here? Well, now I know: use the hash value of 1, but don't dare to fail the script! Wow I didn't know... Is it allowed by bitcoin-qt? By the protocol? I don't find anything in the linked thread These three transaction I referred to my OP have been mined, so obviously it is allowed. And now we all need to live with it - that's another argument on why a documentation other than satoshi's code is useless  |
|
|
|
Thx. And sorry for double post. It only require nIn<=nOut
That's right. But what if nIn=2 and nOut=1 - like here? Well, now I know: use the hash value of 1, but don't dare to fail the script! |
|
|
|
Since yesterday there have been like a few txs, committed into the blockchain, which IMO are literally broken. This broke my client BTW, but I fixed it already, and I know this cannot be reverted anymore, so I only wonder.. From what I understand using SIGHASH_SINGLE that has more outputs than inputs does not make any sense - so the code even prints an error then: unsigned int nOut = nIn;
if (nOut >= txTmp.vout.size())
{
printf("ERROR: SignatureHash() : nOut=%d out of range\n", nOut);
return 1;
}
Normally when there is an error somewhere when executing a script, it just fails - but here, despite of printing the error, it still accepts the transaction, using a hash value of 1 and then verifying the signature for such a hash. So what is up with it? Is it like someone just overlooked this piece of code - or is it "error => hash=1" by design? EDIT: If you don't know what I am talking about, checks these three txs: 315ac7d4c26d69668129cc352851d9389b4a6868f1509c6c8b66bead11e2619f
dbf38261224ebff0c455c405e2435cfc69adb6b8a42d7b10674d9a4eb0464dca
de744408e4198c0a39310c8106d1830206e8d8a5392bcf715c9b5ec97d784edd |
|
|
|
SetCompact sort of compresses the big 256 integer into a 32 bit value. 0x1d00ffff is the reference value that represents difficulty 1. It basically stands for: 0x1d00ffff
nSize = 0x1d
nWord = 0xfffff
Target = nWord << ( 8 * (nSize-3) )
Target = 0xfffff << (8 * 26)
So Bits=0x1d00ffff adds up to the Target of 00000000ffff0000000000000000000000000000000000000000000000000000 If you'd take the current bits; 436249641 = 0x1A00A429, you get a target: 0xA429 << ( 8 * (0x1A-3) ) => 00000000000000a4290000000000000000000000000000000000000000000000 A new (mined) block must have a hash value lower from the current target, in order for it to get accepted by the network. Hash rates impact the block.nBits in a way that each 2016 blocks new target value (encoded in Bits) for the next 2016 blocks is calculated - and then enforced while verifying blocks. The idea is that there should be exactly 2 weeks difference in the timestamps of the two blocks that are 2016 apart - if the difference was longer the target value is decreased, if shorter - increased, always proportionally. |
|
|
|
I'm afraid begging won't help you much. Saying that you have no experience with coding, is like saying that by "help" you mean someone doing it for you. As it turns out, people rarely like to help others that much for free, so better think of a different strategy |
|
|
|
Rather than quizzes, I've been working on enumerating some programming exercises for people to do if they want to start Bitcoin programming. They mainly consist of "Write code to open the blk*.dat files and.... (1) Count the number of blocks (2) Count the number of transactions (3) Verify the proof-of-work and merkle root for each block (4) Identify all the different types of TxOut scripts and address strings associated with them (5) Find the orphan blocks, (6) Calculate the number of UTXO in the pruned blockchain (7) etc". With references to the on-the-wire bytemaps and the Protocol Specification. I'm sure I could come up with some cool quizzes, though not specifically about the Bitcoin-Qt code... more about Bitcoin in general and it's quirks (count the endianness switches needed for this process on a LE machine: ...". But I'm not sure how useful that is (not that threads like this need to be highly efficient in their usefulness). But I think it would be neat to have something more elaborate like above to give people concrete ways to get into Bitcoin dev. I guess you forgot about: (0) - I dare you to build this client yourself. IMO, this would rule out like 90% of candidates |
|
|
|
Hi,
I'm looking for any info related to "tools for writing to the bitcoin chain" in-particular something that can be used to assemble scripts.
assembling scripts is a wide term - writing to the bitcoin chain is even wider what do you want to give at input, and what result would you expect? assembling scripts is easy - signing them is the most complex part, but this you can do in bitcoind with signrawtransaction, if it knows your keys. |
|
|
|
So are you saying that he actually noticed the attack, and only drew your attention by proposing a stupid patch to prevent it? Well, good for you, man. Though, their solution, how to fix it, is better, IMO |
|
|
|
bitcoin hashes are always in reversed order. somebody came with an idea that lsb is faster on the machines we have, so why not to extend it to 256 bits. I don't mean to criticize him, but IMHO it has not turned out to be the most optimal solution after all |
|
|
|
BTW, once again I want to raise my unheard voice, that txs with inputs that are not mined yet should be threat same as non-standard. They don't make any economical sense for anyone, except saroshidice. So unless you guys get a cut of it, or play there, please stop it |
|
|
|
Sorry, its a bit long to read, but if you don't mind I have a question already at the beginning. Almost all objects that are exchanged between Satoshi clients are deserialized to be stored in memory and serialized again when they need to be forwarded. . Transactions are also first deserialized in order to be parsed, but they are stored “as is” in a temporary cache called MapRelay, and forwarded without being serialized again. I really don’t know why this is done. But the point is that the storage of messages as they are received leads to the possibility that an attacker creates messages much bigger than the actual transaction object contained, which, when stored in MapRelay memory, can be used to exhaust the memory of a node. This is the code that patches the vulnerability: So, you are saying that checking whether a serialized size at the moment you receive the transaction, cutting if needed, and keeping the transaction as raw data is less DoS-resistant than keeping the transaction in objects and assembling it each time any node wants it? The only thing I would change here is only banning those that send me too long txs. But since we know that they might just route the shit, because of the bug, banning them would not be polite. So its a hard moral problem |
|
|
|
Thanks a lot! As the first donator you can ask me any feature you want to be included in pywallet. Have some more, since it makes you so happy  I don't need a feature, but just want to let you know that IMO your tool is undoubtedly the most useful bitcoin tool out there. Though, it would not be needed, if the actual client had the same commands just built in.. But well, at least soon it will have a great secured payment protocol. Everybody who wants to receive bitcoins will be able to submit his personal details directly to mossad, in order to receive a free certificate, which will guarantee that the bitcoin address he's sending to you is indeed his. Myself, I've been waiting for such a feature for years - using PGP signatures was so much of a hassle, and it was just too anonymous |
|
|
|
bestblock = highest block height seen/scanned by client
BTW, I don't think this bestblock works. Unless it got fixed recently.. or unless I don't understand what it should do. I used to use satoshi client for my cold storage and each time after updating the blocks+chainstate in this cold PC, I always had to do the -rescan. Without explicit rescan, it was never able to notice the new txs that came to the addresses from my cold wallet - even if there was only one new block added to the chain. |
|
|
|
You really shouldn't mess with the file directly. Treat it like a black box and use the proper tools (bdb). It's a good advise. Though it sucks that the bdb lib is so big - probably even bigger than openssl. May I ask, do you guys plan to remove bdb dependency from satoshi client one day? I mean, switching to HD wallets seems like a reasonable moment to drop it, especially since UTXO moved to leveldb. |
|
|
|
|
This got changed quite recently.
My guess is that someone was testing with debug libs and then forgot to put it back to non-debug, before committing. Or just overlooked it.
But this makefile is not used for the official (gitian) builds anyway.
|
|
|
|
|
I think you'd have a better chance of getting this answered, asking it in one of the mining sections.
|
|
|
|
Still the lack of documentation is kinda sad. It just means countless hours wasted "relearning" the same thing by each developer.
I guess the best entity to address your concerns would be Oracle, since they own the development of this db. But I believe there might be a doc with the format of these files, somewhere. Inside the DB itself, there are satoshi specific "key-value" records, which indeed would be nice to have somewhere on the wiki, but AFAIK there is no such page. And moreover it's getting changed as we speak - a new type of "keymeta" records are coming... Up to v.0.8.3, the possible key-types were: name, tx, acentry, key, wkey, mkey, ckey, defaultkey, pool, version, cscript, orderposnext Most of the key-types are followed with additional data (i.e. tx is followed by its hash). The key-type plus this additional data is the actual DB key. As for the format of the value, you'd need to analyze the source code. Check ReadKeyValue in walletdb.cpp |
|
|
|
|
Your logic seems solid, but I do not see any question in the OP.
Of course bitcoind will not fill the key pool if you don't unlock the wallet - that's kind of obvious.
Unless you have just found a critical bug, but the theory is that it cannot even if it wanted to.
|
|
|
|
It's just writing code and it doesn't seem so much of work.
/me looking forward to reviewing your patch. my client already has a deterministic wallet oh, now I see the problem. replacing a call to secret.MakeNewKey(fCompressed) with secret.DetermineNewKey(fCompressed, lastKey) would be a very simple hack... if not for the fact, that getting the lastKey value seems extremely complex, if not impossible, with the current architecture. so sorry, I ought to take it back; it's not a simple hack. not in this code. but I see that its getting changed as we speak - good! |
|
|
|
Process for creating a "watching wallet" using bitcoind:
1) On a secure non-public computer, create new wallet, expand keypool to desired size, encrypt with strong known passphrase
2) Make an offline backup of the wallet and passphrase = "spending wallet"
3) Change encryption passphrase to a random 256 bit string (base64) = "watching wallet"
4) For security purposes, discard and do not record the random passphrase anywhere.
5) Transfer "watching wallet" to wallet server.
At this point you have two identical copies of the same wallet (including the same sequence of private keys in the keypool). The "watching wallet" has an unknown and unbreakable random passphrase so loss of the server wallet will not compromise the private keys. In testing it would appear that there is no scenario where the watching wallet could create a key not in the spending wallet however I would like some confirmation that I haven't missed anything. It would be more elegant (and also safer) to literally erase (overwrite with random data) the private keys, instead of encrypting them with the "unbreakable" password. Maybe jackjack could add such an option to his so useful pywallet tool. The watching wallet cannot create new keys, but the spending wallet can, so in theory you still need to repeat the process once for awhile. Though in practice, if you told it to used -keypool of thousands, it should take you awhile to consume it all. Unfortunately there is no explicit message to inform you that the pool has just been extended - not on the GUI, though I believe in the debug log there should be something like this: keypool added key XXX, size=YYY |
|
|
|
|
Show Posts
