Bitcoin Forum
November 19, 2017, 11:28:06 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: ACCT using CLTV - More Effective than a sleeping pill!  (Read 3158 times)
CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
January 25, 2016, 06:00:26 PM
 #1

So using the CIYAM Trade application along with using a CIYAM console acting as a Bitcoin/Litecoin wallet I demonstrated to my wife how you could exchange LTC for BTC without a 3rd party (or fees other than tx fees) and apparently it was so boring she fell asleep.

Code:
Generating a spendable amount of RHS for "user1"...
Generating a spendable amount of LHS for "user2"...

Login as "user1" and create a Trading Pair (with Maximum Amount as at least 25) and then Logout.

Now login as "user2" and create a tx from the offer in the All Open Offers list with the following details:

Sending Amount: 25
Refund Address: mtW4pzRHXwNwkHa2mdy2EokKy5GZ4aMWtu
Receiving Address: mkoJtKoxHmdL8aXJvPudmUgZKC1xXHb9KT
Secret Hash: 2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b

Now login as "user1" and edit the Trade Transaction in the My Trade Transactions list with the following:

Refund Address: mids4AKKn42KmcJTvaynUzmnhWnmfgwRMw
Receiving Address: mgF67ucKz7CddjuJwDvDUgC5HiJBRDGNBx

Now login as "user2" and from the tx click on the Waiting tx and copy and paste the Sending Address:

USER2_P2SH=2N1dPcqdkNyfNqysHDqWRq8hqSs6sT91LTP

Now "user2" will send LHS to their P2SH address.

Now login as "user1" and from the tx click on the Waiting tx and copy and paste the Sending Address:

USER1_P2SH=2NFtwQWeiQzMgeidPCrZZhATv6ULXqA8WaB

Now "user1" will send RHS to their P2SH address...

[
    {
        "involvesWatchonly" : true,
        "account" : "user2 (user1's p2sh)",
        "address" : "2NFtwQWeiQzMgeidPCrZZhATv6ULXqA8WaB",
        "category" : "receive",
        "amount" : 25.00000000,
        "vout" : 1,
        "confirmations" : 4,
        "blockhash" : "55647bfcc1ea60124e3e358a046a1e6494babb666d656aec3a9ad7ea3b179e71",
        "blockindex" : 1,
        "blocktime" : 1453733457,
        "txid" : "1b0effc3dbb318d988c5f8f3525c1e79fec7f327aebbc2028274361139042870",
        "walletconflicts" : [
        ],
        "time" : 1453733457,
        "timereceived" : 1453733475
    }
]

Now enter the following from the transaction information above:
TXID=1b0effc3dbb318d988c5f8f3525c1e79fec7f327aebbc2028274361139042870
VOUT=1

Now login as "user2" and from the tx click the Receive Checked button and paste the Secret Reveal Script:
SCRIPT=76a8202bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b87637576a91439f079037b44caa047b19f66f9446ad29ca1835888ac6704d0dea656b17576a9142
236ea542963ca5022db4332cd63aa2ed895af6888ac68

0100000001702804391136748202c2bbae27f3c7fe791e5c52f3f8c588d918b3dbc3ff0e1b01000000d44730440220456e9d366d89034c7321a900f17e60506cb9e6fb3c280587301609fda6af65
8502206d785719bc42de81ce05ac4b461fc9d4aab5286d4ec3ef8d0589ab3ed1076d7501210334ae38e2f6331bfc4832893edd540377bcfc08b1a63730339b91cf8a6e0b6636067365637265744c
6176a8202bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b87637576a91439f079037b44caa047b19f66f9446ad29ca1835888ac6704d0dea656b17576a9142236ea
542963ca5022db4332cd63aa2ed895af6888ac68000000000100f90295000000001976a91439f079037b44caa047b19f66f9446ad29ca1835888ac00000000

Now "user2" will redeem RHS from the "user1" P2SH address tx (exposing their secret).

Balance of RHS for "user2" is:
25.00000000

Now login as "user1" and from the tx click the Receive Checked button and paste the new Check Address:
ADDR=mkoJtKoxHmdL8aXJvPudmUgZKC1xXHb9KT

