Announcing intent for a cross-chain atomic swap


This note describes an example of how the Smileycoin blockchain/mempool can be a part of a cross-chain atomic swap sequence, for any pair of coins (neither of which needs to be the SMLY). It also describes why the SMLY is better suited for this purpose than most other coins, both higher- and lower-valued coins. This is work in progress and should currently be treated as a Request For Comment.

The sendwithmessage command


The development version of the Smileycoin wallet has an additional command, sendwithmessage, which works as follows:

sendwithmessage "smileycoinaddress" amount "message"

as in:

sendwithmessage BLSmLCGS55pbWmDoKRuhpC4tBeGNyL7427 5000 "This is from Bob"

The original intent was to use this command to send a message with a transmitted amount. A typical example would be a simple "Thank you" to go with a payment, but it can also be quite effectively used for the entire information-exchange required for a cross-chain atomic swap.

The detailed implementation of sendwithmessage will be described including an example of how this new command can be a part of a cross-chain atomic swap sequence, for any pair of coins (neither of which needs to be the SMLY).

If Alice has 1 BTC and wants to sell it for 100 LTC, then she needs to advertise this intent. If Bob sees the ad, then Bob needs to respond by declaring interest. Preferably, Alice should respond by accepting Bob as the preferred party. Alice also needs to give Bob a LTC address and Bob needs to give Alice a BTC address. This entire information exchange can be done (semi-)anonymously on the Smileycoin blockchain (more specifically, it can be done in the SMLY mempool). The following also explains why there need to be costs associated with the information exchange and why the Smileycoin is better suited for this than any higher-valued coin (and most lower-valued coins).

The basic information exchange can be as in the following example

1 Alice sends initial statement of intent-to-sell BTC for LTC:
sendwithmessage BLmGXqT5iFeSagteBSjFW4uo7to76YJ9gH 6100 "SELL BTC 1 LTC 1000"
and gets SMLY TxIDa1=f20a4783d653dab3f4e35200032d30142deb2e67af1f66122ee9a7d49f50f5a5

2 Bob wants to be part of this and says so by sending a simple ACCEPT plus a link to the TxId:
sendwithmessage BLmGXqT5iFeSagteBSjFW4uo7to76YJ9gH 19500 "ACCEPT f20a4783d653dab3f4e35200032d30142deb2e67af1f66122ee9a7d49f50f5a5"
and gets TxIDb1=2d7c49a792116b4c93de470f7058f12e5be7c99f795d27419d7c65ea9b843254

3 Alice may have more offers but acknowledges Bob and sends her LTCaddress=Laji6bKnzjCbej2wZjoNeuH8fvmJxtnA7J plus a link to the TxId:
sendwithmessage BLmGXqT5iFeSagteBSjFW4uo7to76YJ9gH 27500 "ACK Laji6bKnzjCbej2wZjoNeuH8fvmJxtnA7J 2d7c49a792116b4c93de470f7058f12e5be7c99f795d27419d7c65ea9b843254"
and gets TxIDa2=7f40fbe1a68c855c0640b408aa423edec855b9b4283b6b1f477e0491eed214e2.

4 Finally, Bob responds by sending his BTCaddress=1BeCDm8DdktKVcWV9DpfSaj5m8jQrFidwk
sendwithmessage BLmGXqT5iFeSagteBSjFW4uo7to76YJ9gH 28500 "ACCEPT 1BeCDm8DdktKVcWV9DpfSaj5m8jQrFidwk 2d7c49a792116b4c93de470f7058f12e5be7c99f795d27419d7c65ea9b843254"

Notice how the messages form a thread. The two users can track this in the mempool or the blockchain and have exchanged the needed addresses to start the cross-chain atomic swap. All of these actual transactions are in the SMLY blockchain and can be viewed in a block explorer, and are explained in detail below.

Why pay for the announcement, whom to pay?

It is important that all parties need to pay. They do not trust each other and to avoid spam each user should be forced to include some form of payment.

Next, the address used as a recipient of the SMLY can not be one of the parties as e.g. Alice could then send out very tempting offers and get lots of responses - and payment - from Bob, Charlie etc. It is therefore suggested that a SMLY address belonging to the non-profit organisation Education in a Suitcase be used as the recipient for these transactions, as in the above example. Of course if a developer of a multi-coin wallet wants to implement these features, then they will use their own SMLY address, but in the open case considered here it is also easier to monitor a single address.


Needless to say, the same method could be used with other coins. However, the costs become very different if the same coding scheme is used with a more expensive coin. The full cost of the above information exchange is 6100+19500+27500+28500 or 81600 SMLY. At current (Nov 2017) SMLY prices (0.2 Satoshi), this is about $1 in total, of which Alice pays about 44 cents. Messing around with 81600 BTC, LTC or even DOGE is a different matter altogether.

