Bitcoin Forum

Announcing a preview release of SwapBill, an embedded protocol focusing on altcoin exchange features.

The release can be found here:
https://github.com/crispweed/swapbill

This contains a preview version of the SwapBill reference client, as well as some information about how to get this set up, as well as basic usage (in README.md).

The client is pure python, with minimal third party dependencies.
This is currently configured with litecoin as the host currency, and so litecoind is required as a backend (or litecoinQT running as a server).

The basic idea is similar to mastercoin and counterparty, but with some key differences.

An important fundamental difference, at the protocol level, is that swapbill transactions are controlled by unspent outputs in the host blockchain (in a way that very closely mirrors the way host coins are spent), as opposed to balances being assigned more generally to addresses.

This gives use the following advantages:
 - we don't need to spend bytes on marking transactions as belonging to the SwapBill protocol, these are identified and authenticated as such automatically by the transaction inputs
 - we don't reuse addresses - after each transaction, change is paid to a new address
 - SwapBill clients don't need access to a full transaction history or transaction index, only the transactions in each new block need to be scanned
 - outputs may be controlled by any encumbrance mechanism the host blockchain supports, so you're not limited to standard pay to address script types, and other script types such as multisig addresses can be used to control SwapBill outputs

SwapBill is created with scalability and efficiency in mind, and the process of scanning the host blockchain for swapbill transactions is designed to be a lot faster than for other embedded currencies.

And, on the coin supply side of things, a unique feature of SwapBill is that the value of one swapbill is *capped* at the value of the host coin.
(So, for swapbill embedded in the litecoin blockchain, the value of 1 swapbill can never exceed 1 litecoin.)
This avoids a lot of the boom and bust mechanics of other currencies, and helps to ensure that swapbill remains relatively stable, and suitable for use as a medium of exchange.

Building a protocol on top of an established blockchain (such as the bitcoin or litecoin blockchain) is good because:
 - there is no need for any kind of 'critical mass' in order to launch the protocol successfully - it just works, and
 - we can delegate complicated things like network management and validity checking to the reference client for the host blockchain

A lot of effort has then been spent on rationalising the protocol and keeping the SwapBill client as simple as possible, as we believe that code complexity is a key issue in making it possible to ensure that a system is robust. The protocol is designed to enable exchange features that would be difficult (or impossible) to implement *and* guarantee as robust in other cryptocurrencies.