[
    {
        "involvesWatchonly" : true,
        "account" : "user1 (user2's reveal)",
        "address" : "mkoJtKoxHmdL8aXJvPudmUgZKC1xXHb9KT",
        "category" : "receive",
        "amount" : 25.00000000,
        "vout" : 0,
        "confirmations" : 1,
        "blockhash" : "5ea97dcb1e76ca90ef0b71aae2208488df5d8344248be2713fbb8f1bae8a1667",
        "blockindex" : 1,
        "blocktime" : 1453733502,
        "txid" : "d374d12b0cee799e7d3b233332b87ae41f18ffae9c1a5dc49f7436df4f216fcf",
        "walletconflicts" : [
        ],
        "time" : 1453733502,
        "timereceived" : 1453733536
    }
]

Now copy and paste the secret reveal txid:
TXID=d374d12b0cee799e7d3b233332b87ae41f18ffae9c1a5dc49f7436df4f216fcf

{
    "txid" : "d374d12b0cee799e7d3b233332b87ae41f18ffae9c1a5dc49f7436df4f216fcf",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "1b0effc3dbb318d988c5f8f3525c1e79fec7f327aebbc2028274361139042870",
            "vout" : 1,
            "scriptSig" : {
                "asm" : "30440220456e9d366d89034c7321a900f17e60506cb9e6fb3c280587301609fda6af658502206d785719bc42de81ce05ac4b461fc9d4aab5286d4ec3ef8d0589ab3
ed1076d7501 0334ae38e2f6331bfc4832893edd540377bcfc08b1a63730339b91cf8a6e0b6636 736563726574 76a8202bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf5
27a25b87637576a91439f079037b44caa047b19f66f9446ad29ca1835888ac6704d0dea656b17576a9142236ea542963ca5022db4332cd63aa2ed895af6888ac68",
                "hex" : "4730440220456e9d366d89034c7321a900f17e60506cb9e6fb3c280587301609fda6af658502206d785719bc42de81ce05ac4b461fc9d4aab5286d4ec3ef8d0589a
b3ed1076d7501210334ae38e2f6331bfc4832893edd540377bcfc08b1a63730339b91cf8a6e0b6636067365637265744c6176a8202bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25
fe97bf527a25b87637576a91439f079037b44caa047b19f66f9446ad29ca1835888ac6704d0dea656b17576a9142236ea542963ca5022db4332cd63aa2ed895af6888ac68"
            },
            "sequence" : 0
        }
    ],
    "vout" : [
        {
            "value" : 25.00000000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 39f079037b44caa047b19f66f9446ad29ca18358 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a91439f079037b44caa047b19f66f9446ad29ca1835888ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "mkoJtKoxHmdL8aXJvPudmUgZKC1xXHb9KT"
                ]
            }
        }
    ]
}

Now copy and paste the revealed secret:
HEX_SCRT=736563726574

[
    {
        "txid" : "e6af2d2c7e6cda9ea14c166a57c83112376a39b24524b5d2b1e607d740663b71",
        "vout" : 0,
        "address" : "2N1dPcqdkNyfNqysHDqWRq8hqSs6sT91LTP",
        "account" : "user1 (user2's p2sh)",
        "scriptPubKey" : "a9145bf232454e73c9cafa022f52d819bbf59c63df1087",
        "amount" : 25.00000000,
        "confirmations" : 9,
        "spendable" : false
    }
]

Now copy and paste the P2SH txid and vout:
TXID=e6af2d2c7e6cda9ea14c166a57c83112376a39b24524b5d2b1e607d740663b71
VOUT=0

Now click the Secret Checked button and paste the Secret Reveal Script:
SCRIPT=76a8202bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b87637576a91407f8009f5b6b12a5ae10e0ae539ea06ce232cfbf88ac67047387a756b17576a9148
e6eac4b9e5944a76f2305a736ed2a7d65742f7688ac68

0100000001713b6640d707e6b1d2b52445b2396a371231c8576a164ca19eda6c7e2c2dafe600000000d4473044022027523c5d0aaf22798d0503c67c073bf4a78522d88d8128720091289845ac0f
1d022078d69e74bea88f7d727a4a04650179136ca24872477f052f58d17f825ce1b0ad01210220d666741f2e8be672556ca8f0b7a7352516422c7b7b3f0681d39adf4cabd953067365637265744c
6176a8202bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b87637576a91407f8009f5b6b12a5ae10e0ae539ea06ce232cfbf88ac67047387a756b17576a9148e6eac
4b9e5944a76f2305a736ed2a7d65742f7688ac68000000000100f90295000000001976a91407f8009f5b6b12a5ae10e0ae539ea06ce232cfbf88ac00000000

