What is the goal here? Are we creating new keys? Trying to insert them into your wallet? Extract existing ones from your wallet? I can't help you with the openssl library, or PEM formats or anything. But I can offer you some code and diagrams that will help you figure out what's going on. The middle link of my signature has a diagram of the address-conversion process (halfway down the page), starting from the two 32-byte public-key integers and ending up at the final BTC address. It sounds like to me, that the private key format is very similar except you're skipping the top half of that diagram and using a full 32-byte repr of the private key, instead of a hash. So a regular address looks like (where netbyte==0x00 for main network) [NetByte | 20-byte Hash | 4-byte-hash-of-first-21-bytes] ==> 25 bytes Instead, the private key format would look like: [0x80 | 32-byte private key (BE) | 4-byte-hash-of-first-33-bytes] ==> 37 bytes If it's anything like the address conversion, the private key will probably have to be big-endian before the hash is applied. My signature has a a link to PyBtcEngine which has a ton of great python tools for playing with this stuff (you can actually ignore all the C++ code, you only need pybtcengine.py and nothing else). Then you can do something like the following: Python/PyBtcEngine Example code on gistAnd here's the output of the above code: Creating new address:
BTC Address: 13KHLsKV1wVSFGAR7ohMWmvdEdcJsVdK52 (BinaryLE=19656185d9ba7af25bb8a3f3182833a39b79ae45)
Have Public Key: True
Have Private Key: True
Public Key Hex (Big-Endian):
04 869499bad9e3b4bf1c94dc772faf8a37d1182581697947b902e7d246dd7e7517
9f6ffe719917b111f87253dda6c4beb31808bcfe45d1a6bd8272fd65f102258d
Private key (integer): 89186423366759378937952085459266693389487184404252697411501348684075646220810
Private key (hex, BE): c52dba0d191411cc7142da6979e47c8faa65ac9708f553c8fb6ce0517e4e7a0a
Encoded privkey: 80c52dba0d191411cc7142da6979e47c8faa65ac9708f553c8fb6ce0517e4e7a0a4095c005
Base58 privkey: 5KK8F9VQF6KMxDMgM1juEDd11XZXhLxVbeMb8hTPtt1bpV58diL
Recovering private key from base58 encoding:
Valid checksum!
Recovered address information:
BTC Address: 13KHLsKV1wVSFGAR7ohMWmvdEdcJsVdK52 (BinaryLE=19656185d9ba7af25bb8a3f3182833a39b79ae45)
Have Public Key: True
Have Private Key: True
Public Key Hex (Big-Endian):
04 869499bad9e3b4bf1c94dc772faf8a37d1182581697947b902e7d246dd7e7517
9f6ffe719917b111f87253dda6c4beb31808bcfe45d1a6bd8272fd65f102258d
Obviously, then you can examine what the python code is doing (just remember my hash256() == sha256(sha256())). Be aware, that the python random-number-generator is probably not the best PRNG to be using for real money, but it is perfectly sufficient for playing around. In any software I produce, I'll probably be making calls to the C++ cryptopp libraries to get random numbers. (you could also generate your own random 32-bytes offline (or integer less than 2^256), and then plug it in at the appropriate line above. P.S. in the python code, I called the method "binary_to_addrStr" and "addrStr_to_binary" because I was expecting to only use it for address strings, but it works fine for private keys, too. |
|
|
|
Is quite simple to do in bitcoinj. Do you have a format in mind? If so send me an sample will see what I can do. Please DOUBLE check it is signed correctly! Make it a transaction that sends to my address below and I will have more motivation! I was thinking that if www.bitaddress.org could also create/sign transactions (not trival as need to link all the inputs), then if you had this web site you could then create transaction totally offline. I just created a tx, transferring 1.0 BTC to the address in your signature. I plugged this tx and the previous one into my ECDSA unit-test (which works on other Blockchain tx-pairs) and it passed. So I'm fairly confident that this is signed correctly. Here's the raw hex: 0100000001f658dbc28e703d86ee17c9a2d3b167a8508b082fa0745f55be5144a4369873aa010000008c49304602210041e1186ca9a41fdfe1569d5d807ca7ff6c5ffd19d2ad1be42f7f2a20cdc8f1cc0221003366b5d64fe81e53910e156914091d12646bc0d1d662b7a65ead3ebe4ab8f6c40141048d103d81ac9691cf13f3fc94e44968ef67b27f58b27372c13108552d24a6ee04785838f34624b294afee83749b64478bb8480c20b242c376e77eea2b3dc48b4bffffffff0200e1f505000000001976a9141b00a2f6899335366f04b277e19d777559c35bc888ac40aeeb02000000001976a9140e0aec36fe2545fb31a41164fb6954adcd96b34288ac00000000 And a pretty version of it: 0x0000: 01000000 01f658db c28e703d 86ee17c9 a2d3b167 a8508b08 2fa0745f 55be5144
0x0020: a4369873 aa010000 008c4930 46022100 41e1186c a9a41fdf e1569d5d 807ca7ff
0x0040: 6c5ffd19 d2ad1be4 2f7f2a20 cdc8f1cc 02210033 66b5d64f e81e5391 0e156914
0x0060: 091d1264 6bc0d1d6 62b7a65e ad3ebe4a b8f6c401 41048d10 3d81ac96 91cf13f3
0x0080: fc94e449 68ef67b2 7f58b273 72c13108 552d24a6 ee047858 38f34624 b294afee
0x00a0: 83749b64 478bb848 0c20b242 c376e77e ea2b3dc4 8b4bffff ffff0200 e1f50500
0x00c0: 00000019 76a9141b 00a2f689 9335366f 04b277e1 9d777559 c35bc888 ac40aeeb
0x00e0: 02000000 001976a9 140e0aec 36fe2545 fb31a411 64fb6954 adcd96b3 4288ac00
0x0100: 000000 @btc_novice: I'll happily toss you a BTC too, to test your solution, if you get something running. |
|
|
|
I've seen that discussion before, and that was actually going to be my last resort if I couldn't find this webpage... I hadn't seen that patch. I'll have to take a look at that.
I think I'll still have a go at setting this up as a webpage, since that would be a lot more convenient for people than patching the client.
Don't let me discourage you from diving into BTC -- it can be a fun, amazingly-educational experience. But I know for sure that three months ago there was a tx-broadcast webpage already in existence. Unfortunately, I lost all my bookmarks and am trying to locate it again... On the other hand, it may not be too difficult to setup such a webpage if you use the patch linked to from terrytibs: run an instance of the patched bitcoind, then make a webpage with a simple text-input box. The POST (?) command will simply convert the input text to binary, and pass it to your patched bitcoind for broadcast. You probably don't even need to know anything about BTC to do it! Just make sure there's someway to identify that there was an error... I imagine 90% of people trying to post txs in this way will have done something incorrectly the first few tries. |
|
|
|
There's a couple different ways to communicate a transaction with ASCII characters as I was proposing here, but the binary structure is constant. See the first image I posted on this page: https://bitcointalk.org/index.php?topic=29416.0That shows exactly how a Tx is serialized in binary, and has an example of every kind of "standard" TxIn and TxOut. This is exactly how the data is stored in your .bitcoin/blk0001.dat file, and exactly how it would be communicated to a tx-forwarder. The only question is if it's a webpage for pasting ASCII, how do you represent that binary data in ASCII? I think the best option is simply representing it in hex: two hexbytes per binary byte. Here's an example transaction, and what I would expect to be able to copy into the webpage: 01000000020f7b7fb86d4cf646058e41d3b007183fdf79736ed19b2a7468abc5bd04b16e91000000008c493046022100b2ee39d2fcc2e5544a57c30f7b4e49cfb82222666d034fb90e22348e17e28e0f022100db91c3199cc7b41d4d7afce0ccb4ceb424b9476d51c06142583daf53ce0a9b66014104c32215a9093011bd3c41283ace3d002c666077b24a605b3cfc8f71019a0f43df66f389f3d9a62188a494b869dc7e5f9dffc98a76d3088a21e9b738ec9eba98cbffffffff97004125528f7b5ed33465caaae021c0b815f3e6a3707641d5a0bca43fc14949010000008a473044022033d02c2e896f1a1252488d534cfb08abf3e7ea90aba7ba6f57abf189cef1d837022005668d755013b0e59a2af5145f10efe62ea716d333268b0b5a3efbd82d1439be014104c32215a9093011bd3c41283ace3d002c666077b24a605b3cfc8f71019a0f43df66f389f3d9a62188a494b869dc7e5f9dffc98a76d3088a21e9b738ec9eba98cbffffffff0100c2eb0b000000001976a91402bf4b2889c6ada8190c252e70bde1a1909f961788ac00000000
If you want to try following the binary bytemap, here's a pretty-printed version of the same data (each row is 32 bytes): 0x0000: 01000000 020f7b7f b86d4cf6 46058e41 d3b00718 3fdf7973 6ed19b2a 7468abc5
0x0020: bd04b16e 91000000 008c4930 46022100 b2ee39d2 fcc2e554 4a57c30f 7b4e49cf
0x0040: b8222266 6d034fb9 0e22348e 17e28e0f 022100db 91c3199c c7b41d4d 7afce0cc
0x0060: b4ceb424 b9476d51 c0614258 3daf53ce 0a9b6601 4104c322 15a90930 11bd3c41
0x0080: 283ace3d 002c6660 77b24a60 5b3cfc8f 71019a0f 43df66f3 89f3d9a6 2188a494
0x00a0: b869dc7e 5f9dffc9 8a76d308 8a21e9b7 38ec9eba 98cbffff ffff9700 4125528f
0x00c0: 7b5ed334 65caaae0 21c0b815 f3e6a370 7641d5a0 bca43fc1 49490100 00008a47
0x00e0: 30440220 33d02c2e 896f1a12 52488d53 4cfb08ab f3e7ea90 aba7ba6f 57abf189
0x0100: cef1d837 02200566 8d755013 b0e59a2a f5145f10 efe62ea7 16d33326 8b0b5a3e
0x0120: fbd82d14 39be0141 04c32215 a9093011 bd3c4128 3ace3d00 2c666077 b24a605b
0x0140: 3cfc8f71 019a0f43 df66f389 f3d9a621 88a494b8 69dc7e5f 9dffc98a 76d3088a
0x0160: 21e9b738 ec9eba98 cbffffff ff0100c2 eb0b0000 00001976 a91402bf 4b2889c6
0x0180: ada8190c 252e70bd e1a1909f 961788ac 00000000
|
|
|
|
|
I can construct transactions offline, signing them with a private key only kept on an offline computer. But then that packet must be transferred to an online computer and broadcast. Right now, the Satoshi client has no tx-forwarding capability. So I have 3 options:
(1) Write a program that can connect to the BTC network with peer discovery, networking protocol, etc (HARD)
(2) Modify the client source code to allow tx-forwarding (HARD -- I could spend a week just figuring out how to compile it)
(3) Copy-and-paste the serialized tx into a webpage where someone has already done this work for the rest of us (takes 10 seconds)
Personally, I prefer option 3.
|
|
|
|
1. TxOut scripts are not evaluated until they are spent-- those are probably unspendable TxOuts.
Fair enough... I was wondering if there was a reason to believe they were spendable, and thus I need to add something to my scripting code to accommodate. I'm really just looking for a sanity check. It sounds like there's no action here.. at least not until someone demonstrates they are spendable and my code would've failed. 2. The inputs must be valid (you're looking at coinbase txns with no inputs though). Again, TxOuts aren't evaluated until they are used as inputs in another transaction; as long as they deserialize properly they'll be accepted.
Looking back, I see that the transactions are coinbase, but the non-std scripts are in the TxOuts -- which means they could've been put on any transaction, not specific to coinbase. So my response is the same here as in #1 -- I'll just assume they are unspendable and that I don't need to accommodate anything new in script engine. You make a good point that TxOut scripts can be anything, so I'll just always assume they are unspendable until I see evidence otherwise. 3. I don't know of any other bugs in the scripts ops, but I don't know that anybody has written thorough unit tests for them (anybody looking for a good get-your-feet-wet project that could be a good one to tackle; there are already unit tests for CHECKMULTISIG in the repostitory....).
It sounds like that arbitrary scripts have been run through the client software successfully in the past (such as these testnet scripts), but there hasn't been any rigorous efforts to check that it's robust, etc. I would volunteer, but I'm not sure how to isolate the ref client scripting engine, and then still throw in things like OP_CHECKSIG evaluations which require more than just the script itself (such as the whole Tx and the ECDSA verification methods). |
|
|
|
Hey, don't destroy all my testnet coins a second time!
The only reason people don't consistently mine on testnet was because of the reset the first time. People were mining on testnet, legitimately, and blocks were semi-regular. But then the first reset came in, and all that effort was destroyed. In my case, it was about a month of multi-GH mining effort that just went up in a puff of smoke. The first time, the reason was apparently that the difficulty was too high for low-end mining testing, plus, and this is IMO, people who weren't in on the testnet OTC market didn't like to see testnet coins for sale (which was making testnet coins a competing currency.)
Complaining about people not consistently mining on testnet this time around is kind of irritating given the first testnet reset was reset even in the face of opposition from people who were actually using it (and consistently mining in it.)
I see a philosophical dilemma here. The testnet was never intended to produce anything of value. Strictly speaking, it's used for "offline" testing in a "realistic" environment. From that perspective, the devs are only interested in what's best for the developer community in terms of what to do with the testnet. On the other hand, if a clique of people latch onto the testnet and its coins, and start treating it as if it has value -- well then it's no different than BTC itself, and the devs should take into account the fact that they are about to destroy something "of value." As such, a lot of people--those who perceive value in the testnet coins--would be peeved at a testnet reset... So where does reality fit into all of this? Well, the developers need a testing network that isn't the real network. I think it had been made clear before that was the purpose of the testnet, so assigning value to it was a "mistake" of that clique, not the developers "destroying" it. We shouldn't be forcing the devs to go out of their way to create a Testnet2 just to accommodate the clique of people who attached themselves to the first one. And for the record, I'm not so much complaining about people not mining consistently... it's that no one is mining right now, and I would do it myself if the difficulty wasn't so high. But, I think it's silly for me spend 24 hours of CPU compute time just to mine one testnet block, which doesn't have any value to me... |
|
|
|
I went on a scavenger hunt, looking for non-std scripts I could use to test my script evaluation engine. Unfortunately (?), the main-network is rather boring in this sense, but the testnet has quite a few goodies. I put a complete dump of every non-std script from the testnet onto github/gist: All non-std scripts in a text-file on gist!Now onto my questions: - (1) What is going on with the first half-dozen Coinbase-TxOut scripts that would normally just be a public-key? There's the normal 0x04 byte at the beginning (as if it were a public key), and OP_CHECKSIG at the end, but then there's 70 bytes of data between them, instead of the usual 64. The following 6 bytes are what follows the 0x04: "00 a0 34 20 00 44". In my code, I push all 71 bytes onto the stack, but my code doesn't recognize it as a public key. In fact, I've tried looking at consecutive 32/32 bytes chunks but none of them correspond to a point on the secp256k1 curve. (None of them have been spent, so I suppose these could be unspendable TxOut scripts)
- (2) I attained these by examining the blockchain file created by the 0.4.0 client when run in testnet mode. Then, is it correct to assume that all these scripts are actually valid, and my code should be able to evaluate all of them to true? I am under the impression that the satoshi client does all verification checks on every block/tx that is received, and thus invalid scripts wouldn't make it into blk0001.dat.
- (3) I am aware that there is a bug with OP_CHECKMULTISIG that causes it to pop too many elements off the stack. It sounds like we're working our way around that bug in the upcoming multi-sig tx isStandard. Are there any other anomalies in the scripting engine that I should know about? It sounds like the satoshi-client behavior is "truth" and thus I should match it, even if it doesn't quite match the intended design.
Just for fun, here's two exciting scripts from the testnet -- the first is a TxOut, the second is the TxIn that spends the TxOut: TxOut Script: 3
OP_ROLL
OP_DUP
2
OP_GREATERTHANOREQUAL
OP_VERIFY
3
OP_ROLL
OP_SIZE
OP_NOT
OP_OVER
OP_HASH160
[PUSHDATA -- 20 BYTES:]
80677c5392220db736455533477d0bc2fba65502
OP_EQUAL
OP_BOOLOR
OP_VERIFY
3
OP_ROLL
OP_SIZE
OP_NOT
OP_OVER
OP_HASH160
[PUSHDATA -- 20 BYTES:]
02d7aa2e76d9066fb2b3c41ff8839a5c81bdca19
OP_EQUAL
OP_BOOLOR
OP_VERIFY
3
OP_ROLL
OP_SIZE
OP_NOT
OP_OVER
OP_HASH160
[PUSHDATA -- 20 BYTES:]
10039ce4fdb5d4ee56148fe3935b9bfbbe4ecc89
OP_EQUAL
OP_BOOLOR
OP_VERIFY
3
OP_CHECKMULTISIG
OP_0
[PUSHDATA -- 73 BYTES:]
3046022100d73f633f114e0e0b324d87d38d34f22966a03b072803afa99c9408201f6d6dc6022100900e85be52ad2278d24e7edbb7269367f5f2d6f1bd338d017ca460008776614401
[PUSHDATA -- 71 BYTES:]
3044022071fef8ac0aa6318817dbd242bf51fb5b75be312aa31ecb44a0afe7b49fcf840302204c223179a383bb6fcb80312ac66e473345065f7d9136f9662d867acf96c12a4201
2
[PUSHDATA -- 65 BYTES:]
048c006ff0d2cfde86455086af5a25b88c2b81858aab67f6a3132c885a2cb9ec38e700576fd46c7d72d7d22555eee3a14e2876c643cd70b1b0a77fbf46e62331ac
[PUSHDATA -- 65 BYTES:]
04b68ef7d8f24d45e1771101e269c0aacf8d3ed7ebe12b65521712bba768ef53e1e84fff3afbee360acea0d1f461c013557f71d426ac17a293c5eebf06e468253e
OP_0
|
|
|
|
|
I was just on the testnet the other day, trying to test my software. I found it convenient to get coins from the faucet, except that no one was mining which meant that I couldn't get any confirmations. A couple hours later I got a burst of a couple blocks, and then nothing. I felt like the real issue is that retargets on testnet go by block-count -- the network may be on target to go back to difficulty <=1, but it still has to accumulate the 2016 blocks to get there, which could take months.
One solution is to force difficulty adjustments by time or block-count, and with short intervals such as (1 day || 256 blocks). Of course, this could create problems for those who are testing retarget-code, since the testnet would be operating under different rules... but I think all other aspects would work out fine, and difficulty movements would be very fluid.
Personally, I don't really like resetting the blockchain every month... there's a lot of good stuff in the testnet blockchain I want to look at (like some crazy scripts), and I think people who are developing software over the course of a couple months, enjoy having a static base of data to be testing on. If I'm trying to debug a problem with my code that happens on block 23,522, and the testnet resets, I'm going to be mildly annoyed. It's not the end of the world, but I think 1 month is too short a cycle.
|
|
|
|
Either that, or a really nasty BTC virus that: rather than stealing your money, just destroys it... No reason for that. If the attacker can send someone's coins to nowhere then the attacker can also send it to their account. It is no harder to destroy than steal. I agree. But maybe... Make levered bets on the price going up. Credibly destroy tons of coins with viral malware. Your coins and bets profit you greatly and you never have to touch coins with a tainted history. Well of course: if I was the attacker I would be taking the coins instead of destroying them. But, given that the coins were destroyed what is a reasonable explanation for it? The fact is, some people do weird things. If there's one thing I learned from my years of poker: always assuming your opponent is a reasonable, rational-thinking person, will lead you to losing a lot of money. |
|
|
|
If it's a significant amount of BTC, someone on the forums might be willing to help you find the passphrase, for probably half of it. If the alternative is abandoning the coins forever, I bet there's some folks who might consider helping. BUT this is only feasible if you have a significant recollection of what the passphrase might be. If you know how many characters it is, but simply forgot a few letters, capitalization, punctuation, etc, it might be doable. But having to do a "blind" search just isn't feasible. The reason it's hashed 25,000 times, is so that an attacker trying to do the same thing will be 25,000 times slower than if they used single-hashing (that's an oversimplification, but you get the point). So, if you tell us how much BTC is behind this wallet, and how far off you think you are from the password, you might get someone's attention and negotiate an agreement. Similarly, you could post all the details here, and leave it as an open challenge. Even if it's not "worth it" now, a future price spike in the BTC market might cause some folks (like myself) to revisit this thread later  EDIT: actually, that's a gamble... there's no guarantee they even give you back your half. But again, if the alternative is losing them forever, anyway... |
|
|
|
I have broken down the entire process from the bit level, to the application level, in an effort to write my own client. And it took me a while, but I eventually did figure out everything you seek to find, except for the mini private keys. And actually, Base58 private keys... I'm not sure how those are generated, but I do know how ECDSA works... First of all, for BTC addresses, start with my post in the middle of this page: https://bitcointalk.org/index.php?topic=29416.0. The other two images on that page are useful for understanding BTC, but not as important. That image in the middle shows you exactly how to get from an ECDSA public key to a Base58 address. It's not trivial, but I've been able to recreate it from scratch on the first try with the aid of that diagram. Second of all, a fellow forum goer "Lis" wrote this very useful, dependency-less ECDSA module in python: https://bitcointalk.org/index.php?topic=23241.0. I ended up using this in my code and it works beautifully. While I understand ECDSA, it would be a pain to reimplement it. FYI: a private key is just a 32-byte integer and a public key is two 32-byte integers cryptographically related to the private key. There's lots of different ways to encode these things, but in the end they are just big numbers. Additionally, in that first link, you can see the "OP_CHECKSIG" diagram. That explains how you get from an unsigned transaction you just created, to a binary string that you can sign with your ECDSA key. It is stupidly complicated... but that's why I made these diagrams! One of the big trip-ups in everything BTC related is the endianness. Most things are little-endian, except for three things: mainly whatever is in TxIn/TxOut scripts, the DER-encoded public key integers before they are converted to B58 addresses, and the final hash that you sign right at the end of the OP_CHECKSIG. I'll be happy to answer any questions, or perhaps you will benefit from looking at the pybtcengine.py script in my github repo (look at the link in my signature). That python file has everything-- it allows you to supply raw numbers for pub/priv keys and verify linked transactions directly from the blockchain. I've spent a lot of time figuring this stuff out the past couple months. I hope I can help someone avoid the pain I went through! EDIT: oh and to answer one of your questions directly: you only ever apply hashes to binary representations of data. Never on the hex or base58 representations. It must always be in binary and you must make sure the endian-ness is right for whatever you are hashing (usually little-endian, but in the case of tx-signing, big-endian) |
|
|
|
|
In order to spend these coins, you have to furnish a public key that, when you apply ripemd160(sha256(pubKey)) is equal to "0x00". Unfortunately, ripemd160 only produces 20-byte hashes. Even if you somehow did have a string that produces such an impossible hash, good luck finding the associated private key...
|
|
|
|
|
This is exactly why I keep an unencrypted backup on a CD/DVD or spare USB key I'm not using anymore. Unless you're worried about someone physically breaking into your house and stealing the key, this will guarantee you can't permanently lose you wallet like this.
Btw, from looking at the source code, it looks like the key is actually created from applying someHashFunction^25000. I'm not sure you'll find any rainbow tables for that.
If I were you, I'd write down everything you think you can remember about your encryption password, and save it so that if you need to seek help figuring out the password, we can narrow down the search space. Especially if it was a lot of coins and a long password.
|
|
|
|
|
A couple months ago I ran across apage someone made with a giant text-input box, where you could copy a serialized Tx into it and it would be broadcast onto the network. Does anyone know if this still exists, and if so, what is the link to it? Extra-credit: does it work with the testnet, too?
|
|
|
|
|
Keep in mind in this discussion, that once you go outside the scope of isStandard(), there is really no computationally-feasible way to evaluate if a script is "invalid" like this. Sure, you could've written error-checking to catch the case that you accidentally plugged OP_0 in between OP_HASH160 and OP_EQUALVERIFY... but there's literally an infinity of other ways you could create an invalid transaction that wouldn't be caught by that condition.
How is the client supposed to know that a non-std script is invalid? Try every possible TxIn-script -- all 256^200 scripts less than 200 bytes? What if he had a valid script but accidentally plugged in all 20 '0x00' bytes instead of the target hash? Or accidentally reversed the endian of the target address before signing? Added or truncated a byte by accident? Hashed one too many times? Sure, you can catch some of these if you clutter your codebase with dozens of validation checks... but there's still billions of other feasible ways to create invalid scripts that just cannot be caught no matter if you have a billion checks.
Just as an example: what if you accidentally reversed the hash of the target address? The target "address" is actually just a hash of a public-key and no one knows whether there even is a public key that exists to match that address. the BE and LE version of the same address are completely indistinguishable to someone who doesn't have the public key that created it. You only know there is a public key when someone actually supplies it to spend the TxOut. But until that happens, it is literally impossible (without trying all 2^256 private keys) to know whether that TxOut is spendable.
|
|
|
|
|
Well, at least it was someone with a lot of BTC, and not some kid like half the people on this forum, who have devoted the last year to BTC and then lost it all with a buggy script. The guy running MtGox can probably afford it, at least...
OTOH, he just helped me identify a bug in my code: it chokes when it receives an OP_0 where it expects to find an address...
|
|
|
|
I was just running some of my blockchain utils unit-tests, and it started crashing where it never has before. Debugging led me to block 150951 which was created a few hours ago. http://blockexplorer.com/block/0000000000000449ee5b94ba7a051caffff5c23d6a03335f6e20e3985b5ffa61It appears that the scripts have a one-byte receipient of "0" for the publicKeyHash field (between the OP_HASH160 and OP_EQUALVERIFY). As far as I can tell, those coins have been effectively destroyed -- Approximately 2500 BTC. I don't see how they can be recovered, because there would be nothing you could put on top of the stack that would hash160 to a 1-byte output. (Blockexplorer shows the address as "Unknown"). My guess is that someone was using a home-made client to sign those transactions, and it choked on some bug when they tried to create the TxOuts. It appears that the change outputs were constructed correctly, but the target output was not... perhaps is one of those "If problem: return 0" conditions gone wrong. Either that, or a really nasty BTC virus that: rather than stealing your money, just destroys it... So who's the lucky person that just lost 2500 BTC? |
|
|
|
i think its memory(cache) intensive code, instead of computation intensive code.
you could do it on a GPU, but if the memory is not fast enough, or all the required memory can't be in cache GPUs will not speed it up.
For today's GPUs, decision-intensive code works well too. Mixing functions like: k ^= (j&1) ? m : n; m ^= (j&2) ? k ? n; n ^= (j&4) ? m ? k; I don't know about ATI, but in CUDA you want to avoid integer division and modulo operations like the plague. A CUDA thread can do like 32 floating point operations per clock cycle, but it takes multiple clock-cycles to do one modulo operation. Anything heavy on the modulus operations would certainly run poorly. |
|
|
|
optimal So you are saying that you wrote an NP-hard Bellman solver in Python? My interest is certainly piqued. Hah. No NP-hard problems for me -- I'll stick to the NP-complete problem of trying to find a decent SelectCoins solution... (I believe an "optimal" SelectCoins solution would be NP-hard) When I say "optimal" in reference to an offline wallet, I mean optimal usability/convenience. I think I can make a very clean GUI/interface that allows people to do offline transactions in only a couple steps, and won't require any JSON or CLI magic. However, I still have a couple things to work out before I get there, so perhaps it was a little pre-mature to bring it up, yet |
|
|
|
|
Show Posts
