Bitcoin Forum
July 04, 2024, 06:08:38 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Mistake when Creating and using multisig address  (Read 1759 times)
RainHawk (OP)
Newbie
*
Offline Offline

Activity: 6
Merit: 0


View Profile
May 08, 2014, 08:54:10 PM
 #1

I’m having some trouble creating a valid testnet multisignature address in java, I’ve included the steps I’ve taken below.  Most of the variables I’m using are hex encoded and I’m using || to represent concatenation.  I hope that someone can help identify my mistake.

Here are the public keys I’m using (these are compressed keys, is that ok?)

pubKey1: 037783b9aee0cd926306a30f37e2e819d69aa66707a1f96a15cc581368270c5bcf
pubKey2: 02b024b76570311b75fa353a0296c50d41629da101ecfee172449935c1a029af81
pubKey3: 03685e7c360d84e7999055e8639776aee4a743c529b4d2c655c03905a754cbbdce


Algorithm for creating redemption script:
n || publicKey0 || publicKey1 || publicKey2 || m || OP_CHECKMULTISIG

My redemption script values:
52 || 037783b9aee0cd926306a30f37e2e819d69aa66707a1f96a15cc581368270c5bcf || 02b024b76570311b75fa353a0296c50d41629da101ecfee172449935c1a029af81 || 03685e7c360d84e7999055e8639776aee4a743c529b4d2c655c03905a754cbbdce || 53 || 174

Redemption script:
52037783b9aee0cd926306a30f37e2e819d69aa66707a1f96a15cc581368270c5bcf02b024b7657 0311b75fa353a0296c50d41629da101ecfee172449935c1a029af8103685e7c360d84e7999055e8 639776aee4a743c529b4d2c655c03905a754cbbdce53ae

Algorithm for creating address from redemption script:
version || hash160(sha256(redemption script)) || checksum

My address values:
c4 || c9d4d1c375a6964fe2cc08100c9178ce9c610999 || 34151294

Address:
c4c9d4d1c375a6964fe2cc08100c9178ce9c61099934151294

Finally my base58 address:
2NBeQknuJrQKY8AHCTV5AVpKzyHryxXXQ9R




I think can spend coins from the address using the redemption script:
52037783b9aee0cd926306a30f37e2e819d69aa66707a1f96a15cc581368270c5bcf02b024b7657 0311b75fa353a0296c50d41629da101ecfee172449935c1a029af8103685e7c360d84e7999055e8 639776aee4a743c529b4d2c655c03905a754cbbdce53ae

I think can send coins to the address using:
OP_HASH160 || 2NBeQknuJrQKY8AHCTV5AVpKzyHryxXXQ9R || OP_EQUAL



When I send coin to shows in blockexplore as unknown, and I can’t seem to spend it.  I’m betting there are some gross mistakes in the steps I’m taking, and I’m hoping the community can help me identify them.

A couple of questions I have are:
1) Can compressed public keys be used to create a multisig address
2) When sending coin using OP_HASH160 || Address || OP_EUQUAL what format should the address be in?
3) Am I using the correct algorithms to create the redemption script and the address?
cbeast
Donator
Legendary
*
Offline Offline

Activity: 1736
Merit: 1006

Let's talk governance, lipstick, and pigs.


View Profile
May 08, 2014, 09:05:03 PM
 #2

You could look at the source code from https://coinb.in/multisig/

Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
Bitornio
Member
**
Offline Offline

Activity: 67
Merit: 10


View Profile
May 08, 2014, 10:11:22 PM
 #3

The transactions are unknown? Can you paste the transaction ID?
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
May 08, 2014, 10:16:58 PM
Last edit: May 08, 2014, 10:40:36 PM by DeathAndTaxes
 #4

Why don't you try creating the address in bitcoind and see where it differs.

1) Can compressed public keys be used to create a multisig address
Yes.

Quote
2) When sending coin using OP_HASH160 || Address || OP_EUQUAL what format should the address be in?

The bitcoin protocol never uses addresses.  Addresses are just for us humans (to avoid mistakes).  The client/app needs to convert the address to the PubKeyHash (Pay2PubKeyHash) or ScriptHash (Pay2ScriptHash) so it should be:
OP_HASH160 || ScriptHash || OP_EQUAL

Quote
3) Am I using the correct algorithms to create the redemption script and the address?