Now "user1" will redeem LHS from the "user2" P2SH address tx.

Balance of LHS for "user1" is:
25.00000000

So I've built a decentralised exchange but I am getting the feeling that I have probably wasted my time doing so (am glad it hasn't taken me more than a couple of weeks).

Does anyone really think that this kind of idea is going to work?

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
1511090886
Hero Member
*
Offline Offline

Posts: 1511090886

View Profile Personal Message (Offline)

Ignore
1511090886
Reply with quote  #2

1511090886
Report to moderator
1511090886
Hero Member
*
Offline Offline

Posts: 1511090886

View Profile Personal Message (Offline)

Ignore
1511090886
Reply with quote  #2

1511090886
Report to moderator
1511090886
Hero Member
*
Offline Offline

Posts: 1511090886

View Profile Personal Message (Offline)

Ignore
1511090886
Reply with quote  #2

1511090886
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511090886
Hero Member
*
Offline Offline

Posts: 1511090886

View Profile Personal Message (Offline)

Ignore
1511090886
Reply with quote  #2

1511090886
Report to moderator
1511090886
Hero Member
*
Offline Offline

Posts: 1511090886

View Profile Personal Message (Offline)

Ignore
1511090886
Reply with quote  #2

1511090886
Report to moderator
Trouble821
Full Member
***
Offline Offline

Activity: 176


View Profile
January 25, 2016, 09:10:45 PM
 #2

Yes if it's fast enough. The Ripple distributed exchange was always slow compared to regular exchanges, but it did plenty of business last year.

If you could make a trade in 30 seconds or less people would use it. A few coins tried cutting block times to the minimum, and managed a block every few seconds which could make an exchange fairly fast. Viacoin has a 24 seconds block time, and Bitshares 2.0 started with 5 second blocks with the option of reducing it to one second blocks.

If the qora devs saw value in reducing the block time to accommodate an exchange they would probably do it.

cr1776
Legendary
*
Online Online

Activity: 1708


View Profile
January 25, 2016, 09:38:41 PM
 #3

So using the CIYAM Trade application along with using a CIYAM console acting as a Bitcoin/Litecoin wallet I demonstrated to my wife how you could exchange LTC for BTC without a 3rd party (or fees other than tx fees) and apparently it was so boring she fell asleep.
...
So I've built a decentralised exchange but I am getting the feeling that I have probably wasted my time doing so (am glad it hasn't taken me more than a couple of weeks).

Does anyone really think that this kind of idea is going to work?


A decentralized exchange with a good interface would be quite useful for many. Can it do the reverse?  e.g. BTC for LTC? 

I presume this related to the CHECKLOCKTIMEVERIFY and the check <data1> against <sig1> questions....I haven't looked at the code above yet.

Congrats on getting it working.  Why do you think you've wasted your time?
CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
January 26, 2016, 03:54:54 AM
 #4

A decentralized exchange with a good interface would be quite useful for many. Can it do the reverse?  e.g. BTC for LTC?  

Yes - it would support that (just using the CIYAM software).

I presume this related to the CHECKLOCKTIMEVERIFY and the check <data1> against <sig1> questions....I haven't looked at the code above yet.

Indeed - that is how it operates.

Congrats on getting it working.  Why do you think you've wasted your time?

Thanks - well - when it is done using AT instead then it will be integrated into a wallet and not have many steps (so ACCT between QORA and BURST should be a good experience).

As CIYAM's blockchain is still a "work in progress" I would have to release Trade as a web application requiring therefore a separate Wallet application to operate with it (which is what my testing is emulating). That adds a few steps (copying and pasting) which I think is not going to be viewed very enthusiastically.

Also when it comes to using Bitcoin (or even Litecoin) you could not realistically be expecting to do trades in under an hour or so (because time stamps in blocks are just not that accurate and you would need to wait for at least one confirmation between each step).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
January 26, 2016, 04:51:50 AM
 #5

