Topic: Re: Bitcoin bounty 0.5 btc challenge (Read 475 times)

There's no reason to apologize, it was my stupid joke.
i was just playing with the repository https://github.com/SjorsO/keys-generator

I don't know if you're being sarcastic to the OP because it's related... so sorry in advance if yes:

Your keys are also outside of the curve, three out of four in your list are spent because those are within the first valid private keys from 0x01 which can easily be "hacked":

• 0000000000000000000000000000000000000000000000000000000000000000 - 0x3f17f1962B36e491b30A40b2405849e597Ba5FB5 (unspent - invalid prvKey)
• 0000000000000000000000000000000000000000000000000000000000000001 - 0x7E5F4552091A69125d5DfCb7b8C2659029395Bdf (spent)
• 0000000000000000000000000000000000000000000000000000000000000002 - 0x2B5AD5c4795c026514f8317c7a215E218DcCD6cF (spent)
• 000000000000000000000000000000000000000000000000000000000000000e - 0x5A83529ff76Ac5723A87008c4D9B436AD4CA7d28 (spent)

All but 0x3f17f1962B36e491b30A40b2405849e597Ba5FB5 have a valid prvKey so those are spent.

take 15+ ETH
private: fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 0x3f17f1962B36e491b30A40b2405849e597Ba5FB5
private: fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364142 0x7E5F4552091A69125d5DfCb7b8C2659029395Bdf
private: fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364143 0x2B5AD5c4795c026514f8317c7a215E218DcCD6cF
private: fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd036414f https://www.blockchain.com/ru/eth/address/0x5A83529ff76Ac5723A87008c4D9B436AD4CA7d28

Valid private keys in decimal:
1 to 115792089237316195423570985008687907852837564279074904382605163141518161494336

This address 1BBwZVdBjoPxotHfrKLpHJBSy7vmc2pjex is from private key 18 ... so it is valid!

This address 1FYMZEHnszCHKTBdFZ2DLrUuk3dGwYKQxh is from private key 115792089237316195423570985008687907852837564279074904382605163141518161494337 ... so it is invalid!

How's that out of range? By decoding the transaction and the script, I see that it has a valid uncompressed public key which is:

And a valid signature:

---

---

Again, an address can't be out of a certain range. It could be any encoding between - 0000000000000000000000000000000000000000 - and - FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF. Remember, an address is just an encoding of a hash.

if you guys says that is not possible how this address which out of range has managed to sent the bitcoin
  d89efd5fe80d5b13fd7d40a7701a842a8ddfff4016615330485411780d1773cc: Appeared in best chain at height 682911, depth 16418, work done 1255748482679875348508874554.
     in   [3044022016f0c4b83a70025ed9c2245f233fd7e30241c168df4f65e7ba206a54207fa2a702204a3fe2d92516ceb60691d42e86bc3d7c209fd224855ede2a86e34daad9e2f21b01] [045601570cb47f238d2b0286db4a990fa0f3ba28d1a319f5e7cf55c2a2444da7ccc136c1dc0cbeb930e9e298043589351d81d8e0bc736ae2a1f5192e5e8b061d58]
          outpoint:1a2c89a8ab17ed51daa2d2e27bb7f02708aff365918e9fc6b303a614a289ce2e:4 hash160:6fc2f6488dce92411d2498cb969b739befcc7988
     out  HASH160 [0d6c58795fcf0f3e9de2dfc2c6f0671fcbe85f8d] EQUAL 0.00008461 BTC
this has been sent to 32uzW2E6paeGGpbudRpRk5uEG4Yb15dFzi from 1BBwZVdBjoPxotHfrKLpHJBSy7vmc2pjex ( which is out of range address)

I know, right? It seems every other day, someone pops up posting something about a 'challenge' or that they have 'almost cracked' something and the like, while in fact they just don't have enough understanding of Bitcoin yet. It's got to do with the Dunning-Kruger Effect, I suppose.

if you want to be really sure about this wallet, just export it's private keys and compare them with what i posted on first page.
if they match than you cannot spend it's balance. simple 

