Good to hear.  Congrats

There's not a lot in your post to really tell what might have happened.  Lots of things just "didn't work" and it's unclear what might have caused them to fail initially.
Eventually you typed your seed in a system which sounds insecure (an online windows machine?), and now the funds are gone.  It sounds like the seed was entered correctly since you are seeing some of the balance.  Does electrum show any transactions going out to an external address you don't recognize?
Maybe the very first attempt at sending from the wallet did in fact work?

* maybe best to move this topic to the technical support subforum?

I realize the use case, but since addresses are single use, what would you be looking for when seeing a new fingerprint?  I agree about the usefulness in the "receive new address now, send coins to it later" case, but it's limited to a person's memory, and it's still possible to misremember some minute features of the fingerprint.
After long use of the same fingerprint you might begin to distinguish it better from others that are similar to it, but that's no good since it means you're just re-using addresses, and in case where some malware intentionally replaces addresses in your clipboard with some different address that might normally change the fingerprint, the same malware could replace the fingerprint too to show what would be the "honest address's" fingerprint.

Maybe it's useful for a hardware wallet setup?  Currently hardware wallets just flash the address on screen and usually there isn't enough room for the complete address, so it the user has to read some scrolling ticker made of random characters and "spot the difference".  A hardware wallet showing the true fingerprint on the screen and the user confirming it's the same one they wanted to use could be a cool feature.

Right, like random-art or an ssh fingerprint.  But still it would only be useful for address re-use which is bad practice in itself.  (I could not think of another use)

I don't know enough about zk-snarks to say if your method is good enough or not, but recently this bip-ZZZ ( https://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki ) was published that I does what you want to achieve in an easier way IMO.
PUSHTXDATA type 15 is TXDATA_VOUT which for a specified output index, first pushes the amount that is being sent to the output, then the scriptPubKey which the amount is sent to.  The type 3 pushes the amount in the input being redeemed.
So if you wanted a script that would always have to pay any amount sent to it to some pre-specified address, say mkqHTnuZ6icRzRms2fTyQU75fRqifpKFGb, you could program :

15 PUSHTXDATA 0x19 0x76A9143A501DE5E8B8A15856CD22A4BD9E5A1BE4C2E5AF88AC EQUALVERIFY 3 PUSHTXDATA EQUAL


