Re: [Bitcoin-development] New BIP32 structure for P2SH multisig wallets

I will just chime in that I've been working on a similar spec for Armory to implement P2SH multisig and I came up with basically an identical scheme. I think you covered most of what is needed. The one thing I did differently was try to match the BIP 32 structure, by keeping the original 3 level

Re: [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)

These two BIPs are not accepted yet, so feel free to submit PRs for them. Note BIP70 is almost agnostic to transport layer. For example, I have implemented it for NFC, QR-codes, Bluetooth, e-mail and In-app payments in Bitcoin Wallet -- doesn't make much sense to put HTTP status codes into the spe

[Bitcoin-development] New BIP32 structure for P2SH multisig wallets

Hi, I'm part of the team building copay , a multisignature P2SH HD wallet. We've been following the discussion regarding standardizing the structure for branches both on this list and on github (1 , 2 <

Re: [Bitcoin-development] BIP32 "wallet structure" in use? Remove it?

On github I commented on the BIP43 pull request about adding a "purpose" of 0' which would correspond to the BIP32 recommended tree structure for a single account wallet. (m/0'/chain) This will allow for backwards compatibility and interoperability at least for existing single account BIP32 impleme

Re: [Bitcoin-development] BIP - Hash Locked Transaction

On Fri, Apr 25, 2014 at 10:14 PM, Peter Todd wrote: > Along those lines, rather than doing up yet another format specific type > as Tier Nolan is doing with his BIP, why not write a BIP looking at how > the IsStandard() rules could be removed? Removal of isStandard() would be even better/more f

Re: [Bitcoin-development] BIP - Hash Locked Transaction

On Fri, Apr 25, 2014 at 01:19:48PM -0700, Gregory Maxwell wrote: > On Fri, Apr 25, 2014 at 1:14 PM, Peter Todd wrote: > > Actually I did some work looking at this problem a few months ago and > > other than somewhat larger transactions it looks like implementing > > oracles by having the oracle re

Re: [Bitcoin-development] BIP - Selector Script

On Fri, Apr 25, 2014 at 9:26 PM, Luke-Jr wrote: > They define standard for interoperability between > software. So, if you want nodes to relay these transactions, you need to > convince them, not merely write a BIP for the transaction format. I agree with you in theory, each miner could decide

Re: [Bitcoin-development] Development Roadmap of Bitcoin Core 0.9.2

On Fri, Apr 25, 2014 at 10:09 PM, Kristov Atlas wrote: > Yes. Tails 1.1, based on Wheezy, will be out on June 10: > https://tails.boum.org/contribute/calendar/ Thanks! Wladimir -- Start Your Social Network Today - Downl

Re: [Bitcoin-development] Development Roadmap of Bitcoin Core 0.9.2

Yes. Tails 1.1, based on Wheezy, will be out on June 10: https://tails.boum.org/contribute/calendar/ -Kristov Atlas On 04/24/2014 08:18 AM, Wladimir wrote: > On Thu, Apr 24, 2014 at 10:25 AM, Wladimir wrote: >> On Thu, Apr 24, 2014 at 10:15 AM, Warren Togami Jr. >> wrote: >> >> But indeed we

Re: [Bitcoin-development] Compatibility Bitcoin-Qt with Tails

Kristov, On Wed, Apr 23, 2014 at 10:05 PM, Kristov Atlas wrote: > On 04/22/2014 09:30 AM, Warren Togami Jr. wrote: > > I see that the latest nightly build (thanks for that, Warren) is still not > compatible with Tails/Debian Squeeze. Is there still an intention to address > this issue? Might it b

Re: [Bitcoin-development] BIP - Selector Script

On Friday, April 25, 2014 8:02:41 PM Tier Nolan wrote: > I don't think the cross chain system needs a BIP (except to justify this > one). > > If cross chain transfer become popular, then it would be useful to ensure > that clients are interoperable, but first things first. If the > transactions a

Re: [Bitcoin-development] BIP - Hash Locked Transaction

On Fri, Apr 25, 2014 at 1:14 PM, Peter Todd wrote: > Actually I did some work looking at this problem a few months ago and > other than somewhat larger transactions it looks like implementing > oracles by having the oracle reveal ECC secret keys works better in > every case. Notably the oracle can

Re: [Bitcoin-development] BIP - Hash Locked Transaction

On Fri, Apr 25, 2014 at 11:06:37PM +0300, Alex Mizrahi wrote: > It is also useful for betting: an oracle will associate a hash with each > possible outcome, and when outcome is know, it will reveal a corresponding > preimage which will unlock the transaction. > > This approach has several advantag

Re: [Bitcoin-development] BIP - Selector Script

