[Bitcoin-development] Some interviews from Amsterdam 2014
Greetings I did four interviews at the bitcoin conference Amsterdam 2014 with - Gavin Andresen - Peter Surda - Patrick Byrne - Stefan Thomas which I have finally published at https://www.youtube.com/user/WYONAPICTURES Hope you like them :-) Thanks Michael -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] DevCore London
Next week on April 15th Gavin, Wladimir, Corey and myself will be at DevCore London: https://everyeventgives.com/event/devcore-london If you're in town why not come along? It's often the case that conferences can be just talking shops, without much meat for real developers. So in the afternoon I'll be doing two things: 1. Running a hackathon/workshop type event. The theme is contracts, but we can hack on whatever you all feel like. 2. My "talk" will actually be a live coding event. Writing contracts apps has become a lot easier in the past few years, and to prove it to you I will write a decentralised cross-platform Tor supporting document timestamping app that uses OP_RETURN outputs and has a nice GUI . in 30 minutes, on stage. Don't think it can be done? Turn up and see for yourself. See you there! -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Request For Discussion / BIP number - Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets
William, I've amended the proposal's "Motivation" section slightly for clarification. I'm not sure how a "cosigner_index" branch would benefit this proposal. Granted, I don't fully understand the benefits of the "cosigner_index" branch in BIP-0045. From what I understand, the "wallet" branch of my proposal seems to accomplish a similar goal. Jona, Your explanation is correct. As for this being appropriate as a BIP, I agree that it's an arguable point to say it improves Bitcoin. However, this proposal exists because of BIP-0044, which also describes a multi-currency hierarchy. For that reason, I think this is an appropriate proposal. Thank you both for your feedback. On 04/08/2015 12:41 PM, William Swanson wrote: > Oops, sorry I missed that. > > Since that's the reason this proposal exists, I would consider putting > it right up top where people can see it. Also, since this proposal is > specifically designed for multi-sig, I would look at what BIP45 is > doing and maybe incorporate a "cosigner_index" branch. Otherwise, this > idea seems like a reasonable way to organize a wallet. > > -William > > On Wed, Apr 8, 2015 at 9:28 AM, 木ノ下じょな wrote: >> William, >> >> I believe the reasoning for this is stated in the Coin Type section. >> >> "Public derivation is used so that cosigners need only know one of each >> other's public keys, rather than needing to distribute public keys for each >> coin." >> >> BIP44 has a coin level, but it's a private derived level, so cosigners would >> not be able to generate multiple crypto currencies of each others' without >> giving each other n xpubs where n is the number of currencies shared. This >> new proposal basically sticks coin type on the public derivation side of >> things so that I could generate litecoin or darkcoin multisigs without your >> permission... >> >> Kefkius, >> >> This BIP seems like a good fit for multi-currency wallets based on multisig. >> So kudos for putting it in writing. >> >> However, I don't know if this is really a BIP thing. It's not improving >> Bitcoin (Bitcoin Improvement Proposal... remember?), in fact, by definition >> it is improving altcoin usability. >> >> For that reason alone I will say I disagree for a BIP for this. >> - Jona >> >> >> 2015-04-08 16:46 GMT+09:00 William Swanson : >>> It's not really clear why this is better than BIP 44 as it already >>> stands. You have the same fields, but they are just in a different >>> order. Couldn't you just use the existing BIP 44 hierarchy, but add >>> the convention that "wallet/account N" is the same wallet in each >>> supported currency? >>> >>> For example, if I have a wallet called "business expenses", which >>> happens to be wallet m / 44' / 0' / 5', for Bitcoin, then the same >>> wallet would be m / 44' / 3' / 5' for Dogecoin, and m / 44' / 2' / 5' >>> for Litecoin. >>> >>> I am trying to think of examples where your proposal is better than >>> BIP 44, but I can't think of any. Even backup recovery works fine. I >>> assume that your idea is to continue iterating over the different >>> wallet indices as long as you are finding funds in *any* currency. >>> Well, you can still do that with BIP 44. The fields are in a different >>> order, but that doesn't affect the algorithm in any way. >>> >>> Maybe you have some deeper insight I'm not seeing, but if so, you need >>> to clearly explain that in your motivation section. The current >>> explanation, "This limits the possible implementations of >>> multi-currency, multisignature wallets," is pretty vauge. Also, there >>> is nothing in this spec that addresses the multisignature use-case. >>> The BIP 45 spec does a lot of extra work to make multisignature work >>> smoothly. >>> >>> I'm not trying to criticize your proposal. I'm just trying to >>> understand what it's trying to accomplish. >>> >>> -William Swanson >>> >>> >>> On Wed, Apr 8, 2015 at 12:05 AM, Kefkius wrote: I have a potential BIP, "Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets." I'm requesting discussion on it, and possibly assignment of a BIP number. It's located in this github gist: https://gist.github.com/Kefkius/1aa02945e532f8739023 > -- > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own
Re: [Bitcoin-development] Build your own nHashType
On Thu, Apr 09, 2015 at 07:22:52AM -0700, Jeff Garzik wrote: > On Thu, Apr 9, 2015 at 7:10 AM, Stephen Morse > wrote: > > > Is hashing transaction data once for each input really a huge bottleneck, > > though? Do mobile devices have an issue with this? > > > > > Think about what slow transaction verification speed means. Slower > propagation across the network. More work per node. Greater opportunity > for algorithmic attacks, races and other shenanigans by attackers. Keep in mind though we can always make part of the soft-fork be to make the hash operations in the new CHECKSIG mechanism consume sigops. For the OP: Have you looked at how CODESEPARATOR allows the signature to sign code to run as part of verifying the signature? E.g. my signature can say "valid if you run these additional opcodes and they return true" where those additional opcodes take the transaction, hash it in the defined way, and verify that the ECC signature correctly signs that hash and the hash of the additional opcodes. For instance in this case making a signature that's only valid if the tx fee is less than the defined amount would be a matter of GET_FEE LESSTHAN VERIFY This can be a much more general mechanism with easy to test modular opcodes; for the consensus-critical codebase this can result in a much easier and simpler to test CHECKSIG facility than a dozen new flags. -- 'peter'[:-1]@petertodd.org 06975f442f50caa4fcc18e165746b3c77b641b75635afecb signature.asc Description: Digital signature -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Build your own nHashType
On Thu, Apr 9, 2015 at 7:10 AM, Stephen Morse wrote: > Is hashing transaction data once for each input really a huge bottleneck, > though? Do mobile devices have an issue with this? > Think about what slow transaction verification speed means. Slower propagation across the network. More work per node. Greater opportunity for algorithmic attacks, races and other shenanigans by attackers. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Build your own nHashType
> > I don't think it's quite a blank check, but it would enable replay attacks > in the form of sending the money to the same place it was sent before if an > address ever receives coins again. > Right, good point. I wonder if this sort of auto forwarding could even be a useful feature. I can't think of one right now. > It's hard, though, because there is different data needs to be signed for > each input. > Yes but is that fundamental or is there a way to avoid it? That's what I'm getting at. > Another possibility would be to put the previous scriptPubKey and previous > output value at the END of the serialized transaction, so that you could > make use of some sort of a signature hash midstate. > Interesting idea! I don't agree it's messy. If anything it should be simpler than what we have today - the need to edit a transaction *in the middle* means that sighash computation involves constantly reserializing a transaction before it even gets to be hashed. > Is hashing transaction data once for each input really a huge bottleneck, > though? Do mobile devices have an issue with this? > Consider what happens with very large transactions, like a big assurance contract that might have thousands of inputs and be multiple megabytes in size. Obviously such large transactions cannot happen today, but there is user demand for giant contracts (or at least, users tell me there is, whether they'd actually do it for real is a bit unclear). -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Build your own nHashType
Hi Mike, Hi Stephen, > > It's an interesting idea. I'm not sure that all the combinations make > sense. Excluding the connected output script or value but still signing the > prev tx hash appears pointless: the script cannot change anyway, and you > still need to know what it is to actually calculate the inputs to it, so > what is the point of this? > That's a good point, maybe SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY and SIGHASH_WITHOUT_PREV_VALUE should be assumed false, since you need the data anyway. That gets the total number of flags down to 17. If we eliminate SIGHASH_WITHOUT_TX_VERSION (I can't think of any good reason for this one), then we're down to a 2-byte nHashType. SIGHASH_SIGN_STACK_ELEMENT could also be removed, I'm not convinced of the usefulness of that one either. > > I also worry that quite a few of these combinations could be unexpectedly > dangerous. If you don't sign the prevout hash or value and combine it with > a regular pay-to-address output then you've effectively written a blank > cheque that can be used by anyone, to claim any money ever sent to that > address ... no? And then any p2p > node or miner could do so, making the transaction pretty useless. > > That isn't inherently a problem as long as people understand which > combinations have what effects or cannot be used for various reasons. But > it would need good documentation and careful thought to explore each > possibility people might use. > I don't think it's quite a blank check, but it would enable replay attacks in the form of sending the money to the same place it was sent before if an address ever receives coins again. Almost like auto-forwarding addresses. If, in addition, you signed with just that input and no outputs as well, then you're basically forfeiting your rights to any coins sent to that address. It allows for some dangerous combinations, but we already have some dangerous nHashTypes. e.g. SIGHASH_NONE | SIGHASH_ANYONECANPAY. Good documentation and careful developers shouldn't have any issues if they use a standard set of sighash flag combinations for their standard use cases. But developers that need special combinations can now use them, so long as they are careful and think things through. > > I'll leave the soft fork business to one side for now. I think any change > in CHECKSIG or new version of it would likely be ready around the same time > as the hard fork we need for changing the block size limit anyway, and it's > much cleaner to do it that way. > > The most important change that we need in sighash calculation, IMO, is > ensuring that you don't have to hash data over and over again without a > good reason. The current sighash definition is unfortunate because it's > possible to make small transactions that involve hashing huge amounts of > data. It's not clear to me that your proposal fixes that: ideally there > would be one exactly one sighash for one transaction no matter how many > checksigs are involved in verifying it. > > It's hard, though, because there is different data needs to be signed for each input. Although, I suppose if you signed your input with SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY, SIGHASH_WITHOUT_PREV_VALUE, and the equivalent of SIGHASH_ALL, then the hash that needs to be signed would be the same for all of your inputs. Strangely enough, I think we might have just found use cases for the flags that we had nearly dismissed. Another possibility would be to put the previous scriptPubKey and previous output value at the END of the serialized transaction, so that you could make use of some sort of a signature hash midstate. But that feels a little messy. It sort of makes sense to have a base serialization for a transaction and then append it with whatever input/output specific information you have, but still, messy. Is hashing transaction data once for each input really a huge bottleneck, though? Do mobile devices have an issue with this? Best, Stephen -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Build your own nHashType
Hi Stephen, It's an interesting idea. I'm not sure that all the combinations make sense. Excluding the connected output script or value but still signing the prev tx hash appears pointless: the script cannot change anyway, and you still need to know what it is to actually calculate the inputs to it, so what is the point of this? I also worry that quite a few of these combinations could be unexpectedly dangerous. If you don't sign the prevout hash or value and combine it with a regular pay-to-address output then you've effectively written a blank cheque that can be used by anyone, to claim any money ever sent to that address ... no? And then any p2p node or miner could do so, making the transaction pretty useless. That isn't inherently a problem as long as people understand which combinations have what effects or cannot be used for various reasons. But it would need good documentation and careful thought to explore each possibility people might use. I'll leave the soft fork business to one side for now. I think any change in CHECKSIG or new version of it would likely be ready around the same time as the hard fork we need for changing the block size limit anyway, and it's much cleaner to do it that way. The most important change that we need in sighash calculation, IMO, is ensuring that you don't have to hash data over and over again without a good reason. The current sighash definition is unfortunate because it's possible to make small transactions that involve hashing huge amounts of data. It's not clear to me that your proposal fixes that: ideally there would be one exactly one sighash for one transaction no matter how many checksigs are involved in verifying it. thanks, -mike -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Double spending and replace by fee
Fwiw, Coinbase relies on the current first-seen mempool behaviour. Wide adoption of RBF (without a suitable replacement available) would make it extremely difficult to pitch bitcoin as a viable alternative to credit cards payments to large merchants. Adrian > On Mar 28, 2015, at 7:22 AM, Peter Todd wrote: > > Signed PGP part > Would you so us all a favor and make a list of companies *actually* relying > on "first-seen" mempool behaviour. Because I've been having a hard time > actually finding anyone who does who hasn't given up on it. Not very useful > to talk about attacks against hypothetical defences. > > On 28 March 2015 09:58:53 GMT-04:00, Mike Hearn wrote: > >I've written a couple of blog posts on replace by fee and double > >spending > >mitigations. They sum up the last few years (!) worth of discussions on > >this list and elsewhere, from my own perspective. > > > >I make no claim to be comprehensive or unbiased but I keep being asked > >about these topics so figured I'd just write up my thoughts once so I > >can > >send links instead of answers :) And then so can anyone who happens to > >agree. > > > >(1) Replace by fee scorched earth, a counter argument: > > > >https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d > > > >This article lays out the case against RBF-SE and argues it is harmful > >to > >Bitcoin. > > > >(2) Double spending and how to make it harder: > > > >https://medium.com/@octskyward/double-spending-in-bitcoin-be0f1d1e8008 > > > >This article summarises a couple of double spending incidents against > >merchants and then discusses the following techniques: > > > > 1. Risk analysis of transactions > > 2. Payment channels > > 3. Countersigning by a trusted third party > > 4. Remote attestation > > 5. ID verification > > 6. Waiting for confirmations > > 7. Punishment of double spending blocks > > > >I hope the material is useful / interesting. > > > > > > > > > >-- > >Dive into the World of Parallel Programming The Go Parallel Website, > >sponsored > >by Intel and developed in partnership with Slashdot Media, is your hub > >for all > >things parallel software development, from weekly thought leadership > >blogs to > >news, videos, case studies, tutorials and more. Take a look and join > >the > >conversation now. http://goparallel.sourceforge.net/ > > > > > > > >___ > >Bitcoin-development mailing list > >Bitcoin-development@lists.sourceforge.net > >https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > -- > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
