crispweed



Offline



Activity: 27

Merit: 0







NewbieActivity: 27Merit: 0 SwapBill embedded protocol: preview and request for feedback May 28, 2014, 11:25:06 AM

Last edit: June 19, 2014, 03:47:13 PM by crispweed #1



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!

Announcing a preview release of SwapBill, an embedded protocol focusing on altcoin exchange features.The release can be found here: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 outputsSwapBill 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 blockchainA 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!

AWARD-WINNING

CASINO CRYPTO EXCLUSIVE

CLUBHOUSE 1500+

GAMES 2 MIN

CASH-OUTS 24/7

SUPPORT 100s OF

FREE SPINS PLAY NOW dvertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here. dvertised sites arenotendorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, orillegal in your jurisdiction.

crispweed



Offline



Activity: 27

Merit: 0







NewbieActivity: 27Merit: 0 Second preview release of SwapBill reference client June 18, 2014, 01:13:43 PM #5



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.



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 A second preview release of the swapbill reference client 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 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

crispweed



Offline



Activity: 27

Merit: 0







NewbieActivity: 27Merit: 0 Preview version 0.3 June 19, 2014, 03:46:39 PM #6 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)..

crispweed



Offline



Activity: 27

Merit: 0







NewbieActivity: 27Merit: 0 Preview client v0.4 pushed July 04, 2014, 07:57:50 AM #7 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.)



crispweed



Offline



Activity: 27

Merit: 0







NewbieActivity: 27Merit: 0 Client update, trustless cross-chain trading support September 11, 2014, 08:26:10 AM #8



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 (

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/

crispweed



Offline



Activity: 27

Merit: 0







NewbieActivity: 27Merit: 0 Re: SwapBill embedded protocol: preview and request for feedback December 19, 2014, 11:01:52 AM #11



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/

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:

slothbag



Offline



Activity: 369

Merit: 250









Sr. MemberActivity: 369Merit: 250 Re: SwapBill embedded protocol: preview and request for feedback December 19, 2014, 12:35:04 PM #12 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.





crispweed



Offline



Activity: 27

Merit: 0







NewbieActivity: 27Merit: 0 Re: SwapBill embedded protocol: preview and request for feedback December 19, 2014, 12:51:04 PM

Last edit: December 19, 2014, 01:08:09 PM by crispweed #15 > 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..



gjhiggins



Offline



Activity: 1946

Merit: 1134









LegendaryActivity: 1946Merit: 1134 Re: SwapBill embedded protocol: preview and request for feedback December 19, 2014, 01:53:23 PM #19



Quote from: crispweed on December 19, 2014, 11:01:52 AM 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.



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 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.CheersGraham