On Fri, Apr 25, 2014 at 1:02 PM, Tier Nolan wrote: >> This looks reasonable from a brief skim over, but does not define any use >> cases (it mentions "necessary for atomic cross chain transfers", but does >> not >> explain how it is useful for that - perhaps that belongs in another BIP >> you >> h

Re: [Bitcoin-development] BIP - Hash Locked Transaction

It is also useful for betting: an oracle will associate a hash with each possible outcome, and when outcome is know, it will reveal a corresponding preimage which will unlock the transaction. This approach has several advantages over approach with multi-sig script: 1. oracle doesn't need to be inv

Re: [Bitcoin-development] BIP - Selector Script

On Fri, Apr 25, 2014 at 8:58 PM, Peter Todd wrote: > Keep in mind that P2SH redeemScripts are limited to just 520 bytes; > there's going to be many cases where more complex transactions just > can't be encoded in P2SH at all. > True. Having said that, this is just a change to isStandard(), rath

Re: [Bitcoin-development] BIP - Selector Script

On Fri, Apr 25, 2014 at 8:17 PM, Luke-Jr wrote: > I believe you meant to link here instead? > https://github.com/TierNolan/bips/blob/bip4x/bip-0046.mediawiki > > Yeah, sorry. > This looks reasonable from a brief skim over, but does not define any use > cases (it mentions "necessary for atom

Re: [Bitcoin-development] BIP - Selector Script

On Fri, Apr 25, 2014 at 07:17:48PM +, Luke-Jr wrote: > I believe you meant to link here instead? > https://github.com/TierNolan/bips/blob/bip4x/bip-0046.mediawiki > > This looks reasonable from a brief skim over, but does not define any use > cases (it mentions "necessary for atomic cross

[Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)

Dear Gavin, all, Going over the payment protocol specifications, I've noticed that there's appears to be a lack of specificity on handling of error states. In most cases there are reasonably obvious solutions, however it would seem positive to formalise processes to ensure consistency. I'm wonderi

Re: [Bitcoin-development] BIP - Hash Locked Transaction

On Fri, Apr 25, 2014 at 8:18 PM, Luke-Jr wrote: > This one looks entirely useless (it cannot be made secure) The hash locking isn't to prevent someone else stealing your coin. Once a user broadcasts a transaction with x in it, then everyone has access to x. It is to release the coin on the ot

Re: [Bitcoin-development] BIP - Selector Script

I believe you meant to link here instead? https://github.com/TierNolan/bips/blob/bip4x/bip-0046.mediawiki This looks reasonable from a brief skim over, but does not define any use cases (it mentions "necessary for atomic cross chain transfers", but does not explain how it is useful for that

Re: [Bitcoin-development] BIP - Hash Locked Transaction

This one looks entirely useless (it cannot be made secure), and the assertion that it is necessary for atomic cross-chain transfers seems unfounded and probably wrong... Luke On Friday, April 25, 2014 6:49:37 PM Tier Nolan wrote: > As part of the atomic cross chain system, outputs need to be ha

[Bitcoin-development] BIP - Selector Script

This is a BIP to allow the spender to choose one of multiple standard scripts to use for spending the output. https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki This is required as part of the atomic cross chain transfer protocol. It is required so that outputs can be retrieved, if

[Bitcoin-development] BIP - Hash Locked Transaction

As part of the atomic cross chain system, outputs need to be hash locked. https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 A user needs to provide x corresponding to hash(x) in order to spend an output. Under th

Re: [Bitcoin-development] BIP32 "wallet structure" in use? Remove it?

I generally agree, but I wonder how popular cloning wallets between devices will be in future. Right now if someone wants to have a wallet shared between Hive, blockchain.info and Bitcoin Wallet for Android, we just tell them they're out of luck and they need to pick one, or split their funds up ma

Re: [Bitcoin-development] BIP32 "wallet structure" in use? Remove it?

On Fri, Apr 25, 2014 at 7:53 AM, Jim wrote: > Oh dear. > > For reasons that are perfectly reasonable we are close to losing any chance > of intra-client HD compatibility for BIP32 wallets. > > In the next 12 months there will probably be collectively millions of users > of our new wallets. I don

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

> > When you have a *bitcoin* TXn buried under 100 blocks you can be damn > sure that money is yours - but only because the rules for interpreting > data in the blockchain are publicly documented and (hopefully) > immutable. If they're mutable then the PoW alone gives me no confidence > that the mo

Re: [Bitcoin-development] BIP32 "wallet structure" in use? Remove it?

Oh dear. For reasons that are perfectly reasonable we are close to losing any chance of intra-client HD compatibility for BIP32 wallets. In the next 12 months there will probably be collectively millions of users of our new wallets. I don't want them to suffer from vendor lockin. Can we not ag

Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory

On 25/04/14 20:19, Mike Hearn wrote: > You don't get any money back, but you do get an angry shopkeeper chasing > you down the street / calling the police / blacklisting you from the > store. > > > If they could do that they'd just take the stolen property back and you > would have f

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

On 25/04/14 20:17, Mike Hearn wrote: > Proving that you can convince the economic majority that the > > interpretation of existing blocks is in any way up for grabs would set a > dangerous precedent, and shake some people's faith in Bitcoin's overall > robustness and security (wel

Re: [Bitcoin-development] Proof-of-Stake branch?

My understanding is that sidechains require merged mining support and that sidechains create no coinbase transactions themselves. When Bitcoin Core supports the two-way peg then I would update my source code branch to incorporate that or any other change that is released. Ideally, when sidechain

[Bitcoin-development] BIP32 "wallet structure" in use? Remove it?

Does anyone use or plan to use the "wallet structure" part of the BIP32 document? I suggest removing it from the document and maybe instead point at BIP43. That new specification proposal just defines a "purpose" and leaves everything else to the inventor of that purpose. The idea it that over tim

Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory

> > You don't get any money back, but you do get an angry shopkeeper chasing > you down the street / calling the police / blacklisting you from the > store. > If they could do that they'd just take the stolen property back and you would have failed to spend your money twice. So this is by definiti

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

> > Proving that you can convince the economic majority that the > interpretation of existing blocks is in any way up for grabs would set a > dangerous precedent, and shake some people's faith in Bitcoin's overall > robustness and security (well, mine anyway.) Hmm, then I think your faith needs t

Re: [Bitcoin-development] Proof-of-Stake branch?

Do it. Someone will scream harm. The loudest voices screaming how it would be harmful are doing the most harm. The only way to know is build it, and test it. If the network breaks, then it is better we find out sooner rather than later. My only suggestion is call it 'bitstake' or something to cle