We're looking for:
 * feedback about the protocol decisions made up to here for the preview version of the reference client,
 * and in particular about some fixed values built in to the protocol (we avoid hardcoded values as far as possible, but in certain cases hard coded values are required in order to implement the protocol robustly and efficiently, the values we've chosen for these hard coded values at this point are then almost certainly not the best possible choices),
 * community involvement in moving SwapBill forward to actual release.

Known issues with the current preview client (version 0.3):
 - the protocol currently creates unspent outputs that can't easily be pruned (ideally we would like to use OP_RETURN, but this is currently treated as non-standard by the litecoin reference client)

That's it for now. Questions here!

links:
github: https://github.com/crispweed/swapbill
twitter: @swapbill (https://twitter.com/swapbill)
subreddit: www.reddit.com/r/swapbill/

I just had a quick look at the github page. Do you have to use an installed litecoin qt to run this?

You need either litecoinQT or litecoind running as a backend.
(The graphical user interface of litecoinQT and the dependencies for this are not required if you use litecoind.)

A second preview release of the swapbill reference client (https://github.com/crispweed/swapbill) is now available.

The main changes for this release:

* a mechanism for single transaction 'backed' exchange of host currency for swapbill
* protocol improvements to remove the concepts of 'active' and 'spendable' balance (so no need for collect transactions, the whole balance can now be spent at any time)
* protocol improvements to increase robustness with respect to potential blockchain reorganisations
* improved user interface for coin amounts and percentages (now formatting and parsed directly as decimal fractions without floating point conversion or approximation issues)

The focus of this version is really all on improving the mechanism for exchanging swapbill for the host currency.

The backed exchange mechanism enables you to obtain some *initial* swapbill without requiring any host currency burn transaction, as long as there's swapbill available for exchange.
And this means that exchanges can now be performed with single transactions *in both directions* (so without any risk associated with being unable to complete an exchange due to DOS attacks or random events such as an internet connection going down).
And, on the other side, it's now possible to exchange all of your swapbill back to host currency, without a requirement to leave a seed amount in your active balance.

The readme (https://github.com/crispweed/swapbill/blob/master/README.md) has been updated with a walkthrough for the new transaction types.

As before, we're still looking for feedback and community involvement in SwapBill, get in touch with me directly if you're interested..

Thomas

Preview version 0.3 has now been pushed to github.
This is essentially identical to version 0.2, but with a change to the way blocks are scanned that removes the requirement for a full transaction index (txindex=1)..

v0.4 preview client has been pushed
This is just a bug fix version for a bug in the order of transaction filtering checks that resulting in synchronisation failing with an assert about 'not UnexpectedFormat_Fast'.
(Not a protocol issue.)

A new version of the SwapBill client (v0.5) has just gone live on https://github.com/crispweed/swapbill.

Notable features for this release are:

 * support for bitcoin as a host blockchain
 * the client supports switching between host blockchains (to work with 'litecoin swapbill' and 'bitcoin swapbill')
 * trustless cross-chain trading is now supported across blockchains
 * usability improvements for the existing on-chain trading functionality (for trading between swapbill and host coin)
 * documentation at readthedocs.org (http://swapbill.readthedocs.org/)

keep watching.

This looks interesting.. I'm surprised you haven't had more interest in this..

Whats the status right now?

Hi there.

The status is that the currency is working, and usable for the intended purpose, but there just doesn't seem to be enough interest in this to justify taking it on to mainnet in a full release.

The fundamental cross chain exchange mechanism is pretty solid, and something that really should be applied more generally, I think.
I made a blog post specifically about this aspect, here:
http://upcoder.com/11/atomic-cross-chain-exchange/ (http://upcoder.com/11/atomic-cross-chain-exchange/)

Yeah, I read it. It looks good.

So from what I can gather SwapBill requires an intermediary currency (e.g SwapBill BTC) to provide the flexibility of creating these new Pay on reveal secret tx types.

And by using proof of burn on a 1 to 1 ratio you are hoping that 1 SwapBill BTC always equals 1 BTC? Or perhaps just stable enough to facilitate trades that might span 24 hours..


Feels to me like "hoping" the SwapBills BTC keeps its value pegged to BTC is a weak link.. especially if you have created a whole bunch for yourself free.. (not that I think you shouldn't be paid).

I like your suggestion about getting "pay on secret reveal" implemented as a standard tx type across all coins. Seems like an easy thing to do and could eliminate the need for 3rd party exchanges.

Unless some major change has happened (to either SwapBill or to the thinking of the Bitcoin core devs) my understanding was that the ACCT (based upon TierNolan's approach) is dependent upon nLockTime which is not likely to become standard any time soon due to the fact that it creates a very simple attack vector (i.e. just exhaust the memory pool of every single node by flooding the network with future nLockTime txs).

I think by implementing his own "sidechain" tx types he doesn't need the nLockTime.. I may be wrong

> And by using proof of burn on a 1 to 1 ratio you are hoping that 1 SwapBill BTC always equals 1 BTC? Or perhaps just stable enough to facilitate trades that might span 24 hours..

The proof of burn setup provides a hard *upper cap* on swapbill value, but the actual market value of one swapbill will then float freely somewhere between 0 and 1 based on supply and demand.

The intention is that a hard upper cap will help a lot with making the currency stable, by avoiding the whole 'to the moon' thing, in a first instance.

But there is then also a bunch of functionality included to make it very easy to sell your swapbill for host currency, which should also help with stability.

The idea is that it should be almost as easy to get your initial swapbill by *exchanging* host currency for swapbill as it is to get swapbill by proof of burn. And then, as long as you think that people will want swapbill in the future, there is an incentive to buy any swapbill being offered far below the burn ratio.

The 'backed' exchange mechanism between swapbill and host currency is then also quite interesting, since this works with just one single 'atomic' exchange transaction being required in each direction. When obtaining host currency from swapbill this is naturally straightforward, but when obtaining swapbill from host currency (with a 'backed' exchange) this is based on some swapbill already being committed by a backer, and with the idea that there is a practical limit on maximum transaction throughput..

Yes, exactly.
The expiry times for SwapBill transactions are determined by the SwapBill protocol, and do not require nLockTime.

Oh - in that case it must have changed quite a bit from when I last examined it - it is now implemented as a sidechain (in accordance with the spec. for those or are you just using the same nomenclature)?

Swabill is still an 'embedded' currency (so, right, they're not actually "sidechain" transactions), but transaction expiry is nevertheless determined by an independent protocol, and nLockTime is not required.

Hi Thomas,


To be brutal, it's unfinished and advertises itself as such. A lack of polish and inadequate documentation exacerbate the unfinished feel and together, all three form the primary cause of the low level of interest expressed. The latter issues can be remedied relatively easily, leaving “just” the resolution of the described implementation issues to be addressed, either in code or in documentation.

Unit tests and coverage reports would go some way towards countering the project's current overall ambience of “mad scientist code dump”.

Cheers

Graham

Hi Graham,

> Unit tests and coverage reports would go some way towards countering the project's current overall ambience of “mad scientist code dump”.

There *are* a load of automated tests for SwapBill, in fact, including a host abstraction layer, and this all results in pretty good coverage.
This part of the project is excluded from the public release, however, at this time. :(

> To be brutal, it's unfinished and advertises itself as such. A lack of polish and inadequate documentation exacerbate the unfinished feel and together, all three form the primary cause of the low level of interest expressed.

Brutal is good, but do you have any more specific suggestions for adding polish, or improving on the current documentation (which can be found here: http://swapbill.readthedocs.org/en/latest/ (http://swapbill.readthedocs.org/en/latest/))?

I actually thought the documentation was pretty impressive for a proof-of-concept release.

Anyway, I gave it a try.. I got 0.9BTC from testnet faucet.. I burned 0.2BTC which gave me 0.2 swapbill.. then I tried a offer_buy qty of 0.2..

Now I have 0 balance of swapbill and zero balance of BTC.. lol.. dunno what happened but the coins *poof* gone :)

I think it needs a nice friendly GUI to really hold peoples hand through the process to get people involved.. but that wont guarantee success either.

I'm still skeptical that burning host currency will mean it keeps a stable value.. If I write the serial number of a 20 dollar note on a piece of paper and tear up the $20.. the paper with a serial number is not really gonna be accepted as $20 or even anything at all..

Edit: It appears I just needed to wait for a block or two for my testnet BTC change to confirm, now my BTC is back.. the 0.2 swapbill is probably committed in a pending tx i suppose.

SwapBill maps pretty directly onto the underlying Bitcoin mechanisms of unspent output and change.

There are some important reasons why this is a good thing. For example, this enables new addresses to be generated per transaction, which avoids repeatedly signing with the same public key, and so on. And this also makes it possible to make a kind of 'light' SwapBill client.

But this means that you get exactly the same issues with funds being 'locked up' in pending transactions as you see in Bitcoin.
With Bitcoin, when you make a payment, some larger valued unspent output is consumed, and you only get back the change from this unspent output once the transaction has gone through fully on the blockchain.
It's the same with SwapBill.

This is something that definitely came up as an issue in testing.
The issue was addressed *in principle* by the -i command line option, but it's certainly an area where there can be more polish.

Basically, if you add -i to the end of the command line for stuff like the get_balance query, then you'll get a balance for SwapBill state *assuming all memory pool transactions go through correctly*.
Doing a get_balance without -i tells you about the SwapBill state based only on transactions that have actually gone through in the current (longest) blockchain.

Comparing this to some Bitcoin clients, you can think of the query with -i as telling you about your actual 'spendable' balance (assuming no blockchain reorganisation), and the -i query as reporting a total balance that may include some currently unspendable part.


Yes.
Swapbill gets transferred into the buy offer.

From there the buy should either match against a sell offer (in whole or in part), be left outstanding, or expire, depending on the blocksUntilExpiry parameter.

If you have a buy offer outstanding then you should see this with the get_buy_offers query.

In general, it's possible for you to have funds locked up in buy or sell offers, or pending exchanges, and it is not easy enough, I think, to see what's going on.
To improve this I guess there should be some kind of display_all_wallet_elements (or similar, better named!) query which tells you about all this kind of stuff..


Well a copy of a serial number is not proof of burn, first of all. ;)

But, yes, just because you have proof of destruction of another currency, this doesn't *inherently* give the new currency any value.
SwapBill only has value if other people agree it has value.

Note that SwapBill is designed to have value because it has a specific *utility* (for exchange with other currencies), but the design avoids *speculative value* (with the hard value cap).
I kind of like the idea that crypto-currencies have *utility value*, but it's possible that I'm just being naive about this. :D

I like the release on key reveal, this seems like an easy tx to add to most coins..

I might start with the NXT guys, I reckon they could get it included in the reference client pretty easily.

Good news, NXT will include pay on secret reveal as part of the 2-phased transactions. Hopefully in the next few months.

That's pretty cool.

Do you know what secret hashing function they're planning to use for this?
(It's important that this is standardised.)

Do you have a link to relevant posts on their forum?

No, I don't think its been decided yet.. Probably just a simple sha256 hash to begin with for simplicity.. But I'd like to see a list of hash options to choose from.  That way clients can negotiate their hash method and choose the most appropriate.. Especially if different ALTcoins run with different hash methods.

No forum post yet.. Here is the proposal..

https://bitbucket.org/JeanLucPicard/nxt/issue/224/proposal-new-tx-type-pay-on-reveal-secret

great， thanks for your work

Public key hashes are generated by a ripemd-160 hash of the sha256 hash of the public key, and this is what SwapBill uses currently.

Using chained hash functions like this (or running more than one round of the same hash function) definitely seems like a good idea, as this gets you a whole lot of cryptographic future proofing at the expensive of just twice the hashing costs.

The exact secret hashing function used by SwapBill (in python) is as follows:


Btw. I just found the following article from Vitalik Buterin, which is pretty relevant to this point:
http://bitcoinmagazine.com/6021/bitcoin-is-not-quantum-safe-and-how-we-can-fix/
According to Vitalik, public key hashing is actually a lot stronger than the elliptic curve part with regards to stuff like potential future quantum computing based attacks, so it seems like the SwapBill secret hashing is actually pretty good.



Arg, yes, that's probably how it will all inevitably end up, I guess.
But if we *could* all standardise on one good secret hashing function it would make things a whole lot simpler and cleaner..

Which public key to you hash as the secret? obviously not one that has been made public I assume?

I agree, we should try match the swapbill method initially.

Right!

The secret for SwapBill pay on reveal secret transactions is basically just a binary string which happens to have the same length as a public key, and which can then be hashed with exactly the same code as is used for generating a bitcoin public key hash from bitcoin public key.

But this secret data is not actually used as a public key.

The secret data is managed separately from other public key data in SwapBill wallets, and is not used as a payment target, or publicly revealed in any way, except from in explicit 'reveal secret' transactions.

Are the transactions in use with swapbill actually accepted by the major bitcoin pools? I know a lot of non-standard transactions are simply not mined for safety purposes.

The current encoding from SwapBill transaction to raw Bitcoin transaction is very straightforward, doesn't require any non-standard features, and there shouldn't be any issues with either network relaying or mining of these transactions.

You can see the actual code for this here (https://github.com/crispweed/swapbill/blob/master/module/SwapBill/RawTransaction.py), in the Create() function.

(btw. The flip side of this is that this creates unspendable outputs.
It would be nicer to encode the transactions with OP_RETURN and avoid unspendable outputs, but last time I checked this wasn't considered standard by litecoind.
Changing the transaction encoding to use OP_RETURN is not hard, and doesn't affect the rest of the protocol.)

There is a big difference between non-standard features and non-standard transactions. A better question is this: have you confirmed that miners will pick up and mine these transactions on mainnet?

They're standard transactions.


Yes.

Just saw this...

https://bitsharestalk.org/index.php?topic=10132.0 (https://bitsharestalk.org/index.php?topic=10132.0)

Nice one. Thanks!