It also looks like you are using decimal instead of hex value for OP_CHECKMULTISIG.  It should be 0xae not 174.  Everything will always be in binary.  Opcodes are always one byte (2 hex digits).

RedeemScript
5221037783b9aee0cd926306a30f37e2e819d69aa66707a1f96a15cc581368270c5bcf2102b024b 76570311b75fa353a0296c50d41629da101ecfee172449935c1a029af812103685e7c360d84e799 9055e8639776aee4a743c529b4d2c655c03905a754cbbdce53ae

Address:
37S7ghArXes3tU7k6aTUcjrD4aDVFbuQDi
RainHawk (OP)
Newbie
*
Offline Offline

Activity: 6
Merit: 0


View Profile
May 09, 2014, 03:10:40 PM
 #5

Thank you DeathAndTaxes!

You are right, I was encoding the OP_MULTISIG incorrect.

I took your advice to generate the multisig address using bitcoin for comparison.  The address created and redemption script match the values you listed and  I noticed that I was not including the opcode prefix on my public keys when creating the redemption script.

My updated example, including a transaction to try and spend my source address is below.  Both the change and the destination are (I think) going to multisig addresses, just one is using the redemption script, and one is using a pay 2 script hash.

source address
Quote
pubKey1: 037783b9aee0cd926306a30f37e2e819d69aa66707a1f96a15cc581368270c5bcf
pubKey2: 02b024b76570311b75fa353a0296c50d41629da101ecfee172449935c1a029af81
pubkey3: 02d43c07142463a881897de5640b724942857dfd89db6fcf47241cc0d2e71b801d

source redemptionScript:
n || publicKey0 || publicKey1 || publicKey2 || m || OP_CHECKMULTISIG

source redemptionScriptValues:
52 || 037783b9aee0cd926306a30f37e2e819d69aa66707a1f96a15cc581368270c5bcf || 02b024b76570311b75fa353a0296c50d41629da101ecfee172449935c1a029af81 || 02d43c07142463a881897de5640b724942857dfd89db6fcf47241cc0d2e71b801d || 53 || ae

source redemptionScript:
5221037783b9aee0cd926306a30f37e2e819d69aa66707a1f96a15cc581368270c5bcf2102b024b 76570311b75fa353a0296c50d41629da101ecfee172449935c1a029af812102d43c07142463a881 897de5640b724942857dfd89db6fcf47241cc0d2e71b801d53ae

source address: version || hash160(publicKey) || checksum
source address: c4 || 8e9ec4f0c66c4045542515899929de513aeb393e || b332b6ad
source address: c48e9ec4f0c66c4045542515899929de513aeb393eb332b6ad
source base58 address: 2N6FL91RhAjoD2jF7rYBmtpeUR3RGZKp31n

source address from bitcoind:
{
"address":"2N6FL91RhAjoD2jF7rYBmtpeUR3RGZKp31n",
"redeemScript":"5221037783b9aee0cd926306a30f37e2e819d69aa66707a1f96a15cc581368270c5bcf2102b024b 76570311b75fa353a0296c50d41629da101ecfee172449935c1a029af812102d43c07142463a881 897de5640b724942857dfd89db6fcf47241cc0d2e71b801d53ae"
}




destination address
Quote
destination pubKey1: 037783b9aee0cd926306a30f37e2e819d69aa66707a1f96a15cc581368270c5bcf
destination pubKey2: 02b024b76570311b75fa353a0296c50d41629da101ecfee172449935c1a029af81
destination pubkey3: 026a9bb2736489c4b946d1787b6c19e4a15078acad0a24058f6f411ee2cd80d308


destination redemptionScript:
n || publicKey0 || publicKey1 || publicKey2 || m || OP_CHECKMULTISIG

destination redemptionScriptValues:
52 || 037783b9aee0cd926306a30f37e2e819d69aa66707a1f96a15cc581368270c5bcf || 02b024b76570311b75fa353a0296c50d41629da101ecfee172449935c1a029af81 || 026a9bb2736489c4b946d1787b6c19e4a15078acad0a24058f6f411ee2cd80d308 || 53 || ae

destination redemptionScript:
5221037783b9aee0cd926306a30f37e2e819d69aa66707a1f96a15cc581368270c5bcf2102b024b 76570311b75fa353a0296c50d41629da101ecfee172449935c1a029af8121026a9bb2736489c4b9 46d1787b6c19e4a15078acad0a24058f6f411ee2cd80d30853ae

