I think by implementing his own "sidechain" tx types he doesn't need the nLockTime.. I may be wrong
Yes, exactly.
The expiry times for SwapBill transactions are determined by the SwapBill protocol, and do not require nLockTime.
Topic: SwapBill embedded protocol: preview and request for feedback - page 2. (Read 7833 times)
Yes, exactly.
The expiry times for SwapBill transactions are determined by the SwapBill protocol, and do not require nLockTime.
> 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..
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..
I think by implementing his own "sidechain" tx types he doesn't need the nLockTime.. I may be wrong
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).
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.
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.
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/
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/
This looks interesting.. I'm surprised you haven't had more interest in this..
Whats the status right now?
Whats the status right now?
keep watching.
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/)
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/)
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.)
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.)
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)..
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)..
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
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
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.)
I just had a quick look at the github page. Do you have to use an installed litecoin qt to run this?
links:
github: https://github.com/crispweed/swapbill
twitter: @swapbill
subreddit: www.reddit.com/r/swapbill/
github: https://github.com/crispweed/swapbill
twitter: @swapbill
subreddit: www.reddit.com/r/swapbill/
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!
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!
Jump to: