PyWallet import should be fixed now. I'll add labels to paper wallets soon.

O/T: FFS why did silk road have to allow selling guns on the site. I got about 10 emails today from family and friends:


They have really shot themselves and bitcoin in the foot.

It comforting to know security experts are reviewing the code and this is the best exploit they can come up with.

You need to add ?multsig=true to your login url e.g. mine

https://blockchain.info/wallet/piuk?multisig=true

It is not ready for use yet, redemption is proving to be a bit of an up hill struggle but I think i've found a good solution now.

MORA: Thanks, i fixed it yesterday.

Split key is a step in the right direction, but it is not some magic solution that instantly solves all security problems. If a User has one half of their private keys on their phone what happens when they drop it in a river on a night out... If your trusting your split keys with a "wallet protection service" there is no way you can be sure they aren't colluding with other entity - or go rogue and hold you keys to ransom.

Whilst I do agree it would be best for everyone to just move forward with BIP 16 (since the wheels are already in motion). There is still no need to rush it, make the decision now, but the switch on date should still be at least a few months in the future (not a ~week as in the original proposal). Ideally there should at least one new client release before the change is switched on, giving both miners, users and merchants opportunity to upgrade.

Follow the example of Satashi. A change he made two years ago to the bitcoin client is only just being activated now http://bitcoin.stackexchange.com/questions/2788/what-are-the-february-20-changes-to-the-bitcoin-protocol

Sorry, everyone got two incorrect notifications from 1Vay due a bug when I pushed the multi-sig update. It is fixed now.

The good news is the the block explorer now supports M-Of-N Multisigs (No P2SH quite yet). I am using "Escrow" as the terminology for multi-sig (P2SH will be "Split Key"). Example:



Escrow transactions will show on the results page of every address involved however the value will not be included in the final balance or in the total received.

You can also construct escrow transactions with My Wallet but you cannot redeem them yet (Redemption will be available tomorrow). Add "?multisig=true" to your My Wallet login page.



More updates tomorrow when redemption is working.

farfiman: Thanks, I've updated it

They were made standard recently. The problem was m & n are not actually numbers they are op codes e.g. OP_TURE, OP_2

My test transaction finally got mined by Ozcoin:

https://blockchain.info/tx/60a20bd93aa49ab4b28d514ec10b06e1829ce6818ec06cd3aabd013ebcdc4bb1?show_adv=true

So I've made a bit of progress and have patched bitcoin-js so it can generate multi-sig transactions and also patched my bitcoind with the latest git Script changes.

However for some reason the MultiSig transactions are not passing IsStandard() and are being rejected.


Just to confirm should n & m be pushed onto the stack as if they were data?

I think this might be one http://blockchain.info/tx-index/14682055?show_adv=true

Some small updates

On Address pages you can now filter by Sent/Received/Escrow(Multi Sig)

Double spends page - http://blockchain.info/double-spends

Explanation of My Wallet JSON Format - https://blockchain.info/wallet/wallet-format

I need someone to create and redeem one M-Of-N transaction and one P2SH transaction on main net.

Offering modest bounty of 2 BTC.

My Wallet can do this (offline or online). 0.005 - 0.01 BTC fee per tx.

This should now be fixed. Sorry for missing your previous post.

Thanks, I've added both ips. Just to clarify which IP are solved blocks be relayed from?


----

You can now set a second password for your My Wallet account to enable double encryption. The private keys inside your wallet will be individually encrypted with your second password using the shared key as a salt. This should make it much safer to login on an untrusted machine to check your balance. When paired with two-factor authentication you have pretty good protection from key loggers.

Thank You to everyone that honoured the bounty. All payments have been received.

Next on my TODO list is to make an API call that merchants can use.

Received, cheers Tycho.

Added.


Thats great, Thank you to the both of you.

New Address 1JArS6jzE3AJ9sZ3aFij1BmTcpFGgN86hA

Probably just accidental:

http://blockchain.info/tx-index/14760752/2c412e1ab2c66590f9be8d43e4d787eeaca167cec9a6a5f57651482ef2e737aa?show_adv=true
http://blockchain.info/tx-index/14760749/5a875fe607947f5d914eb5ef2ba7c7f6fb2319ceb77485297a7df520ccf7def0?show_adv=true

Two very similar, but with one different output address. The value probably isn't high enough to be malicious.

http://blockchain.info/tx-index/13084119/c407cc2973c191e50f6ef01630b417d0814e5030f493629c062a5852e94b8bd0

Is the only double spend between different orphaned branches in the entire database. I imported the blockchain from bitcoinchart's dump which contains orphaned blocks from way back in 2010, so it looks like there hasn't been any successful double spend attempts of any value.

Tycho, When I initially made the double spend page there was only one transaction, now there are 4. Is that you testing it?

I PM'd the other bounty contributors, but I don't think they are active anymore.

BIP 0011 has been accepted and is already supported by the network - yet there are no clients that have a ui to construct Multi-sig transactions yet. Perhaps that should be priority? bitcoin-qt has no ui for constructing P2SH transactions. I also expect there will be situations where people try and send funds to a pay to script addresses from clients / exchanges that don't have P2SH support, sending the BTC into a black hole. I don't see the point in rushing it.