destination address: version || hash160(publicKey) || checksum
destination address: c4 || 247d3ea09b45ebe826042b5e58e98727b47e5d54 || f8bd4906
destination address: c4247d3ea09b45ebe826042b5e58e98727b47e5d54f8bd4906
destination base58 address: 2MvaAMLfZZ8JUb2UvC8w7Y9YevzkzQ69NBX

destination address from bitcoin d:
{
"address":"2MvaAMLfZZ8JUb2UvC8w7Y9YevzkzQ69NBX",
"redeemScript":"5221037783b9aee0cd926306a30f37e2e819d69aa66707a1f96a15cc581368270c5bcf2102b024b 76570311b75fa353a0296c50d41629da101ecfee172449935c1a029af8121026a9bb2736489c4b9 46d1787b6c19e4a15078acad0a24058f6f411ee2cd80d30853ae"
}

change address
Quote
change publickey0: 037783b9aee0cd926306a30f37e2e819d69aa66707a1f96a15cc581368270c5bcf
change publickey1: 02b024b76570311b75fa353a0296c50d41629da101ecfee172449935c1a029af81
change publickey2: 026a9bb2736489c4b946d1787b6c19e4a15078acad0a24058f6f411ee2cd80d308

redemptionScript:
n || publicKey0 || publicKey1 || publicKey2 || m || OP_CHECKMULTISIG

redemptionScriptValues:
52 || 037783b9aee0cd926306a30f37e2e819d69aa66707a1f96a15cc581368270c5bcf || 02b024b76570311b75fa353a0296c50d41629da101ecfee172449935c1a029af81 || 026a9bb2736489c4b946d1787b6c19e4a15078acad0a24058f6f411ee2cd80d308 || 53 || ae

change redemptionScript:
5221037783b9aee0cd926306a30f37e2e819d69aa66707a1f96a15cc581368270c5bcf2102b024b 76570311b75fa353a0296c50d41629da101ecfee172449935c1a029af8121026a9bb2736489c4b9 46d1787b6c19e4a15078acad0a24058f6f411ee2cd80d30853ae

change address: version || hash160(publicKey) || checksum
change address: c4 || 247d3ea09b45ebe826042b5e58e98727b47e5d54 || f8bd4906
change address: c4247d3ea09b45ebe826042b5e58e98727b47e5d54f8bd4906
base58 address: 2MvaAMLfZZ8JUb2UvC8w7Y9YevzkzQ69NBX

Transaction
Quote
Tx - version: 01000000
Tx - tx_in_count: 01
Outpoint - hash: 8b536157c1124e4f36abc779267b1b077d7fb32a4cd05675be5bb2d8e3d74933
Outpoint - index: 01000000
TxIn - script_length: 17
TxIn - signature_script: a9148e9ec4f0c66c4045542515899929de513aeb393e87
TxIn - sequence: ffffffff
Tx - tx_out_count: 02
TxOut - value: 40420f0000000000
TxOut - pk_script_length: 17
TxOut - pk_script: a914247d3ea09b45ebe826042b5e58e98727b47e5d5487
TxOut - value: 0039332a00000000
TxOut - pk_script_length: 69
TxOut - pk_script: 5221037783b9aee0cd926306a30f37e2e819d69aa66707a1f96a15cc581368270c5bcf2102b024b 76570311b75fa353a0296c50d41629da101ecfee172449935c1a029af8121026a9bb2736489c4b9 46d1787b6c19e4a15078acad0a24058f6f411ee2cd80d30853ae
Tx - lock_time: 00000000