To elaborate on the workflow that would be involved in trading LTC for BTC:

  • Alice creates an LTC / BTC offer pair using the Trade web application (as this could be done once for many trades it won't be counted as a step).
  • Brian clicks on the offer and then creates a Trade Transaction providing an Amount, an LTC Refund Address, a BTC Receive Address and a hashed Secret.
  • Alice is notified she has a new Trade Transaction and supplies her BTC Refund Address and LTC Receive Address.
  • Brian is notified that the deal is on and now sees a P2SH LTC Address which he sends the LTC funds to.
  • Alice detects that Brian has sent the LTC funds (via a "watch address") and sends her BTC funds to a BTC P2SH Address.
  • Brian now copies and pastes the BTC P2SH Redeem script into a special Wallet and redeems the BTC (disclosing the secret).
  • Alice detects (via a "watch address") that Brian has redeemed the BTC and then discovers the secret from the redeem tx.
  • Alice copies and pastes the secret and the LTC P2SH Redeem script into a special Wallet and redeems the LTC.

Number of steps for Alice (apart from creating the offer) is four whilst the number of steps for Brian is three (guess it should be slightly easier for the party that "goes first").

Note that if the Wallet is clever enough then perhaps Alice's second last step can be simply automated (i.e. the last two steps could be combined into one) but I think three steps each is about as good as it can get with this design.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
February 02, 2016, 12:24:23 PM
 #6

Why is there a need for copy/pasting?

You could require that both people have their litecoin and bitcoin wallets open and connect to them via RPC.  The standard clients can generate private keys and fund transactions.  They even handle P2SH addresses that are basic.

The annoying part of ACCT is that waiting for confirms is kind of required.  This means that you are really giving an option to the other party.  The other person can drop out if the price shifts.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 02, 2016, 12:29:03 PM
 #7

Why is there a need for copy/pasting?

You could require that both people have their litecoin and bitcoin wallets open and connect to them via RPC.  The standard clients can generate private keys and fund transactions.  They even handle P2SH addresses that are basic.

The reason for that is just up to how it is implemented and yes it could be possible to get rid of that via scripts, etc.

Unfortunately the ACCT/CLTV Bitcoin tx is not something that Bitcoin (or Litecoin) can handle with its raw tx support (so it can't create the tx and nor can it sign it).

The annoying part of ACCT is that waiting for confirms is kind of required.  This means that you are really giving an option to the other party.  The other person can drop out if the price shifts.

I think that is simply the nature of the beast (so it will never be attractive for "day traders").

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
February 02, 2016, 03:36:29 PM
 #8

Unfortunately the ACCT/CLTV Bitcoin tx is not something that Bitcoin (or Litecoin) can handle with its raw tx support (so it can't create the tx and nor can it sign it).

You have to build up the transactions manually, but it does track coins held by the wallet.  It also tracks payments to the wallet, as long as you pay them to one of the standard output formats.

The fun with testing is that you need to run 4 wallets.  You can quickly burn all your outputs and then have to wait 10 minutes for more.

The RPC commands I used in my unfinished (pre-checklocktimeverify) version are:

listunspent (gets available coins in the wallet)

getrawchangeaddress (for change)
getnewaddress (for receiving)
dumpprivkey (for converting an address into a private key)
validateaddress (gets info about the address)

sendrawtransaction (sends the raw transaction)

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 02, 2016, 03:39:36 PM
 #9

Yup - I found that for the 4 wallets the simplest approach is to use "-regtest" (as you can generate the coins instantly).

I also use pretty much the same commands you list - but the construction and signing is done with my own software (I was a little disappointed that Bitcoin couldn't do at least the signing but it is a very unusual looking raw tx so perhaps not that surprising).

The CIYAM script I am using for testing this is here: https://github.com/ciyam/ciyam/blob/master/src/bct_acct_test.cin
(some of it is probably a bit mysterious but you can see the Bitcoin RPC calls fairly clearly).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 02, 2016, 03:46:45 PM
 #10

Note that I didn't use the "get" calls or "dumprivkey" as for the purposes of simplifying the test script I used hard-coded private keys (but in a "live version" I would be basically doing just that).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 02, 2016, 04:02:40 PM
 #11

In order to make the UI "nicer" I am using "unix time stamps" rather than block numbers - so with a bit of work maybe I could convert the time stamp back into a block number and improve the speed that this could be used at (as Bitcoin time stamps can be out by as much as two hours).

But even so - you are going to need to see at least 1 confirmation from the "initiator" (to the P2SH address they need to send to) before you are going to bother (as the "responder") to send to the complimenting P2SH address (as you wouldn't lock up your funds if you haven't seen that).

And presumably the "initiator" won't reveal their secret until at least one confirmation (keeping in mind that 1 confirmation is still somewhat risky).

So the likelihood of an ACCT taking place in less than an hour is not that much (so this is not a solution for day traders).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
coins101
Legendary
*
Offline Offline

Activity: 1400



View Profile
February 04, 2016, 09:29:22 AM
 #12

If you allow for third party liquidity providers (one or many, eg crowd funded trades), you can pair trades faster.

CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 04, 2016, 09:49:10 AM
 #13

If you allow for third party liquidity providers (one or many, eg crowd funded trades), you can pair trades faster.

Without many offers presumably the application could never even take off (that would require some marketing effort) but the speed is limited by the method (ACCT using CLTV) rather than by the number of offers that are available.

(and it would become a bit tricky for users to keep track of a whole lot of trades that will require them to create txs at the right point in time)

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
coins101
Legendary
*
Offline Offline

Activity: 1400



View Profile
February 04, 2016, 07:54:55 PM
 #14

If you allow for third party liquidity providers (one or many, eg crowd funded trades), you can pair trades faster.

Without many offers presumably the application could never even take off (that would require some marketing effort) but the speed is limited by the method (ACCT using CLTV) rather than by the number of offers that are available.

(and it would become a bit tricky for users to keep track of a whole lot of trades that will require them to create txs at the right point in time)


The end result is very exciting, but the current process is a bit clunky.

Liquidity providers can hold a certain amount of 'x' altcoin which will be ready for exchange at any point. This would be a great way for people to make some money on being liquidity providers. You wouldn't need to worry about marketing.

With liquidity providers with ratings, you're not far off an alt/btc only variant of localbitcoins / shapeshift.

TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
February 09, 2016, 05:14:20 PM
 #15

A problem with the deployment of CLTV on Bitcoin is that many altcoins don't support it.

This protocol allows transfers to coins that use the oldest type of IsStandardChecks.  Outputs have to use basic script or they won't be accepted.

0) Commit to paying fees NEW

Both parties pick a random number and the trade_id = hash256(alice_random_number | bob_random_number)

Both parties should create a transaction which pays to

Code:
OP_1 <creators_public_key> <02, tradeId> OP_2 OP_CHECKMULTISIG

It must pay fees that are greater than 0.1% of the coins being exchanged.  It is a one of two multisig.  Since the 2nd public key is generated from the trade_id, nobody has the corresponding private key.  This means that it is the same as having 1 key, but it allows committing the fee to the trade.

If <02, tradeId> is not a valid compressed key, then a new tradeId should be selected, until a valid compressed key can be created.

This step could be skipped when in "trusting" mode.  If other parties tend to abort before step 1 ends, then the node could switch to untrusting mode.

Reputation systems could be deployed here.

1) Cut and choose

Bob generates 1000 keypairs and sends hash(bob_priv_n) and bob_pub_n to Alice for each n (1 to 1000).

Alice picks n from 1 to 1000 and Bob sends bob_priv_n for the 999 other n's.

If they are ok, then Alice assumes the pair she didn't see is valid.

Similarly, Alice generates 1000 key pairs and has Bob choose.

This gives the following public info.

  hash(bob_priv_n) matches bob_pub_n
  hash(alice_priv_m) matches alice_pub_m

There is a 0.1% chance of fraud for each attempt.  This means that fees must be at least 0.1% of the transaction value.  In that way, there is no incentive to cheat at the cut-and-choose.

2) Bob pays D to

Code:
OP_IF
  <now + 2 days> OP_CLTV OP_DROP <alice_pub_1001> OP_CHECKSIG
OP_ELSE
  OP_HASH160 <hash(bob_priv_n)> OP_EQUALVERIFY <bob_pub_1001> OP_CHECKSIG
OP_ENDIF

D should be more valuable than the value of the Bitcoins or altcoins.  

This is a promise by Bob to release bob_priv_n within 2 days (or lose his deposit).

3) Alice pays a altcoins to

