Even having the public key you still have to reverse the Elliptic Curve calculations to get to the private key. Which is again obviously impossible.
Well that depends. Based on the "32 BTC Puzzle transaction" thread it was made clear you can get the private key from a public key if you know already that the private key lies in a very limited range using a technique called "Baby Step - Giant Step". Borrowed from said thread: Getting the private key from a public key is known as "the elliptic curve discrete logarithm problem". There are several algorithms to solve this problem: 1) brute force attack (roughly p steps) 2) Pollard Rho (roughly sqrt(p) steps, based on birthday paradox) 3) Baby Step - Giant Step ( roughly sqrt(p) steps if you have enough memory space to store sqrt(p) points) (p = number of points = number of private keys ) Take a look at: http://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/http://www.cs.umd.edu/~gasarch/COURSES/198/Su14/baby.pdf |
|
|
|
|
Just adding my 2 cents:
It sure looks like this is a transaction for storing data in the blockchain using "Pay 2 Fake Key". The RIPEMD-160 is made based upon a message that was needed to encode. Based on BASE-58 encoding this was turned into an address. This means the private key for the address is unknown. The fact none of the inputs has been spent afterwards also points out to Pay 2 Fake Key addresses being used. So I agree this doesn't seem at all like a puzzle transaction aimed at cracking the private keys.
|
|
|
|
Bumping this thread as I am also doing something similar, and plan to publish my results to increase awareness of the risk of using sha256 brainwallets.
Thanks for bumping. I kind of felt there was not much interest in this before as I expected to get a lot more responses to the list I published. Publishing the results including proof cost me quite some time. But good to see another person with the same interest  So far I've found 20329 valid keys. The large majority of the keys are based on single English dictionary words, which seem to have been deliberately sent small amounts (for research? for fun?) back in 2013.
I think your results share a lot of findings in my set. I am very much interested in the ones you found so I can update my list with the ones I missed. Any chance you can share your findings? (a list of found words/sentences you found would be enough) The funds were swept out instantly, which strongly suggests it was a theft by a bot watching that privkey. The passphrase is a song title, wit
Yes, there are a couple of bots active which monitor the mempool (using a modified bitcoind client) for incoming transactions. Each address found is then matched against a very large set of addresses composed on all kinds of brainwallets. In other words: Just because the brainwallet "Jack" hasn't been used yet doesn't mean it is a safe brainwallet. When you would deposit some coins into the attached address you can be sure they will be stolen within the blink of an eye. |
|
|
|
whereas Andrew has provided an extensive answer, I thought I'd add two and a half more things. I had this confusion with keys in hex and WIF, and then how to come to bitcoin addresses. So I made a small picture, which I posted on a thread in bitcoin.SE. Do you have or know of an updated picture including bech32 addresses from Public Key? |
|
|
|
You are a legend dude. I would give merit if I had but where is the nonce?
This is the nonce in the example provided by seoincorporation: 42a14695 version = "01000000"
hashPrevBlock = "81cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000"
hashMerkleRoot = "e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122b"
Time = "c7f5d74d"
Bits = "f2b9441a"
Nonce = "42a14695"
|
|
|
|
Nice to see this get fixed, as you commented before, no one talk about that second parameter for decoderawtransaction, the true at end makes the difference. avoiding the problem. Maybe you can change the topic to Fixed and close the thread now.  The problem itself isn't fixed in my opinion since the heuristic part still can result in bogus output for decoderawtransaction. The given workaround will only be usable if you can reference a transaction-id. That will not be the case if I constructed a raw transaction which I want to check with decoderawtransaction. Thread should only be closed when this is no longer the case. This should produce the same outcome (as mentioned before and as a test): bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4
bitcoin-cli decoderawtransaction <output from previous getrawtransaction>
VERSUS
bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4 true
Note the first approach gives the bogus output with a value of -49104543721.81252095. The second output will produce the correct output. |
|
|
|
|
Thread updated - Btc2Double still scamming
|
|
|
|
That is a fairly safe assumption.
If there are no "txinwitness" blocks, then none of the inputs being used are "SegWit" inputs... therefore, it isn't a SegWit "transaction"... or more correctly, it doesn't contain any SegWit data.
I am currently doing some more research into this and maybe there is at least one other scenario where a transaction is a "Segwit transaction" without a single "txwitness" block. That scenario is when the coinbase reward is collected by a native Segwit address (bc1...). An example: bitcoin-cli getrawtransaction 2d531f2d4bf1227a6492656b4b340d36c810d313d94a413a965524ae71086bb9 1
Returns:
{
"txid": "2d531f2d4bf1227a6492656b4b340d36c810d313d94a413a965524ae71086bb9",
"hash": "157d1c3bf4860855a6f98792d459f83ad3bd8844cf729c8d9a6ec3accc5e2d7f",
"version": 2,
"size": 290,
"vsize": 263,
"locktime": 0,
"vin": [
{
"coinbase": "039b4208045c2b9b5b642f4254432e434f4d2ffabe6d6d91102119a0522dda683a998f05620ba4beb1f5372a04689d07d47a291dbd25c20100000000000000653f93327a0200fd00000000",
"sequence": 4294967295
}
],
"vout": [
{
"value": 12.50253935,
"n": 0,
"scriptPubKey": {
"asm": "0 97cfc76442fe717f2a3f0cc9c175f7561b661997",
"hex": "001497cfc76442fe717f2a3f0cc9c175f7561b661997",
"reqSigs": 1,
"type": "witness_v0_keyhash",
"addresses": [
"bc1qjl8uwezzlech723lpnyuza0h2cdkvxvh54v3dn"
]
}
},
{
"value": 0.00000000,
"n": 1,
"scriptPubKey": {
"asm": "OP_RETURN aa21a9ed1892392fc479aa2479df651f83a83c625ae23d35876a9fac6d9c617c8d602d9f",
"hex": "6a24aa21a9ed1892392fc479aa2479df651f83a83c625ae23d35876a9fac6d9c617c8d602d9f",
"type": "nulldata"
}
},
{
"value": 0.00000000,
"n": 2,
"scriptPubKey": {
"asm": "2 3 [error]",
"hex": "52534b424c4f434b3ad1087f5ba5c0e6d2c0ebe90d2ef35033860dfa99aec1afe04dfd11fa70ebd1a2",
"type": "nonstandard"
}
}
],
"hex": "020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff4b039b4208045c2b9b5b642f4254432e434f4d2ffabe6d6d91102119a0522dda683a998f05620ba4beb1f5372a04689d07d47a291dbd25c20100000000000000653f93327a0200fd00000000ffffffff036f5c854a0000000016001497cfc76442fe717f2a3f0cc9c175f7561b6619970000000000000000266a24aa21a9ed1892392fc479aa2479df651f83a83c625ae23d35876a9fac6d9c617c8d602d9f00000000000000002952534b424c4f434b3ad1087f5ba5c0e6d2c0ebe90d2ef35033860dfa99aec1afe04dfd11fa70ebd1a20120000000000000000000000000000000000000000000000000000000000000000000000000",
"blockhash": "0000000000000000000b616cd42f140420d47544464ea9e59f72ff4d124f903a",
"confirmations": 48,
"time": 1536895846,
"blocktime": 1536895846
}
Note: the vout-part mentions a type of "witness_v0_keyhash". I'm not sure if this should be counted as a "Segwit transaction" or not. I guess it all comes down to the question if a coinbase transaction always counts as a non-segwit input or not. Any feedback is welcome! |
|
|
|
|
What you are describing has been done before. You might want to lookup the story of Counterparty who was responsible for trading a new currency "XCP" for people who were willing to burn bitcoin in exchange. Over 2,100 BTC's were burned this way.But some smaller startups have done it as well in the past.
|
|
|
|
Burning Bitcoin offline is easy. Transfer to a Drive and destroy the drive. Same with paper wallet, there you will actually get the satisfaction of burning it.
OP asked for a way to to track it and verifiable prove it. Also: Burning a paper wallet or destroying a drive is not burning a coin, it's still registered in the utxo. |
|
|
|
example:bitcoin-cli getrawtransaction 2157b554dcfda405233906e461ee593875ae4b1b97615872db6a25130ecc1dd6 1
error code: -5
error message:
No such mempool transaction. Use -txindex to enable blockchain transaction queries. Use gettransaction for wallet transactions. With txindex enabled the error message should be slightly different: "No such mempool or blockchain transaction. Use gettransaction for wallet transactions." |
|
|
|
Is your node fully synced? What do you get from the getblockchaininfo command?
Both transactions seem to be from the same block with height 500000. I personally have no problem getting the right response for both transactions though with bitcoin-cli so I'm not sure what is going on. |
|
|
|
I am not looking to destroy Bitcoin but rather a way to effectively send a deposit to a wallet and then destroy the wallet along with the Bitcoins.
I'd want to be able to do this with any cryptocoin. And I want to be able to track it and verifiably prove it.
Why exactly do you want to send to a wallet? Do you by any chance mean an address? Because otherwise I could be holding a wallet with some addresses in them having a huge balance and then they all get destroyed because you deposit some satoshi's in an address from that wallet? Essentially setting up an off-chain burning tool / service.
What's the off-chain aspect of this? How will coins get deposited into this wallet if it's not on-chain? In general the preferred way in Bitcoin to burn coins is to include an OP_RETURN in a transaction with a value > 0.00. That way it is verifiable because it's registered in the blockchain but it cannot be spent afterwards. This is a better way than using fake addresses like the Bitcoineater one since the will be unspendable but it will also be included in the utxo-database. |
|
|
|
But instead of saving users information in a usual database what I want to do is; I want to store them in blockchain.
Can you explain why you want to store them in a blockchain? Because I would expect you first wite down your requirements and then try to find a technical solution which best fits those requirements. It looks like you did it the other way around: Starting with a technical solution (blockchain) which then should accomplish whatever requirement you came up with. I register on a website and then I create a book and start writing the first page.
once the first page is finished click on save button.
Now, this information should create a block and could be only opened by its author.
The very idea of a blockchain is that all information stored in there is publicly available. So once again: why do you think blockchain is the best option for your idea? So everytime i add another page it should create a block and add to the blockchain.
What will happen if I decide to change some text on my first page already saved? How is a page (which is a single block in your solution) linked to another page in your solution? So will it be linked to a random page from another user or only to my own pages? my query is where will this blockchain saved? in database? or its a raw file which user could download on their own computer?
Well the entire idea of a (public) blockchain is that all the information will be stored on every node (every computer which is part of the network). What would be the incentive in your solution for people to keep a copy of all these pages they can't even read themselves? I personally would expect for your idea to just have a regular server-based solution with a database to store the pages. Users can then lookup previous saved pages of themselves and if needed alter them. All of this based on authentication (user credentials given in the webpage). To make a long story short: Blockchain is a great solution for some problems, but relational databases are way better solutions for others! |
|
|
|
./btcrecover.py --wallet wallet.dat --tokenlist tokens.txt --utf8 --min-tokens 18 it ends with the following error message: "at least 3,800,000 passwords to try, ETA > --max-eta option (168 hours), exiting" The default maximum runtime is 168 hours you can override this with a higher value by adding a --max-eta parameter to your call. Something like this: ./btcrecover.py --wallet wallet.dat --tokenlist tokens.txt --utf8 --min-tokens 18 --max-eta=100000000 Just be prepared the script can run for a very long time now! But at least the script won't stop and throw that message anymore. |
|
|
|
This is a known issue and unfortunately it cannot be fixed without a fork. The issue lies with the format of a segwit transaction itself. A segwit transaction, under some circumstances, can be interpreted as either a 0 input, 1 output transaction, or as a witness transaction. Since getrawtransaction fetches transactions from blocks themselves or from the mempool, the transaction must be a valid network transaction and thus witness serialization can be attempted safely as a first step and only deserializing as non-witness if the witness deserialization fails.
However, decoderawtransaction behaves differently as it is intended to be used during the transaction creation steps. This means that it must be able to handle 0-input, 1 output transactions (which are inherently non-witness) as users may create a 0-input, 1 output transaction, decode it, and then pass it to fundrawtransaction to get inputs. But because some 0-input, 1 output transactions can be interpreted as witness transactions, and some witness transactions can be interpreted as 0-input, 1 output transactions, decoderawtransaction does not always succeed to decoding a transaction correctly. It uses some heuristics in order to decrease the number of false decodings, but sometimes, as you can clearly see, it's wrong.
Thanks, very informative. I didn't know decoderawtranscaction was intended to be used during transaction creation steps. Fortunately, if you know that a transaction is witness you can set the iswitness argument (added in 0.16) to true to tell it explicitly to decode the transaction as witness. You can set it to false for non-witness decoding. Not setting it uses the heuristics. So your command will be something like: bitcoin-cli decoderawtransaction <tx> true
Yes, this does indeed work! The documentation found at https://bitcoin.org/en/developer-reference#decoderawtransaction doesn't list the second parameter. According to the documentation decoderawtransaction only takes a single parameter. Guess the documentation isn't up to date here. One last question about the heuristic in this specific case: It's pretty clear the assumption made this was a transaction without witness data is wrong based on the fact it's reporting a negative value as an amount. So shouldn't the "heuristic algoritm" reassess itself when the output generated was clearly wrong: Input -> Trying as non witness -> Output is valid -> Done
Input -> Trying as non witness -> Output is invalid -> Trying as witness ->Output is valid -> Done
I might be oversimplifying things here but it seems to me this would lead to a lot less incorrect assumptions from heuristics.
|
|
|
|
Just to add another piece to the puzzle: I do get the right response when overriding the second parameter of getrawtransaction to "true", as stated in the documentation https://bitcoin.org/en/developer-reference#getrawtransactionbitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4 true
Results in:
{
"result": {
"txid": "00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4",
"hash": "68749aae9aeb5d1a6971ed16e0244f648aadcffbfe8ff6c6eec6fbeb1e43e1c7",
"version": 1,
"size": 249,
"vsize": 168,
"locktime": 0,
"vin": [
{
"txid": "d77c1bc59aea11eff5a289d8e79b92d7c19a06e993eeb44be6bbda8fc3e45f68",
"vout": 0,
"scriptSig": {
"asm": "001422234e073571fde8414ae49a8fb294c712a96c88",
"hex": "16001422234e073571fde8414ae49a8fb294c712a96c88"
},
"txinwitness": [
"30440220768f93a61c9630eea0553d2a1a8e69ffb3307681c7561cbc8a17643b82e44f3402203e7 74304ea44bcc4f1269cf4a7a4652c49eacbd9250d57e71d769fdc52cff87901",
"02355c851b796e318091b404efab45e9fc34cf6184aa0bb279cd76255a4e643b9e"
],
"sequence": 4294967295
}
],
"vout": [
{
"value": 2.57409060,
"n": 0,
"scriptPubKey": {
"asm": "OP_HASH160 85fdf348463ede1237e06e471cce02746b9220fd OP_EQUAL",
"hex": "a91485fdf348463ede1237e06e471cce02746b9220fd87",
"reqSigs": 1,
"type": "scripthash",
"addresses": [
"3DuW1qNmzF3BtrbVSornifUb9EseA8KAGE"
]
}
},
{
"value": 0.20000000,
"n": 1,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 eee47d625f1e4a72e579ca884363ebda0f11f4b1 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a914eee47d625f1e4a72e579ca884363ebda0f11f4b188ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"1Nn9YQSAkLXU1d51fnkxmXSbB8DXePWnMh"
]
}
}
],
"hex": "01000000000101685fe4c38fdabbe64bb4ee93e9069ac1d7929be7d889a2f5ef11ea9ac51b7cd70 00000001716001422234e073571fde8414ae49a8fb294c712a96c88ffffffff0224c0570f000000 0017a91485fdf348463ede1237e06e471cce02746b9220fd87002d3101000000001976a914eee47 d625f1e4a72e579ca884363ebda0f11f4b188ac024730440220768f93a61c9630eea0553d2a1a8e 69ffb3307681c7561cbc8a17643b82e44f3402203e774304ea44bcc4f1269cf4a7a4652c49eacbd 9250d57e71d769fdc52cff879012102355c851b796e318091b404efab45e9fc34cf6184aa0bb279 cd76255a4e643b9e00000000",
"blockhash": "0000000000000000013aa3efc9b6e19ec6b43f55596a5e7246de92e881537297",
"confirmations": 57144,
"time": 1504306950,
"blocktime": 1504306950
},
"error": null,
"id": null
}
Summing up my experience: Works:bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4 true Fails:bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4 Followed by using the output from this step as input to decoderawtransaction bitcoin-cli decoderawtransaction <output from getrawtransaction above> Expected:bitcoin-cli getrawtransaction <txid> true is equal tobitcoin-cli getrawtransaction <txid> ->rawtransaction bitcoin-cli decoderawtransaction <rawtransaction> |
|
|
|
Interesting found, i checked this possible bug/problem with Bitcoin Core 0.16.2 (txindex disabled, so i just try decoderawtransaction) and few explorer/services with getrawtransaction/decoderawtransaction show different result.
Did you get the same results as I did? Gonna try it after reindexing is done.
Thanks a lot! Keep us posted |
|
|
|
And are the books PDFs? Are they legit copies, or scanned from a textbook? If not, why would the publisher let them give it away for free. Just my skeptical mind.
They are in multiple formats including PDF, EPUB, MOBI and online reading. They also include zip-files with all code examples. This is a legit site/service. In the end they try to sell you books ofcourse, these free books are meant to lure you in. But you can still claim a book every day without having to buy anything. |
|
|
|
Ok, i found some one with the same problem and the explanation: That transaction is a witness transaction, but 0.14.2 is interpreting it as non-witness, which is why the hash is the same as the txid and there are no inputs. 0.15.0 interprets it fine. Please take a look to https://github.com/bitcoin/bitcoin/issues/11157 'Fail to decode transaction correctly.' That's referring to bitcoin core before 0.15.0. As I've posted multiple times now that's not the case for me. So the original question remains why this is (still) happening with 0.16.02? Anyone who can do this simple test with running the latest version of bitcoin core (0.16.02) and list their result: bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4
And then:
bitcoin-cli decoderawtransaction <output from previous getrawtransaction>
|
|
|
|
|
Show Posts