this is second transaction i did from same wallet
d583535bf202ebba9f29e384b4f20db91edbdb51b66afa4ce9433bf2fdba8607: Pending/unconfirmed.
     in   [304402201957864de5ad6717f160d09d712f981f05579ab1c12addc6468a2304d6dce60802200e9d4194f082236cc6751add1be10ce93ce02c2dc2a8c6de30ddc281c5cdcfd701] [00]
          outpoint:7841a229f0bf69ed55974551828408a7a6a6bd513ffd04d94e10cc92278f4f85:0 hash160:9f7fd096d37ed2c0e3f7f0cfc924beef4ffceb68
     in   [3045022100ecf2d324cdb16faed9f9ba16d07fa45c4217f32272ae98fa00ddceab1d736d8c0220149d4da1632aa1cae7f795070429390c9d84de39475ad0f8a7a8cda1e6cafd5801] [00]
          outpoint:a1fb47719387e4f7594cde20b385b8b122d4080a0c4fc63ec33c0c4a41f8c4be:1 hash160:9f7fd096d37ed2c0e3f7f0cfc924beef4ffceb68
     in   [304402201ade8b0df28c062fdabcd0ce648cbe3059c8da018d7704c1f0fe987aa43e5b1d02202cc8dfb108a497d86a7bb8142a7946c1068afef8e8ec022649cb44ac11ff5e7a01] [00]
          outpoint:27d11ff383a2ed09b08d776c6e6bbd11667354025b1f97deeccb34f9057cb49a:0 hash160:9f7fd096d37ed2c0e3f7f0cfc924beef4ffceb68
     in   [304402203ffb94f91ca748b59347777c125be33d170bf9b4a971de825a52ca69980bea2c02207643c44acfda187b843c4f41f71bda6e8208dd768dbfb6bb4e378d2730d477c601] [00]
          outpoint:9dc33588482af217c038024d593183eb3d227de85e1df6076b64b68dc60ed908:0 hash160:9f7fd096d37ed2c0e3f7f0cfc924beef4ffceb68
     in   [30450221008673e4387d6093611bafba6be6852df5eb0d3277cfe265d55dd6b3b0dfb6a7ed0220617f5706d6b6acdabe06d42c2f92621ad1cc8b16827715ec04b9102b3c86924401] [00]
          outpoint:d72bf5ae04301be810cae7878306a8d2e0d0c323414b5b78974b528b18a2e4be:0 hash160:9f7fd096d37ed2c0e3f7f0cfc924beef4ffceb68
     in   [3045022100cc7b0f0d7ee0be99133664b4aa9f86e6ad7fa7b3dd1de569d964f6d170e666460220564017a0216fc56cfb967238cd4c3a5ff536ebd2797434fbaa5f677ed04e72d201] [00]
          outpoint:3bd20e73c838a064cfea311294391f66940d43c0bebc1e7a7787a9386efd6aa5:1 hash160:9f7fd096d37ed2c0e3f7f0cfc924beef4ffceb68
     in   [3044022046f7e7b15fc41671e05d71f40a887c3236143f1b43867550bfea4214b8e50db80220228052014888ab84a77efdc897bf83bd5a79cf3cc9cf6f9ecaa1731e5b9f417901] [00]
          outpoint:ec1f4e15d19460ac490c905e22340aad3af3e9836e267af0f4b0153536867b7b:1 hash160:9f7fd096d37ed2c0e3f7f0cfc924beef4ffceb68
     in   [3044022058743dbb4040e18dd796719ac8726f9b662384739ebd5059ed1a8966e4dee7ab0220423f010844f89ce4f512ee1e05ef14fdcfcc24763d7304b39a952db5ecb758e901] [00]
          outpoint:1d0a739cecae0277ed20ed51616435a86bf744add9b84b8bc7f1d31bb483e001:0 hash160:9f7fd096d37ed2c0e3f7f0cfc924beef4ffceb68
     in   [304402200c8cf8921123976e351d80cbcc7267ceb130f0940753ef4329602a8e3edbb7aa02206a81b81a799dfd94ddb32a3e56b15139742111ac9e367da6a2dfdfab06cd45b801] [00]
          outpoint:af6826fe571668e6d83e05d7dcf7f6de45b6b642103db29ea5e25bedb9888f73:1 hash160:9f7fd096d37ed2c0e3f7f0cfc924beef4ffceb68
     in   [3045022100e50e2203c5da034a5d1e94c87950855435fff52de522e16610927c4e9898ca0802204bc1046989f66b77488174f10c947e2607f0f99d440a4fe97a6e3158b0fb476c01] [00]
          outpoint:e12853c51e39f772743fea3448b04d4cc44f7de1435bd02b8b2096bde1ae8728:18 hash160:9f7fd096d37ed2c0e3f7f0cfc924beef4ffceb68
     in   [3045022100a6426b093e541cb07fbf36cadea5f6d0034b90a29b23320019e338cf95ed6e40022060cd4aaac0e9ddb46a11a5fa81730d742c58c3491e731eecb8bd71e453b0df2b01] [00]
          outpoint:1c9f7d81a663709cf0f57c2e6d134427f4ddc57163bdfaa471406a890e0f7073:0 hash160:9f7fd096d37ed2c0e3f7f0cfc924beef4ffceb68
     in   [304402203a575c3d180d2f16ec1c03cbb89d9ef88c9fa1d30d99988f1dfbad40721897df022077dfd9cb8d18b90f0b42a73d44ed1797dfac78faabf363974a665493c5b8d92701] [00]
          outpoint:206c52a5ea2cd1012fae3441d15fe101a1a03356d3399fd8febf35150e96a9f1:0 hash160:9f7fd096d37ed2c0e3f7f0cfc924beef4ffceb68
     in   [3044022012bbc9feaaf29574520c8e1acbc2df73c95651b7ab1ea04f23019d12845360c702204fabaaaf88aca8c596268e3b9aff520ec9eef0cb036a876eeaacc57f3848178601] [00]
          outpoint:815988bfa1935d40d57fb0a125fd455676520bf1cf361b2c3e40065570a6f3c0:0 hash160:9f7fd096d37ed2c0e3f7f0cfc924beef4ffceb68
     in   [3045022100d2e44eb657dfeaca0043263e778b8c94f5ca87180499be72d3fb42ff0c4310af02201b32e142dce263d63be5ab5f5f4f0fd9e455c2ec6f4f45b6661410c96e03f30401] [00]
          outpoint:88a2e1f80556032551985011858b3f9f0c0d2e3e9cd7345daef4bdb926eab76b:0 hash160:9f7fd096d37ed2c0e3f7f0cfc924beef4ffceb68
     in   [3045022100c17c9b2622d5ff5fb50ed7445d02d7a850acb3c0e6b67aeb451fc890c76af51f0220724121cffa8a68fd5ba9aa5857487a46749293b776ce19c1712126d2d475d83201] [00]
          outpoint:bafef8acbe396a6b2216999713d04139d1ff58dcd5a9a7460e5244b80818a4c8:0 hash160:9f7fd096d37ed2c0e3f7f0cfc924beef4ffceb68
     in   [3045022100fe7dcfc74f6b57a1d6af09a90d05a0833da6b02c74bf0bf3ea7c44aabadbf0d9022012a0ee0e6c8d074e93989cca8b76f0b3378acc88e25244512c9b353f539bd6da01] [00]
          outpoint:fca5a1e609c6bde3fc23e14fa92a3658f6bda05aaf1354af14ec452d4a1d871f:0 hash160:9f7fd096d37ed2c0e3f7f0cfc924beef4ffceb68
     in   [3044022027a21249aef2c1948c93779e0759e25020fc02286e1d30187e29fcaac3cfbd1102205d0809f89cd6080881db3a94db688c8d92e1902960cf8347ff97745e6a3b700101] [00]
          outpoint:af6826fe571668e6d83e05d7dcf7f6de45b6b642103db29ea5e25bedb9888f73:0 hash160:9f7fd096d37ed2c0e3f7f0cfc924beef4ffceb68
     in   [3045022100da5ded5bc1147d37721905f1f41f68aa40dd14c6a831396bc8d5e1a2fe6a44f702206ab23306e395867a5bf4eceeff7844a25e060666c3601e1dc5a72f9dfaaaa25001] [00]
          outpoint:348d24086b7be3118b776d7e2e3651a8a37f8734f653de5a6bab7323911c8cb3:7 hash160:9f7fd096d37ed2c0e3f7f0cfc924beef4ffceb68
     out  DUP HASH160 [d880f4772ccae13030f67c89436d96ee74e7a635] EQUALVERIFY CHECKSIG 0.005 BTC
     out  DUP HASH160 [9f7fd096d37ed2c0e3f7f0cfc924beef4ffceb68] EQUALVERIFY CHECKSIG 0.00012735 BTC