Code:
OP_2 <bob_pub_n> <alice_pub_m> OP_2 OP_CHECKMULTISIG

4) Bob pays b Bitcoins to

Code:
OP_IF
  <now + 1 day> OP_CLTV OP_DROP <bob_pub_1002> OP_CHECKSIG
OP_ELSE
   OP_HASH160 <hash(alice_priv_m)> OP_EQUALVERIFY <alice_pub_key_1001> OP_CHECKSIG
OP_ENDIF

Alice has 1 day to claim her output, but that means she must provide alice_priv_m.

5) Alice spends the output (and provides alice_priv_m).

6) Bob can spend the altcoin output (since he has both keys)

7) Bob reclaims his deposit

This is atomic and it is recoverable if either party refuses to complete a step.

1) Either party refuses to perform cut-and-choose.

Nothing has been sent to either chain, so no harm done.

2) Bob refuses to pay deposit.

Nothing has been sent to either chain, so no harm done.

3) Alice refuses to bail-in.

Bob reclaims his D after 2 days.
Releasing bob_priv_n has no effect since there was no bail-in by Alice, so the key is never used.

4) Bob refuses to bail-in

If Bob reclaims his deposit, then Alice will have both private keys and can reclaim her bail-in.

If Bob fails to claim his deposit, then Alice gets that as compensation instead of her bail-in.  In that case, Bob loses his deposit and can't claim the altcoins.  This means he should reclaim his output.

