Merge pull request #882 from jl777/FSM
prepare for gateways multisig and add notarization check to disconnect tip
This commit is contained in:
jl777
@@ -447,7 +447,51 @@ WARNING: there is an attack vector that precludes betting any large amounts, it
|
||||
In order to mitigate this, the disclosure of the house entropy needs to be delayed beyond a reasonable reorg depth (notarization). It is recommended for production dice game with significant amounts of money to use such a delayed disclosure method.
|
||||
|
||||
|
||||
Chapter 10 - lotto example
|
||||
Chapter 10 - channels example
|
||||
It might be hard to believe, but channels CC implements an instant payment mechanism that is secured by dPoW in a way that is backward compatible with the existing wallets, explorers, etc. and channels CC does not require both nodes to be online. Its usecases are all the usecases for Lightning Network, it is just more secure, less expensive and backward compatible! The one aspect which some might consider a downside (and others another benefit) is that all payments are onchain. This means it would increase blockchain size, but the idea is for channels CC to be used on blockchains with relatively lower value coins, so a txfee of 0.0001 is not anything significant.
|
||||
|
||||
Warning: very confusing blockchain reorganization issues described below. Will be confusing to most people
|
||||
|
||||
From a distance, the blockchain is a chain of blocks. One block after the next, each referencing all the prior blocks. Each block containing a group of transactions. Prior to getting into a block, the transactions are broadcast to the network and if it is valid, it enters the memory pool. Each miner then constructs a valid block from these memory pool transactions and when a transaction gets mined (confirmed), it is removed from the memory pool.
|
||||
|
||||
That is the simple version!
|
||||
|
||||
The reality is quite a bit more complex, but the critical aspect is that the blockchain can (and is) reorganized as part of the expected protocol. This can happen even when there is no 51% attack happening and it is important to understand this process in detail, so here goes.
|
||||
|
||||
What happens if two miners find a valid block at the same time? In this case the "same time" means within the time it takes for a block to propagate to the network. When a miner finds a new block, it is broadcast to the network and nodes update and start waiting for the next block. When there are two different (and valid) blocks propagating at the same time, some nodes update with one of the blocks and some the other, lets call it blockA and blockB. Now the nodes will know about both blockA and blockB, but some will consider blockA to be the chaintip and others will consider blockB to be the chaintip.
|
||||
|
||||
This is where it gets confusing. Which is the correct chaintip (latest block?). It turns out that both blockA and blockB are valid at this moment in time. So there are actuall two blockchains. We have what is called a small fork! Now dont worry, the protocol will help us converge to a single chain, but in order to do that, we need the next block.
|
||||
|
||||
Some miners will be mining from blockA and others from blockB. In most all cases, when the next block is found, it wont be at the "same time" again. So we will end up with a chain that is blockA+blockA2 or blockB+blockB2. Here comes the small reorg! Let's assuming blockA2 was found before blockB2, so that means all nodes that had blockB as the chaintip now see a longer chain blockA+blockA2, which trumps blockB. When that happens, it reorgs the chain so it is on blockA+blockA2. To do this properly, all the transactions that were in blockB are put back into the mempool and blockA is added, then blockA2.
|
||||
|
||||
Of course, when blockB2 arrives, the nodes see it but blockB+blockB2 is the same length as blockA+blockA2, so no reorg happens. Since we postulated that blockAs arrived "before" blockB2, that means all nodes are on the same chaintip, including all the miners and the next block found would be blockA3, without any complications.
|
||||
|
||||
Believe it or not, this sort of thing is happening all the time, one all blockchains. The chaintip is a volatile thing and that is why more than one confirmation is needed to avoid the small reorgs invalidating blockhash. However, it is possible for more than just the blockhash to change. When the reorg happens, all the transactions in the block are put back into the mempool and then the new blocks are processed in order. So what happens if one of the inputs to a transaction that happened in blockB, gets spent in blockA2? Based on random utxo allocation by wallets this is not impossible if an address has a lot of activity, but if it is part of a 51% attack, then this remote chance of an utxo being spent becomes a certainity! In fact, that is what a 51% attack is.
|
||||
|
||||
The attack can go much deeper than just one block. For chains that use the longest chain rule, it can go quite deep indeed. So as all the reorged transactions are put back into the mempool, we feel good that it will get confirmed again. Unfortunately, there is no enforcement of a miner needing to mine any specific transaction in the mempool. And the 51% attacker is intent on mining the transaction that spends an already spent utxo in the reorganized chain. it is called a double spend, but in the reorganized chain, it is spent only once. So it is a bit of a misnomer.
|
||||
|
||||
The important thing to understand is that if any transaction has inputs that are signed by a node, it is possible when the chain reorganizes for that transaction to become invalid. This is why dPoW is important as it doesnt strictly use the longest chain rule, but rather the longest notarized chain rule. Once a block is notarized, then it will refuse to reorganize that block (or any block before). So the risk is still there, but only until a notarization. Please see more detailed information about dPoW <here>.
|
||||
|
||||
Given the above, if you are wondering how can it be possible to have a mempool payment be secured by dPoW. Since it is explained how the reorgs can make valid transactions disappear, it seems unlikely any such solution is possible. However, the CC is very powerful and it can make unlikely things possible.
|
||||
|
||||
The following describes how.
|
||||
|
||||
We know that any payment that is utxo based can be invalidated via 51% attack, or even an unlikely but not impossible random utxo allocation from a busy wallet. Which means the payment cant be via a utxo. Since the CC system is utxo based, you might think that it means CC cant solve this. However, CC is very powerful and can implement payments that are not utxo based. But before this non-utxo payment method is explained, first we need to solve the mechanics of payment.
|
||||
|
||||
At a high level, we want to lock funds into a channel, have this lock notarized so it cant be reorganized. Then payments can unlock funds. Additionally, if we are restricting the payment to just one destination, we also need a way for the sender to reclaim the unused funds. So there needs a way for a close channel notification, which when notarized allows the sender to reclaim all funds. After the channel close is notarized, then the only action possible should be a reclaim of sender funds.
|
||||
|
||||
We need to assume that any payment, channel close, reclaim can be reorganized until it is notarized so great care needs to be made that a payment that is made will always be valid. With some allowances for blocks after a channelclose is notarized, we can protect the payments using the logic of "stop accepting payments after a channelclose is seen". It might be that a full notarization of wait time after the channelclose is notarized is needed to provide sufficient time for all the payments to be reprocessed.
|
||||
|
||||
Now we can finally describe the requirements for the CC. The locked funds need to be able to be spent by either the sender or receiver, the former only after sufficient time after a channelclose and the latter only after a payment is seen (not just confirmed, but just seeing it should be enough). The protection from reorgs is that the payment itself reveals a secret that is needed for the payment and only the secret would be needed, so it wont matter what utxo is used. To lock funds into a CC address that can handle this we need a 1of2 CC address, which can accept a signature from either of two pubkeys. The additional CC constraints would be enforced to make sure payments are made until the channel is closed.
|
||||
|
||||
A hashchain has the nice property of being able to encode a lot of secrets with a single hash. You can hash the hash, over and over and the final hash is the public value. By revealing the next to last hash, it can be verified that it hashes to the final hash. There is a restriction that a hashchain needs to be of reasonable maximum depth, say 1000. That means each iteration of the hashchain that is revealed is worth 1/1000th the total channelfunds. In fact, if the 500th hash value is revealed, half the channelfunds are released. this allows 1/1000th resolution that can be released with a single hash value.
|
||||
|
||||
Now we can make the payment based on the hashvalue revealed at a specified depth before the prior released hashchain value. Both the sender and receiver can make a payment to the destination by attaching a hashchain secret. This means even if the sender's payment is reorganized, if the destination has the revealed secret, a replacement payment can be made that is valid. If the destination account isnt monitoring the blockchain, then it wont see the revealed secret, but in this case there shouldnt be value released for the payments that are reorganized. So it would be a case of no harm, no foul. In any event, all the payments end up verifiable on the blockchain to provide verifiability.
|
||||
|
||||
Payments at the speed of the mempool, protected by dPoW!
|
||||
|
||||
<details of rpc calls, vin/vout allocations, etc>
|
||||
|
||||
|
||||
Chapter 11 - oracles example
|
||||
Oracles CC is an example where it ended up being simpler than I first expected, but at the same time a lot more powerful. It is one of the smaller CC, but it enables creation of an arbitrary number of data markets, in a performant way.
|
||||
@@ -582,6 +626,39 @@ Conclusion
|
||||
I hope this document has helped you understand what a Komodo utxo based CC contract is and how it is different from the other smart contracts. If you are now able to dive into the cc directory and start making your own CC contract, then I am very happy!
|
||||
|
||||
|
||||
gateways CC
|
||||
gateways CC is the first CC that combines multiple CC into a single one. In order to achieve its goals, both the assets CC and the oracles CC is used, in addition to a dapp that issues regular transactions. This general approach can be used to solve quite a few different use cases, so it is important to understand how a multi-CC solution is put together. There are some tricky issues that only arise when using more than one CC at a time.
|
||||
|
||||
Before the implementation details, first lets understand what the gateways CC does. At a high level it is similar to the old multigateway (from NXT AE 2014), but with improvements. The basic idea is to tokenize other crypto coins (like BTC) and then use the assets CC to transact/swap against the tokenized crypto. By enforcing a 1:1 peg between a specific token and BTC and an automated deposit/withdraw mechanism, it is possible to transact in the virtual BTC without the delay or expensive txfees. Then anybody that ends up having any of the BTC token would be able to withdraw actual BTC by redeeming the token.
|
||||
|
||||
BTC -> deposit to special address -> receive token that represents BTC onchain
|
||||
do onchain transactions with the BTC token
|
||||
anybody who obtains the BTC token can redeem the token and get actual BTC in the withdraw address
|
||||
|
||||
By bringing the operations onchain, it avoids the need for crosschain complications for each trade. The crosschain does still have to happen on the deposit and withdraw, but that is all. There is just one aspect that makes it not fully decentralized, which is the reliance on MofN multisig. However, with N trusted community members and a reasonable M value, it is not expected to be a big barrier. Since all operations are automated, the only trust needed is that M of the N multisig signers are running their nodes with the gateways dapp active and also that M of them wont collude to steal the funds locked in the multisig. In three years of operations, the MGW multigateway didnt have any incident of multisig signer misbehavior and it was only 2of3 multisig.
|
||||
|
||||
How can the gatewaysCC work? First, it needs a dedicated token that can be used to represent the external crypto coin. In order to avoid any issues with misplaced tokens, it is simplest to require that 100% of all the tokens are all locked in the gatewaysCC address. We want to make it so that the only way the tokens can be released from the locked address is when a verified deposit is made. So, we also need a deposit address, which means there needs to be a set of pubkeys that control the deposit address. It turns out, we also need to post merkleroot data from the external coin so that the information is onchain to be able to validate the external deposit. Since we are already trusting the deposit address signers to safekeep the external coins via MofN multisig, trusting them to post the merkleroots doesnt increase the trust footprint needed.
|
||||
|
||||
Now we have all the ingredients needed, a dedicated token, a set of multisig pubkeys and an oracle for merkleroots.
|
||||
|
||||
gatewaysbind tokenid oracletxid coin tokensupply M N pubkey(s)
|
||||
|
||||
With a gatewaysbind, a new gateway is defined. the pubkeys are for the custodians of the multisig funds and they also need to be posting merkleroots to the chain, so the oracle needs to be setup and funded and each of the signers needs to run the oraclefeed dapp. That posts each new merkleroot via oraclesdata and also responds to withdraw requests.
|
||||
|
||||
The MofN pubkeys generates a deposit address and when funds are sent to that address along with a small amount to the claim address. With the txid from this external coin, along with the txproof and the rawtransaction, all is submitted with a gatewaysdeposit. This adds a special baton output which is a gateways CC output to invoke gateways validation and also prevents double claims by using the unspent status of the baton.
|
||||
|
||||
gatewaysdeposit bindtxid height coin cointxid claimvout deposithex proof destpub amount
|
||||
gatewaysclaim bindtxid coin deposittxid destpub amount
|
||||
|
||||
Once the gatewaysdeposit is validated, it can be claimed and now the token is sent to the claim address. A 1:1 pegging of the external crypto to the token is established. And as long as one of the deposit address signers is running the oraclefeed, then the deposit/claim process is fully automatic and under the control of the depositor. Nothing needs to be signed by any other party! Also by using the utxo from the deposittxid, double claims are prevented.
|
||||
|
||||
On the withdraw side, the tokens are sent back to the address where the tokens are locked and this needs to create a redemption right that can only be used once.
|
||||
|
||||
gatewayswithdraw bindtxid coin withdrawpub amount
|
||||
|
||||
|
||||
And with a bit more magic in the oraclefeed, this is achieved. To be continued...
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -27,6 +27,7 @@ std::string GatewaysClaim(uint64_t txfee,uint256 bindtxid,std::string refcoin,ui
|
||||
std::string GatewaysWithdraw(uint64_t txfee,uint256 bindtxid,std::string refcoin,std::vector<uint8_t> withdrawpub,int64_t amount);
|
||||
UniValue GatewaysPendingWithdraws(uint256 bindtxid,std::string refcoin);
|
||||
std::string GatewaysMarkdone(uint64_t txfee,uint256 withdrawtxid,std::string refcoin,uint256 cointxid);
|
||||
UniValue GatewaysMultisig(uint64_t txfee,std::string refcoin,uint256 bindtxid,uint256 withdrawtxid,char *unspentstr);
|
||||
|
||||
// CCcustom
|
||||
UniValue GatewaysInfo(uint256 bindtxid);
|
||||
|
||||
@@ -524,12 +524,29 @@ cJSON *get_rawtransaction(char *refcoin,char *acname,bits256 txid)
|
||||
}
|
||||
else if ( retstr != 0 )
|
||||
{
|
||||
fprintf(stderr,"get_rawtransaction.(%s) error.(%s)\n",acname,retstr);
|
||||
fprintf(stderr,"get_rawtransaction.(%s) %s error.(%s)\n",refcoin,acname,retstr);
|
||||
free(retstr);
|
||||
}
|
||||
return(0);
|
||||
}
|
||||
|
||||
void importaddress(char *refcoin,char *acname,char *depositaddr)
|
||||
{
|
||||
cJSON *retjson; char *retstr;
|
||||
if ( (retjson= get_komodocli(refcoin,&retstr,acname,"importaddress",depositaddr,"","")) != 0 )
|
||||
{
|
||||
printf("importaddress.(%s)\n",jprint(retjson,0));
|
||||
free_json(retjson);
|
||||
}
|
||||
else if ( retstr != 0 )
|
||||
{
|
||||
fprintf(stderr,"importaddress.(%s) %s error.(%s)\n",refcoin,acname,retstr);
|
||||
free(retstr);
|
||||
}
|
||||
return(0);
|
||||
}
|
||||
|
||||
|
||||
void gatewaysmarkdone(char *refcoin,char *acname,bits256 withtxid,char *coin,bits256 cointxid)
|
||||
{
|
||||
char str[65],str2[65],*retstr; cJSON *retjson;
|
||||
@@ -546,6 +563,33 @@ void gatewaysmarkdone(char *refcoin,char *acname,bits256 withtxid,char *coin,bit
|
||||
}
|
||||
}
|
||||
|
||||
int32_t get_gatewaysinfo(char *refcoin,char *acname,char *depositaddr,int32_t *Mp,int32_t *Np,char *bindtxidstr,char *coin,char *oraclestr)
|
||||
{
|
||||
char *oracle,*retstr,*name,*deposit; cJSON *retjson;
|
||||
if ( (retjson= get_komodocli(refcoin,&retstr,acname,"gatewaysinfo",bindtxidstr,"","")) != 0 )
|
||||
{
|
||||
if ( (oracle= jstr(retjson,"oracletxid")) != 0 && strcmp(oracle,oraclestr) == 0 )
|
||||
{
|
||||
if ( jstr(retjson,"coin") != 0 && strcmp(jstr(retjson,"coin"),coin) == 0 && jint(retjson,"N") >= 1 && (deposit= jstr(retjson,"deposit")) != 0 )
|
||||
{
|
||||
*Mp = jint(retjson,"M");
|
||||
*Np = jint(retjson,"N");
|
||||
strcpy(depositaddr,deposit);
|
||||
//printf("(%s)\n",jprint(retjson,0));
|
||||
} else printf("coin.%s vs %s\n",jstr(retjson,"coin"),coin);
|
||||
} else printf("%s != %s\n",oracle,oraclestr);
|
||||
free_json(retjson);
|
||||
}
|
||||
else if ( retstr != 0 )
|
||||
{
|
||||
printf("error parsing get_gatewaysinfo.(%s)\n",retstr);
|
||||
free(retstr);
|
||||
}
|
||||
if ( *Mp <= 0 || *Np <= 0 )
|
||||
return(-1);
|
||||
else return(0);
|
||||
}
|
||||
|
||||
int32_t tx_has_voutaddress(char *refcoin,char *acname,bits256 txid,char *coinaddr)
|
||||
{
|
||||
cJSON *txobj,*vouts,*vout,*sobj,*addresses; char *addr,str[65]; int32_t i,j,n,numvouts,retval = 0;
|
||||
@@ -608,7 +652,7 @@ int32_t coinaddrexists(char *refcoin,char *acname,char *coinaddr)
|
||||
return(num);
|
||||
}
|
||||
|
||||
void update_gatewayspending(char *refcoin,char *acname,char *oraclestxidstr)
|
||||
void update_gatewayspending(char *refcoin,char *acname,char *bindtxidstr,int32_t M,int32_t N)
|
||||
{
|
||||
// check queue to prevent duplicate
|
||||
// check KMD chain and mempool for txidaddr
|
||||
@@ -617,9 +661,9 @@ void update_gatewayspending(char *refcoin,char *acname,char *oraclestxidstr)
|
||||
/// if enough sigs, sendrawtransaction and when it confirms spend marker (txid.2)
|
||||
/// if not enough sigs, post partially signed to acname with marker2
|
||||
// monitor marker2, for the partially signed withdraws
|
||||
cJSON *retjson,*pending,*item; char str[65],*coinstr,*txidaddr,*signeraddr,*withdrawaddr; int32_t i,n,retval,processed = 0; bits256 txid,cointxid,origtxid,zeroid; int64_t satoshis;
|
||||
cJSON *retjson,*pending,*item,*clijson; char str[65],*unspentstr,*coinstr,*txidaddr,*signeraddr,*depositaddr,*withdrawaddr; int32_t i,j,n,retval,processed = 0; bits256 txid,cointxid,origtxid,zeroid; int64_t satoshis;
|
||||
memset(&zeroid,0,sizeof(zeroid));
|
||||
if ( (retjson= get_gatewayspending("KMD",acname,oraclestxidstr)) != 0 )
|
||||
if ( (retjson= get_gatewayspending("KMD",acname,bindtxidstr)) != 0 )
|
||||
{
|
||||
if ( jint(retjson,"queueflag") != 0 && (coinstr= jstr(retjson,"coin")) != 0 && strcmp(coinstr,refcoin) == 0 )
|
||||
{
|
||||
@@ -632,7 +676,7 @@ void update_gatewayspending(char *refcoin,char *acname,char *oraclestxidstr)
|
||||
item = jitem(pending,i);
|
||||
origtxid = jbits256(item,"txid");
|
||||
//process item.0 {"txid":"10ec8f4dad6903df6b249b361b879ac77b0617caad7629b97e10f29fa7e99a9b","txidaddr":"RMbite4TGugVmkGmu76ytPHDEQZQGSUjxz","withdrawaddr":"RNJmgYaFF5DbnrNUX6pMYz9rcnDKC2tuAc","amount":"1.00000000","depositaddr":"RHV2As4rox97BuE3LK96vMeNY8VsGRTmBj","signeraddr":"RHV2As4rox97BuE3LK96vMeNY8VsGRTmBj"}
|
||||
if ( (txidaddr= jstr(item,"txidaddr")) != 0 && (withdrawaddr= jstr(item,"withdrawaddr")) != 0 && (signeraddr= jstr(item,"signeraddr")) != 0 )
|
||||
if ( (txidaddr= jstr(item,"txidaddr")) != 0 && (withdrawaddr= jstr(item,"withdrawaddr")) != 0 && (depositaddr= jstr(item,"depositaddr")) != 0 && (signeraddr= jstr(item,"signeraddr")) != 0 )
|
||||
{
|
||||
if ( (satoshis= jdouble(item,"amount")*SATOSHIDEN) != 0 && (retval= coinaddrexists("KMD",acname,txidaddr)) == 0 )
|
||||
{
|
||||
@@ -641,16 +685,44 @@ void update_gatewayspending(char *refcoin,char *acname,char *oraclestxidstr)
|
||||
if ( bits256_nonz(txid) != 0 && coinaddrexists("KMD",acname,txidaddr) > 0 )
|
||||
{
|
||||
// the actual withdraw
|
||||
cointxid = sendtoaddress(refcoin,"",withdrawaddr,satoshis);
|
||||
if ( bits256_nonz(cointxid) != 0 )
|
||||
if ( strcmp(depositaddr,signeraddr) == 0 )
|
||||
{
|
||||
fprintf(stderr,"withdraw %s %s %s %.8f processed\n",refcoin,bits256_str(str,cointxid),withdrawaddr,(double)satoshis/SATOSHIDEN);
|
||||
gatewaysmarkdone("KMD",acname,origtxid,refcoin,cointxid);
|
||||
processed++;
|
||||
cointxid = sendtoaddress(refcoin,"",withdrawaddr,satoshis);
|
||||
if ( bits256_nonz(cointxid) != 0 )
|
||||
{
|
||||
fprintf(stderr,"withdraw %s %s %s %.8f processed\n",refcoin,bits256_str(str,cointxid),withdrawaddr,(double)satoshis/SATOSHIDEN);
|
||||
gatewaysmarkdone("KMD",acname,origtxid,refcoin,cointxid);
|
||||
processed++;
|
||||
}
|
||||
else
|
||||
{
|
||||
fprintf(stderr,"ERROR withdraw %s %s %s %.8f processed\n",refcoin,bits256_str(str,cointxid),withdrawaddr,(double)satoshis/SATOSHIDEN);
|
||||
}
|
||||
}
|
||||
else
|
||||
else if ( (unspentstr= get_listunspent(refcoin,"",depositaddr)) != 0 )
|
||||
{
|
||||
fprintf(stderr,"ERROR withdraw %s %s %s %.8f processed\n",refcoin,bits256_str(str,cointxid),withdrawaddr,(double)satoshis/SATOSHIDEN);
|
||||
if ( (clijson= get_komodocli("KMD",&retstr2,acname,"gatewaysmultisig",bindtxidstr,bits256_str(str,origtxid),unspentstr)) != 0 )
|
||||
{
|
||||
if ( jint(clijson,"complete") != 0 )
|
||||
{
|
||||
cointxid = komodobroadcast(refcoin,"",clijson2);
|
||||
if ( bits256_nonz(cointxid) != 0 )
|
||||
{
|
||||
fprintf(stderr,"withdraw %s M.%d N.%d %s %s %.8f processed\n",refcoin,M,N,bits256_str(str,cointxid),withdrawaddr,(double)satoshis/SATOSHIDEN);
|
||||
gatewaysmarkdone("KMD",acname,origtxid,refcoin,cointxid);
|
||||
processed++;
|
||||
}
|
||||
}
|
||||
else if ( jint(clijson,"partialtx") != 0 )
|
||||
{
|
||||
// 10000 + ith -> txidaddr
|
||||
txid = komodobroadcast("KMD",acname,clijson2);
|
||||
fprintf(stderr,"%s M.%d of N.%d partialtx %s sent\n",refcoin,M,N,bits256_str(str,txid));
|
||||
processed++;
|
||||
}
|
||||
free_json(clijson);
|
||||
}
|
||||
free(unspentstr);
|
||||
}
|
||||
} else fprintf(stderr,"error sending %s txidaddr.%s -> %s exists.%d\n",acname,txidaddr,bits256_str(str,txid),coinaddrexists(refcoin,acname,txidaddr));
|
||||
}
|
||||
@@ -724,7 +796,7 @@ oraclesdata 17a841a919c284cea8a676f34e793da002e606f19a9258a3190bed12d5aaa3ff 034
|
||||
|
||||
int32_t main(int32_t argc,char **argv)
|
||||
{
|
||||
cJSON *clijson,*clijson2,*regjson,*item; int32_t acheight,i,retval,n,height,prevheight = 0; char *format,*acname,*oraclestr,*bindtxidstr,*pkstr,*pubstr,*retstr,*retstr2,hexstr[4096],refcoin[64]; uint64_t price; bits256 txid;
|
||||
cJSON *clijson,*clijson2,*regjson,*item; int32_t acheight,i,retval,M,N,n,height,prevheight = 0; char *format,*acname,*oraclestr,*bindtxidstr,*pkstr,*pubstr,*retstr,*retstr2,depositaddr[64],hexstr[4096],refcoin[64]; uint64_t price; bits256 txid;
|
||||
if ( argc < 6 )
|
||||
{
|
||||
printf("usage: oraclefeed $ACNAME $ORACLETXID $MYPUBKEY $FORMAT $BINDTXID [refcoin_cli]\n");
|
||||
@@ -744,6 +816,7 @@ int32_t main(int32_t argc,char **argv)
|
||||
printf("only formats of L and Ihh are supported now\n");
|
||||
return(-1);
|
||||
}
|
||||
M = N = 1;
|
||||
acheight = 0;
|
||||
refcoin[0] = 0;
|
||||
while ( 1 )
|
||||
@@ -759,7 +832,13 @@ int32_t main(int32_t argc,char **argv)
|
||||
printf("need to specify path to refcoin's cli as last argv\n");
|
||||
exit(0);
|
||||
}
|
||||
printf("set refcoin <- %s [%s]\n",refcoin,REFCOIN_CLI);
|
||||
if ( get_gatewaysinfo("KMD",acname,depositaddr,&M,&N,bindtxidstr,refcoin,oraclestr) < 0 )
|
||||
{
|
||||
printf("cant find bindtxid.(%s)\n",bindtxidstr);
|
||||
exit(0);
|
||||
}
|
||||
importaddress(refcoin,"",depositaddr);
|
||||
printf("set refcoin %s <- %s [%s] M.%d of N.%d\n",depositaddr,refcoin,REFCOIN_CLI,M,N);
|
||||
}
|
||||
if ( (regjson= jarray(&n,clijson,"registered")) != 0 )
|
||||
{
|
||||
@@ -779,7 +858,7 @@ int32_t main(int32_t argc,char **argv)
|
||||
prevheight = height;
|
||||
acheight = get_coinheight(refcoin,"");
|
||||
printf("%s ht.%d <- %s\n",refcoin,height,hexstr);
|
||||
update_gatewayspending(refcoin,acname,bindtxidstr);
|
||||
update_gatewayspending(refcoin,acname,bindtxidstr,M,N);
|
||||
}
|
||||
free_json(clijson2);
|
||||
}
|
||||
|
||||
@@ -74,6 +74,7 @@ string oracles
|
||||
./c oraclessubscribe 1f1aefcca2bdea8196cfd77337fb21de22d200ddea977c2f9e8742c55829d808 02ebc786cb83de8dc3922ab83c21f3f8a2f3216940c3bf9da43ce39e2a3a882c92 1000
|
||||
f9499d8bb04ffb511fcec4838d72e642ec832558824a2ce5aed87f1f686f8102
|
||||
|
||||
gatewaysbind tokenid oracletxid coin tokensupply M N pubkey(s)
|
||||
./c gatewaysbind a7398a8748354dd0a3f8d07d70e65294928ecc3674674bb2d9483011ccaa9a7a 1f1aefcca2bdea8196cfd77337fb21de22d200ddea977c2f9e8742c55829d808 KMD 100000000000000 1 1 02ebc786cb83de8dc3922ab83c21f3f8a2f3216940c3bf9da43ce39e2a3a882c92
|
||||
e6c99f79d4afb216aa8063658b4222edb773dd24bb0f8e91bd4ef341f3e47e5e
|
||||
|
||||
@@ -281,7 +282,7 @@ bool GatewaysValidate(struct CCcontract_info *cp,Eval *eval,const CTransaction &
|
||||
|
||||
// helper functions for rpc calls in rpcwallet.cpp
|
||||
|
||||
int64_t AddGatewaysInputs(struct CCcontract_info *cp,CMutableTransaction &mtx,CPubKey pk,int64_t total,int32_t maxinputs)
|
||||
/*int64_t AddGatewaysInputs(struct CCcontract_info *cp,CMutableTransaction &mtx,CPubKey pk,int64_t total,int32_t maxinputs)
|
||||
{
|
||||
char coinaddr[64]; int64_t nValue,price,totalinputs = 0; uint256 txid,hashBlock; std::vector<uint8_t> origpubkey; CTransaction vintx; int32_t vout,n = 0;
|
||||
std::vector<std::pair<CAddressUnspentKey, CAddressUnspentValue> > unspentOutputs;
|
||||
@@ -307,7 +308,7 @@ int64_t AddGatewaysInputs(struct CCcontract_info *cp,CMutableTransaction &mtx,CP
|
||||
}
|
||||
}
|
||||
return(totalinputs);
|
||||
}
|
||||
}*/
|
||||
|
||||
int32_t GatewaysBindExists(struct CCcontract_info *cp,CPubKey gatewayspk,uint256 reftokenid) // dont forget to check mempool!
|
||||
{
|
||||
@@ -694,7 +695,7 @@ std::string GatewaysClaim(uint64_t txfee,uint256 bindtxid,std::string refcoin,ui
|
||||
}
|
||||
if ( GetTransaction(deposittxid,tx,hashBlock,false) == 0 )
|
||||
{
|
||||
fprintf(stderr,"cant find bindtxid %s\n",uint256_str(str,bindtxid));
|
||||
fprintf(stderr,"cant find deposittxid %s\n",uint256_str(str,bindtxid));
|
||||
return("");
|
||||
}
|
||||
if ( (depositamount= GatewaysDepositval(tx)) != amount )
|
||||
@@ -709,7 +710,7 @@ std::string GatewaysClaim(uint64_t txfee,uint256 bindtxid,std::string refcoin,ui
|
||||
{
|
||||
if ( inputs > amount )
|
||||
CCchange = (inputs - amount);
|
||||
mtx.vin.push_back(CTxIn(deposittxid,0,CScript()));
|
||||
mtx.vin.push_back(CTxIn(deposittxid,0,CScript())); // triggers EVAL_GATEWAYS validation
|
||||
mtx.vout.push_back(MakeCC1vout(EVAL_ASSETS,amount,mypk));
|
||||
if ( CCchange != 0 )
|
||||
mtx.vout.push_back(MakeCC1vout(EVAL_ASSETS,CCchange,gatewayspk));
|
||||
@@ -836,3 +837,53 @@ UniValue GatewaysPendingWithdraws(uint256 bindtxid,std::string refcoin)
|
||||
return(result);
|
||||
}
|
||||
|
||||
std::string GatewaysMultisigUpdate(struct CCcontract_info *cp,int32_t &complete,int32_t &partialtx,CPubKey mypk,int32_t ith,uint256 withdrawtxid,uint8_t M,uint8_t N,char *unspentstr)
|
||||
{
|
||||
CMutableTransaction mtx; cJSON *unspents; std::string hex,rawtx; CScript opret; uint64_t txfee = 10000;
|
||||
complete = partialtx = 0;
|
||||
{
|
||||
// iterate txidaddr, extract signatures!
|
||||
// iterate for sigs depth and find the deepest
|
||||
// if not already a signer, add signature and post to next
|
||||
// if first one, then create a rawtx and sign it, ie. depth 1
|
||||
// if fully signed, broadcast
|
||||
|
||||
return(FinalizeCCTx(0,cp,mtx,mypk,txfee,opret));
|
||||
}
|
||||
return(hex);
|
||||
}
|
||||
|
||||
UniValue GatewaysMultisig(uint64_t txfee,std::string refcoin,uint256 bindtxid,uint256 withdrawtxid,char *unspentstr)
|
||||
{
|
||||
UniValue result(UniValue::VOBJ); std::string coin,hex; char str[67],numstr[65],depositaddr[64],gatewaysassets[64]; uint8_t M,N; std::vector<CPubKey> pubkeys; uint8_t taddr,prefix,prefix2; uint256 tokenid,oracletxid,hashBlock; CTransaction tx; CPubKey Gatewayspk,mypk; struct CCcontract_info *cp,C; int32_t i,n,complete,partialtx; int64_t totalsupply;
|
||||
cp = CCinit(&C,EVAL_GATEWAYS);
|
||||
if ( txfee == 0 )
|
||||
txfee = 10000;
|
||||
complete = partialtx = 0;
|
||||
mypk = pubkey2pk(Mypubkey());
|
||||
Gatewayspk = GetUnspendable(cp,0);
|
||||
_GetCCaddress(gatewaysassets,EVAL_ASSETS,Gatewayspk);
|
||||
if ( GetTransaction(bindtxid,tx,hashBlock,false) != 0 )
|
||||
{
|
||||
depositaddr[0] = 0;
|
||||
if ( tx.vout.size() > 0 && DecodeGatewaysBindOpRet(depositaddr,tx.vout[tx.vout.size()-1].scriptPubKey,coin,tokenid,totalsupply,oracletxid,M,N,pubkeys,taddr,prefix,prefix2) != 0 && M <= N && N > 1 && coin == refcoin )
|
||||
{
|
||||
n = pubkeys.size();
|
||||
for (i=0; i<n; i++)
|
||||
if ( mypk == pubkeys[i] )
|
||||
break;
|
||||
if ( i != n )
|
||||
{
|
||||
hex = GatewaysMultisigUpdate(cp,complete,partialtx,mypk,i,withdrawtxid,M,N,unspentstr);
|
||||
} else fprintf(stderr,"not one of the multisig signers\n");
|
||||
}
|
||||
}
|
||||
// complete:1 -> send tx to refcoin withdraw complete
|
||||
// partialtx:1 -> send partialsig to txidaddr, satoshis 10000 + ith pubkey + 1
|
||||
result.push_back(Pair("result","success"));
|
||||
result.push_back(Pair("coin",refcoin));
|
||||
result.push_back(Pair("complete",complete));
|
||||
result.push_back(Pair("partialtx",partialtx));
|
||||
result.push_back(Pair("hex",hex));
|
||||
return(result);
|
||||
}
|
||||
|
||||
@@ -3375,6 +3375,15 @@ bool static DisconnectTip(CValidationState &state, bool fBare = false) {
|
||||
CBlock block;
|
||||
if (!ReadBlockFromDisk(block, pindexDelete,1))
|
||||
return AbortNode(state, "Failed to read block");
|
||||
{
|
||||
int32_t prevMoMheight; uint256 notarizedhash,txid;
|
||||
komodo_notarized_height(&prevMoMheight,¬arizedhash,&txid);
|
||||
if ( block.GetHash() == notarizedhash )
|
||||
{
|
||||
fprintf(stderr,"DisconnectTip trying to disconnect notarized block at ht.%d\n",(int32_t)pindexDelete->nHeight);
|
||||
return(false);
|
||||
}
|
||||
}
|
||||
// Apply the block atomically to the chain state.
|
||||
uint256 anchorBeforeDisconnect = pcoinsTip->GetBestAnchor();
|
||||
int64_t nStart = GetTimeMicros();
|
||||
|
||||
Reference in New Issue
Block a user