There really isn't anything to see here, there is no need for a raw hex either. The OP is clear enough. 0x00 is being used as the public key for all the inputs and when the interpreter reaches the first OP_CHECKSIG and pops the top stack item (ie. 0x00) it will reject the transaction because it has an invalid public key and it fails here as CPubKey.IsValid() returns false for anything smaller than 1.

I'm always surprised by people who try to fool others into thinking these things are "their own private key"!
Not to mention that they try to spend outputs that sat there unspent for 7 years as if nobody else (with more understanding of how bitcoin works) has ever seen these things

This public key belongs to 1BbBEt3uuNTo867wXnD2p4iv478Tcs3h1H and 1FG37pnmz9WPB413hMnn3VZEg3nF2QkUPA addresses

If the transaction uses an empty public key, then it's invalid. This means that a block containing the signature from that key would also be invalid. So it doesn't have to do with the miners. It simply isn't valid, that's why they reject it.

That isn't a raw tx. It should look like this in length:

decoderawtransaction "0100000001dfee7c0aa6cb1cf8f4c9ac9339d9b6078d792a106267f93802ac75b52a6ad0de00000 0006a47304402203e408f62cf85e326dc4066636c306b85ce0b94dd94c001fbfd35da58979def3f 022075255c85e927340d4777963357cb03482566e29f93cc9f590398dfb3a89cbb970121028ce82 9db535d42389defbf9ba58731f56ddb1cc7a189e5e30a85d63eb225b5d2ffffffff018813000000 0000001976a91496a07833918317f2e0e23eea585970831da66f8988ac00000000"