5) Alice refuses to claim her Bitcoins

1 day later Bob can reclaim his Bitcoins

Alice gets her altcoins back or she gets D instead (if Bob doesn't reclaim his deposit).

6) Bob refuses to claim his altcoins

He loses his altcoins when he reclaims his deposit.  Alice already has his Bitcoins by this point.

He has an incentive to complete this step.

7) Bob refuses to claim his deposit

He loses his deposit and Alice gets it.

He has an incentive to complete this step.

For each step, there is either an incentive to complete the step or failure to complete the step causes the protocol to abort.  In an abort, the incentives are to perform a clean abort.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 09, 2016, 05:21:44 PM
 #16

Am going to have to digest your new protocol a bit but I think it is quite interesting.

BTW - if you are interested in being part of creating a decentralised exchange with this sort of protocol as the "settlement layer" then welcome to PM me (I have decided that due to the time it would take to perform such ACCTs they are only going to be good for "settlement" so order matching and general trading will be done via a separate blockchain or maybe a sidechain).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
jl777
Legendary
*
Offline Offline

Activity: 1162


View Profile WWW
February 09, 2016, 10:04:51 PM
 #17

A problem with the deployment of CLTV on Bitcoin is that many altcoins don't support it.

This protocol allows transfers to coins that use the oldest type of IsStandardChecks.  Outputs have to use basic script or they won't be accepted.

1) Cut and choose

Bob generates 1000 keypairs and sends hash(bob_priv_n) and bob_pub_n to Alice for each n (1 to 1000).

Alice picks n from 1 to 1000 and Bob sends bob_priv_n for the 999 other n's.

If they are ok, then Alice assumes the pair she didn't see is valid.

Similarly, Alice generates 1000 key pairs and has Bob choose.

This gives the following public info.

  hash(bob_priv_n) matches bob_pub_n
  hash(alice_priv_m) matches alice_pub_m

There is a 0.1% chance of fraud for each attempt.  This means that fees must be at least 0.1% of the transaction value.  In that way, there is no incentive to cheat at the cut-and-choose.

2) Bob pays D to

Code:
OP_IF
  <now + 2 days> OP_CLTV OP_DROP <alice_pub_1001> OP_CHECKSIG
OP_ELSE
  OP_HASH160 <hash(bob_priv_n)> OP_EQUALVERIFY <bob_pub_1001> OP_CHECKSIG
OP_ENDIF

D should be more valuable than the value of the Bitcoins or altcoins. 

This is a promise by Bob to release bob_priv_n within 2 days (or lose his deposit).

