Topic: SwapBill embedded protocol: preview and request for feedback (Read 7833 times)

Nice one. Thanks!

Just saw this...

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

They're standard transactions.


Yes.

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?

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, 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.)

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.

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.

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.

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

great， thanks for your work

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

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?

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

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.

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.

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.

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/)?

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

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.

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)?