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 clearly differentiate it from Bitcoin. This also might be an interesting application of the side chains concept Peter Todd has discussed. On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote: Hello all. I understand that Proof-of-Stake as a replacement for Proof-of-Work is a prohibited yet disputed change to Bitcoin Core. I would like to create a Bitcoin branch that provides a sandboxed testbed for researching the best PoS implementations. In the years to come, perhaps circumstances might arise, such as shifting of user opinion as to whether PoS should be moved from the prohibited list to the hard-fork list. - A poll I conducted today on bitcointalk, https://bitcointalk.org/index.php?topic=581635.0 with an attention-grabbing title suggests some minority support for Bitcoin Proof-of-Stake. I invite any of you to critically comment on that thread. Annual 10% bitcoin dividends can be ours if Proof-of-Stake full nodes outnumber existing Proof-of-Work full nodes by three-to-one. What is your choice? I do not care or do not know enough. - 5 (16.1%) I would download and run the existing Proof-of-Work program to fight the change. - 14 (45.2%) I would download and run the new Proof-of-Stake program to favor the change. - 12 (38.7%) Total Voters: 31 - Before I branch the source code and learn the proper way of doing things in this community, I ask you simply if creating the branch is harmful? My goal is to develop, test and document PoS, while exploring its vulnerabilities and fixing them in a transparent fashion. Thanks for taking a bit of your time to read this message. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 to be shaken. Bitcoin is money, and money is a purely artificial social construct. The interpretation of what a bitcoin means, or what a dollar means, has always been and always will be a human decision taken in order to achieve some socially useful goal. How could it be any other way? Do you want humanity to be enslaved by its own money? This notion that the block chain encodes some kind of natural, immovable law that's above human judgement is a very strange one to me - I guess it comes from the fact that encryption *is* based on some kind of natural law. Without the key you can't decrypt a message no matter how strong the consensus is. But Bitcoin doesn't use encryption anywhere, just digital signatures. The only thing approaching natural law, that stops majority consensus controlling everything, is lack of information. Hence all the discussion around privacy and anonymity that goes on all the time. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 definition, not a successful double spend. We are worried about the cases when you could successfully double spend, and the only thing stopping you is Bitcoin. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[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 time a standard will evolve naturally rather than top-down. https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki I'd volunteer to submit a pull request if I can see some level of consent here. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 sidechains can work with PoW Bitcoin, then those same sidechains should work without any changes with PoS Bitcoin running in my testnet. I will be examining PPC, NXT and whitepapers for ideas that I can implement in such a way as the result can be called Bitcoin. The only difference would be the absence of wasteful Proof-of-Work, and the presence of mining rewards distributed to full nodes in proportion to the amount of bitcoin each is willing to expose to the network. Coin age is a good starting point. A reference peer-to-peer pool developed by me would be responsible for fairly distributing the mining rewards as daily dividend payments to PoS full node pool members. In a few days, I plan to establish a Proof-of-Stake Bitcoin project thread in the Project Development sub-forum of Bitcointalk. We can continue the technical discussion there, starting with a list of principles. Stephen L. Reed Austin, Texas, USA 512.791.7860 On Friday, April 25, 2014 4:42 AM, Jeffrey Paul sn...@acidhou.se wrote: Are proof of stake blockchains compatible with the sidechain/two-way peg system invented by Greg (and maybe others - reports unclear)? http://letstalkbitcoin.com/blockchain-2-0-let-a-thousand-chains-blossom/ It's my limited understanding that any sidechains in such a model are somewhat cryptographically tied to the PoW system that bitcoin's chain uses. I am seriously curious if alternate decentralized consensus algorithms (proof of execution, proof of stake, et c) are compatible with the sidechain universe as envisioned. Perhaps someone with a deeper technical understanding could explain how, if so, or if my incomplete hunch (that alternate consensus algorithms cannot retain compatibility with Bitcoin in a two way peg model) is correct. These sorts of alternate universe altcoin experiments with different proof models take on a different cost/benefit ratio if they can't ever interoperate as sidechains, which is why I'm curious. Best, -jp -- Jeffrey Paul +1 (312) 361-0355 5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2 On 25.04.2014, at 00:33, Troy Benjegerdes ho...@hozed.org wrote: This also might be an interesting application of the side chains concept Peter Todd has discussed. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 (well, mine anyway.) Hmm, then I think your faith needs to be shaken. Bitcoin is money, and money is a purely artificial social construct. The interpretation of what a bitcoin means, or what a dollar means, has always been and always will be a human decision taken in order to achieve some socially useful goal. My argument does not concern what a bitcoin means, just what data in the blockchain means. People are free to value an individual bitcoin however they like. But it's useful if we all agree on a standard that defines who owns them - ie. the protocol as described in Satoshi's whitepaper. I recognise that your ability to provide a valid scriptSig for /any existing UTXO in the blockchain/ as proof of your ownership of the corresponding bitcoin. You want to pick and choose which UTXO (well, coinbase; same diff) you consider valid and spendable /after they've become part of the blockchain/, regardless of the fact they're buried under PoW. As an illustration, consider Counterparty - an altcoin whose TXns are embedded as unvalidated data in the bitcoin blockchain. A lot of people imagine that an XCP transaction buried under 100 blocks and a BTC transaction buried under the same 100 blocks are equally secure. You tell me: are they? It's the same PoW chain after all. Hell no they're not! The way Counterparty interprets that data in the blockchain is anything but stable or well documented. On more than one occasion they've gone whoops, found a bug that caused some transactions to occur that we don't consider valid - we'll just fix that. A suddenly the reference client doesn't consider the XCP in your wallet valid anymore - they just magically disappear - because the parent of the TXn that paid you was actually invalid. Nobody rewrote history via PoW; they simply tweaked their interpretation of the existing history. 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 money is really mine, and we're left with a much less useful system. This should be more sacred than the 21m limit. signature.asc Description: OpenPGP digital signature -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 failed to spend your money twice. So this is by definition, not a successful double spend. We are worried about the cases when you could successfully double spend, and the only thing stopping you is Bitcoin. You might not succeed in catching them, but however small the risk of getting caught is, they're taking that risk for an assured zero gain. Any rational attacker would therefore not bother. I think it's a very elegant solution to the typical broadcast double spend attack. Of course it unfortunately does nothing to stop a dishonest mining pool from secretly working on your double spend for a fee. But that breaks down to: * trade first and hope the dishonest pool finds the next block * the dishonest pool finds and withholds the block while you trade We can discount the second one entirely - the orphan risk makes it very expensive to execute, and people are typically accepting zero-conf for low value items like cups of coffee. For high value items it is probably reasonable (and hopefully common practice?) to wait for a block. So we're left with the first situation. As others have noted, given a dishonest pool with 5% total hashrate, a dedicated attack is out (unless you want to end up actually buying goods to 20x the value of the attack in the process.) That leaves the opportunists, who press the attempt to take-back 70% of this transaction (remember the pool gets their cut) every time they buy a coffee and very occasionally get lucky. They're the only unsolvable problem I can see here. It remains to be seen how many such opportunists we'll end up with, or how much hashrate the dishonest pool can actually attract. signature.asc Description: OpenPGP digital signature -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 agree on a lowest common denominator that we agree to support ? An HD Basic if you like. For entry level users we can keep things simple and any HD Basic bitcoin will be fully interoperable. Sure, if you use anything fancy you'll be locked in to a particular wallet but a lot of users just want somewhere safe to put their bitcoin, spend it and receive it. I appreciate standising everything is very difficult (if not impossible) but if we don't have a minimum of interoperability I think we'll do our users a disservice. On Fri, Apr 25, 2014, at 11:23 AM, Andreas Schildbach wrote: 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 time a standard will evolve naturally rather than top-down. https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki I'd volunteer to submit a pull request if I can see some level of consent here. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- http://bitcoin-solutions.co.uk -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 money is really mine, and we're left with a much less useful system. This should be more sacred than the 21m limit. Well, I think we should avoid the term sacred - nothing is sacred because we're not building a religion here, we're engineering a tool. Consider a world in which 1 satoshi is too valuable to represent some kinds of transactions, so those transactions stop happening even though we all agree they're useful. The obvious solution is to change the rules so there can be 210 million coins and 10x everyones UTXOs at some pre-agreed flag day. We probably wouldn't phrase it like that, it's easier for people to imagine what's happening if it's phrased as adding more places after the decimal point or something, but at the protocol level coins are represented using integers, so it'd have to be implemented as a multiply. Would this be a violation of the social contract? A violation of all that is sacred? I don't think so, it'd just be sensible engineering and there'd be strong consensus for that exactly because 21 million *is* so arbitrary. If all balances and prices multiply 100-fold overnight, no wealth is reallocated which would be the *actual* violation of the social contract: we just get more resolution for setting prices. So. The thing that protects your money from confiscation is not proof of work. PoW is just a database synchronisation mechanism. The thing that protects your money from confiscation is a strong group consensus that theft is bad. But that's a social rule, not a mathematical rule. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP32 wallet structure in use? Remove it?
On Fri, Apr 25, 2014 at 7:53 AM, Jim jim...@fastmail.co.uk 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't want them to suffer from vendor lockin. Can we not agree on a lowest common denominator that we agree to support ? An HD Basic if you like. For entry level users we can keep things simple and any HD Basic bitcoin will be fully interoperable. Sure, if you use anything fancy you'll be locked in to a particular wallet but a lot of users just want somewhere safe to put their bitcoin, spend it and receive it. I appreciate standising everything is very difficult (if not impossible) but if we don't have a minimum of interoperability I think we'll do our users a disservice. I don't believe that wallet interoperability at this level is possible in general except as an explicit compatibility feature. I also don't believe that it is a huge loss that it is so. The structure of the derivation defines and constrains functionality. You cannot be structure compatible unless you have the same features and behavior with respect to key management. To that extent that wallets have the same features, I agree its better if they are compatible— but unless they are dead software they likely won't keep the same features for long. Even if their key management were compatible there are many other things that go into making a wallet portable between systems; the handling of private keys is just one part: a complete wallet will have other (again, functionality specific) metadata. I agree that it would be it would be possible to support a compatibility mode where a wallet has just a subset of features which works when loaded into different systems, but I'm somewhat doubtful that it would be widely used. The decision to use that mode comes at the wrong time— when you start, not when you need the features you chose to disable or when you want to switch programs. But the obvious thing to do there is to just specify that a linear chain with no further branching is that mode: then that will be the same mode you use when someone gives you a master public key and asks you to use it for reoccurring changes— so at least the software will get used. Compatibility for something like a recovery tool is another matter, and BIP32 probably defines enough there that with a bit of extra data about how the real wallet worked that recovery can be successful. Calling it vendor lock in sounds overblown to me. If someone wants to change wallets they can transfer the funds— manual handling of private keys is seldom advisable, and as is they're going to lose their metadata in any case. No one expects to switch banks and to keep their account records at the new bank. And while less than perfect, the price of heavily constraining functionality in order to get another result is just too high. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 manually. But probably a lot of people would like to use different UI's to access the same wallets. Sharing key trees is a part of that, though full blown wallet metadata sync would also be needed. So I guess we're going to end up with some kind of fairly complex compatibility matrix. But I agree it may be unavoidable. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[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 the process ends before being committed. https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 The script allows multiple standard scripts to be included in the scriptPubKey. When redeeming the script the spender indicates which of the standard scripts to use. Only one standard script is actually executed, so the only cost is the extra storage required. A more ambitious change would be a soft fork like P2SH, except the spender is allowed to select from multiple hashes. Effectively, it would be Multi-P2SH. This gets much of the benefits of MAST, but it requires a formal soft fork to implement. If there is agreement, I can code up the reference implementation as a PR. The multi-P2SH might actually be easier. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 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 the protocol, one of the participants is required to provide the secret number in order to spend an output. Once they do that, the other participant can use the secret number to spend an output on the other chain. This provides a mechanism to link the 2 chains together (in addition to lock times). Once the first output is spent, that commits the transfer. This is half of the scripting operations required to implement the protocol. The proposal is to make this an adder on to the other standard transactions. It does a check that the hash matches, and then runs the standard transaction as normal. Adding the prefix to a P2SH transactions wouldn't work, since the template wouldn't match. A script of this form could be embedded into a P2SH output. I think that is ok, since embedding the password in the hashed script gets all the benefits. If there is agreement, I can code up the reference implementation as a PR. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 - perhaps that belongs in another BIP you haven't written yet, though). IMO, it should also require P2SH. Luke On Friday, April 25, 2014 6:49:35 PM Tier Nolan wrote: 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 the process ends before being committed. https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 The script allows multiple standard scripts to be included in the scriptPubKey. When redeeming the script the spender indicates which of the standard scripts to use. Only one standard script is actually executed, so the only cost is the extra storage required. A more ambitious change would be a soft fork like P2SH, except the spender is allowed to select from multiple hashes. Effectively, it would be Multi-P2SH. This gets much of the benefits of MAST, but it requires a formal soft fork to implement. If there is agreement, I can code up the reference implementation as a PR. The multi-P2SH might actually be easier. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP - Hash Locked Transaction
On Fri, Apr 25, 2014 at 8:18 PM, Luke-Jr l...@dashjr.org 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 other chain. If you spend the output, you automatically give the other participant the password to take your coin on the other chain (completing the trade). The BIP allows the hash to protect any of other standard transactions (except P2SH, since that is a template match). For example, it would allow a script of the form OP_HASH160 [20-byte-password-hash] OP_EQUAL_VERIFY OP_DUP OP_HASH160 pubKeyHash OP_EQUALVERIFY OP_CHECKSIG To spend it, you would need to provide the password and also sign the transaction using the private key. and the assertion that it is necessary for atomic cross-chain transfers seems unfounded and probably wrong... I meant that it is required for the particular protocol. Luke -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[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 wondering therefore if either you'd be willing to edit the existing BIP, or advise on whether this is useful to write up as a new BIP? The main area of concern is handling unexpected problems while sending the Payment message, or receiving the corresponding PaymentACK message. For example, in case of a transport layer failure or non-200 HTTP status code while sending the Payment message, what should the wallet software do next? Is it safe to re-send the Payment message? I'd propose that for any transport failure or 500 status code, the client retries after a delay (suggested at 30-60 seconds). For 400 status codes, the request should not be repeated, and as such the user should be alerted and a copy of the Payment message saved to be resent later. For 300 (redirect and similar) status codes, is it considered safe to follow redirects? I think we have to, but good to make it clear in the specification. On the merchant's side; I think it would be useful for there to be guidance for handling of errors processing Payment messages. I'd suggest that Payment messages should have a fixed maximum size to avoid merchant systems theoretically having to accept files of any size; 10MB would seem far larger than in any way practical, and therefore a good maximum size? A defined maximum time to wait (to avoid DDoS via connection holding) might be useful too, although I'd need to do measurements to find what values are tolerable. I would like to have the protocol state that merchant systems should handle repeatedly receiving the same Payment message, and return an equivalent (if not identical) PaymentACK to each. This is important in case of a network failure while the client is sending the Payment message, as outlined above. Lastly, I'm wondering about potential timing issues with transactions; if a merchant system wants to see confirmation of a transaction before sending a PaymentACK, any thoughts on whether it should hold the connection, or send a PaymentACK with a memo indicating payment has been seen on the relay network but is not yet confirmed, or something else? Happy to write this up as a new BIP if that's more appropriate than editing the original, and please do tell me if I've missed anything obvious/prior discussion on this topic. Ross -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 chain transfers, but does not explain how it is useful for that - perhaps that belongs in another BIP you haven't written yet, though). IMO, it should also require P2SH. 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. -- 'peter'[:-1]@petertodd.org 6407c80d5d4506a4253b4b426e0c7702963f8bf91e7971aa signature.asc Description: Digital signature -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP - Selector Script
On Fri, Apr 25, 2014 at 8:17 PM, Luke-Jr l...@dashjr.org 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 atomic cross chain transfers, but does not explain how it is useful for that - perhaps that belongs in another BIP you haven't written yet, though). One use case should be enough. The atomic cross chain proposal has been discussed for a while. It feels like bitcoin works on an ask permission first basis. It always stalls at the fact that non-standard transactions are hard to get confirmed on other coins. It is hard to find pools on other coins which have weaker isStandard() checks. The timeouts have to be set so that they are long enough to guarantee that transactions are accepted before they expire. A testnet to testnet transfer is the best that would be possible at the moment. 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 aren't accepted in any chains, then everything stalls. Secure transfers require that the malleability issue is fixed, but that is a separate issue. I am assuming that will be fixed at some point in the future, since micro-payment channels also requires that it is fixed. IMO, it should also require P2SH. It could be restricted to only P2SH, I don't think there would be a loss in doing that. Personally, I would make it so that P2SH is mandatory after a certain time. It makes distributed verification of the block chain easier. Everything needed to verify a script is present in the transaction (except that the output actually exists). A soft fork that expands P2SH functionality would be even better, but I would rather not let the best be the enemy of the good. Luke On Friday, April 25, 2014 6:49:35 PM Tier Nolan wrote: 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 the process ends before being committed. https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 The script allows multiple standard scripts to be included in the scriptPubKey. When redeeming the script the spender indicates which of the standard scripts to use. Only one standard script is actually executed, so the only cost is the extra storage required. A more ambitious change would be a soft fork like P2SH, except the spender is allowed to select from multiple hashes. Effectively, it would be Multi-P2SH. This gets much of the benefits of MAST, but it requires a formal soft fork to implement. If there is agreement, I can code up the reference implementation as a PR. The multi-P2SH might actually be easier. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP - Selector Script
On Fri, Apr 25, 2014 at 8:58 PM, Peter Todd p...@petertodd.org 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(), rather than a protocol change. These transactions can already be mined into blocks. -- 'peter'[:-1]@petertodd.org 6407c80d5d4506a4253b4b426e0c7702963f8bf91e7971aa -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 involved in each specific transaction 2. resolution is same for everyone who makes a bet on a specific event outcome 3. no need for two-way communication 4. no need for a special protocol: oracle might publish unlocking preimage on a web page, and participants will manually enter it into their clients -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP - Selector Script
On Fri, Apr 25, 2014 at 1:02 PM, Tier Nolan tier.no...@gmail.com 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 haven't written yet, though). One use case should be enough. The atomic cross chain proposal has been discussed for a while. It feels like bitcoin works on an ask permission first basis. You're reading that response the wrong way. It isn't in any way opposed to the specification, it's pointing out that the specification is _unclear_ about the applications, it mentions one but doesn't explain it and it wouldn't be apparent to all readers. Thats all. It could be clarified by saying something like allows spending to be controlled by the publication of information, for example in another transaction so that they can only be completed atomically [citation to a revision of the contracts page]. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 advantages over approach with multi-sig script: 1. oracle doesn't need to be involved in each specific transaction 2. resolution is same for everyone who makes a bet on a specific event outcome 3. no need for two-way communication 4. no need for a special protocol: oracle might publish unlocking preimage on a web page, and participants will manually enter it into their clients 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 prove they really do have the key by signing a challenge message, and with some ECC math the transaction can include keys that have been derived from the oracle keys, blinding what purposes the oracle is being used for from the oracle itself. -- 'peter'[:-1]@petertodd.org 852baa93672889c1cc0ebe0b886b153410529d6bf404b835 signature.asc Description: Digital signature -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP - Hash Locked Transaction
On Fri, Apr 25, 2014 at 1:14 PM, Peter Todd p...@petertodd.org 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 prove they really do have the key by signing a challenge message, and with some ECC math the transaction can include keys that have been derived from the oracle keys, blinding what purposes the oracle is being used for from the oracle itself. I think the hash-locked transactions are very useful, and I think Peter agrees (no?) But I agree with him that that for the oracle case the EC public points are superior. (Also: Reality keys works like this.) -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 aren't accepted in any chains, then everything stalls. I think you may be misunderstanding what BIPs are. They do not force nodes to take on any given relay/mining policy (thus, BIPs should never talk about IsStandard at all). 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. Defining a BIP for cross-chain trading would be one way to do that. Secure transfers require that the malleability issue is fixed, but that is a separate issue. I am assuming that will be fixed at some point in the future, since micro-payment channels also requires that it is fixed. The malleability issue has been known for years. I wouldn't expect any special effort made to fix it... A soft fork that expands P2SH functionality would be even better, but I would rather not let the best be the enemy of the good. There is some ongoing discussion of a softfork to basically redo the Script language entirely, but it will take quite a bit of time and development before we'll see it in the wild. Luke P.S. Did the BIP editor assign these numbers? If not, best to keep them numberless until assigned, to avoid confusion when people Google the real BIP 44 and 45... -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Compatibility Bitcoin-Qt with Tails
Kristov, On Wed, Apr 23, 2014 at 10:05 PM, Kristov Atlas kristovat...@gmail.com 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 be fixed by 0.9.2? I've modified the gitian build so that it builds against Qt 4.6 instead of Qt 4.8 in this pull request: https://github.com/bitcoin/bitcoin/pull/4094 A test build of master with that pulls gitian descriptor is available: https://download.visucore.com/bitcoin/linux-4765b8c-gitian-2d48b96.tar.gz https://download.visucore.com/bitcoin/linux-4765b8c-gitian-2d48b96.tar.gz.sig These bitcoin-qt executables *should* work on Debian Squeeze / Tails Linux. Let me know if it is the case. Wladimir -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 laa...@gmail.com wrote: On Thu, Apr 24, 2014 at 10:15 AM, Warren Togami Jr. wtog...@gmail.com wrote: But indeed we need to decide on a cut-off point. I'd have preferred 4.7 or 4.8. Qt 4.6 is *ancient* - it was released in februari 2010. Apart from tails it doesn't seem like anyone is using those old stable distributions on the desktop. Does anyone know of the timeframe in which tails will switch to a newer version of Qt? As it's debian based: will switch to a Wheezy/7.4. Wheezy has Qt 4.8 so is decidedly unproblematic. I see they're working on migration at least: - https://tails.boum.org/blueprint/Wheezy/ - https://git-tails.immerda.ch/tails/log/?h=feature/wheezy Wladimir -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Development Roadmap of Bitcoin Core 0.9.2
On Fri, Apr 25, 2014 at 10:09 PM, Kristov Atlas aut...@anonymousbitcoinbook.com 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 - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP - Selector Script
On Fri, Apr 25, 2014 at 9:26 PM, Luke-Jr l...@dashjr.org 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 their inclusion rules for themselves. In practice, if the reference client is updated, then most miners will accept those transactions. In addition, it would eventually propagate to alt-coins (or at least the supported ones). I could simply submit the changes as a pull request for the reference client, but I was hoping that by doing it this way, it would increase the odds of it being accepted. Defining a BIP for cross-chain trading would be one way to do that. I don't think it quite requires the same coordination in the short term. I could write up the sequence as an info BIP. The malleability issue has been known for years. I wouldn't expect any special effort made to fix it... It is possible to tweak the protocol so that it still works. However, it means that 3rd parties are required (that could go in the BIP too). There is some ongoing discussion of a softfork to basically redo the Script language entirely, but it will take quite a bit of time and development before we'll see it in the wild. Implementing multi-P2SH gets a lot of the benefits of MAST, in terms of efficiency. Luke P.S. Did the BIP editor assign these numbers? If not, best to keep them numberless until assigned, to avoid confusion when people Google the real BIP 44 and 45... Not yet, but that is just my personal repo. I did email gmaxwell, but he said that they can't be assigned until some discussion has happened. I take your point that the name appears in the link though, so could cause issues with searching. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 p...@petertodd.org 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 prove they really do have the key by signing a challenge message, and with some ECC math the transaction can include keys that have been derived from the oracle keys, blinding what purposes the oracle is being used for from the oracle itself. I think the hash-locked transactions are very useful, and I think Peter agrees (no?) Yup. Revealing EC points is *not* a replacement for the hash-locked case. But I agree with him that that for the oracle case the EC public points are superior. (Also: Reality keys works like this.) Same again, and on top of that the EC public point method still works better in many circumstances with what are currently non-standard transactions rather than trying to shoe-horn everything into one big CHECKMULTISIG. 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? Last year John Dillon proposed it be replaced by a P2SH opcode whitelist(1) and I proposed some extensions(2) to the idea to make sure the whitelist didn't pose transaction mutability issues; very similar to Pieter Wuille's proposed soft-fork to stamp-out mutability.(3) The key reasons to have IsStandard() right now are the following: 1) Mitigate transaction mutability. Pieter's soft-fork mitigates mutability well, and can be applied even more easily as an IsStandard() rule. 2) Reduce the potential for scripting bugs to impact the ecosystem. The scripting system has had a lot more testing since IsStandard() was implemented. Additionally we have a large pool mining non-standard transactions anyway, mostly negating the value of IsStandard() for this purpose. 3) Ensure that after a soft-fork upgrade transactions considered IsStandard() by the the remaining non-upgraded hashing power continue to be valid. We don't want that hashing power to be able to be tricked into mining invalid blocks. Future soft-forks for transactions will most likely be done by either incrementing the transaction version number, or by redefining one of the OP_NOPx opcodes with new functionality. We just need to ignore transactions with version numbers that we are not familiar with and additionally not include any of the OP_NOPx opcodes in the whitelist. One last detail is that sigops should be taken into account when calculating fees; Luke-Jr's accept non-standard patch has code to do this already. 1) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg02606.html 2) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg02611.html 3) https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki -- 'peter'[:-1]@petertodd.org 231ff812c54986461c6f76414390f88e41476a2c2c877304 signature.asc Description: Digital signature -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP - Hash Locked Transaction
On Fri, Apr 25, 2014 at 10:14 PM, Peter Todd p...@petertodd.org 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 flexible. A whitelist of low risk opcodes seems like a reasonable compromise. My thoughts behind these two BIPs are that they are a smaller change that adds functionality required for a particular use-case (and some others). Changing the entire philosophy behind isStandard() is a much bigger change than just adding one new type. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 implementations like my own. The only issue is that it would involve a new BIP, and it wouldn't follow the BIP43 recommendation of using the BIP number as the purpose number, unless I can get BIP0. :) Aaron There's no trick to being a humorist when you have the whole government working for you -- Will Rodgers On Fri, Apr 25, 2014 at 8:49 AM, Mike Hearn m...@plan99.net wrote: 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 manually. But probably a lot of people would like to use different UI's to access the same wallets. Sharing key trees is a part of that, though full blown wallet metadata sync would also be needed. So I guess we're going to end up with some kind of fairly complex compatibility matrix. But I agree it may be unavoidable. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] New BIP32 structure for P2SH multisig wallets
Hi, I'm part of the team building copay https://github.com/bitpay/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 https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki, 2 https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki, 3https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki, 4 https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki, 5https://github.com/bitcoin/bips/pull/52). Soon, we realized the assumptions in the discussions were not true for a multisig hd wallet, so we wanted to share our current approach to that, to get feedback and see if we can arrive to a new standard (and possibly a new BIP) These are our assumptions: - N parties want to share an m-of-n wallet. - Each party must generate their master private keys independently. - Use multisig P2SH for all addresses. - Use BIP32 to derive public keys, then create a multisig script, and use the P2SH address for that. - The address generation process should not require communicating with other parties. (Thus, all parties must be able to generate all public keys) - Transaction creation + signing requires communication between parties, of course. - Following BIP43, we're be using: m / purpose' / * where *purpose* is the hardened derivation scheme based on the new BIP number. We then define the following levels: m / purpose' / cosigner_index / change / address_index Each level has a special meaning detailed below: *cosigner_index* http://en.wikipedia.org/wiki/Co-signing: the index of the party creating this address. The indices can be determined independently by lexicographically sorting the master public keys of each cosigner. *change*: 0 for change, 1 for receive address. *address_index*: Addresses are numbered from index 0 in sequentially increasing manner. We're currently syncing the max used index for each branch between all parties when they connect, but we're open to considering removing the index sync and doing the more elegant used-address discovery via a gap limit, as discussed in BIP44https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#address-gap-limit. We feel 20 might be too low though. *Wallet high-level description:* Each party generates their own extended master keypair and shares the extended purpose' public key with the others, which is stored encrypted. Each party can generate any of the other's derived public keys, but only his own private keys. *General address generation procedure:* When generating an address, each party can independently generate the N needed public keys. They do this by deriving the public key in each of the different trees, but using the same path. They can then generate the multisig script and the corresponding p2sh address. In this way, each path corresponds to an address, but the public keys for that address come from different trees. *Receive address case:* Each cosigner generates addresses only on his own branch. One of the n cosigners wants to receive a payment, and the others are offline. He knows the last used index in his own branch, because only he generates addresses there. Thus, he can generate the public keys for all of the others using the next index, and calculate the needed script for the address. *Example: *Cosigner #2 wants to receive a payment to the shared wallet. His last used index on his own branch is 4. Then, the path for the next receive address is m/$purpose/2/1/5. He uses this same path in all of the cosigners trees to generate a public key for each one, and from that he gets the new p2sh address. *Change address case:* Again, each cosigner generates addresses only on his own branch. One of the n cosigners wants to create an outgoing payment, for which he'll need a change address. He generates a new address using the same procedure as above, but using a separate index to track the used change addresses. *Example: *Cosigner #5 wants to send a payment from the shared wallet, for which he'll need a change address. His last used change index on his own branch is 11. Then, the path for the next change address is m/$purpose/5/0/12. He uses this same path in all of the cosigners trees to generate a public key for each one, and from that he gets the new p2sh address. *Transaction creation and signing:* When creating a transaction, first one of the parties creates a Transaction Proposal. This is a transaction that spends some output stored in any of the p2sh multisig addresses (corresponding to any of the copayers' branches). This proposal is sent to the other parties, who decide if they want to sign. If they approve the proposal, they can generate their needed private key for that specific address (using the same path that generated the public key in that address, but deriving the private key instead), and sign it. Once the proposal reaches m signatures, any
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 levels (wallet, chain, addresses), and use 2*N chains to handle the N different parties generating receiving and change addresses. It's not necessary, but it follows more closely the three-level scheme that BIP 32 originally envisioned. I also concluded that the chain indices are ordered by lexicographical sorting of root public keys, but resorting each individual address. There are use cases where it will be necessary for parties to know how to combine public keys into a multi-sig address without knowing the root keys. Also, for the purposes of one-off types of escrow multi-sig, we have included a wallet locator field in the transaction that must be passed around. This wallet locator is stored with each key (perhaps at the time public keys are collected and merged), and passed around with transactions to be signed. This allows lightweight devices like hardware wallets, to recognize their own keys. It would encoded in a VAR_STR, and doesn't have to be meaningful to the other participants -- each device would look at all signing slots in a transaction (either singlesig or each key in a multisig) and would generate a public key along each path, and see if the result matches. If so, it can sign it. If not, it must be someone else's. I bring this up, because this multisig wallet structure you're talking about has a very simple wallet locator scheme -- all parties will use the same locator for a given receiving address. But that field should remain part of the data structure for each key, to accommodate all types of multisig, not just linked/parallel tree schemes. -Alan On 04/25/2014 06:27 PM, Manuel Araoz wrote: Hi, I'm part of the team building copay https://github.com/bitpay/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 https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki, 2 https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki, 3 https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki, 4 https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki, 5 https://github.com/bitcoin/bips/pull/52). Soon, we realized the assumptions in the discussions were not true for a multisig hd wallet, so we wanted to share our current approach to that, to get feedback and see if we can arrive to a new standard (and possibly a new BIP) These are our assumptions: - N parties want to share an m-of-n wallet. - Each party must generate their master private keys independently. - Use multisig P2SH for all addresses. - Use BIP32 to derive public keys, then create a multisig script, and use the P2SH address for that. - The address generation process should not require communicating with other parties. (Thus, all parties must be able to generate all public keys) - Transaction creation + signing requires communication between parties, of course. - Following BIP43, we're be using: m / purpose' / * where /purpose/ is the hardened derivation scheme based on the new BIP number. We then define the following levels: m / purpose' / cosigner_index / change / address_index Each level has a special meaning detailed below: /cosigner_index/ http://en.wikipedia.org/wiki/Co-signing: the index of the party creating this address. The indices can be determined independently by lexicographically sorting the master public keys of each cosigner. /change/: 0 for change, 1 for receive address. /address_index/: Addresses are numbered from index 0 in sequentially increasing manner. We're currently syncing the max used index for each branch between all parties when they connect, but we're open to considering removing the index sync and doing the more elegant used-address discovery via a gap limit, as discussed in BIP44 https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#address-gap-limit. We feel 20 might be too low though. *Wallet high-level description:* Each party generates their own extended master keypair and shares the extended purpose' public key with the others, which is stored encrypted. Each party can generate any of the other's derived public keys, but only his own private keys. *General address generation procedure:* When generating an address, each party can independently generate the N needed public keys. They do this by deriving the public key in each of the different trees, but using the same path. They can then generate the multisig script and the corresponding p2sh address. In this way, each path corresponds to an address, but the public keys for that address come