Unless if I'm missing something from your screenshot.

Me neither, but we shouldn't take it for granted. It's wrong to assume for a certain public key if the person hasn't stated they hashed that one before.

the error i am getting when i tried to decode raw tx is
https://imgur.com/a/4LeOqCE
the public key in hex for this address is 049663999D864D6D1A79FFB0C547D19CB5A51123888AD4BDAE5CCEDB61CC3239BA4182C2088B09D 67ADEDF1BDC543B5F336D017017FF8D83E44D75A00A3D6BEE
i read it from other post

Your other post in the services board says:

You mean "found" this private key?: Bitcoin Elliptic curve point multiplication results in key ZERO
Is that why you're using an unknown client, probably something that accepts invalid private keys that are outside of the curve.

That is true, there are ~2^96 valid private keys but it's highly unlikely that the OP found an address collision. (didn't hear that to happen even a single time, but maybe it's just me)

https://imgur.com/a/QS3OwX5
even with mining pool people so that they can force to broadcast the transaction.
if the transaction is broadcasted then i think it gets confirmed
Means the transaction is rejected by nodes or some peers are not seeing the transaction

I know the address and the fact that there's a private key, which gives an empty public key which once hashed with hash160 and encoded with base58 gives it, but spending from that address isn't impossible. I have no fuckin' idea what's OP doing, but there are around 2^96 - 1 besides that invalid one that can indeed be used to unlock the outputs.

---

@praveen aj, did we find it? Is it because the public key you've used is disallowed? It's highly unlikely to be a different case. Still, though, you could give us the tx raw to verify it.

Yeah I was trying to understand the dump that was posted.

https://www.reddit.com/r/Bitcoin/comments/2t3vn0/i_cant_send_my_btc_a_triangle_apear_i_use_multibit/
The utxo's are unspendable indeed, due to a bug. Coins are lost forever.

@praveen aj these funds are unspendable because of the unallowed 0 exponent.

just a simple conversion from ripemd160 to address which equals to 1FYMZEHnszCHKTBdFZ2DLrUuk3dGwYKQxh
if you google that address you will see some topics even here on bitcointalk about that address  

this is the exact thing happened i managed upload the private key in an old wallet and after syncing finished it shown available balance i managed to attempt to send btc to my address it created a transaction and showing 'transaction is not confirmed yet, it is unknown how many peers has seen this transaction"
when i clicked on the transaction details it shown the raw transaction details which i posted above and bitcoin deducted from the wallet i uploaded it is not picked by any peer or node, if somebody help me to broadcast the transaction and when its get confirmed i am happy to send 0.5 btc this is 100% as i promised.
the image of the transaction i shared above