Bitcoin Forum
July 08, 2024, 09:35:43 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Alternate cryptocurrencies / Altcoin Discussion / Re: SwapBill embedded protocol: preview and request for feedback on: January 02, 2015, 10:37:57 AM

Nice one. Thanks!
2  Alternate cryptocurrencies / Altcoin Discussion / Re: SwapBill embedded protocol: preview and request for feedback on: December 30, 2014, 03:58:12 PM
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.
3  Alternate cryptocurrencies / Altcoin Discussion / Re: SwapBill embedded protocol: preview and request for feedback on: December 29, 2014, 03:36:34 PM
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.)
4  Alternate cryptocurrencies / Altcoin Discussion / Re: SwapBill embedded protocol: preview and request for feedback on: December 29, 2014, 03:14:11 PM
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.
5  Alternate cryptocurrencies / Altcoin Discussion / Re: SwapBill embedded protocol: preview and request for feedback on: December 29, 2014, 11:05:17 AM
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..
6  Alternate cryptocurrencies / Altcoin Discussion / Re: SwapBill embedded protocol: preview and request for feedback on: December 25, 2014, 10:30:46 AM
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?
7  Alternate cryptocurrencies / Altcoin Discussion / Re: SwapBill embedded protocol: preview and request for feedback on: December 20, 2014, 10:58:28 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 Smiley

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. 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
8  Alternate cryptocurrencies / Altcoin Discussion / Re: SwapBill embedded protocol: preview and request for feedback on: December 19, 2014, 02:03:34 PM
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. Sad

> 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/)?
9  Alternate cryptocurrencies / Altcoin Discussion / Re: SwapBill embedded protocol: preview and request for feedback on: December 19, 2014, 01:00:00 PM
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.
10  Alternate cryptocurrencies / Altcoin Discussion / Re: SwapBill embedded protocol: preview and request for feedback on: December 19, 2014, 12:53:29 PM
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.
11  Alternate cryptocurrencies / Altcoin Discussion / Re: SwapBill embedded protocol: preview and request for feedback on: December 19, 2014, 12:51:04 PM
> 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..
12  Alternate cryptocurrencies / Altcoin Discussion / Re: SwapBill embedded protocol: preview and request for feedback on: December 19, 2014, 11:01:52 AM
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/
13  Economy / Trading Discussion / Blog post about cross chain trading on: November 20, 2014, 04:15:59 PM
Hi,

I just posted this, about atomic cross chain trading, and proposing a standardised set of fundamental transaction semantics for this:
http://upcoder.com/11/atomic-cross-chain-exchange/

Feedback welcome!

Thomas
14  Alternate cryptocurrencies / Altcoin Discussion / Client update, trustless cross-chain trading support on: September 11, 2014, 08:26:10 AM
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/)
15  Alternate cryptocurrencies / Altcoin Discussion / Preview client v0.4 pushed on: July 04, 2014, 07:57:50 AM
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.)
16  Bitcoin / Development & Technical Discussion / Re: getrawtransactionsinblock RPC command on: June 26, 2014, 08:21:58 AM
For reference, for anyone coming across this post from a search or whatever, have a look at this blog post for a working alternative to the getrawtransactionsinblock rpc command I suggested above..
17  Bitcoin / Development & Technical Discussion / Blog post: Fast blockchain scanning on: June 20, 2014, 01:11:05 PM
I just added a blog post about faster blockchain scanning through bitcoind RPC calls, by replacing gettransaction queries per transaction with getblock <blockhash> false and DIY block and transaction decoding.

The blog post is here:
http://upcoder.com/8/fast-blockchain-scanning/

Feedback welcome.

Thomas
18  Alternate cryptocurrencies / Altcoin Discussion / Preview version 0.3 on: June 19, 2014, 03:46:39 PM
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)..
19  Bitcoin / Development & Technical Discussion / Re: getrawtransactionsinblock RPC command on: June 19, 2014, 02:07:25 PM
and.. closed
It turns out there's a second parameter to getblock, (not listed on the wiki) and you can call getblock <blockhash> false to get the raw block data, that can be parsed pretty straightforwardly to obtain the raw transaction data I need..
20  Bitcoin / Development & Technical Discussion / Re: getrawtransactionsinblock RPC command on: June 19, 2014, 01:18:10 PM
Ok, pull request is here: https://github.com/bitcoin/bitcoin/pull/4369
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!