3) Alice pays a altcoins to

Code:
OP_2 <bob_pub_n> <alice_pub_m> OP_2 OP_CHECKMULTISIG

4) Bob pays b Bitcoins to

Code:
OP_IF
  <now + 1 day> OP_CLTV OP_DROP <bob_pub_1002> OP_CHECKSIG
OP_ELSE
   OP_HASH160 <hash(alice_priv_m)> OP_EQUALVERIFY <alice_pub_key_1001> OP_CHECKSIG
OP_ENDIF

Alice has 1 day to claim her output, but that means she must provide alice_priv_m.

5) Alice spends the output (and provides alice_priv_m).

6) Bob can spend the altcoin output (since he has both keys)

7) Bob reclaims his deposit

This is atomic and it is recoverable if either party refuses to complete a step.

1) Either party refuses to perform cut-and-choose.

Nothing has been sent to either chain, so no harm done.

2) Bob refuses to pay deposit.

Nothing has been sent to either chain, so no harm done.

3) Alice refuses to bail-in.

Bob reclaims his D after 2 days.
Releasing bob_priv_n has no effect since there was no bail-in by Alice, so the key is never used.

4) Bob refuses to bail-in

If Bob reclaims his deposit, then Alice will have both private keys and can reclaim her bail-in.

If Bob fails to claim his deposit, then Alice gets that as compensation instead of her bail-in.  In that case, Bob loses his deposit and can't claim the altcoins.  This means he should reclaim his output.

5) Alice refuses to claim her Bitcoins

1 day later Bob can reclaim his Bitcoins

Alice gets her altcoins back or she gets D instead (if Bob doesn't reclaim his deposit).

6) Bob refuses to claim his altcoins

He loses his altcoins when he reclaims his deposit.  Alice already has his Bitcoins by this point.

He has an incentive to complete this step.

7) Bob refuses to claim his deposit

He loses his deposit and Alice gets it.

He has an incentive to complete this step.

For each step, there is either an incentive to complete the step or failure to complete the step causes the protocol to abort.  In an abort, the incentives are to perform a clean abort.
Fantastic! Yes, this seems to solve the issue. I will change things to match this.

James

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
February 10, 2016, 12:20:16 PM
 #18

There is an attack on the cut-and-choose.

An attacker could keep starting trades and perform the cut-and-choose step with 1 invalid pair.  If they get detected (99.9%), then they can abort the trade.

Since there is no fee paid for step 1, there is no cost to the attacker.

I have updated the protocol to add a step 0.  This slows things down since there is another commit step.

There is a tradeoff between complexity and performance.

If the altcoin supports CLTV, it could be used directly. 

It is possible that there is an improved protocol for altcoins which support the more flexible P2SH IsStandard rules.

I would split altcoins into 3 ranks.

Rank 1 coins support CLTV
Rank 2 coins skip the IsStandard check for P2SH outputs
Rank 3 coins only allow standard outputs, even for P2SH

Bitcoin moved from rank 3 to rank 2 about 18 months ago and to rank 1 with the release of CLTV.

On the other hand, a single protocol for all altcoins keeps things simple.

It would be necessary to be clear that there is a 0.1% chance of attack.  With the step 0 fee commit, it isn't in anyone elses interests to cheat.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 10, 2016, 12:23:42 PM
 #19

Whilst I think your approach is sound (especially after the additional step) my gut feel is that the complexity of it all is just not going to work very neatly with an implementation.

Assuming I do launch something it will only be supporting the Rank 1 coins (i.e. the least complexity) and if that only includes BTC and LTC then I'm okay with that.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
February 10, 2016, 01:11:38 PM
 #20

Assuming I do launch something it will only be supporting the Rank 1 coins (i.e. the least complexity) and if that only includes BTC and LTC then I'm okay with that.

That seems reasonable for version 1, at least.  With CLTV, there is no cut-and-choose risk.

I wonder if something like the Lightening network could be accomplished.  In that case, trustless hubs could be created.  To perform the trade, the trade happens with the hubs acting as trade hubs.  The trade hubs could support multiple altcoins.

It would be a p2p network with 2 types of nodes (or at least 2 specialties).  As long as you connect to a few hubs, you could trade with anyone on the network.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!