From d2edba3cb6b686bc79125048ad042ed15d060258 Mon Sep 17 00:00:00 2001 From: jl777 Date: Tue, 3 May 2016 21:26:10 -0500 Subject: [PATCH] fixed all 0 pub key on new address creation --- iguana/iguana_passport.c | 64 +++++++++++++++++++++++++++++++--- iguana/iguana_wallet.c | 19 ++++------ iguana/tests/.signmessage.swp | Bin 12288 -> 0 bytes iguana/tests/signmessage | 2 +- iguana/tests/verifymessage | 2 +- 5 files changed, 69 insertions(+), 18 deletions(-) delete mode 100644 iguana/tests/.signmessage.swp diff --git a/iguana/iguana_passport.c b/iguana/iguana_passport.c index 156d66c35..40c568684 100755 --- a/iguana/iguana_passport.c +++ b/iguana/iguana_passport.c @@ -18,8 +18,8 @@ /* Asset Passport System - first draft spec - Asset Export - destination blockchain and address, BTC sync - Asset Import - source blockchain txid or BTCD txid + Asset Export - destination blockchain and address, optional BTC sync + Asset Import - source blockchain txid/vout or BTCD txid/vout Assets can be exported from any blockchain that supports a burn transaction with an attachment. This attachment needs to have a destination blockchain and address. In case a blockchain cannot support a combined burn with attachment, the burn txid can be added to the export payload and this combined data signed using the source blockchain's signing method to create a BTCD 'APS' OP_RETURN @@ -32,12 +32,68 @@ While it is not expected that there will be more than 256 such blockchains, by u 'o' -> open assets 'w' -> WAVES 'x' -> counterparty (XCP) - '?' -> please contact jl777 to have asset supporting blockchain added. + '?' -> please contact jl777 to have a new code for asset supporting blockchain added. When 0xfc slots are filled, the code (0xfd + 2 bytes) will be used. It is safe to assume there wont be more than 65534 supporting blockchains, but codes 0xfe and 0xff will be reserved just in case The destination address is the 20 byte rmd160 of the sha256 of the 256 bit privkey, basically the precursor to all bitcoin type of addresses in a coin agnostic format, so this handles all the blockchains that use a bitcoin type of addressing. For blockchains that do not, the method to map its privkeys to a 256 bit privkey needs to be defined. Then the standard rmd160(sha256(mapped privkey)) will be the address -By encoding the above 21 bytes into the existing blockchain with the burning of the asset on that blockchain, it no longer exists on the source blockchain and it has a unique destination blockchain. +If many exports from multiple blockchains are done all at the same time, it might be desireable to create an ordering of the exports. To facilitate this, the lower 64-bits of a recent BTC blockhash can be added. Any time sequence resolution will use the height of the first BTC blockhash that matches, scanning backward from the likely starting point based on the source blockchain's timestamp. In order to compensate for clock drift, it is advised to select a BTC block that is 2 blocks in the past. In the event there are multiple exports still tied, the lower 64bits of the txids will be used for a tiebreak. In the event there are still multiple exports tied, then the blockchain code from above will be used. In the event there are multiple exports from the same blockchain that are still tied, then that local blockchain's transaction ordering will be used. +By encoding the above 21 (or 28) bytes into the existing blockchain with the burning of the asset on that blockchain, it no longer exists on the source blockchain and it has a unique destination blockchain. + +Requiring all blockchains to be monitoring all the other blockchains creates an N*N complexity where each blockchain needs to be able to read all the other blockchains. In order to simplify this, the BTCD blockchain can be used to provide a single blockchain that can be accessed via SuperNET API locally or remotely to retrieve a list of asset exports. To facilitate this a BTCD 'APS' OP_RETURN needs to be created by the client software: + + OP_RETURN + 'A' + 'P' + 'S' + <21 or 28 bytes> + + + + + -> contents to be verified against the <21 or 28 bytes> + -> only needed if original and source blockchain are different + -> to be verified with the signer's pubkey of the blockchain txid signer + + + Asset Import + Importing assets creates a rather troublesome issue, in that to make it fully automated, all blockchains would need to monitor all the other blockchains for valid Asset Exports and then also to properly issue newly created assets to match. Since some blockchains are not able to issue more assets after the initial issuance, there needs to be a way for a reserve amount of assets to be transfered on demand. However, keeping this reserve totally blockchain controlled could be problematic for some blockchains, so provision for the asset issuer to sign a transfer for valid exports is needed. + + Which leads to the following simplification of the process. The asset issuer needs to run a special automated process that monitor's for Asset Exports and when it is received, to send out the appropriate new asset on the destination blockchain. This allows the asset issuer to create appropriate assets on each blockchain and can encapsulate whether new assets are created dynamically, or transferred from a reserve account. When an asset is created for the APS on a blockchain, its specifics should be recorded on the BTCD APS OP_RETURN by the asset issuer: + + OP_RETURN + 'A' + 'P' + 'S' + + + + + + + + -> to be verified with the issuer's pubkey + + + When the matching Asset Import is completed for an Asset Export, this needs to be recorded with a BTCD APS: + + OP_RETURN + 'A' + 'P' + 'S' + + + + + -> to be verified with the issuer's pubkey + + + + All of the BTCD APS OP_RETURNS can have security added to them by generating a matched BTC APS OP_RETURN with the SHA256 of the contents of the BTCD APS (including the signature) + + In order to simplify signature validation, all signatures will use secp256k1 signatures of the double sha256 hash of the contents. + +Given the above set of APS OP_RETURNS, the SuperNET passport API will provide aggregate information on the global assets, such as total issued, circulation, assetid mappings, etc */ diff --git a/iguana/iguana_wallet.c b/iguana/iguana_wallet.c index 5a63d2bf6..e1dcd6f3c 100755 --- a/iguana/iguana_wallet.c +++ b/iguana/iguana_wallet.c @@ -114,6 +114,7 @@ struct iguana_waddress *iguana_waddressadd(struct supernet_info *myinfo,struct i printf("iguana_waddressadd verify error %p vs %p\n",ptr,waddr); if ( waddr != 0 && waddr != addwaddr ) { + waddr->wiftype = coin->chain->wiftype; if ( redeemScript != 0 && (addwaddr->scriptlen= (int32_t)strlen(redeemScript) >> 1) != 0 ) { if ( waddr->scriptlen != addwaddr->scriptlen ) @@ -129,20 +130,14 @@ struct iguana_waddress *iguana_waddressadd(struct supernet_info *myinfo,struct i memset(&waddr->privkey,0,sizeof(waddr->privkey)); memset(waddr->pubkey,0,sizeof(waddr->pubkey)); } - if ( addwaddr->scriptlen == 0 && bits256_nonz(waddr->privkey) == 0 ) - { - waddr->privkey = addwaddr->privkey; - if ( bitcoin_priv2wif(waddr->wifstr,waddr->privkey,coin->chain->wiftype) > 0 ) - { - waddr->wiftype = coin->chain->wiftype; - waddr->addrtype = coin->chain->pubtype; - } - } - else if ( addwaddr->wifstr[0] != 0 ) + else { - waddr->addrtype = addwaddr->addrtype; + waddr->addrtype = coin->chain->pubtype; waddr->wiftype = addwaddr->wiftype; - strcpy(waddr->wifstr,addwaddr->wifstr); + if ( bits256_nonz(waddr->privkey) == 0 ) + waddr->privkey = addwaddr->privkey; + if ( addwaddr->wifstr[0] != 0 ) + strcpy(waddr->wifstr,addwaddr->wifstr); memcpy(waddr->pubkey,addwaddr->pubkey,sizeof(waddr->pubkey)); } memcpy(waddr->rmd160,addwaddr->rmd160,sizeof(waddr->rmd160)); diff --git a/iguana/tests/.signmessage.swp b/iguana/tests/.signmessage.swp deleted file mode 100644 index cd28a7c6ca79044cb5e0c9d5d4627d76983644d6..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 12288 zcmeI&y-tKc5C`x%8!MyH7r?QxkXzsi45gigKmY;|fB*y_009U<00Izz z00bcLPXepHD?Q(LS6&;_CPIW!JPqs-CbonAnr${!MtS@sxysDCNhK$ee|6DIzLMOk UPF32b7Lr|`{m@}A`SF?Q2Vq!8O#lD@ diff --git a/iguana/tests/signmessage b/iguana/tests/signmessage index 86a37fd9c..9b97e5bca 100755 --- a/iguana/tests/signmessage +++ b/iguana/tests/signmessage @@ -1,2 +1,2 @@ -curl --url "http://127.0.0.1:7778" --data "{\"method\":\"signmessage\",\"params\":[\"testmessage\"]}" +curl --url "http://127.0.0.1:7778" --data "{\"method\":\"signmessage\",\"params\":[\"1KHJ4zELwwwND4dytYp7tFyBvELMH1r7a7\", \"testmessage\"]}" diff --git a/iguana/tests/verifymessage b/iguana/tests/verifymessage index 86a37fd9c..89a6081bf 100755 --- a/iguana/tests/verifymessage +++ b/iguana/tests/verifymessage @@ -1,2 +1,2 @@ -curl --url "http://127.0.0.1:7778" --data "{\"method\":\"signmessage\",\"params\":[\"testmessage\"]}" +curl --url "http://127.0.0.1:7778" --data "{\"method\":\"verifymessage\",\"params\":[\"1KHJ4zELwwwND4dytYp7tFyBvELMH1r7a7\", \"MEQCIFLlZ2QVOEq+DzxfmVHy3pXVkCt3SZeNV1byiDVPL42fAiBHL1GN7J7uDW2WULZHruNtOqwfHKJMtL+LndDq08/ybA=\", \"testmessage\"]}"