Re: [Bitcoin-development] Bug in 2-of-3 transaction signing in Bitcoind?
For what it is worth, I found btcd (the go implementation of bitcoind) has much better error/diagnostics messages. It would have given you more than "-22 TX Rejected". I used it to debug my own multi-sig transactions and it was very helpful. Mike On Tue, Apr 15, 2014 at 8:42 AM, Matt Whitlock wrote: > On Tuesday, 15 April 2014, at 5:30 pm, Mike Hearn wrote: > > > > > > That's so weird, though, because we haven't been able to get anything > to > > > accept the transaction, seemingly, and yet it was accepted into the > block > > > chain 15 blocks ago. > > > > > > If the tx is already in the block chain then it won't be accepted again, > > because it would be double spending itself! > > Haha, yes, I know that. But we had been trying to get a 2-of-3 to be > accepted by something for hours, and everything was rejecting it: Coinb.in, > our local Bitcoind, the Eligius tx push form. Evidently something did > accept it and we didn't notice. We're starting over again now and trying to > reproduce the success (or failure). > > > -- > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On Wed, Mar 26, 2014 at 6:01 PM, Alan Reiner wrote: > This might be tangential, but the comment about "refund" chains reminded > me. Armory will be implementing multi-sig/linked wallets where a each > device has a parallel HDW branch and produces P2SH addresses. For those > types of wallets, I plan to allocate two chains *per signing authority*. > If you have a shared 2-of-2 wallet split between your phone and your > spouse's phone, your phone would distribute addresses on P2SH chain 0 and > generate change addresses on P2SH chain 1. Your spouse's phone would use > chains 2 and 3. > > So if you and your spouse switch to a new app that supports M-of-N linked > wallets, it should search for coin history along the first 2*N chains. > In general with multisig, we should probably discourage using a common root keychain for multiple keys in the same P2SH address. The reason is because if you have the single, root private key, you can sign them all. This generally goes against the point of multisig - which was trying to introduce a system which had multiple keys required to unlock :-) For the BitGo BIP32 implementation we are doing the following: - users create 2 extended keys - bitgo creates 1 extended key for that user - the user can create any number of separate branches (accounts) of P2SH addresses from those extended keys. - change/public addresses are generated from the 0/1 branches - new addresses are generated from there. - each time a new change address is generated, all 3 keys in the P2SH are rotated. This makes it so that for any chain depth *i* of the P2SH address, we're using the *i*th key in each keychain. For privacy reasons, we don't need to rotate all keys. But I think it makes management simpler and probably more ready for interop. So the paths in a user's keychain look exactly like BIP32's layout: m/// Another issue unique to P2SH addresses is order of the keys. There has been talk in this list of how to sort them. While sorting is simplifying for interop if you never use new change addresses, I believe sorting makes wallet management more difficult when BIP32 is introduced. Specifically, imagine a P2SH address with keys held by Bob, Charlie, and Dana. If you sort the pubkeys, then with each BIP32 chain, the order of the keys could be different. By maintaining key order, we always know which of the pubkeys belongs to which user without having to do any lookups. Obviously this can all be calculated too. But the sorting seems gratuitous to me - it adds complexity but offers little value. On the other hand, it can be really handy to know that key #0 for this address is always Bob's key, regardless of how deep the chaining goes. Mike > > -Alan > > > > > On 03/26/2014 07:37 PM, Andreas Schildbach wrote: > > Thanks for starting the discussion on finding a better structure. > > For me, the most important thing is either we're 100% interoperable or > 0%. There should not be anything inbetween, as users will delete seeds > without knowing there is still money in them on another implementation. > I heard from multiple sources that using this standard some wallets will > only see a subset of the addresses/keys of some other wallets. > Implementation differences can always happen (and should addresses as > bugs), but I think its unacceptable that this source of issues is by design. > > I suggest we agree on an even simpler least common denominator and > wallets that want to implement some feature on top of that can do but > are encouraged to pick a totally different "cointype". I guess that > would mean removing reserved and account. > > I'm still thinking it might be a good idea to have a separate chain for > "refunds". Refunds will be rarely used and thus need a much slower > moving window than receiving addresses or change. > > > On 03/26/2014 09:49 PM, Mike Hearn wrote: > > Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure > our BIP32 wallet structures would be compatible - and I discovered that > only I was planning to use the default structure. > > Because I'm hopeful that we can get a lot of interoperability between > wallets with regards to importing 12-words paper wallets, we > brainstormed to find a structure acceptable to everyone and ended up with: > > /m/cointype/reserved'/account'/change/n > > The extra levels require some explanation: > > * cointype: This is zero for Bitcoin. This is here to support two > things, one is supporting alt coins based off the same root seed. > Right now nobody seemed very bothered about alt coins but sometimes > feature requests do come in for this. Arguably there is no need and > alt coins could just use the same keys as Bitcoin, but it may help > avoid confusion if they don't. > > More usefully, cointype can distinguish between keys intended for > things like multisig outputs, e.g. for watchdog services. This means > if your wallet does not know about th
Re: [Bitcoin-development] Testnet block explorer
Great! There is another one at http://testnet.btclook.com/ which provides a different view as well. Mike On Fri, Dec 27, 2013 at 10:05 AM, Mike Hearn wrote: > For a long time the only block explorer for testnet has been the original > blockexplorer.com, which is unfortunately often broken / behind / slow > and not really maintained any more. > > There is now a new one, here: > > https://www.biteasy.com/testnet/blocks > > There's also a REST/JSON API for it. > > Please note one curiosity of this block explorer is that the coinbase tx > doesn't necessarily come first in the listing (it's sorted by "time > received", see). > > Other interesting thing to note: this site is built using bitcoinj. The > author can be contacted on IRC sometimes using the nick damethos. > > > -- > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [unSYSTEM] DarkWallet Best Practices
Hey Peter - I think this is a super list. A couple of thoughts: a) In the section on multi-sig and multi-factor, I think we can split these apart. Multi-factor user authentication is very valuable and not the same as multi-factor signing, which is a second level of complexity. The multi-factor auth can be off-blockchain, e.g. authenticating with SMS message to your phone or Google Authenticator challenge. Given the state of malware today, I personally would propose two requirements: 1) wallets SHOULD use multi-factor authentication before authorizing access to a wallet (e.g. view balances, addresses, transactions, etc) 2) wallets MUST use multi-factor auth before signing a transaction. [note: I recognize that MUST might be too aggressive right now, but I wouldn't use a wallet without it. this can also be impractical for server-side wallets] b) Multi-factor signing (e.g. P2SH) may be too early to really define. But here are some issues which have come up from my own personal development experience: - Wallets SHOULD NOT create two keys on a single host or device - Wallets SHOULD provide a way to import external public keys which can be used as part of a P2SH address Slightly off topic: For P2SH, address creation requires the public key, not the public hash of an address. For me, this has made it difficult to import keys created through out-of-band sources. Most wallets/key generators/etc only provide the address and not the public key, and this is a hinderance to easy P2SH creation off host. It would be great if there were a way to address this, but I don't know how. c) Small word-choice nit: I had to go lookup the meaning of "SHALL" (I now know it is the same as MUST). I think most RFCs just use MUST these days. Thanks, mike On Thu, Dec 19, 2013 at 8:32 AM, Drak wrote: > On 19 December 2013 16:04, Amir Taaki wrote: > >> About signing each commit, Linus advises against it: >> >> http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html > > > Yeah, it makes no sense after reading it. Nice catch. > > However, his recommendation for signing tags with `git tag -s` should > probably be incorporated into the spec as a MUST. > > Drak > > > > > -- > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Testnet under attack?
It appears that someone is minting new blocks literally every couple of seconds on the testnet chain right now. You can see it on both blockexplorer: http://blockexplorer.com/testnet and also btclook: http://testnet.btclook.com/ Is this something we should worry about? thanks, Mike -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
