Quote from: slothbag on December 20, 2014, 06:07:24 AM

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.

Quote from: slothbag on December 20, 2014, 06:07:24 AM

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

Quote from: slothbag on December 20, 2014, 06:07:24 AM

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

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