|
Declaration of Independence
We the asset holders hereby declare our independence from any single blockchain.
An open and jointly developed specification on cross chain atomic asset transfers will be developed. Any current or future blockchain is invited to join.
Each blockchain will need to not only promise protections for asset holder interests, they need to live up to them. Otherwise, all the assets will simply move to blockchains that do.
Additionally, once assets become mobile, the different blockchains will start to differentiate themselves with better features for the assets. Better liquidity, better fees, more functions.
This ability for the asset holder to choose where their assets reside is the only protection from the tyranny of the hardfork.
Traditional companies trade on multiple exchanges, it is time for decentralized assets to distribute the blockchains they exist on. Maintaining a constant total number of assets issued across all blockchains will allow maintaining a fixed total, but only if each participating blockchain follows strict rules on asset issuance.
The reality is that everything in crypto trades against BTC. One of the conditions for cross chain assets is the ability to trade directly against BTC, preferably native BTC and not a derivative. I will be working on a reference implementation as a first draft and look forward to collaborate with all other asset oriented projects.
This is an interop standards effort and it needs to be blockchain agnostic and asset centric.
James
P.S. I am not asking for any funds or investments.
|
|
|
|
From PM, because this is an important point that others might not realize: Well if an attacker runs a DE and I dont attack back, then that DE works, so at least there will be one DE that works
The attacker can set the effective minimum fee (even it is multiples higher than the advertized fee due to jammed trades), by ratio of how much they attack their own (or another's) DE. So in essence the attacker can shut down all DE, by making sure he earns just enough on his DE to offset his attack costs on other DE, but this is a moving target that eventually ends up in all users giving up and abandoning DEs. There only needs to be one attacker. Edit: I think I offered a solution upthread. I didnt fully understand you solution. can you describe it in more detail? James |
|
|
|
|
I think it is more a matter of decentralized solutions that transact in crypto.
Since BTC is the most liquid crypto, it is the natural one to use for crypto transactions. As long as ALT/BTC pairs are what the market trades, this allows converting from ALT0 <-> ALT2 via BTC as the most efficient path.
So, not sure how important it is if <Use Case App> is running on blockchain A, B, or C, the transactions flow through BTC.
Like the DE usecase, it has BTC on one side and all the other altcoins on the other side.
The decentralized poker usecase, the gameplay really cannot be on any blockchain due to speed and space constraints, so the blockchain uses will need to be the function of the cashier.
The 10 minute blocktime of BTC prevents its usage directly for many use cases. So if a 1:1 price peg to BTC is required and the 24+ hours latency is not a problem, then it seems a side chain can have whatever characteristics desired. It is definitely an interested method.
BTC -> (~24hrs) -> sidechain ... [side chain functions] ... -> (~24hrs) BTC
BTC -> (~4hrs worst case, 3 confirms normally) atomic swap -> altcoin ... [altcoin functions] -> atomic swap back
I think I have the above timings correct. The difference going to the altcoin is there is no price peg. So there are issues with both appoaches.
I like:
(realtime app) <-> BTC cashier
The above model puts the speed and space consuming data flow internal to the realtime app and avoids bloating the BTC blockchain and if the app denominates in BTC, it avoids needing a peg
James
|
|
|
|
@TierNolan As the implementation is filling out, I found another minor attack vector, the slippage attack. Assuming all other parts of the protocol is followed, there is just one place where one side is granting the other an at the money put option without paying anything for this. Some sort of black-scholes option premium is needed. Scenario: Alice and Bob agree to trade ALT at 0.02 BTC We get to where Bob's payment has confirmed and he is waiting for Alice to send payment. Now Alice runs a modified client that is checking poloniex to wait until the price goes below 0.02 until sending the response. In half the cases the timeout is reached, but as long as the slippage is more than the fee, Alice has gained. This is why the shorter the time window to complete the better, but since BTC blocktimes are unpredictable, I think 1 hour is the shortest time we can set the altcoin sides timeout and I am still not sure what to do about the +/-2 hours leeway on bitcoin timestamps and how that affects CLTV http://www.fintools.com/resources/online-calculators/options-calcs/options-calculator/using volatility of 25% and 5% riskless interest rate, a one day at the money put option's value us about 0.5%, which is more than 3 times the fee. So actually at the one hour timeframes the 0.13% fee is actually right around the put option value! So maybe this isnt a problem after all. Maybe Alice needs to pay a bit higher fee for the option premium in addition to the insurance fee for the cut and choose. I think if Alice paid the same value fee for BTC and altcoin, that takes care of this asymmetry. Bob has a much weaker slippage attack surface. He is not getting a call option, but some sort of hybrid (not sure of name, maybe a half straddle butterfly) If price goes against him, he delays sending, but then Alice wont complete so he wont gain, but now Alice paid for the put option and not benefiting from it... OK, so this needs some tweaking of fees, maybe an extra one inserted into the protocol, but the shorter the timeframe the smaller this problem is, so I want to get as streamlined of an ordermatch working first James |
|
|
|
I told you I don't understand Bitcoin op codes, therefor I don't understand your post. Also you said the point of cut and choose is when CLTV is not available. But then you using CLTV in your example above  The protocol puts all the fancy opcodes in the bitcoin side, only the basic scripts are assumed to work on the altcoin side |
|
|
|
The coin days requirement should be reserved for usage by user option when there is an ongoing attack, as otherwise new users wont be able to trade.
Allow me to correct you on this non-sequitor. The newness of a user of a decentralized exchange doesn't require that user's UXTO is newly acquired. I was thinking of someone that just got their first BTC locally. wouldnt that be too young to be used? maybe i dont understand the intended coinage well enough. If we assume that a lot of new users will be using the DE, they will be coming from the CE. And maybe they never had a local wallet, so they do a withdraw. patiently wait the confirms so it is in the wallet, then start a trade (after all they are doing this to use the DE) and then told "sorry you have to wait X amount of time since your dont have the right time of utxo" I really want to avoid having what is potentially a mainstream real world case have such an error message to be expected James You are building a DE so that should mean that users have some coins on a block chain that they wish to trade. Who knows how long ago they acquired those coins. The Coin Days Destroyed is the time (# of blocks) elapsed since the UXTO was created. Since this is suggested to be a user configurable setting which they set only on their own decentralized client (which filters which counter parties they accept to start the DE protocol), then user whose UXTO is very young, can set the threshold so their UXTO fulfills the chosen threshold. If the threshold isn't high enough, they incur more risk of being jammed. But also note that while they are being jammed, their UXTO is aging, so they can continually increase their chosen threshold if necessary to foil an attacker. There is no disadvantage to offering the feature. An error msg will never be shown. The only effect is the number of available counter parties may shrink as the threshold is raised, as well the risk of jam attack decreases as the threshold is raised. There a many people who have dozens of different altcoins and no wallet for any of them, or just a few. In fact most people fall in that category, where they have a few alts they have local wallets and still they buy alts on exchanges they dont have wallets for, with the intent of converting them before withdrawing. Good point that it can be done without any error messages, but just a gradual increase in the potential matches that are possible. Maybe we can have a sunrise type of graphics to show that the longer you wait the more trades are possible James |
|
|
|
Separately, for all failed trades, the keypairs commitments are verified and any violations detected are broadcast to the network. (Or all the peers can monitor all the other trades)
Violations of cut and choose mean that the party doesn't publish the keys. That means you can't prove it. I am of the position that if you dont publish the keys you forfeit the fee. It seems if one side just stops for whatever reason, they cant prove they didnt cheat. So it is a reverse logic of guilty until proven innocent. It is all automated so as long as they run unmodified software, the only time it would happen is if they get disconnected for the entire 2hour period. If the trade is big enough, there is hopefully enough time to get to a local wifi hotspot to complete the trade. Why wouldnt this approach work? What you need to do is show that the person agreed to pay the fee and then refused to build the transaction.
The proof would be the signed fee transaction but missing the other party's signature. The accused party could then respond by publishing the full transaction and "clear their name".
By providing the final privkey during the protocol, it is proven that that person didnt cheat. We probably need a few cases to deal with Bob bailing out before Alice had to disclose her privkey, probably via some blame states. If fraud was successful, then you could publish the locked output and show that the published private key didn't match the committed public key.
Certainly if a fraud is a success, then this is broadcast to all the nodes. I think even any delay from the earliest time a privkey could have been disclosed should send out warnings. That way within a few blocks any funny business is detected and everyone warned. By using the sum of all fees paid by an account as insurance, then in the event that account steals from another, we could support an insurance claim (up to the limit of the fees paid by the attacker). This way as long as users can see the total fees paid by the other party, they will know how much coverage there is. Granted there are issues about an account building up large amounts of fees and then doing a large number in parallel, but that assumes there are that many that will match up at the same time. I guess this could be fixed by broadcasting all pending trades and adjusting the available insurance. Now we end up with just some propagation based edge cases where not all the pending amounts have been propagated before a trade is agreed to, right at the critical moment. It feels like it is getting to edge cases that can be handled James |
|
|
|
The coin days requirement should be reserved for usage by user option when there is an ongoing attack, as otherwise new users wont be able to trade.
Allow me to correct you on this non-sequitor. The newness of a user of a decentralized exchange doesn't require that user's UXTO is newly acquired. I was thinking of someone that just got their first BTC locally. wouldnt that be too young to be used? maybe i dont understand the intended coinage well enough. If we assume that a lot of new users will be using the DE, they will be coming from the CE. And maybe they never had a local wallet, so they do a withdraw. patiently wait the confirms so it is in the wallet, then start a trade (after all they are doing this to use the DE) and then told "sorry you have to wait X amount of time since your dont have the right time of utxo" I really want to avoid having what is potentially a mainstream real world case have such an error message to be expected James |
|
|
|
Any way, I think I have thought of a solution for DE.
The key is to identify the attacker immediately so that all decentralized parties can apply my blocking "Coin Days Destroyed" suggestion upthread.
So change the protocol is the provider of the hash sends to the trade's counter party to sign it (hashed with the other party's UXTO address) so the counter party's UXTO can be identified. Then the hash provider (the potential jamming victim) posts this information in a timed refundable transaction to the block chain (spending to the payee contingent on releasing the hash). If the attacker never posts the reciprocal transaction on the other block chain, this enables anyone to identify that attacker and apply the Coin Days Destroyed filtering that I proposed upthread.
Note this eliminates the need for any fee. But I assume you can find some justification for a fee, so as perhaps keeping your source code for the DE app closed source and/or offering a centralized fee structure for matching orders, limit orders, etc.. You won't be able to steal funds, which afaik is the most significant advantage of DE over CE.
I think we are both circling around (converging?) to a similar type of solution. The cut and choose aspect is not requiring any details about bitcoin scripts. The idea is that one side commits to a large number of keypairs, the other side picks a random one and then the original side sends the privkeys to all keypairs except for the chosen one. Probabilistically as long as the cost of the fee (which is required) must be more than the expected return. Current settings are 1000 keypairs and 1/777 as the fee, so there is about a 13% negative cashflow for anybody that tries to cheat on a large scale. Now whether preventing economically motivated attackers is enough or not, clearly it is a necessary problem to solve completely. With both sides doing the above, each side has a privkey that can be used. I call it privAm and privBn, for Alice m and Bob n. These privkeys enable proof that you didnt cheat by sneaking in a fake keypair. It cannot be disclosed until after the protocol is past all the possible refund claims and the actual payments as they all hinge on these privkeys. To commit to them, a hash of the privkey is included in the protocol for each side, before any big money is committed. For now, let us agree that a vandalism oriented attack can tie up other's fees, but allowing the victim to recoup the fee for failed trades is adequate. It is 0.13% of the trade, so for the normal user not a big deal, but this small fee adds up to the friction that makes cheating uneconomical. The enforcement of fee collection for only the swaps that complete is by requiring the InstantDEX account to proactively spend the fees using both privAm and privBn, which are disclosed in the cases of successful swaps. [there might be some cases where a failed swap also ends up disclosing both privkeys, but not sure if it is even possible. if it is an additional time window would need to be created]. After the time window (probably 24hrs), both bob and alice can recoup their fees. By doing it once per day, there can be a single fee reclaim tx to aggregate all fees from the failed trades. This reduces the bitcoin txfees needed and a user can actually delay for however long they want. Might need to add another secret to the fee reclaim script to prevent the other party from reclaiming, but the high level concept is that if the trade goes through, the fee is paid and if not the fee is reclaimed. By making it so the fees are not sent until after both sides commit to their set of keypairs, we can identify the attacker. The method is for the field product of the privkeys to be made part of the protocol. We have the privAm * (privkeys other than privA) and the hash(privAm), so given the former two we can verify the hashes match. The privAm is disclosed after it is not a sensitive secret anymore. If cheating was going on, the hashes wont match and the corresponding party immediately punished. As soon as a failed proof of commitment is detected, this violation can be broadcast to all the nodes, who immediately update reputation score. With such a realtime feedback, it does not seem likely that an attacker can do any prolonged attack from the same address. Sybil attacks are reduced in effect dramatically if the nodes all know the historical performance of that account. Zero activity would mean potential attacker. non-zero activity (and by activity I mean fees paid to eliminate any advantage from self-trading) would enable the attacker to start attacking, but after the first failure to disclose, he is blacklisted in realtime. Similarily attackers who just want to tie up your funds for the deposit or payment (not the fee) it is a different attack. They cant both follow the keypairs commitment protocol and also prevent the trade from completing as in order to prove your commitment, you need to disclose the privAm or privBn. The coin days requirement should be reserved for usage by user option when there is an ongoing attack, as otherwise new users wont be able to trade. But it would rapidly exhaust the utxo the attacker can use in addition to being blacklisted, and losing funds. I believe the following fee policy solves the incentives issue, especially penalizing the attacker. Fee policy: 1. When both sides have committed to their set of keypairs, the fee is paid 2. If the trade completes, the fee goes to InstantDEX account 3. If the trade doesnt complete the party that followed the protocol can recover the fee With the above three rules, there is not even a fee tied up, until both parties have committed. Once committed, both parties will have to complete the protocol or get flagged and I think a penalty of forfeiting the fee is needed to enforce economic unviability for attacks. pseudo-code for a payment script would be: if ( elapsedtime < day && privAm disclosed && privBn disclosed ) InstantDEX claims the fees; // this is the case where trade has been completed else if ( elapsedtime >= day ) { if ( no privAm ) Bob claims his fee else if ( no privBn ) Alice claims her fee } Separately, for all failed trades, the keypairs commitments are verified and any violations detected are broadcast to the network. (Or all the peers can monitor all the other trades) Any feedback regarding economically motivated attackers is much appreciated. James |
|
|
|
getting back on track for the atomic swap. With the change in fee handling, I had to add some states and I realized I had a few missing. Working backwards from all the terminal states, I think we have: // if all goes well both alice and bob get to claim the other's payments
s = instantdex_statecreate(s,n,"ALICE_claimedbtc",ALICE_claimbtcfunc,0,0,0,0);
instantdex_addevent(s,*n,"ALICE_claimedbtc","aclfound","poll","BTC_cleanup");
instantdex_addevent(s,*n,"ALICE_claimedbtc","poll","poll","ALICE_claimedbtc");
s = instantdex_statecreate(s,n,"BOB_depclaimed",BOB_reclaimfunc,0,0,0,0); // deposit back
instantdex_addevent(s,*n,"BOB_depclaimed","brefound","poll","BTC_cleanup");
instantdex_addevent(s,*n,"BOB_depclaimed","poll","poll","BOB_depclaimed");
s = instantdex_statecreate(s,n,"BOB_claimedalt",BOB_claimaltfunc,0,0,0,0);
instantdex_addevent(s,*n,"BOB_claimedalt","bclfound","poll","BOB_depclaimed");
instantdex_addevent(s,*n,"BOB_claimedalt","poll","poll","BOB_claimedalt");
// if things go wrong, bob gets his deposit and fee back
s = instantdex_statecreate(s,n,"BOB_feereclaimed",BOB_feereclaimfunc,0,0,0,0);
instantdex_addevent(s,*n,"BOB_feereclaimed","bfrfound","poll","BTC_cleanup");
instantdex_addevent(s,*n,"BOB_feereclaimed","poll","poll","BOB_feereclaimed");
s = instantdex_statecreate(s,n,"BOB_reclaimed",BOB_reclaimfunc,0,0,0,0); // deposit back
instantdex_addevent(s,*n,"BOB_reclaimed","brefound","poll","BOB_feereclaimed");
instantdex_addevent(s,*n,"BOB_reclaimed","poll","poll","BOB_reclaimed");
// if things go wrong, alice reclaims her altpayment or claims the deposit and then fee
s = instantdex_statecreate(s,n,"ALICE_feereclaimed",ALICE_feereclaimfunc,0,0,0,0);
instantdex_addevent(s,*n,"ALICE_feereclaimed","afrfound","poll","BTC_cleanup");
instantdex_addevent(s,*n,"ALICE_feereclaimed","poll","poll","ALICE_feereclaimed");
s = instantdex_statecreate(s,n,"ALICE_reclaimed",ALICE_reclaimfunc,0,0,0,0); // altpayment
instantdex_addevent(s,*n,"ALICE_reclaimed","arefound","poll","ALICE_feereclaimed");
instantdex_addevent(s,*n,"ALICE_reclaimed","poll","poll","ALICE_reclaimed");
s = instantdex_statecreate(s,n,"ALICE_depositclaimed",ALICE_claimdepositfunc,0,0,0,0); // altpayment
instantdex_addevent(s,*n,"ALICE_depositclaimed","adpfound","poll","ALICE_feereclaimed");
instantdex_addevent(s,*n,"ALICE_depositclaimed","poll","poll","ALICE_depositclaimed");
// end terminal [BLOCKING] states
// need to create states before they can be referred to, that way a one pass FSM compile is possible
s = instantdex_statecreate(s,n,"BOB_sentprivs",BTC_waitprivsfunc,0,"BTC_cleanup",0,0);
s = instantdex_statecreate(s,n,"BOB_waitfee",BOB_waitfeefunc,0,"BTC_cleanup",0,0);
s = instantdex_statecreate(s,n,"BOB_sentdeposit",BOB_waitBTCalttxfunc,0,"BOB_reclaimed",0,0);
s = instantdex_statecreate(s,n,"BOB_altconfirm",BOB_waitaltconfirmfunc,0,"BOB_reclaimed",0,0);
s = instantdex_statecreate(s,n,"BOB_sentpayment",BOB_waitprivMfunc,0,"BOB_reclaimed",0,0);
s = instantdex_statecreate(s,n,"ALICE_sentprivs",BTC_waitprivsfunc,0,"BTC_cleanup",0,0);
s = instantdex_statecreate(s,n,"Alice_waitfee",ALICE_waitfeefunc,0,"BTC_cleanup",0,0);
s = instantdex_statecreate(s,n,"ALICE_waitdeposit",ALICE_waitdepositfunc,0,"BTC_cleanup",0,0);
s = instantdex_statecreate(s,n,"ALICE_sentalt",ALICE_waitBTCpaytxfunc,0,"ALICE_reclaimed",0,0);
s = instantdex_statecreate(s,n,"ALICE_waitconfirms",ALICE_waitpayconf_or_bobreclaimfunc,0,"ALICE_reclaimed",0,0);
if ( 0 ) // following are implicit states and events handled externally to setup datastructures
{
//s = instantdex_statecreate(s,n,"BOB_idle",BTC_idlefunc,0,0,0);
//s = instantdex_statecreate(s,n,"ALICE_idle",BTC_idlefunc,0,0,0);
instantdex_addevent(s,*n,"BOB_idle","usrorder","BTCoffer","BOB_sentoffer"); // send deck
instantdex_addevent(s,*n,"ALICE_idle","usrorder","BTCoffer","ALICE_sentoffer");
instantdex_addevent(s,*n,"BOB_idle","BTCoffer","BTCdeckC","BOB_gotoffer"); // send deck + Chose
instantdex_addevent(s,*n,"ALICE_idle","BTCoffer","BTCdeckC","ALICE_gotoffer");
}
// after offer is sent, wait for other side to choose and sent their deck, then send privs
s = instantdex_statecreate(s,n,"BOB_sentoffer",BTC_waitdeckCfunc,0,"BTC_cleanup",0,1);
s = instantdex_statecreate(s,n,"ALICE_sentoffer",BTC_waitdeckCfunc,0,"BTC_cleanup",0,1);
instantdex_addevent(s,*n,"BOB_sentoffer","BTCdeckC","BTCprivC","BOB_sentprivs"); // send privs + Chose
instantdex_addevent(s,*n,"ALICE_sentoffer","BTCdeckC","BTCprivC","ALICE_sentprivs");
// gotoffer states have received deck and sent BTCdeckC already (along with deck)
s = instantdex_statecreate(s,n,"BOB_gotoffer",BTC_waitprivCfunc,0,"BTC_cleanup",0,1);
s = instantdex_statecreate(s,n,"ALICE_gotoffer",BTC_waitprivCfunc,0,"BTC_cleanup",0,1);
instantdex_addevent(s,*n,"BOB_gotoffer","BTCprivC","BTCprivs","BOB_sentprivs"); // send privs
instantdex_addevent(s,*n,"ALICE_gotoffer","BTCprivC","BTCprivs","ALICE_sentprivs");
// to reach sentprivs, all paths must have sent/recv deck and Chose and verified cut and choose
s = instantdex_statecreate(s,n,"BOB_sentprivs",BTC_waitprivsfunc,0,"BTC_cleanup",0,0);
instantdex_addevent(s,*n,"BOB_sentprivs","BTCprivs","poll","BOB_waitfee");
s = instantdex_statecreate(s,n,"ALICE_sentprivs",BTC_waitprivsfunc,0,"BTC_cleanup",0,0);
instantdex_addevent(s,*n,"ALICE_sentprivs","BTCprivs","poll","Alice_waitfee");
// [BLOCKING: fee] Bob waits for fee and sends deposit when it appears
s = instantdex_statecreate(s,n,"BOB_waitfee",BOB_waitfeefunc,0,"BTC_cleanup",0,0);
instantdex_addevent(s,*n,"BOB_waitfee","feefound","BTCdeptx","BOB_sentdeposit");
instantdex_addevent(s,*n,"BOB_waitfee","poll","poll","BOB_waitfee");
// [BLOCKING: fee and deposit] Alice waits for fee and then waits for deposit to confirm and sends altpayment
s = instantdex_statecreate(s,n,"Alice_waitfee",ALICE_waitfeefunc,0,"BTC_cleanup",0,0);
instantdex_addevent(s,*n,"Alice_waitfee","feefound","poll","ALICE_waitdeposit");
instantdex_addevent(s,*n,"Alice_waitfee","poll","poll","Alice_waitfee");
s = instantdex_statecreate(s,n,"ALICE_waitdeposit",ALICE_waitdepositfunc,0,"BTC_cleanup",0,0);
instantdex_addevent(s,*n,"ALICE_waitdeposit","depfound","BTCalttx","ALICE_sentalt");
instantdex_addevent(s,*n,"ALICE_waitdeposit","poll","poll","ALICE_waitdeposit");
// [BLOCKING: BTCalttx and altfound] now Bob's turn to make sure altpayment is confirmed and send real payment
s = instantdex_statecreate(s,n,"BOB_sentdeposit",BOB_waitBTCalttxfunc,0,"BOB_reclaimed",0,0);
instantdex_addevent(s,*n,"BOB_sentdeposit","BTCalttx","poll","BOB_altconfirm");
s = instantdex_statecreate(s,n,"BOB_altconfirm",BOB_waitaltconfirmfunc,0,"BOB_reclaimed",0,0);
instantdex_addevent(s,*n,"BOB_altconfirm","altfound","BTCpaytx","BOB_sentpayment");
instantdex_addevent(s,*n,"BOB_altconfirm","poll","poll","BOB_altconfirm");
// [BLOCKING: BTCpaytx] now Alice's turn to make sure payment is confrmed and send in claim or see bob's reclaim and reclaim
s = instantdex_statecreate(s,n,"ALICE_sentalt",ALICE_waitBTCpaytxfunc,0,"ALICE_reclaimed",0,0);
instantdex_addevent(s,*n,"ALICE_sentalt","BTCpaytx","poll","ALICE_waitconfirms");
s = instantdex_statecreate(s,n,"ALICE_waitconfirms",ALICE_waitpayconf_or_bobreclaimfunc,0,"ALICE_reclaimed",0,0);
instantdex_addevent(s,*n,"ALICE_waitconfirms","bobfound","poll","ALICE_reclaimed");
instantdex_addevent(s,*n,"ALICE_waitconfirms","payfound","BTCprivM","ALICE_claimedbtc");
instantdex_addevent(s,*n,"ALICE_waitconfirms","poll","poll","ALICE_waitconfirms");
// [BLOCKING: privM] Bob waits for privM either from Alice or alt blockchain
s = instantdex_statecreate(s,n,"BOB_sentpayment",BOB_waitprivMfunc,0,"BOB_reclaimed",0,0);
instantdex_addevent(s,*n,"BOB_sentpayment","btcfound","BTCdone","BOB_claimedalt");
instantdex_addevent(s,*n,"BOB_sentpayment","BTCprivM","BTCdone","BOB_claimedalt");
instantdex_addevent(s,*n,"BOB_sentpayment","poll","poll","BOB_sentpayment");
The BTC_cleanup state is the ultimate destination for all statemachines and it takes care of cleaning up memory, removing from active queues, adding to trade history, etc. Basically, if all goes well we just have both alice and bob making their corresponding claims and the FSM leading into those states seems pretty complete. All the above are states after the corresponding tx has been claimed, these tx are side effects automatically invoked at the appropriate state transitions. Maybe it is a good idea to have a way to table drive those too, but I think there is very little leeway as to when any tx can be done. The error states look like Bob reclaims deposit and fee (not sure if there is another possible path?) and Alice has two (reclaim altpayment and fee) or (claim deposit and fee) Hopefully I didnt miss any terminal states and once all these are set, then finalizing the events that transition into these states will finalize the FSM to handle all possible error paths. James |
|
|
|
CSV doesnt exist yet, but isnt there a BIP for it that is pending with high likelihood it will get adopted?
There is a BIP... and no released software that implements it, no implementation of the soft-fork for it yet, etc. (as you may note, the deployment section of the BIP is empty.) I didnt see anywhere in the CSV BIP that you can only use it with RBF enabled. Without replacement, someone could announce a inferior sequenced spend first and block the superior sequence spend; undermining the intended operation. The op_code would still "work" but wouldn't achieve the intended effect as reliably. It just feels very lopsided to forever prevent any other sequenceids without RBF.
I think there might be misunderstanding on this point. Opt-in replacement is just local node policy-- virtually every release of Bitcoin Core has twiddled policy in some way or another, local policy is invisible to the blockchain, and there is nothing forever about it in any way. As I understand it, if things go live as it is, It's already "live"; in that there appears to be a non-totally negligible amount of hashpower running it. There is no activation or enforcement of it-- it's inherently unenforceable as it is purely local policy. then to maintain backward compatibility we would be stuck with RBF enabled for anything but -1 and -2 No-- policy can, and is, pretty liberally changed between versions. It's generally more compatible and more safe to have things go from replaceable to non-replaceable; and every proposed usage of the sequence field (short of ones that turn stuff totally unrelated data into it) seen so far involves some kind of replacement (if not exactly the BIP125 kind). Thanks, makes sense. I had some cases of wanting to store some arbitrary data in the sequenceid field, but it sounds like that is a bad idea James |
|
|
|
Huh? Sequence numbers work precisely as documented (they currently don't do much of anything; though BIP68 seeks to change that...). CSV is a very new proposal, why did you think it was active on mainnet?
I probably looked at the wrong documentation? The official definition: "A number intended to allow unconfirmed time-locked transactions to be updated before being finalized; not currently used except to disable locktime in a transaction" If you read the above definition and dont realize that "intended" means that the entire part about unconfirmed time-locked transactions is irrelevant, it is quite easy to get confused. Also, bitcoinj documents micropayment channels and it uses increasing sequenceids. Assuming the OP is correct, it appears to contradict the bitcoinj documented behavior. If two transactions spend the same outputs, then the miner is supposed to pick the transaction (input) with the higher sequence number. This cannot be enforced and so, the miner would probably pick the one with the highest fees
Additionally, each input has a sequenceid field, its only current function is to toggle locktime on/off, but there is only one locktime per tx. The many toggles all operating on the same locktime is another confusing part. I assume that for SIGHASH_ALL, if any sequenceids are not -1 locktime is on, or is it off, or do all have to have the same. and for SIGHASH_SINGLE I have no idea how it is supposed to work. I doubt I am the only one confused by all this and the only reason I need to know the details is because I am writing a fullnode from scratch so I need to be able to handle how it has been done historically. James |
|
|
|
Reindexing exists exclusively because the local state may have become corrupted. Trusting the state of a corrupted node is not what you really want to do in a reindex.
Specifically, prior errors in signature validation (nodes not updated for soft-forks or nodes run with an incompatible OpenSSL update) caused nodes to both accept and reject signatures that they shouldn't have accepted. A reindex currently clears that state.
On a fast host a reindex for me takes under three hours; so that puts an absolute upper bound on the improvement possible.
The bigger question is why are you reindexing in the first place?
I think the general direction in Bitcoin Core is a complete removal of checkpoints or anything resembling them. Other fixes have no largely mooted their original utility, and they have reliably caused severe misunderstandings of the security model (including, unfortunately, in academic papers) which have been harmful far beyond the narrow advantages they provide.
Syncing the entire chain and building the data structures from scratch in 30 minutes feels like a pretty not-narrow advantage. I used to feel the blockchain size was a big problem, but now I can parallel stream process the entire blockchain, it is not a problem at all. On a good connection 500mbps, it resyncs over lunch. Even on a typical home connection of 20mbps, it syncs in 6hrs. In order to achieve this I had to make everything go in parallel and since it is all verified locally I didnt see any problems. James |
|
|
|
what about CHECKSEQUENCEVERIFY? That appears to be broken by this as there is no dynamic range available for different sequence values. And relative block addressing is also broken [or forced to use RBF, which is same as broken to many]
CSV doesn't exist yet; but sequence locks generally _require_ replacement in order to be usable: Otherwise someone could race with a less mature sequence and mempool preclude the more mature sequence. I believe the rational in the design is that any transaction which is not marked _final_ will ultimately be subject to some kind of replacement. The conservative behavior for wallets that don't understand the details is that they should consider anything non-final ... as... non-final. As other use cases come up the policy could be further restricted to specify what kinds of replacement should happen in what cases. BIP125 is very generic, which means that further changes to limit it's behavior are less likely to create surprise exposure for anyone. Confused... CSV doesnt exist yet, but isnt there a BIP for it that is pending with high likelihood it will get adopted? I didnt see anywhere in the CSV BIP that you can only use it with RBF enabled. Is there any way to reserve more than just -1 and -2 as exempt from RBF. There is already a special case needed in the code, so there could be a constant you compare against #define RBF_DISABLED_RANGE -65536 It just feels very lopsided to forever prevent any other sequenceids without RBF. maybe that is the intent? Even with 16 bits at the top, that provids some amount of flexibility. As I understand it, if things go live as it is, then to maintain backward compatibility we would be stuck with RBF enabled for anything but -1 and -2. James |
|
|
|
It seems what ever design you contemplate employing a fee can always be gamed by an attacker so that he pays no cost.
The attacker can make his own DE and receive the fees. So then he attacks the other DEs (which are honest) 100% of the time but doesn't attack his own DE (or attacks he own less frequently) thus all users migrate to his DE. Thus he is losing much less in attack fees than he is gaining from fees.
Since more than one attacker can do this to each other, no one will use DE.
P.S. I knew that there would be a leak in fees that would maintain my conclusion that DE is fundamentally impossible. Sorry when I come to these sort of generative essence conclusions they stick.
By this logic no cryptocoin would exist. Instead of all out war all the time, maybe some sort of truce would be made? Why would everyone running a DE want to spend all that time attacking the other DE's just to get attacked back and then nobody's works. Seems like MAD. I notice your attack scenarios are getting more and more convoluted as now the attacker needs to run a DE themselves to make it even a potential issue. So things are improving. It also might be possible to make it so the attacker wont be able to get their fee back, but no script for that yet. However, you must have missed my post where it is possible to identify the attacker. It would be after the fact, but that allows a reputation system to be created and as long as people are careful about filling orders from newbies, there wont be much problems. James P.S. Using your logic, no central exchange would exist as they would all be Ddosing each other all the time. You dont need to pay exchange fees to Ddos an website. |
|
|
|
Creating custom bitcoin tx and signing them from scratch took a while to debug, but finally the protocol is generating: I set the fee in BTCD for now: Bob feetx: {
"txid" : "80a3afd3b9a325e03efffd3e1a87ae734b11fa1c62df8446f1965d2674151b34",
"version" : 1,
"time" : 1455894047,
"locktime" : 0,
"vin" : [
{
"txid" : "7b9b69c0926219f1267fc4dbfe2934aca8f493a3b961e75fcc9b897ec4d9c5e8",
"vout" : 1,
"scriptSig" : {
"asm" : "3046022100a36015c8807725671688ae86dbeefbbce998816f662b8f0c0f8941f97a690806022100bf7e0d2ae774902a61d6938353974bf36f4f539006f6bb99172c4a72e1fdb0f401",
"hex" : "493046022100a36015c8807725671688ae86dbeefbbce998816f662b8f0c0f8941f97a690806022100bf7e0d2ae774902a61d6938353974bf36f4f539006f6bb99172c4a72e1fdb0f401"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 0.40030880,
"n" : 0,
"scriptPubKey" : {
"asm" : "42798d71482300af OP_DROP OP_DUP OP_HASH160 ca1e04745e8ca0c60d8c5881531d51bec470743f OP_EQUALVERIFY OP_CHECKSIG",
"type" : "nonstandard"
}
},
{
"value" : 0.58043605,
"n" : 1,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 5dba2c4ae40b488dcd1f3ff265dcd068aea43c79 OP_EQUALVERIFY OP_CHECKSIG",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"RHpmwtFAqE3PV4rwAGkAGA2f1jXHdgp2Mu"
]
}
}
]
}
Alice feetx: {
"txid" : "c910a3a535ea9fa5360417378316687bdc6e0836f639a4e7cdaa7a2857447aff",
"version" : 1,
"time" : 1455894042,
"locktime" : 0,
"vin" : [
{
"txid" : "ba12c78637e5f23350cb4bb8148207f1e71ccfc8e92867931b25de141adc7e0c",
"vout" : 1,
"scriptSig" : {
"asm" : "3045022100daa4b876cb75a10064d09d6dff0a8462974453c610175047f6650ec8dc05550c022025051a9691f97432e241c80fd394a2b469fc0420b8ae82b82d5858d7bcd133e801",
"hex" : "483045022100daa4b876cb75a10064d09d6dff0a8462974453c610175047f6650ec8dc05550c022025051a9691f97432e241c80fd394a2b469fc0420b8ae82b82d5858d7bcd133e801"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 0.40030880,
"n" : 0,
"scriptPubKey" : {
"asm" : "0ec4cb45ab2ec327 OP_DROP OP_DUP OP_HASH160 ca1e04745e8ca0c60d8c5881531d51bec470743f OP_EQUALVERIFY OP_CHECKSIG",
"type" : "nonstandard"
}
},
{
"value" : 0.11747422,
"n" : 1,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 74d61d299290b014fa9e609dd49978f9be54730b OP_EQUALVERIFY OP_CHECKSIG",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"RKvxxfU8yBvfrUz6ucip8AvUBA712dNrEn"
]
}
}
]
}
For now I am just using local bitcoind/BitcoinDarkd to isolate the atomic logic with known working daemons. Then I can switch to using iguana any bugs will be isolated to the new iguana code. Once that is done, then there wont be a need to run multiple daemons, but since the atomic swap can work with any pair of the local daemons, I think i will have an earlier release that assumes local daemons. Much pain the debugging is, but making steady progress. I did see the deposit and payment tx get created, but without the "poll" event things get stuck waiting, so I need to switch to proper event generation in a way that will be compatible with both iguana and bitcoind Once that is done, assuming the state machine is correct, it should be a matter to verify the refund handling. I will assume that my post above with the double secret fee release to InstantDEX and cltv reclaim of fee by Alice/Bob is adequate. It does require changing where the feetx is generated (after both sides choose) but before even the deposit is committed to. James |
|
|
|
RBF is opted into if sequenceid is used?
Doesnt that mean using CLTV or CSV or microchannels that use sequenceid is forced to accept RBF? If so, doesnt that break the entire premise for atomic tx
The rules are sequence = 0xFFFFFFFF means final (ignore locktime) and no replace by fee sequence = 0xFFFFFFFE means non-final (can use locktime) but opts out of replace by fee sequence = 0x80000000 - 0xFFFFFFFD means opt-in to replace by fee sequence = 0x00000000 - 0x7FFFFFFF is intended for use with relative locktime (plus probably RBF) It seems much much worse. RBF is enabled if any input has any value other than -1 or -2 That seems to break 90%+ of whatever uses sequenceid (assuming you dont like the RBF behavior), like CSV. Not sure but it might break SIGHASH_SINGLE signed tx, and possibly some or all coinshuffle protocols as the presence in any input affects the entire tx Hopefully you can influence the right people to dramatically scale down the RBF's hogging of 31.99 of the 32 bits. Just give it the LSB if it is just a flag? James |
|
|
|
Also, my design doesnt require reindexing as all the data is directly put into the bundle files with enough indexing information in them to be able to do the required operations. That is why the dataset grew to 25GB. If more speed is needed for the queries another layer of indexing can be added once all the bundle files arrive, but I am seeing decent performance for most queries without that layer for now.
With pruning data is thrown away. It just seems wasteful to re-validate in addition to having to re-download. certainly. once validated, just set a flag locally that it was validated. if paranoid about external tampering just save these validated flags in an encrypted file James |
|
|
|
Does this mean that transactions that need to change nSequence so they can use CHECKLOCKTIMEVERIFY will be forced to enable RBF?
No, the special sequence value UINT_MAX-1 disables RBF but also allows CLTV. UINT_MAX disables both. what about CHECKSEQUENCEVERIFY? That appears to be broken by this as there is no dynamic range available for different sequence values. And relative block addressing is also broken [or forced to use RBF, which is same as broken to many] Why does it make sense to give RBF such a large range? What about micropayment protocols that track transactions with sequenceid, or any other use of sequenceid. I would suggest using the LSB as the RBF flag, so it only uses one bit, which would only cause issues for sequenceid used for relative blocks for small intervals (though that can be fixed by dividing the sequenceid by two for relative block addressing). its usage as timestamp wont suffer much being limited to just the even numbered timestamps. It also says that if ANY of the inputs has such a sequenceid, the RBF is enabled. Does that mean for all outputs? What if it is signed as SIGHASH_SINGLE? If so, why does an unrelated input/output affect the others. Even if this case isnt broken, having any input affect all of them could break some coinshuffle protocols where the inputs and outputs are pretty independent. RBF sounds like a nice option to have, but by it using up 2^32-2 out of 2^32 values, basically we are saying sequenceid is for use by RBF and it will override other uses of sequenceid. James |
|
|
|
One of the disadvantages with pruning is that you have re-download everything for re-indexing.
When downloading the blockchain, the reference client skips signature validation until it reaches the last checkpoint. This greatly speeds up processing and then it slows down.
There is no loss in security by self-checkpointing. When a block is validated, a checkpoint could be stored in the database. This would be a "soft" checkpoint. It would mean that signature validation doesn't have to happen until that point.
In 0.12, the last block to be checkpointed has a height of 295000. The block is over 18 months. Core has to verify all blocks that were received in the last 18 months.
When downloading, core will download blocks 0 to 295000 without performing signature validation and then fully validates everything from 295000 to 399000. If re-indexing is requested, then it has to validate the 100k blocks a second time. There is no security value in doing that.
Instead, the client could record the hash for blocks that have already been validated. If a block is more than 2016 blocks deep and has a height that is divisible by 5000, then soft checkpoint the block.
It is possible that the new signature validation library resolves the problem. That would make the problem moot.
In iguana I save both the first blockhash and the hash(2000 blocks) for each blockhdrs for every 2000 blocks. This allows verification of the entire header as it comes in and parallel loading of all bundles of blocks in each header, with assurance that it will be the right set of blocks; Due to spends referencing still unseen outputs, full signature validation cant be 100% done until all the bundles are processed in the second pass (the first pass gets the raw blocks), however a lot of things can be verified during the second pass and I create read only files for each bundle. Since they are read only files, the entire set of them can be put into a squashfs to reduce its size to about 15GB (will probably be 20GB when I get all the data into the bundle file). The read only files include bloom filter lookup tables so by memory mapping them, it gets an in-memory structure that can directly be used for queries, without any time needed at startup. Another advantage of the read only format is that once it is validated, it doesnt change, so doesnt need to keep getting verified each restart. [I should add some checks to make sure the files havent changed to prevent external tampering.] Since it only takes 30 minutes for the two passes, I think I will add a third pass for the signature verification to avoid needing to do partial sig verifications and then resuming, etc. Also, my design doesnt require reindexing as all the data is directly put into the bundle files with enough indexing information in them to be able to do the required operations. That is why the dataset grew to 25GB. If more speed is needed for the queries another layer of indexing can be added once all the bundle files arrive, but I am seeing decent performance for most queries without that layer for now. James |
|
|
|
|
Show Posts