Now if you fund this scriptpubkey, to use it as an input in some transaction, you must also include mkqHTnuZ6icRzRms2fTyQU75fRqifpKFGb in one of the outputs, and make sure that the amount in the utxo that you are redeeming is paid in full to that address.
I'm not even bothering with adding any checksigs or handling keys because the worst that could happen is that my address will get paid.
You could add more types of PUSHTXDATA and be a bit more clever with amount checks to even encode some pre-specified allowed fees (or hard code a subtraction of just *this* input and output's worth)

A cool post on the subject :
https://blockstream.com/2016/11/02/covenants-in-elements-alpha.html

Just wanted to add that it's also easy to keep most of the encoded address the same while changing the hash completely, for example :

FFE70FB0B47E80EBDC1CC4C3C59581110A10D52B
0469804540E7B2C646007EFA8C3BF4FBE146E931

Will result in :

1QL67LXU5LS8uoKCXDAy4bbgWY7ue2nHTA
1QL67LXU5LS8uoKCXDAy4bbgWY7uJFBhq

Of course it's hard to do this trick if I have to right-align the addresses

No worries.
I'll just add that a good source for me was Hal's post at https://bitcointalk.org/index.php?topic=3238.0
Cheers.

If you're adventurous, you could try running it in my bc interface
https://github.com/fivepiece/btc-bash-ng

Two warnings :

• It's building a patched version of gnu bc and using it.  The patch is available in the repo
• There is little to no documentation, but I can answer questions

Sorry @amacilin1, I missed your reply.  Seems like there are no solvers, so I'll post the full solution :

we want to grab the funds from 2MuUKuRSr5sbj9HA9dDo5RS4QVMDrcnyu1o
p2sh scriptpubkey :
OP_HASH160 0x14 0x186A98FF714EF8DDE99847F6769C3913E770E172 OP_EQUAL

from 4c004c3f06f5b76ae3f325cfb26ff305146bda0a3f9e5662462653b41324ac4a we can tell:
redeemScript :
asm:

1. this is a 2-of-2 multisig of two public keys {P1,P2}
2. we can see from the parity byte that P2 = -P1, from this we know..
3. we must find two private keys {d1,d2}, where d1 = -d2

coordinates for P1 :

x1 = 3F3C3501D05E6151F5B483C3962251EA2113D8F5B76F58C44A4252B4580ED574
y1 = CE66AAA31BA3C747A93609B53924D8FFF549315EF352894D491DB9355FDF1528

coordinates for P2 :

x2 = 3F3C3501D05E6151F5B483C3962251EA2113D8F5B76F58C44A4252B4580ED574
y2 = 3199555CE45C38B856C9F64AC6DB27000AB6CEA10CAD76B2B6E246C9A020E707

let's take a look at the signatures
signature for P1 :

signature for P2 :

r1 = B68E234D58FEAFC61E733CC95C16E1E042D6D5AAD849A0763704D63C4E497997
s1 = 0E503CE27C5D94A3D9A164037B51FD13A67EB392FCFB4073A7EB63AE62725328

r2 = 0A35A7B0D6A2EEE7EBD83F730DC6CC359C15515F704706C57EB8D70E59A7AD24
s2 = 2A58D3F55356A656F2A1E65A66083B680AEC6C704093CB3A3BCD566FA7120C8A

reconstruct the midstate:

sighash (same for both signatures) :
z1 = 24917770E481E6AF860E5CBECE6C8DDA74CD7A2BE90FEC53570438F54E8E38DC
when verifying the signatures ( r1 == R1_x && r2 == R2_x ), we make use of the uncompressed R point :

verify(z1,x1,y1,r1,s1)
R1_x = B68E234D58FEAFC61E733CC95C16E1E042D6D5AAD849A0763704D63C4E497997
R1_y = 3199555CE45C38B856C9F64AC6DB27000AB6CEA10CAD76B2B6E246C9A020E707

verify(z1,x2,y2,r2,s2)
R2_x = 0A35A7B0D6A2EEE7EBD83F730DC6CC359C15515F704706C57EB8D70E59A7AD24
R2_y = 3199555CE45C38B856C9F64AC6DB27000AB6CEA10CAD76B2B6E246C9A020E707

we can see that ( r1 == R1_x && r2 == R2_x ), and we can also observe..

4. R1_y == R2_y
from this we can tell that..
5. k1 = -k2 - the nonce used in both signatures is basically the same !
but also..
6. R1_y == R2_y == P2_y - Both 'R' points and the second public key share the same Y coordinate !!

looking at y^2 = x^3 + 7, we can see that there are 3 'x' solutions for each 'y'.
we can find these three solutions for our r1_y :
cube_root( R1_y^2 - 7 ) mod p

sol1 = 0A35A7B0D6A2EEE7EBD83F730DC6CC359C15515F704706C57EB8D70E59A7AD24
sol2 = B68E234D58FEAFC61E733CC95C16E1E042D6D5AAD849A0763704D63C4E497997
sol3 = 3F3C3501D05E6151F5B483C3962251EA2113D8F5B76F58C44A4252B4580ED574

the three X coordinates share a property with the cube roots of 1 mod p which are :

rm1p = 1
rm2p = 7AE96A2B657C07106E64479EAC3434E99CF0497512F58995C1396C28719501EE
rm3p = 851695D49A83F8EF919BB86153CBCB16630FB68AED0A766A3EC693D68E6AFA40

And really what's going on with all these points' X coordinate that we gathered is :

P2_x * rm1p = P2_x mod p  # trivial
P2_x * rm2p = R2_x mod p
P2_x * rm3p = R1_x mod p

when this is true for some three points on secp256k1, for the cube roots of 1 mod n which are :

rm1n = 1
rm2n = AC9C52B33FA3CF1F5AD9E3FD77ED9BA4A880B9FC8EC739C2E0CFC810B51283CE
rm3n = 5363AD4CC05C30E0A5261C028812645A122E22EA20816678DF02967C1B23BD72

the following is also true :

rm1n * P2 = P2  # trivial
rm2n * P2 = R1
rm3n * P2 = R2

recall step (2): ( P2 = -P1  ->  d2 = -d1 ), we now also know that {d1,d2,k1,k2} all share the same property with :

k1 = d2 * rm2n % n
k2 = -d1 * rm3n % n

an ecdsa signature is computed like :
1/k * ( z + ( r * d ) ) = s  mod n

we know that :

1/k1 * ( z1 + ( r1 * d1 ) ) = s1
1/k2 * ( z1 + ( r2 * d2 ) ) = s2

k1 = d2 * rm2n
k2 = -d1 * rm3n

d2 = -d1

substitute k2:

1/(-d1 * rm3n) * ( z1 + ( r2 * (-d1) ) ) = s2   ## multiply by rm2n
1/d1 * ( z1 + ( r2 * (-d1) ) ) = -s2 * rm3n
z1/d1 + (r2 * (-d1))/d1 = -s2 * rm3n
z1/d1 - r2 = -s2 * rm3n  
z1/d1 = ( -s2 * rm3n ) + r2   ## "divide" by z1

we get equation that we can use to solve for d1 :
1/d1 = ( ( -s2 * rm3n ) + r2 ) * 1/z1  mod n

which gives us :

d1 = C3FC5135DF80FC592FD8A8A278799F6CD493CD5786858E9022475D52EE21B654
     cU9fw5RaHJNuEEWRgxo7xpLVDtJNNwYnuPHKyzw1m9Z4B5C19dik

d2 = 3C03AECA207F03A6D027575D87866091E61B0F8F28C311AB9D8B0139E2148AED
     cPbMwEBKaLTxXdqXDLGeNYyTyzepcaoARKzxL1bwvDJodd1JynPZ

and now we can redeem the input at 10b1bbb7477d0736b4cadd18cf93f02a0ecd01d0e056b1ab9333aaf95ae914e1.
but the puzzle says that we need to "obtain ownership of the coins", so what about the very first spend at a7d13228... ?

since we had :

k1 = d2 * rm2n
k2 = -d1 * rm3n

how about we try :
from {k1, k2} we get the two keypairs :

k1 = C05A50169BBE16DB798465D7FA4B4FF95BD7FD3B83057181406AD4E31491D1AB
K1 = 03B68E234D58FEAFC61E733CC95C16E1E042D6D5AAD849A0763704D63C4E497997
address : mkaczxMUDgN9usu7hqpBiYKjZ6zJguFr1v

k2 = 03A2011F43C2E57DB65442CA7E2E4F7378BBD01C03801D0EE1DC886FD98FE4A9
K2 = 030A35A7B0D6A2EEE7EBD83F730DC6CC359C15515F704706C57EB8D70E59A7AD24
address : mxLMDERfVDfiQdkrY7gVbiKRYupTfHgZqd

the address for k1 doesn't look familiar, but mxLMDERfVDfiQdkrY7gVbiKRYupTfHgZqd is the address in the second output!
maybe the spender did the same trick?

k3 = -k1 mod n

k3 = 3FA5AFE96441E924867B9A2805B4B0055ED6DFAB2C432EBA7F6789A9BBA46F96
K3 = 02B68E234D58FEAFC61E733CC95C16E1E042D6D5AAD849A0763704D63C4E497997
address : mmr1JWt6t3szFdRpTZ7CjLBTwAzMHnxrrP

looks like we now own all coins.

The main catch in this puzzle is identifying that R1 and R2 share the same Y value.  Once that is known, you have enough information to solve for the private keys.  The last part was just a bonus

That "witness count" is just how many items are in this current witness' stack.
For this witness there is the signature and the pubkey, so the witness count is "2".
This entire witness with its two items is used by the first input input in the transaction. You can see the transaction is redeeming a p2sh(p2wpkh).

--------------------



In here the same thing happens with the first input.  It also redeems a p2sh(p2wpkh) so we see the normal witness stack of two items, the signature and the pubkey.
The second input redeems a non-segwit scriptpubkey.  By bip141 rules, when a segwit input and a non segwit input are redeemed in the same transaction, the non-segwit input will have an empty witness.  That is the single 0x00 byte that tells you "this is a witness stack of 0 items"
(note that because you didn't parse the "empty stack" byte, your nlocktime was shifted.  the final byte in the nlocktime is also 0x00, but it's not the same byte that you asked about) - sorry, my bad.  you asked about the right byte.

The generation tx in that block does have a witness and you're probably parsing the marker byte ( 0x00 ) as if it means "zero inputs".

Try running the client with the -rpcserialversion=0 flag and try parsing it again.  You should look into bip141 for what segwit serialization looks like.

Cheers Chicago.  Good luck with the new set of keys.

Using bip16 it's possible to take any script and "wrap" it with a p2sh script (has a standard address), so that there's a simple way to accept payment even to more advanced scripts with the burden of setting up the redemption terms moved to the person getting paid.
The decodescript example above shows how it can be used:

run:
The output is :


Note the p2sh address.
The scriptpubkey that is known to have this address type is made out of a push of a hash160 of the redeemscript, and an op_equal.  You can read more on the bip16 link.

You can now run:
And see that :
Which is what is used in the 21 mil. redemption.

Well, first I generated a random private key cTtH93A1spUmeMV2QdPXtET8KT2w98YxDjkQJNbZbYBgKAxsTbsr, then got the public key from it which is 036622CF5134172EE134EA77A181AAD2D544D3E084AF105423779C94545F96508E.
I created a "pay to pubkey" (p2pk) script using it, which is 21036622CF5134172EE134EA77A181AAD2D544D3E084AF105423779C94545F96508EAC, and wrapped that in a "pay to script hash" (p2sh) script, which is A9148F121357DC6D9130F3A19B3EDD965998B6B23E5687.
The p2pk script is then the redeemscript and money (the 21 million btc) is sent to that p2sh script, which is the scriptpubkey.

The txid for the input transaction, the one that paid 21 million btc to the p2sh script, is chosen to be 0000000000000000000000000000000000000000000000000000000000000100 .  In reality, you can't choose value that but for this test this is what is used.

To redeem that input, I need to provide the redeemscript for the p2sh scriptpubkey, and since that redeemscript is actually a p2pk script, I also need to provide the private key for signage.

To read about scripts like p2pk, p2sh and more, this might be a good reference: https://bitcoin.org/en/developer-guide#term-output .

You could use Core to generate everything from the private key to the p2sh script by using commands like getnewaddress, dumpprivkey, importaddress...
I recommend using testnet or regtest locally to play around with it

* For example, you could run:
bitcoin-cli -testnet decodescript 21036622CF5134172EE134EA77A181AAD2D544D3E084AF105423779C94545F96508EAC
And see what that script actually says, which is just "do a checksig operation with this pubkey".

I used a different private\public key pair because I don't know what's the private key that was used in the tests, but the scripts should be the same.
You can't use createrawtransaction because the output's script is 51, and seems like createrawtransaction accepts only addresses for outputs.

458091 = 00000000000000000000011246f099d94f91628d71c9d75ad2f9a06e2beb7e92

meh...


$ randhex 32
D391EFDB25A444378BCE5FA210FDD4D1463E42B1D6AF40B6448C5D7B6D81F8E4
$ key_priv2pub D391EFDB25A444378BCE5FA210FDD4D1463E42B1D6AF40B6448C5D7B6D81F8E4
032354D13BC27086470F9160F808B1874129D44CF2DA10ADB242570EA111AFD696

1PCvTZ6Jn8KYMfP3t3r2eU4N5dRbU5MzSe - bitcoin
n3iskcBHb9ko8mrfbcpQUPGgwd2JV94LdS - testnet
LhRsimQ8rnZbcU5D4BqKvV88HqnsenDJG6 - litecoin


what are you saying here exactly?  you can't just send litecoins to a bitcoin address or vise versa because the wallet will fail on a wrong network version byte.  if you meant "send them to the valid address on another chain", then you can obviously still redeem it because the p2pkh script is still solvable with the same conditions (hash160 matches the pubkey).
unless you mean something else?

if you want to accept coins from a different chain, this is a good starting point:
https://en.bitcoin.it/wiki/Atomic_cross-chain_trading

let me know if I just didn't get what you mean.

From the spend redeeming the first transaction sent to the address.  The script (redeemScript) is the first input.


Maybe


Awesome!  I recommend setting up an indexing(!) testnet node with a command line interface and just start messing with it.  In no time you'll learn the names of a bunch of technical terms, and then you'll have keywords to use when searching for something new you wanna learn about.
For example you could run this with your indexing testnet node, and see the script as the bottom item in scriptSig :

bitcoin-cli -testnet getrawtransaction 4c004c3f06f5b76ae3f325cfb26ff305146bda0a3f9e5662462653b41324ac4a 1

Aside from that, I don't want to accidentally drop clues to the answer in case someone is still working on solving this, so I'll stop here

Yes, I wish I had the spare cash to fund this puzzle on mainnet, that would've made it a lot more exciting
If anyone wants to fund the same mainnet address, that would be awesome, but they'll have to trust me that I won't grab the prize myself.


Still, you are very close!

Hello all,

I set up what I think is a fun a transaction puzzle on the testnet address 2MuUKuRSr5sbj9HA9dDo5RS4QVMDrcnyu1o

I've made two transactions funding the address, and one redeeming.  The goal of the puzzle is the obtain ownership of the coins.
The transactions associated with the address are :


fund :
a7d13228ec32508e3255ce35aff85a143e2784d38511df2a9e13569912ab47b9

fund :
10b1bbb7477d0736b4cadd18cf93f02a0ecd01d0e056b1ab9333aaf95ae914e1

spend from a7d13228...
4c004c3f06f5b76ae3f325cfb26ff305146bda0a3f9e5662462653b41324ac4a


Cheers