There is indeed some progress as far as I heard, but nothing set in stone. Let's rather say: the whole project hasn't stalled and especially virtuals keeps pushing.

Did you send any multisig (m-of-n) transactions to it by any chance? This happend to me.


I feel like this is needed to be said since so many people report in with a similar problem:

I believe some of the stock USB cables are broken (white and blue) due to a wrong wiring. If the device is not recognized, unplug the cable immediately and if it works with another one, never use the stock cable again. Playing devils advocate: using a broken cable may harm the device.

Try to run:


This message appears, if your wallet is encrypted and this command will unlock the wallet for a moment.




Yes, I'd really like to do so and I have more than one node online which might be used for this task. But the main problem I see is security related. Creating raw transactions, preparing all commands (for bitcoin-cli or other wallets) and broadcasting the transaction in the end is fine, but I really don't want users to expose their private keys online.

An alternative could be to create a basic one-purpose "offline" and clientside based tool which allows to sign the transaction. The process would be something like:

1. Enter your wallets online, select the coins to redeem
2. Copy transaction information into the offline signing tool
3. Push the transaction online

This would minimize the risk, but maintaing usability is another topic. Well, I guess compared to now anything would be beneficial.

As a sidenote some numbers:

Out of 84'666 multisig outputs in total (as of block height 312'999) only 14'954 are redeemed - that's 17.662 %. Chancecoin currently defines the golden standard with a ratio of ~60 % redeemed outputs -- they integrated the web API directly into their client. (docs are somewhat outdated - backend can be found here)

Alright, I'm sorry for the misinformation.

Actually it looks like Electrum expected signrawrawtransaction("hex", ["privatekey"], "electrumpassword") (edit: this indicates that Electrum's signrawtransaction hsa a different behavior than Bitcoin Core and it doesn't expect a raw hex, but rather some transaction blueprint), but I was still not able to sign a transaction. I tried it with something standard, nothing special that involved multisig. :/

But: I missed the fact that you mentioned Bitcoin Qt. In the case you have a fully synced Bitcoin Core client available, it should be easy. Please follow this tutorial:

https://bitcointalk.org/index.php?topic=573342.msg6336408#msg6336408

I really have to admit, this outlines the need for easier tools. For some time I wanted to make redeem.bitwatch.co more user friendly in general, but I also see the need for a simple "sign any transaction" tool with low overhead, so it's easy to audit. Unfortunally all this is not yet done.

Please let me know, if the Bitcoin-Qt route worked.

I did some experiments and opened the USB cable. Turns out the connections are not correct.

The order of the wire colors seem to match and on the mini adapter side it's:

Red - White - Green - Black

This is how the connection between the adapters should be according to the web:

Standard => Mini
1 VBUS => 1 VBUS
2 D-   => 2 D-  
3 D+   => 3 D+  
4 GND => 5 GND

Pin 4 on the mini side is not connected.

But this is how it's actually is:

1 VBUS => 1 VBUS
2 D-   => 2 D-  
3 D+   => 5 GND (!)
4 GND => 3 D+   (!)

There is no short circuit, simply flipped associations.

It's sort of crazy, there is a psychological barrier to overcome, at least for me. It took me quite a while to move larger amounts from Electum/Core to a paper wallet. Not because I didn't trust the technology, but because paper (memory cards, or ...) feels even less tangible.

I encounter the same problem right now with my Trezor and my intermediate solution is to keep the paper untouched where it is, but move parts of the pocket money to Trezor. This feels the most secure to me, because I don't intend to spend the cold stored coins anyway and adding exposure only adds risk in my opinion. On the other hand it's great and awesome to know that the day-to-day coins are pretty untouchable now, too.

The only thing missing is support for raw transaction signing, but I haven't explored all options yet and only played around with the Trezor "web wallet". I do a lot stuff that involves handcrafting transactions, but the flow has changed from "transfer coins from Electrum to Core/daemon dev wallet" to "transfer coins from Trezor to dev wallet.".

Aah I see. I'm not sure, if this is supported. For what it's worth: if you are using Electrum by any chance, then there is also an option to sign and broadcast transactions (UI console -> signrawtransaction("hex") -> sendrawtransaction("signedhex") --- if I recall correctly).

Which Bitcoin Core client verison are you using? If you like, send me the raw transaction and I'll take a look.

The process is basically:

 - open redeem.bitwatch.co
 - paste your address into the input box
 - press "get unspent outputs"
 - copy the complete hex string at the bottom
 - power up bitcoin-qt, -cli
 - enter: signrawtransaction *hex*
 - no error should appear
 - copy this result
 - enter: sendrawtransaction *signedhex*

TIL:

- This torrent is extremely useful, thanks Jeff and all the seeders!
- DO droplets are much faster than I expected.

Could it be that Chancecoin pretty much goes through the roof at the moment? According to my logs there were more queries in the last week than in the whole time periode before.