The SMLY blockchain has a few things going for it over other coins. First, a more expensive coin will result in correspondingly more expensive transmissions. Secondly, unlike many other low-value coins, the SMLY is a part of several educational projects being developed around the world so the Smileycoin is here to stay. The notes at the end give further comments on this issue.


The sendwithmessage command works by splitting the message into 4-character chunks and coding each chunk as 8 decimals in a transmission to the recipient address. The value transmitted needs to be greater than the total cost of all the chunks. Alice's initial announcement of "SELL BTC 1 LTC 1000" consists of 19 characters and goes into 5 chunks. The transaction containing these chunks starts with a special amount indicating the start of a general message, followed by the chunks. The ASCII decimal codes for this message are
"83 69 76 76 32 66 84 67 00 49 32 76 84 67 32 49 48 48 48".

Each character is coded by subtracting 32 from the ASCII decimal code for each character, resulting in
"51 37 44 44 00 34 52 35 00 17 00 44 52 35 00 17 16 16 16".

The chunks of 4 characters are now strung together and padded to form the decimal places in the transaction:


Finally, a base transmission cost of 1000 SMLY along with a sequence number is added to each chunk so the list of values, including the starting batch becomes


These values are exactly the ones seen in SMLY transaction f20a4783d653dab3f4e35200032d30142deb2e67af1f66122ee9a7d49f50f5a5, as given by but the actual transaction also contains two change values. One is the normal change back to Alice's wallet but the second stems from the fact that Alice specified 6100 SMLY but the value which was actually needed to cover the text message was only 1000.31415926+ 1001.51374444+1002.00345235+1003.00170044+1004.52350017+1005.16161600
or 6016.51817266 and the corresponding change (or "Tip") was therefore 6100-6016.51817266 or 83.48182734 as seen in the transaction.

Why not use OP_RETURN?

The OP_RETURN code is a code implemented in many coins (it was not in SmileyCoin at the time this was first written). In BTC and LTC implementations, it allows the sender of a transaction to include one output with an 80 character string. 

A well-though-out OP_RETURN implementation could  replace the sendwithmessage proposal. Other concerns raised here still apply: the data transactions should include minimum value also; the value should go to predefined addresses; these addresses are the ones which would be monitored by interested parties' wallets for announcements.




1 The base transmission cost of 1000 SMLY is a magic constant which will need to evolve.

2 These costs could be cut if Alice publishes a unique new LTC address with the first transaction and Bob publishes the BTC address immediately with the answer. However, Alice may get many responses and should publish an ACK specific to Bob. Preferably Alice should also use a unique LTC address for each potential responder. The above method permits Alice to accept several offers.

3 The price of SMLY has traditionally been closer to 1 Satoshi rather than the 0.2 used above. At current BTC prices ($6500) this would put the total transmission cost at $5 from the first baseline of $1.

4 Depending on how the price of SMLY develops, one may consider reducing the base transmission cost from 1000 SMLY to 100 SMLY.  The first implementation will almost certainly reduce this baseline to 100 SMLY, reducing the base cost from $1 to 10 cents at current SMLY prices, or to 50 cents if the SMLY price increases to 1 Satoshi. 

Notice that if one were to use DOGE in place of SMLY as a vehicle, the costs of the above transaction would currently be around $20 and historically DOGE has often been priced much higher. For example, with DOGE at 100 Satoshi or more, it becomes difficult to even reduce the base transmission cost without messing up the sequence numbers.

6 Rather than the keyword "SELL" in the initiating command, one should probably use "SWAP". One might also allow "AUTO" to indicate a desire to do multiple swaps of the same form.

7 Rather than just "ACK" to close a single sale, the initiator could acknowledge the single closure using different terms, "CLOSE" to close this session and terminate the initial offer or "OPEN" to close this session and indicate a desire to still accept bids into the initial offer.

8 If this is to be used generally as a part of a cross-chain atomic swap sequence then the sendwithmessage command should be renamed sendswapoffer to reflect that status.

9 The original sendwithmessage command, as a text transmission service, will be modified to include encryption of the message, which can not be used as an open call for an atomic swap. Note however, that this implies that parts of the above transaction can be encrypted, e.g. the send/receive addresses.

10 It is hard to predict the development of costs if the price of SMLY goes over 10 Satoshi. This is a very unlikely scenario since both non-profit organisations and students own a large number of SMLY and will almost certainly start selling at such prices.

Add comments either to the bitcointalk thread:

or  to the Twitter thread:

Modifications to the proposal (edits)

Modifications (such as suggested cost reductions) are simply edited into the above text unless explicitly listed below.