SwapBill embedded protocol: preview and request for feedback

[slothbag]

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.

[1715143654]

1715143654

[1715143654]

1715143654

[1715143654]

1715143654

[crispweed]

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

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.

the 0.2 swapbill is probably committed in a pending tx i suppose.

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

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

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.

[slothbag]

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.

[slothbag]

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

[crispweed]

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?

[slothbag]

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

[Counterpartybtc]

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

great， thanks for your work

[crispweed]

Probably just a simple sha256 hash to begin with for simplicity..

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:

Code:

import hashlib
def publicKeyToPubKeyHash(publicKey):
    assert type(publicKey) is type(b'')
    assert len(publicKey) == 64
    ripemd160 = hashlib.new('ripemd160')
    ripemd160.update(hashlib.sha256(b'\x04' + publicKey).digest())
    return ripemd160.digest()

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.

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.

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

[slothbag]

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.

[crispweed]

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

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.

[monsterer]

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.

[crispweed]

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

[monsterer]

doesn't require any non-standard features, and there shouldn't be any issues with either network relaying or mining of these transactions.

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?

[crispweed]

doesn't require any non-standard features, and there shouldn't be any issues with either network relaying or mining of these transactions.

There is a big difference between non-standard features and non-standard transactions.

They're standard transactions.

A better question is this: have you confirmed that miners will pick up and mine these transactions on mainnet?

Yes.

[slothbag]

Just saw this...

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

[crispweed]

Just saw this...

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

Nice one. Thanks!