And I see you are pushing lower fees for a while. How's that going? Are there significant confirmation delays? I'm especially interested in the fee itself, not the output amounts, because the later seems well accepted on a broader scale since ~June, at least according to my own tests.

Last note: ever thought about including change in one of the multisig packages? This pretty much kills the ability to spend the coins via standard client, but it may become more interesting once the transition to "fees per single byte" (vs. per 1000 byte, rounded up) is done.

This was tested with USB 2.0 ports on a Dell XPS 1645.

I can confirm this very odd behavior:

Win 8.1, Chrome, Trezor + original USB cable is not recognized
Win 8.1, Chrome, Trezor + Nexus 5 USB cable is recognized and working

And wow, this is a cute and nice little item! The finish surpassed my expectations.


Edit: maybe very important:

The device becomes quite warm within a few seconds with the original cable, which is not the case with the other one. Here is the heatspot:

FWIW: https://docs.google.com/spreadsheets/d/1ZenAAlcp4PPQMcG0NBWaqRuNc66vr8x8nNZZt3MA9Yo/edit?usp=sharing + imgur

For those why may remember this post - the number of 35M was actually not the number of multisig outputs, but rather the total number of all transactions.

TL;TR: proofofexistence.com appears to create more OP_RETURN outputs than OpenAssets/CoinPrism, almost all multisig outputs in the last months were created by applications on top of the blockchain and only 18 % of those multisig outputs are spent. Chancecoin is the clear winner in this discipline with a ratio of 58 % of redeemed multisig outputs. Mastercoin pretty much flatlines for some time now, Counterparty goes exponentially through the roof. Since March the number of application related transactions has increased significantly, but the overall footprint is hilarious. Over 99 % of all outputs are pay-to-pubkey-hash outputs and I could map only less than 0.2 % of all transactions to applications. The overall number of unspent outputs has risen from 9.819.223 to a total of 115.229.897 within the last three-four months. -- All data based on blocks with a height between 0-312999.

More data and all raw data is available in the above linked Google Docs document, but that were mostly the interesting parts.

You two (or rather three) miss one point. The further the price moves from where it was, the more action there is. You'll probably notice high volume peaks in most support and resistance zones.

There is Sipa's original address indexed branch which allows to list all transactions associated with an address: https://github.com/bitcoin/bitcoin/pull/2802

This branch is kept up to date by jmcorgan: https://github.com/jmcorgan/bitcoin/tree/addrindex

I wrapped an RPC call around it to explicitly list unspents from any address ("listallunspent"): https://github.com/dexX7/bitcoin/tree/master-addrindex-extended#rpc-commands

The later is also exposed via: http://redeem.bitwatch.co

And there is of course blockchain.info's API as well as insight (https://github.com/bitpay/insight), if I'm not mistaken.

You may also be successful by queriying the Electrum servers - this can be done via the Electrum client console with 'getaddressunspent("1address")'.

Does this affect all subsequent orders or only those two parties?

This is an issue, if there is a chain of unconfirmed transactions, e.g. in micropayment channels, but I don't see a problem in this context - because Bob doesn't sign the refund transaction before Alice' BTC payment confirmed anyway. The time locked approach alone is heavily in favor of Alice, but I think it's obvious this is not a replacement for an arbitrator or oracle based approach, but might be considered as an additional tool or option.

Thanks for the reading material. I highly appreciate the level of detail and surely will comment again, once I've found some time.

Cheers!

This is the utmost exciting and promising project I've seen in the last time, wow!

I'm not through the text material, but I noticed one thing:


Did you think about adding time locked transactions to all this? The basic process would be this:

1. Alice wants to sell 2 BTC for fiat, Bob agrees to buy.
2. Bob and Alice exchange public keys and create a 2-of-2 multisig wallet from which can only be spent, if both parties agree.
3. Alice prepares a transaction which sends 2 BTC to this wallet, but does not reveil it at this moment.
4. She also creates a transaction which spends those 2 BTC back to herself - from the P2SH wallet. This "refund" transaction makes use of nLockTime with a number far in the future - before this time (or block height) the transaction cannot be mined. She passes this transaction to Bob.
5. Bob signs the refund transaction.
6. Alice actually sends the 2 BTC to the 2-of-2 multisig wallet.
7. Once confirmed, Bob initiates the fiat transfers.
8. After Alice receives the fiat, both sign a transaction which spends the coins to Bob.

If Bob doesn't pay, Alice ultimately receives her coins back.
If Alice acts fraudulent and doen't release the coins with the intention of claiming the refund, she has to wait nevertheless and Bob can start to hunt her.

Combined with collaterals and arbitrators it might get even more exciting.

More: https://bitcoin.org/en/developer-guide#escrow-and-arbitration


Edit: just noticed this exists for some months.

Storj related, maybe?

Anyway, gratulations!

Yes. And it actually looks like it's ready rather sooner than later:
https://github.com/mastercoin-MSC/mastercore/blob/michael-0921/doc/apidocumentation.md#broadcasting-a-send-to-owners-transaction