transactionJsonObject:
{
  "txid": "bb76d7a2eb8aa03ddd760bc20f165e155d3cd9da3180ec1435f49497095b41bf",
  "version": 1,
  "locktime": 0,
  "vin": [
    {
      "txid": "3349d7e3d8b25bbe7556d04c2ab37f7d071b7b2679c7ab364f4e12c15761538b",
      "vout": 1,
      "scriptSig": {
        "asm": "OP_HASH160 8e9ec4f0c66c4045542515899929de513aeb393e OP_EQUAL",
        "hex": "a9148e9ec4f0c66c4045542515899929de513aeb393e87"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.01,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 247d3ea09b45ebe826042b5e58e98727b47e5d54 OP_EQUAL",
        "hex": "a914247d3ea09b45ebe826042b5e58e98727b47e5d5487",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "2MvaAMLfZZ8JUb2UvC8w7Y9YevzkzQ69NBX"
        ]
      }
    },
    {
      "value": 7.08,
      "n": 1,
      "scriptPubKey": {
        "asm": "2 037783b9aee0cd926306a30f37e2e819d69aa66707a1f96a15cc581368270c5bcf 02b024b76570311b75fa353a0296c50d41629da101ecfee172449935c1a029af81 026a9bb2736489c4b946d1787b6c19e4a15078acad0a24058f6f411ee2cd80d308 3 OP_CHECKMULTISIG",
        "hex": "5221037783b9aee0cd926306a30f37e2e819d69aa66707a1f96a15cc581368270c5bcf2102b024b 76570311b75fa353a0296c50d41629da101ecfee172449935c1a029af8121026a9bb2736489c4b9 46d1787b6c19e4a15078acad0a24058f6f411ee2cd80d30853ae",
        "reqSigs": 2,
        "type": "multisig",
        "addresses": [
          "mjDPU8nqkhjX3YxzTw7tPnPEa5puPPiQPx",
          "mpe29LVS4NzxTM2xK1Bvasfq5GjBPXcaR7",
          "mzW2Qzo9igJXbx9g7rNaRzVJzVQcoAhadu"
        ]
      }
    }
  ]
}
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
May 09, 2014, 03:44:51 PM
 #6

i think you still have some mistakes.  I don't have the time to take a detailed look however it is important to understand there are two different multisigs in Bitcoin.  There is the original multsig where the script is encoded in the output itself.  I generally call this "native multisig" to be explicit.  Then there is P2SH (pay to script hash) where the payment is sent to a hash of the script (redeem script).

It appears in your tx above that out[0] is a payment using p2sh and out[1] is a payment using "native multisig".  Also it looks like you are using the same keys both outputs.  So you have 7.09 BTC going to the same set of keys, 0.01 BTC being sent using P2SH address (out[0]) and another 7.08 BTC being sent using native multisig (P2SH).

There is no requirement for change.  The protocol just sees inputs and outputs.  We only use a "change" address to balance the equation sum(input) = sum(outputs) + fee when the intended transaction amount is smaller than the input being "spent".

So I am going to assume the input (txid: 3349d7e3d8b25bbe7556d04c2ab37f7d071b7b2679c7ab364f4e12c15761538b index: 1) is worth 7.09 BTC (I don't see it on testnet blockchain but that may be my issue) and you are trying to make a tx with no fee?

If you just want to send the full amount to the P2SH address then you only need a single output worth 7.09 (or the value of the input - intended miner fee)

If you wanted to send 0.01 BTC to the P2SH address then the second output should just be another address in the senders wallet (if you are using a single wallet and sending to yourself I would just grab a "normal" address to use as the second output and the value of that should be value of input - 0.01 - intended fee.

If you haven't already I would do this demo from start to finish (just substitute your keys and your funding transaction) using bitcoind on testnet:
https://gist.github.com/gavinandresen/3966071

Gavin's demo is good because it walks through all of the following:
1) Create a P2SH address (2 of 3)
2) Send funds to the P2SH address
3) Create a tx "spending" funds from the P2SH address
4) Sign the P2SH address in multiple steps (simulating keys on different machines)
5) Broadcast the fully signed transaction.

Make sure you can do all this using nothing but bitcoind before moving on to custom java.  Otherwise it makes it difficult to see if the problem is in your java or your understanding of P2SH or your understanding on bitcoin tx in general.  Once you are able to go through it once, you can do it again, save the output of each step but don't broadcast.  You now have a step by step template and your java should produce the same outputs at each step.
RainHawk (OP)
Newbie
*
Offline Offline

Activity: 6
Merit: 0


View Profile
May 09, 2014, 06:08:30 PM
 #7

Thank you for the link with Gavin's example, I will use that as a base case to test from.

The two outputs are going to the same set of keys, I wanted to try using both the p2sh and the "native multisig".  Labeling one of them as change was probably a poor choice.

I still need to work through the signing step, but hopefully working from the link you provided with Gavin's example I wont run into much trouble.

You should put a an address in your signature, I would love to tip you some coin for all the help you've given me!
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!