lukechilds
/
SuperNET
mirror of https://github.com/lukechilds/SuperNET.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
Browse Source

fixed all 0 pub key on new address creation

release/v0.1
jl777 9 years ago
parent
da904a6c29
commit
d2edba3cb6
5 changed files with 69 additions and 18 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 64
      iguana/iguana_passport.c
  2. 19
      iguana/iguana_wallet.c
  3. BIN
      iguana/tests/.signmessage.swp
  4. 2
      iguana/tests/signmessage
  5. 2
      iguana/tests/verifymessage

64
iguana/iguana_passport.c
View File

@ -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>
<original blockchain where asset was issued>
<original assetid>
<source blockchain byte>
<source asset amount in satoshis>
<source blockchain txid of burn> -> contents to be verified against the <21 or 28 bytes>
<source assetid> -> only needed if original and source blockchain are different
<signature of the above> -> to be verified with the signer's pubkey of the blockchain txid signer
<optional BTC txid with SHA256 of above in APS OP_RETURN>
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'
<original blockchain where asset was issued>
<original assetid>
<dest blockchain byte>
<dest asset issued in satoshis>
<dest blockchain txid of new issue>
<asset name>
<asset description>
<signature of the above> -> to be verified with the issuer's pubkey
<optional BTC txid with SHA256 of above in APS OP_RETURN>
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'
<BTCD APS txid/vout of Asset Export>
<dest assetid>
<dest assets transferred in satoshis>
<dest blockchain txid of transfer>
<signature of the above> -> to be verified with the issuer's pubkey
<optional BTC txid with SHA256 of above in APS OP_RETURN>
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
*/

19
iguana/iguana_wallet.c
View File

@ -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));

BIN
iguana/tests/.signmessage.swp
View File

Binary file not shown.

2
iguana/tests/signmessage
View File

@ -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\"]}"

2
iguana/tests/verifymessage
View File

@ -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\"]}"

Write Preview
Loading…
Cancel
Save