Re: [Bitcoin-development] Block Size Increase
This isn't about everyone's coffee. This is about an absolute minimum amount of participation by people who wish to use the network. If our goal is really for bitcoin to really be a global, open transaction network that makes money fluid, then 7tps is already a failure. If even 5% of the world (350M people) was using the network for 1 tx per month (perhaps to open payment channels, or shift money between side chains), we'll be above 100 tps. And that doesn't include all the non-individuals (organizations) that want to use it. The goals of a global transaction network and everyone must be able to run a full node with their $200 dell laptop are not compatible. We need to accept that a global transaction system cannot be fully/constantly audited by everyone and their mother. The important feature of the network is that it is open and anyone *can* get the history and verify it. But not everyone is required to. Trying to promote a system where the history can be forever handled by a low-end PC is already falling out of reach, even with our miniscule 7 tps. Clinging to that goal needlessly limits the capability for the network to scale to be a useful global payments system On 05/07/2015 03:54 PM, Jeff Garzik wrote: On Thu, May 7, 2015 at 3:31 PM, Alan Reiner etothe...@gmail.com mailto:etothe...@gmail.com wrote: (2) Leveraging fee pressure at 1MB to solve the problem is actually really a bad idea. It's really bad while Bitcoin is still growing, and relying on fee pressure at 1 MB severely impacts attractiveness and adoption potential of Bitcoin (due to high fees and unreliability). But more importantly, it ignores the fact that for a 7 tps is pathetic for a global transaction system. It is a couple orders of magnitude too low for any meaningful commercial activity to occur. If we continue with a cap of 7 tps forever, Bitcoin *will* fail. Or at best, it will fail to be useful for the vast majority of the world (which probably leads to failure). We shouldn't be talking about fee pressure until we hit 700 tps, which is probably still too low. [...] 1) Agree that 7 tps is too low 2) Where do you want to go? Should bitcoin scale up to handle all the world's coffees? This is hugely unrealistic. 700 tps is 100MB blocks, 14.4 GB/day -- just for a single feed. If you include relaying to multiple nodes, plus serving 500 million SPV clients en grosse, who has the capacity to run such a node? By the time we get to fee pressure, in your scenario, our network node count is tiny and highly centralized. 3) In RE fee pressure -- Do you see the moral hazard to a software-run system? It is an intentional, human decision to flood the market with supply, thereby altering the economics, forcing fees to remain low in the hopes of achieving adoption. I'm pro-bitcoin and obviously want to see bitcoin adoption - but I don't want to sacrifice every decentralized principle and become a central banker in order to get there. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On 05/08/2015 01:13 AM, Tom Harding wrote: On 5/7/2015 7:09 PM, Jeff Garzik wrote: G proposed 20MB blocks, AFAIK - 140 tps A proposed 100MB blocks - 700 tps For ref, Paypal is around 115 tps VISA is around 2000 tps (perhaps 4000 tps peak) For reference, I'm not proposing 100 MB blocks right now. I was simply suggesting that if Bitcoin is to *ultimately* achieve the goal of being a globally useful payment rails, 7tps is embarrassingly small. Even with off-chain transactions. It should be a no-brainer that block size has to go up. My goal was to bring some long-term perspective into the discussion. I don't know if 100 MB blocks will *actually* be necessary for Bitcoin in 20 years, but it's feasible that it will be. It's an open, global payments system. Therefore, we shouldn't be arguing about whether 1 MB blocks is sufficient--it's very clearly not. And admitting this as a valid point is also an admission that not everyone in the world will be able to run a full node in 20 years. I don't think there's a solution that can accommodate all future scenarios, nor that we can even find a solution right now that avoids more hard forks in the future. But the goal of everyone should be able to download and verify the world's global transactions on a smartphone is a non-starter and should not drive decisions. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
Actually I believe that side chains and off-main-chain transactions will be a critical part for the overall scalability of the network. I was actually trying to make the point that (insert some huge block size here) will be needed to even accommodate the reduced traffic. I believe that it is definitely over 20MB. If it was determined to be 100 MB ten years from now, that wouldn't surprise me. Sent from my overpriced smartphone On May 8, 2015 1:17 PM, Andrew onelinepr...@gmail.com wrote: On Fri, May 8, 2015 at 2:59 PM, Alan Reiner etothe...@gmail.com wrote: This isn't about everyone's coffee. This is about an absolute minimum amount of participation by people who wish to use the network. If our goal is really for bitcoin to really be a global, open transaction network that makes money fluid, then 7tps is already a failure. If even 5% of the world (350M people) was using the network for 1 tx per month (perhaps to open payment channels, or shift money between side chains), we'll be above 100 tps. And that doesn't include all the non-individuals (organizations) that want to use it. The goals of a global transaction network and everyone must be able to run a full node with their $200 dell laptop are not compatible. We need to accept that a global transaction system cannot be fully/constantly audited by everyone and their mother. The important feature of the network is that it is open and anyone *can* get the history and verify it. But not everyone is required to. Trying to promote a system wher000e the history can be forever handled by a low-end PC is already falling out of reach, even with our miniscule 7 tps. Clinging to that goal needlessly limits the capability for the network to scale to be a useful global payments system These are good points and got me thinking (but I think you're wrong). If we really want each of the 10 billion people soon using bitcoin once per month, that will require 500MB blocks. That's about 2 TB per month. And if you relay it to 4 peers, it's 10 TB per month. Which I suppose is doable for a home desktop, so you can just run a pruned full node with all transactions from the past month. But how do you sync all those transactions if you've never done this before or it's been a while since you did? I think it currently takes at least 3 hours to fully sync 30 GB of transactions. So 2 TB will take 8 days, then you take a bit more time to sync the days that passed while you were syncing. So that's doable, but at a certain point, like 10 TB per month (still only 5 transactions per month per person), you will need 41 days to sync that month, so you will never catch up. So I think in order to keep the very important property of anyone being able to start clean and verify the thing, then we need to think of bitcoin as a system that does transactions for a large number of users at once in one transaction, and not a system where each person will make a ~monthly transaction on. We need to therefore rely on sidechains, treechains, lightning channels, etc... I'm not a bitcoin wizard and this is just my second post on this mailing list, so I may be missing something. So please someone, correct me if I'm wrong. On 05/07/2015 03:54 PM, Jeff Garzik wrote: On Thu, May 7, 2015 at 3:31 PM, Alan Reiner etothe...@gmail.com wrote: (2) Leveraging fee pressure at 1MB to solve the problem is actually really a bad idea. It's really bad while Bitcoin is still growing, and relying on fee pressure at 1 MB severely impacts attractiveness and adoption potential of Bitcoin (due to high fees and unreliability). But more importantly, it ignores the fact that for a 7 tps is pathetic for a global transaction system. It is a couple orders of magnitude too low for any meaningful commercial activity to occur. If we continue with a cap of 7 tps forever, Bitcoin *will* fail. Or at best, it will fail to be useful for the vast majority of the world (which probably leads to failure). We shouldn't be talking about fee pressure until we hit 700 tps, which is probably still too low. [...] 1) Agree that 7 tps is too low 2) Where do you want to go? Should bitcoin scale up to handle all the world's coffees? This is hugely unrealistic. 700 tps is 100MB blocks, 14.4 GB/day -- just for a single feed. If you include relaying to multiple nodes, plus serving 500 million SPV clients en grosse, who has the capacity to run such a node? By the time we get to fee pressure, in your scenario, our network node count is tiny and highly centralized. 3) In RE fee pressure -- Do you see the moral hazard to a software-run system? It is an intentional, human decision to flood the market with supply, thereby altering the economics, forcing fees to remain low in the hopes of achieving adoption. I'm pro-bitcoin and obviously want to see bitcoin adoption - but I don't want to sacrifice every decentralized principle and become a central
Re: [Bitcoin-development] Block Size Increase
This *is* urgent and needs to be handled right now, and I believe Gavin has the best approach to this. I have heard Gavin's talks on increasing the block size, and the two most persuasive points to me were: (1) Blocks are essentially nearing full now. And by full he means that the reliability of the network (from the average user perspective) is about to be impacted in a very negative way (I believe it was due to the inconsistent time between blocks). I think Gavin said that his simulations showed 400 kB - 600 kB worth of transactions per 10 min (approx 3-4 tps) is where things start to behave poorly for certain classes of transactions. In other words, we're very close to the effective limit in terms of maintaining the current standard of living, and with a year needed to raise the block time this actually is urgent. (2) Leveraging fee pressure at 1MB to solve the problem is actually really a bad idea. It's really bad while Bitcoin is still growing, and relying on fee pressure at 1 MB severely impacts attractiveness and adoption potential of Bitcoin (due to high fees and unreliability). But more importantly, it ignores the fact that for a 7 tps is pathetic for a global transaction system. It is a couple orders of magnitude too low for any meaningful commercial activity to occur. If we continue with a cap of 7 tps forever, Bitcoin *will* fail. Or at best, it will fail to be useful for the vast majority of the world (which probably leads to failure). We shouldn't be talking about fee pressure until we hit 700 tps, which is probably still too low. You can argue that side chains and payment channels could alleviate this. But how far off are they? We're going to hit effective 1MB limits long before we can leverage those in a meaningful way. Even if everyone used them, getting a billion people onto the system just can't happen even at 1 transaction per year per person to get into a payment channel or move money between side chains. We get asked all the time by corporate clients about scalability. A limit of 7 tps makes them uncomfortable that they are going to invest all this time into a system that has no chance of handling the economic activity that they expect it handle. We always assure them that 7 tps is not the final answer. Satoshi didn't believe 1 MB blocks were the correct answer. I personally think this is critical to Bitcoin's long term future. And I'm not sure what else Gavin could've done to push this along in a meaninful way. -Alan On 05/07/2015 02:06 PM, Mike Hearn wrote: I think you are rubbing against your own presupposition that people must find and alternative right now. Quite a lot here do not believe there is any urgency, nor that there is an immanent problem that has to be solved before the sky falls in. I have explained why I believe there is some urgency, whereby some urgency I mean, assuming it takes months to implement, merge, test, release and for people to upgrade. But if it makes you happy, imagine that this discussion happens all over again next year and I ask the same question. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
I'll add fuel to the fire here, and express that I believe that replace-by-fee is good in the long-term. Peter is not breaking the zero-conf, it was already broken, and not admitting it creates a false sense of security. I don't want to see systems that are built on the assumption that zero-conf tx are safe solely because it has always appeared safe. You can argue about rational miner behaviors all day, but in a decentralized system you have no idea what miners consider rational, or speculate about their incentives. If there's one thing I learned playing poker (many years ago), was that always assuming your opponent is rational can lose you a lot of money. You made play that, in hindsight, was terrible given what he actually had. But you assumed no sane or rational person in his position would make such a play so you discounted it in your decision-making process. You're right that his actions were terrible and irrational, but he still won your money because you discounted his ability to make such a bad play. Here, you are speculating that an opponent uses the same values/motivations/rationality as yourself, and then building systems that depend on that being true. Even if it should be true doesn't mean that it is true and will remain that way. And you will get burned by it eventually. The Bitcoin network achieves something that we didnt' think was possible 10 years ago: a totally trustless, decentralized ledger. The cost? It takes time for the decentralized network to reach consensus that transactions happened. That is quite literally the trade-off that we make: you can centralize things by putting a bank in the middle and getting instant confirmation, or you decentralize and let the network reach consensus over time without the central authority. If you want instant confirmations, you're going to need to add centralization because Bitcoin never offered it. I support efforts to dispel any such myths as soon as possible and encourage building robust solutions (payment channels, insured zero-conf services, etc.). -Alan On 02/12/2015 07:37 PM, Allen Piscitello wrote: You cannot close Pandora's box. Whether or not this type of patch should exist is irrelevant. It does, and there are incentives to use it by miners. These are the bounds we have to deal with and the world we must adapt to. On Thu, Feb 12, 2015 at 12:11 PM, Justus Ranvier justusranv...@riseup.net mailto:justusranv...@riseup.net wrote: On 02/12/2015 05:24 PM, Oleg Andreev wrote: I think that is a misdirection on your part. The point of replace-by-fee is to make 0-confirms reliably unreliable. Currently people can get away with 0-confirms but it's only because most people arent actively double spending, and when they do it is for higher value targets. Double spend attacks are happening a lot more frequently than is being admitted here, according to Peter from work with various clients. Like single address reuse, people have gotten used to something which is bad. Generally accepting 0-conf is also a bad idea(tm) and instant confirmation solutions should be sought elsewhere. There are already interesting solutions and concepts: greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment channels for example. Rather than supporting and promoting risky 0-confirms, we need to spend time on better alternative solutions that will work for everyone and not during the honeymoon phase where attackers are fewer. Here's value-free assessment of the issue here: 1. Zero-conf txs are unsafe. 2. We'd all want to have a safer instant payments solution if possible. 3. As a social artifact, today zeroconf txs happen to work for some people in some situations. 4. Replace-by-fee will break #3 and probably hasten development of #2. The discussion boils down to whether we should make #2 happen sooner by breaking remnants of #3 sooner. I personally would rather not break anything, but work as fast as possible on #2 so no matter when and how #3 becomes utterly broken, we have a better solution. This implies that I also don't want to waste time debating with Peter Todd and others. I want to be ready with a working tool when zeroconf completely fails (with that patch or for some other reasons). TL;DR: those who are against the patch are better off building a decentralized clearing network rather than wasting time on debates. When we have such network, we might all want this patch to be used for all the reasons Peter has already outlined. You've left out of the discussion that many (or all) proposed solutions for 2 either reduce privacy, or security, or both. That fact should not be ignored or swept under the rug. There's also no mention of the degree to which child-pays-for-parent achieves the stated aims of the original proposal (clearing mempool of stuck transactions, increasing payee assurance of conformation) without introducing incentives to double
Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE
On 01/23/2015 11:27 AM, Alan Reiner wrote: I am happy to entertain other ideas that achieve our goals here, but I'm fairly confident that the new SIGHASH type is the only way that would allow devices like Trezor to truly simplify their design (and still work securely on 100% of funds contained by the wallet). Self-correction ... I didn't mean it's the only way, I mean it's by far the easiest, simplest, least-intrusive way that achieves the properties we need for this to be useful. -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE
Unfortunately, one major attack vector is someone isolating your node, getting you to sign away your whole wallet to fee, and then selling it to a mining pool to mine it before you can figure why your transactions aren't making it to the network. In such an attack, the relay rules aren't relevant, and if the attacker can DoS you for 24 hours, it doesn't take a ton of mining power to make the attack extremely likely to succeed. On 01/23/2015 10:31 AM, Tamas Blummer wrote: Not a fix, but would reduce the financial risk, if nodes were not relaying excessive fee transactions. Tamas Blummer -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE
The SIGHASH_WITHINPUTVALUE proposal is a hardfork, but otherwise non-intrusive, doesn't change any TxOut scripts, doesn't change any tx/block parsing (besides verification), it works with all existing coins in the network, and existing software doesn't have to use it if they don't want to upgrade their signers. The proposal simply provides a way to optionally sign the input values with the TxOut scripts. In other words a signature right now says I sign this transaction using these inputs, whatever value they are. With this SIGHASH type, the signature says I sign this transaction assuming that input 0 is X BTC, input 1 is Y BTC,. If the online computer providing the data to be signed lies about the value of any input, the resulting signature will be invalid. Unfortunately, it seems that there was no soft-fork way to achieve this benefit, at least not one that had favorable properties. Most of the soft-fork variations of it required the coins being spent to have been originated in a special way. In other words, it would only work if the coins had entered the wallet with some special, modified TxOut script. So it wouldn't work with existing coins, and would require senders to update their software to reshape the way they send transactions to be compatible with our goals. I *strongly* encourage this to be considered for inclusion at some point. Not only does it simplify HW as Marek suggested, it increases the options for online-offline communication channels, which is also a win for security. Right now, QR codes don't work because of the possibility of having to transfer megabytes over the channel, and no way to for the signer to control that size. With this change, it's possible for the signer to control the size of each chunk of data to guarantee it fits in, say, a QR code (even if it means breaking it up into a couple smaller transactions). -Alan On 01/23/2015 09:51 AM, slush wrote: Hi, is any progress or even discussion in this area? https://bitcointalk.org/index.php?topic=181734.0 I don't insist on any specific solution, but this is becoming a real issue as hardware wallets are more widespread. I'm sitting next to TREZOR for 40 minutes already, because it streams and validate some complex transaction. By using proposed solution, such signature would be a matter of few seconds. That's also not just about time/resource/hw cost optimization. I'm talking about possibility of huge simplification of the firmware (=security FTW), because 50% of actual codebase is solving this particular downside of Bitcoin protocol. So, there's real world problem. On which solution can we as a community find a wide agreement? Best, Marek -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE
On 01/23/2015 11:05 AM, Gregory Maxwell wrote: On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner etothe...@gmail.com wrote: Unfortunately, it seems that there was no soft-fork way to achieve this benefit, at least not one that had favorable properties. Most of the soft-fork variations of it required the coins being spent to have been originated in a special way. In other words, it would only work if the coins had entered the wallet with some special, modified TxOut script. So it wouldn't work with existing coins, and would require senders to update their software to reshape the way they send transactions to be compatible with our goals. I think this is unreasonable. There is a straight-forward soft-fork approach which is safe (e.g. no risk of invalidating existing transactions). Yes, it means that you need to use newly created addresses to get coins that use the new signature type... but thats only the case for people who want the new capability. This is massively preferable to expecting _every_ _other_ user of the system (including miners, full nodes, etc.) to replace their software with an incompatible new version just to accommodate your transactions, for which they may care nothing about and which would otherwise not have any urgent need to change. As far as I'm concerned, anything that requires the coins to originate in the wallet with some special form is a non-starter. The new SIGHASH type allows you to sign transactions with any coins already in your wallet, and imposes no requirements on anyone paying your cold wallet. Any such proposals that require origination structure means that 100% of people paying you need to be nice and use this new script type, or else you *have* to -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE
On 01/23/2015 11:05 AM, Gregory Maxwell wrote: On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner etothe...@gmail.com wrote: Unfortunately, it seems that there was no soft-fork way to achieve this benefit, at least not one that had favorable properties. Most of the soft-fork variations of it required the coins being spent to have been originated in a special way. In other words, it would only work if the coins had entered the wallet with some special, modified TxOut script. So it wouldn't work with existing coins, and would require senders to update their software to reshape the way they send transactions to be compatible with our goals. I think this is unreasonable. There is a straight-forward soft-fork approach which is safe (e.g. no risk of invalidating existing transactions). Yes, it means that you need to use newly created addresses to get coins that use the new signature type... but thats only the case for people who want the new capability. This is massively preferable to expecting _every_ _other_ user of the system (including miners, full nodes, etc.) to replace their software with an incompatible new version just to accommodate your transactions, for which they may care nothing about and which would otherwise not have any urgent need to change. As far as I'm concerned, anything that requires the coins to originate in the wallet with some special form is a non-starter. The new SIGHASH type allows you to sign transactions with *any* coins already in your wallet, and imposes no requirements on anyone paying your cold wallet to be compatible with your signer. Any proposals that require coin origination features means that 100% of people paying you need to be nice and send you coins with this special structure. You can't spend old coins that were sent before this proposal was implemented, and if anyone sends you coins without respecting the new structure, then your signing devices need the full-complexity routines to accommodate, which defeats the entire purpose. I am happy to entertain other ideas that achieve our goals here, but I'm fairly confident that the new SIGHASH type is the only way that would allow devices like Trezor to truly simplify their design (and still work securely on 100% of funds contained by the wallet). -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
I'm a bit confused. It's been a long time since I looked at protobuf (and will have to dig into it soon), but I seem to recall it doesn't have any of the determinism properties you guys just said. It is intended to allow you to skip details of the on-the-wire representations and just send a bunch of named fields between systems. I thought there was no guarantee that two identical protobuf structures will get serialized identically...? On 01/19/2015 02:57 PM, Richard Brady wrote: Thanks guys, great answers. The design choice certainly makes a lot more sense now regardless of whether one agrees with it or not. Regards, Richard -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions
I see no reason to restrict compressed/uncompressed. Strings don't have to be the same length to sort them lexicographically. If a multi-sig participant provides an uncompressed key, they are declaring that the key that they use and it will only be used uncompressed. Clients don't have to go looking for all combinations of compressed uncompressed. On 01/16/2015 11:34 AM, Thomas Kerin wrote: It seems there is scope for further narrowing down how a multisig scripthash address should be determined - what do people think of anticipating only compressed keys for scripts? It's possible to cause confusion if one put forward a compressed key at some time, and an uncompressed key at another. A different script hash would be produced even though there is no difference to the keys involved. The client will not search for this. Having spoken with Jean-Pierre and Ruben about this for quite some time now, there is 100% the need for a BIP outlining this. Everyone has had the idea at some point, and some of us already using it, but people shouldn't have to go digging in BIP45 for the two lines which mention it. All we need is a place to put the docs. I am building up a list of implementations which currently support sorting, and briefly describing a motivation for such a BIP. On 16/01/15 10:16, Ruben de Vries wrote: Since we only need the sorting for creating the scriptPubKey, wouldn't it make the most sense to sort it by the way it represented in that context? On Thu, Jan 15, 2015 at 2:03 PM, Wladimir laa...@gmail.com mailto:laa...@gmail.com wrote: On Thu, Jan 15, 2015 at 1:17 AM, Matt Whitlock b...@mattwhitlock.name mailto:b...@mattwhitlock.name wrote: On Wednesday, 14 January 2015, at 3:53 pm, Eric Lombrozo wrote: Internally, pubkeys are DER-encoded integers. I thought pubkeys were represented as raw integers (i.e., they're embedded in Script as a push operation whose payload is the raw bytes of the big-endian representation of the integer). As far as I know, DER encoding is only used for signatures. Am I mistaken? OP_CHECKSIG (and OP_CHECKSIGVERIFY) takes a DER-encoded pubkey and a DER-encoded signature on the stack. Possibly you're confused with OP_HASH160 hash160 OP_EQUALVERIFY as used in outputs, which compares the 160-bit hash of the pubkey against the given hash (usually taken from a bitcoin address). It doesn't help understanding to consider either as integers. They are binary blob objects with either a fixed format (DER) or a fixed size (hashes). Wladimir -- BlockTrail B.V. Barbara Strozzilaan 201 1083HN Amsterdam The Netherlands Phone:+31 (0)612227277 E-mail:ru...@blocktrail.com mailto:ru...@blocktrail.com Web:www.blocktrail.com http://www.blocktrail.com/ Github:www.github.com/rubensayshi http://www.github.com/rubensayshi BlockTrail B.V. Is registered with the Dutch Chamber of Commerce in Amsterdam with registration No.:60262060 and VAT No.:NL853833035B01 -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
On 11/16/2014 02:04 PM, Jorge Timón wrote: I remember people asking in #bitcoin-dev Does anyone know any use case for greater sizes OP_RETURNs? and me answering I do not know of any use cases that require bigger sizes. For reference, there was a brief time where I was irritated that the size had been reduced to 40 bytes, because I had an application where I wanted to put ECDSA in signatures in the OP_RETURN, and you're going to need at least 64 bytes for that. Unfortunately I can't remember now what that application was, so it's difficult for me to argue for it. But I don't think that's an unreasonable use case: sending a payment with a signature, essentially all timestamped in the blockchain. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
By the way, I really like this proposal. I haven't spent much time thinking about the deeper subtleties and risks associated with it, but I see a lot of opportunities. One just came to mind that I didn't see mentioned in his original proposal: _Non-Interactive Recurring payments__with ID-association_: You want to make N recurring payments of 1 BTC each month to a service. Sign N transactions each of them use a CHECKLOCKTIMEVERIFY block number approximately X months in the future (one for each month). The script allows the customer to move the coins at any time, but after the locktime the merchant/service has signing access. The merchant software will continually watch for and sweep all coins that become available via this mechanism and credit the appropriate customer account. The customer maintains control of the funds until payment time, the merchant can automatically collect it each month without requiring user interaction, and the customer can cancel it just by spending it elsewhere before the locktime. This scheme has an added benefit: both the merchant's address and the user's address is in the script. Given an appropriate scheme for linking addresses to accounts (perhaps sending the service a watch-only BIP32 branch), the service can use the other address in the script to recognize and link that payment to the user's account. This allows you to continue paying and extending your subscription without having to explicitly link each payment to the account. The wallet will simply make sure to use a return address that is in a BIP32 branch that was provided to the service during signup, and the service will automatically extend your subscription every month based on that info when it sweeps payments. Along with everything else that was mentioned by Peter in his original proposal, I see OP_CHECKLOCKTIMEVERIFY as an enabling feature, not just a simple improvement. -Alan On 10/08/2014 06:26 AM, Wladimir wrote: On Tue, Oct 7, 2014 at 6:08 PM, Mike Hearn m...@plan99.net wrote: That is easy to change; I'll submit a pull request. That's certainly a useful improvement. It won't help the existing userbase though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release. The next minor release (0.9.4) could have Gavin's change already. I don't think CHECKLOCKTIMEVERIFY will make it into the next major release though. Once headers-first and pruning is merged (which is expected to be a matter of weeks). I'd like to split off the 0.10 branch and give it some time to stabilize with a feature freeze, then do a release before the end of the year. So 0.11, in say 6 months, would be soonest. Wladimir -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
On 10/01/2014 04:58 PM, Gavin Andresen wrote: If the first transaction is P2SH, then the miner won't know there is an advantage to holding it until it is too late (the scriptPubKey is an opaque hash until the second transaction is final and relayed/broadcast). If you're doing some kind of proof-of-burn scheme, wouldn't using P2SH defeat the purpose of it? -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New opcodes and transaction version numbers (was 'relax the IsStandard rules for P2SH transactions')
On 09/28/2014 10:35 PM, Peter Todd wrote: This can be solved by upgrading the address format at the same time to let senders know they must send the funds in a transaction with an increased version number, but obviously needing new addresses for every new opcode defeats the purpose of P2SH. Can't this be solved with a single update to the address format, allowing a tx version number to be part of the address serialization? Then the sending software will apply that version to the payment tx. Of course, I'm not sure if allowing nodes to create transactions with version numbers outside of their programming is safe. It seems like it should be since we're talking about soft forks anyway, but there's probably some subtleties I'm overlooking. -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP43 Purpose code for voting pool HD wallets
I'm in favor of BIP43. Adding a Purpose node can be used as an identifier for what kind of tree is in the wallet file we're reading. I can envision a few different, common tree structures. Perhaps using a non-hardened first-layer derivation (we have clients who want this). Similarly, my proposal for a No-collision mode for multisig BIP32 trees http://sourceforge.net/p/bitcoin/mailman/message/32860512/ is another variant that might get some traction but not everyone will use it. These things could be supported by simply changing the BIP43 Purpose index and wallet software could be designed to recognize and react to the Purpose node for any number of different tree structures, and ignore any trees that it doesn't recognize (or maybe be able to view the balance across all the leaves of the tree but not expand it) We have clients with special use-cases (complex multi-layer trees) that are unlikely to be recycled across users. In such cases we might just use a random Purpose that is recognized by their system, and know that other software won't mess with it. Though it would be better if that field was encoded in the root seed, instead. Nonetheless, putting that extra layer between the root and the important tree nodes provides flexibility to BIP32 as a whole. -Alan On 09/25/2014 09:53 PM, Gregory Maxwell wrote: On Tue, Aug 19, 2014 at 10:11 AM, Justus Ranvier jus...@monetas.net wrote: Two draft information BIPs are attached. I've pinged some people privately but also pinging the list… no commentary on this proposal? -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Proposal: No-Collision mode for Multisig BIP32 Wallets
This topic has been touched on briefly here before, but I wanted to solidify it and propose it as a BIP if there is wider support for it. Also, the topic is difficult to discuss without lots of pictures -- so that's what I've done (mainly to describe it to my team, but also as general documentation). It's in presentation form: https://s3.amazonaws.com/bitcoinarmory-media/MultisigWalletNoCollide.pdf The proposal is that for an M-of-N multisig wallet based on BIP32, there should be N internal chains and N external chains. Each party is assigned a chain based on the lexicographic ordering of their wallet's root public key in the multisig. This guarantees that no parties are generating and distributing the same addresses, and also provides a certain level of built-in book-keeping. Coins being received on chain 2*x were created by participant x (receiving), and coins received on 2*x+1 are change outputs created by participant x (outgoing). Thus, it's easy from simply looking at the wallet structure who was responsible for which transactions. Alternatively, we could change it to suggest that each device is assigned a pair of chains. For a 2-of-3 there may 3 participants plus a CFO with a watch-only version of the multisig wallet. Then you might use four pairs of chains. I'm just not sure how they would be assigned. If this has been proposed before, then consider this my contribution to documentation. -Alan P.S. -- No-Collision Mode is not a great name. Happy to take suggestions for changing it. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: No-Collision mode for Multisig BIP32 Wallets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2014 12:37 PM, Justus Ranvier wrote: Would be nice if you'd at least mention our work, since we did share it with you back in January and have been publicly documenting it ever since. Or does the fact that we're implementing it in btcwallet mean what we're working on is unmentionable here? Please don't assume poor intentions or sneaky motives. I get a lot of emails from a lot of people about a lot of things. Nine months ago was an eternity in this world, and it can't be ruled out that I simply forgot. I have no problem giving credit where it is due, and I mentioned in my first email that I wasn't sure if my stuff was original. Please recap/link it here so that it can be part of this discussion. - -Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUIaRiAAoJEBHe6b77WWmFcBgP/2IiQWda5diBIrd8MjbtYz/X pF+B1zOipClil151pKN5h9f4CI75qwSBSG6pUS+QH1lCz97nr5AoVYV5SAaRzv0z L9Bz0PiHJFHd4IRbfuFqlPZB8mw2TMD7QWJx/1U+WmpnYYOGsUeJn25psIVZSRTU FTCsmYrA4cGZ4bZoUKI/eiXrHao8rm/zQ7QHKOMSFWZT57sNea67vlxPXKu+AkmK nEYa4hD0kD7/R/TrNcmRmOlmbqCnyjICd/yp8Lj26CdHPv3PAvaxUwSX3VhWPbdc UOiGeo+lXqRnBVpwMd+k7oFddwrc2k9ISRdUVsU86z3JdAXKl/dLS5UoOtfC1JA9 m90TuRtq4QuuzjLF3brI9FthuHNowA//qaVfjo/AYgsKy15td9UBtFbt4E9w263M NiFEmFkXfbE1JmIvmPG3AQEEdQ1/nmWiN5UcLrBfauEHMDQ1fGd89A8IBpus7bWM kYXboW3E9RBN4lB6OdyYU4AuH0YQhZodmry4iElMPox/tclmNiaeqDR8UYhD5BMd eQN9zAALyR1IY1167Ki/abVfWVf5jF7b0Eeu/wAfwcble3sCFrvWWAwzHjNi3GjY gNfy1eDTbwLj2M63QbtB+YqzQBZx3+SY4euGKYQ1s1CVV9ibAFI52oxeMhwzVOWF ofeDK5BPL8H+5L3tk+1o =tX2n -END PGP SIGNATURE- -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin-development Digest, Vol 40, Issue 9
Yes, we sort the keys at each address as well. But this isn't about key sorting, it's about assigning each device a different branch of the BIP 32 tree to avoid accidental address re use and to make it self evident which devices were used for each transaction in the overall wallet history. I only suggested sorting the root public keys as a way to assign which internal/external pair of chains the device should use. @Justus... Looking at the links you sent I'm not clear how it is related. And naming it key voting pools seems unrelated to why we are proposing this scheme. I'll need more than naked links to understand (I'm not saying it isn't related, I'm just not seeing the connection) -Alan Sent from my overpriced smartphone On Sep 23, 2014 2:25 PM, Vitalik Buterin v...@buterin.com wrote: Have you looked at how Coinvault does it? They have a similar setup, but sort the pubkeys at each address. On Tue, Sep 23, 2014 at 1:09 PM, bitcoin-development-requ...@lists.sourceforge.net wrote: Send Bitcoin-development mailing list submissions to bitcoin-development@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/bitcoin-development or, via email, send a message with subject or body 'help' to bitcoin-development-requ...@lists.sourceforge.net You can reach the person managing the list at bitcoin-development-ow...@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than Re: Contents of Bitcoin-development digest... Today's Topics: 1. Re: Proposal: No-Collision mode for Multisig BIP32 Wallets (Justus Ranvier) 2. Re: Proposal: No-Collision mode for Multisig BIP32 Wallets (Alan Reiner) 3. Re: Proposal: No-Collision mode for Multisig BIP32 Wallets (Justus Ranvier) -- Message: 1 Date: Tue, 23 Sep 2014 16:37:20 + From: Justus Ranvier jus...@monetas.net Subject: Re: [Bitcoin-development] Proposal: No-Collision mode for Multisig BIP32 Wallets To: bitcoin-development@lists.sourceforge.net Message-ID: 5421a1c0.6080...@monetas.net Content-Type: text/plain; charset=utf-8 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/23/2014 04:16 PM, Alan Reiner wrote: P.S. -- No-Collision Mode is not a great name. Happy to take suggestions for changing it. I'd call it a voting pool wallet, since that was the original application for this arrangement. Would be nice if you'd at least mention our work, since we did share it with you back in January and have been publicly documenting it ever since. Or does the fact that we're implementing it in btcwallet mean what we're working on is unmentionable here? - -- Justus Ranvier | Monetas http://monetas.net/ mailto:jus...@monetas.net | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJUIaHAAAoJEMP3uyY4RQ21nwoH/3MYi9JibblZYmSOvCT1vJrN Ih+Q2WNumIAI+Y9bh4bBgLuhnG5lXyHedhYEUW+mfuwGiX+92Uc47nwaWED2/Lte 4Zk/KZnwLifdWCgKLdGpW6mzksRiOaVyU4vV5JchVOrGZZ2zYNIq+NcChtCph7Y5 L202ReAG+1dfSpp4rFckuv7pTVjNcrq89UN1tJFDNQdxzIRd7bwoeCuvyFurZagB 88bNiOl0BI3e090WC+CWmbC6BfqJiicn/d0gp/agW01wy7CVbLypPPTKmYqt3+54 msLUgaRHcbjuyKqu8HMHpYtgYVSNFg2q+U4SgmEepzPAkQ97khbduqA6i1B0ULM= =t/xp -END PGP SIGNATURE- -- next part -- A non-text attachment was scrubbed... Name: 0x38450DB5.asc Type: application/pgp-keys Size: 14046 bytes Desc: not available -- Message: 2 Date: Tue, 23 Sep 2014 12:48:34 -0400 From: Alan Reiner etothe...@gmail.com Subject: Re: [Bitcoin-development] Proposal: No-Collision mode for Multisig BIP32 Wallets To: bitcoin-development@lists.sourceforge.net Message-ID: 5421a462.6030...@gmail.com Content-Type: text/plain; charset=ISO-8859-1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2014 12:37 PM, Justus Ranvier wrote: Would be nice if you'd at least mention our work, since we did share it with you back in January and have been publicly documenting it ever since. Or does the fact that we're implementing it in btcwallet mean what we're working on is unmentionable here? Please don't assume poor intentions or sneaky motives. I get a lot of emails from a lot of people about a lot of things. Nine months ago was an eternity in this world, and it can't be ruled out that I simply forgot. I have no problem giving credit where it is due, and I mentioned in my first email that I wasn't sure if my stuff was original. Please recap/link it here so that it can be part of this discussion. - -Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUIaRiAAoJEBHe6b77WWmFcBgP/2IiQWda5diBIrd8MjbtYz/X pF+B1zOipClil151pKN5h9f4CI75qwSBSG6pUS
[Bitcoin-development] [ANN] Armory 0.92 with Decentralized Multi-sig and Simulfunding
Hi Everyone, The Armory team is pleased to announce the official release of our decentralized multi-signature interface, called Lockboxes. It is a true multi-signature transaction interface: * Decentralized multi-sig (no third-party servers or signers needed) * Any multi-sig from 1-of-2 up to 7-of-7 * Any or all of the signing devices can be *offline* * All private keys can be generated and managed independently * Works with existing Armory wallets * Simultaneous funding (simulfunding) features for escrow and contracts (basically CoinJoin) * All wrapped up in a nice graphical user interface! Armory 0.92 includes a GUI for creating, funding and spending from multi-signature lockboxes, anything from 1-of-2 up to 7-of-7. All private keys can be generated independently and never have to be co-located.Most importantly, any number of the signing keys can be created and managed on offline computers! Also, all transaction and signature data is communicated directly between parties/devices using ASCII-armored blocks of text, so no third-party servers/services are needed (though, in the future, we hope to provide an optional service to help synchronize the data between parties). The release also includes the ability to do simultaneous funding (simulfunding) which is basically CoinJoin through a GUI, but intended to be used for contracts and escrow. Each party creates a promissory note (which is basically just a list of UTXOs and a change address), and those can be merged into a single transaction to be signed by all funders. Either all contributions are made simutaneously, or none of them are. There is no other outcome. This means that no trust is required between the simulfunders. It is a basic contract enforced by the bitcoin network itself. Simulfunding would normally be used in conjuction with multi-signature lockboxes -- two parties that don't trust each other together create a lockbox, and then simultaneously fund it (and subsequently spend it) according to some agreement. However, it can actually be used to simulfund any address. To promote this feature, Armory Technologies Inc is offering to match up to 20 BTC in donations to the EFF, FSF, College Crypto Network, Chamber of Digital Commerce, and the Bitcoin Foundation (and hopefully wikipedia, as a late addition to the list).We posted a list of ATI promissory notes for matching donations on our website: https://bitcoinarmory.com/donation-match-list/ We're very excited about this release, which has been in testing for over three months, and we've been using for management of company funds between officers for the last two months. We have not seen anything else that comes close to matching the flexibility and security afforded by it (and without being exceptionally inconvenient!). See our tutorials, and especially the FAQ at the end: https://bitcoinarmory.com/about/using-lockboxes https://bitcoinarmory.com/about/using-lockboxes/#faq We hope that people will try it out and provide feedback. Maybe even match some donations! We've already matched 3 BTC so far and it was announced less than 24 hours ago. Cheers, -Alan -- Press Release: http://finance.yahoo.com/news/armory-releases-first-decentralized-multi-233500704.html -- Changelog: *VERSION 0.92** **Released July 29, 2014** * - *Multi-Signature Lockboxes!* Full-featured interface for creating multi-signature addresses, putting money into them, and collecting signatures to spend them. See our tutorials at: https://bitcoinarmory.com/about/using-lockboxes/ - *Simulfunding for Addresses and Lockboxes* Use the Multi-Sig menu to do prepare simulfunding to any arbitrary address. Or click on the Simul checkbox in the lockbox manager if you are simulfunding a lockbox. As a promotion for this feature we are matching up to 20 BTC worth donations to organizations that support Bitcoin, digital security, online freedoms, and open-source software. See our donation list (with instructions): https://bitcoinarmory.com/about/donation-match-list - *Improved Mac/OSX Stability* We merged a couple Qt4 patches that dramatically improved compatibility on OSX 10.7 and newer. Should work with the upcoming release of OSX 10.10. - *Armory Daemon/API Upgrades (Beta)* The Armory API has been upgraded substantially since version 0.91. This version has tons of new functionality matching bitcoind, as well as unique functionality including lockbox operations. Plan to have complete functionality implemented and tested by version 0.93. - *Upgraded Transaction History Export to CSV* Added running balance reporting for individual and all wallets. Also fixed a bug where internal transfers within wallets were not being reported properly. -
Re: [Bitcoin-development] ASIC-proof mining
Just a thought on this -- I'm not saying this is a good idea or a bad idea, because I have spent about zero time thinking about it, but something did come to mind as I read this. Reading 20 GB of data for every hash might be a bit excessive. And as the blockchain grows, it will become infeasible to continue. However, what comes to mind is the ROMix algorithm defined by Colin Percival, which was the pre-cursor to scrypt. Which is actually what Armory uses for key stretching because it's far simpler than scrypt itself while maintaining the memory-hard properties (the downside is that it's much less flexible in allowing the user to trade-off compute time vs memory usage). ROMix works by taking N sequential hashes and storing the results into a single N*32 byte lookup table. So if N is 1,000,000, you are going to compute 1,000,000 and store the results into 32,000,000 sequential bytes of RAM. Then you are going to do 1,000,000 lookup operations on that table, using the hash of the previous lookup result, to determine the location of next lookup (within that 32,000,000 bytes). Assuming a strong hash function, this means its impossible to know in advance what needs to be available in RAM to lookup, and it's easiest if you simply hold all 32,000,000 bytes in RAM. Something similar could be applied to your idea. We use the hash of a prevBlockHash||nonce as the starting point for 1,000,000 lookup operations. The output of the previous lookup is used to determine which block and tx (perhaps which chunk of 32 bytes within that tx) is used for the next lookup operation. This means that in order to do the hashing, you need the entire blockchain available to you, even though you'll only be using a small fraction of it for each hash. This might achieve what you're describing without actually requiring the full 20 GB of reading on ever hash. -Alan On 07/04/2014 06:27 AM, Andy Parkins wrote: Hello, I had a thought after reading Mike Hearn's blog about it being impossible to have an ASIC-proof proof of work algorithm. Perhaps I'm being dim, but I thought I'd mention my thought anyway. It strikes me that he's right that it's impossible for any algorithm to exist that can't be implemented in an ASIC. However, that's only because it's trying to pick an algorithm that is CPU bound. You could protect against ASCI mining (or rather, make it irrelevant that it was being used) by making the algorithm IO-bound rather than CPU-bound. For example, what if the proof-of-work hash for a block were no longer just hash of block, which contains the hash of the parent block, but instead were hash of [NEW_BLOCK] [ALL_PREVIOUS_BLOCKS] [NEW_BLOCK] [ALL_PREVIOUS_BLOCKS] is now 20GB (from memory) and growing. By prefixing and suffixing the new block, you have to feed every byte of the blockchain through the hashing engine (the prefix prevents you caching the intermediate result). Whatever bus you're using to feed your high speed hashing engine, it will always be faster than the bus -- hence you're now IO-bound, not CPU-bound, and any hashing engine will, effectively, be the same. I'm making the assumption that SHA-256 is not cacheable from the middle outwards, so the whole block-chain _has_ to be transferred for every hash. Apologies in advance if this is a stupid idea. Andy -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] ASIC-proof mining
On 07/04/2014 07:15 AM, Andy Parkins wrote: On Friday 04 July 2014 06:53:47 Alan Reiner wrote: ROMix works by taking N sequential hashes and storing the results into a single N*32 byte lookup table. So if N is 1,000,000, you are going to compute 1,000,000 and store the results into 32,000,000 sequential bytes of RAM. Then you are going to do 1,000,000 lookup operations on that table, using the hash of the previous lookup result, to determine the location of next lookup (within that 32,000,000 bytes). Assuming a strong hash function, this means its impossible to know in advance what needs to be available in RAM to lookup, and it's easiest if you simply hold all 32,000,000 bytes in RAM. My idea wasn't to make hashing memory hungry; it was to make it IO-hungry. It wouldn't be too hard to make an ASIC with 32MB of RAM. Especially if it gained you a 1000x advantage over the other miners. It seems that sort of solution is exactly the one that Mike Hearn was warning against in his blog. I think you misundersood using ROMix-like algorithm, each hash requires a different 32 MB of the blockchain. Uniformly distributed throughout the blockchain, and no way to predict which 32 MB until you have actually executed it. If the difficulty is high enough, your miner is likely to end up going through the entire X GB blockchain while searching for a good hash, but other nodes will only need to do 32 MB worth of disk accesses to verify your answer (and it will be unknown which 32 MB until they do the 1,000,000 hash+lookup operations on their X GB blockchain). I think that strikes a good compromise of needing access to 100% of the blockchain, without requiring reading 20 GB to verify a block. (Replace N=1,000,000, 32 MB and 20 GB with the appropriately calibrated numbers in the future) -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bloom bait
On 06/07/2014 07:22 AM, Mike Hearn wrote: You can send different bloom filters to different peers too, so I'm not sure why you're listing subsetting as a unique advantage of prefix filters. Please let me know if we've gone down this path before, but it would seem that the more different bloom filters you create, the more information you give away. It would be most useful to create a single bloom filter that captures every address you ever intend to use (say a look ahead of 1000 addresses), and then only ever communicate that. Once people see multiple filters that you produce, they can start looking at the intersection of them to reduce the identity space. I would expect that after enough bloom variants, they could figure out a perfect subset of blockchain addresses in your wallet. (I suppose you could intentionally select an extra 20% addresses to include in every bloom filter, but it's a hack). Similarly, if you keep updating your bloom filter to include more addresses, the difference in what passes through the previous one and the new one gives away information about new addresses you created. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cut-through propagation of blocks
On 05/24/2014 07:41 PM, Ashley Holman wrote: On Sun, May 25, 2014 at 8:29 AM, Bernd Jendrissek bitc...@bpj-code.co.za mailto:bitc...@bpj-code.co.za wrote: The difference is that with cut-through forwarding of blocks, a sufficiently motivated attacker (being willing to blow 25BTC's worth of electricity on the effort) can subjugate the entire Bitcoin network to its DoS attack, rather than having to connect to every node individually and then still have those individual nodes reject that invalid block without relaying any knowledge of its existence. That is true, but they could also apply the same hash power to mine valid blocks and would achieve the same outcome (their blocks would go to everyone), except they would get paid for it. I wonder if it should even be called DoS, due to the extreme and costly rate-limiting thats implied. An attack could also take the form of a block body that never arrives - a sort of teergrube attack, where the goal is to get the network mining empty block upon empty block on top of that valid-PoW header whose body never arrives. It doesn't have to be with an explicitly invalid block. Thank you for raising this, as I share this concern. There is another similar attack: if I send you a new block very slowly, I occupy all your upstream peer slots indefinitely until the block is complete, because there is no out-of-band messaging capability or ability to cancel a message. There is also sub-optimal logic in choosing to download a block only from the first person to offer it. It means you are fetching it from the lowest latency path, but what really matters is who can give it to you fastest. If there are multiple people who can send you a block at once, and you have some idea of your spare upstream bandwidth capacity, why not let two or more peers compete to send you the block fastest? So to implement this type of thing, the p2p protocol should allow for multiplexing of messages. Something like HTTP chunked encoding. It could be in the form of: msgidchunksizerawbytes, msgidchunksizerawbytes, etc etc You only send a chunk once you've got the whole chunk in your buffer, so it's not possible to get hung up on a single slow message. One block can overtake another along the same hop path if it is being streamed faster. On Sun, May 25, 2014 at 8:46 AM, Gregory Maxwell gmaxw...@gmail.com mailto:gmaxw...@gmail.com wrote: If you want to go full out crazy in optimizing in this space, there are fancier things that can be done to further reduce latency and increase efficiency: https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding ... but some of this stuff really should be done as a seperate protocol. There is no need to have Bitcoin transport all using a single protocol, and we can get better robustness and feature velocity if there are a couple protocols in use (you could just run a block-transport-protocol daemon that connects to your local node via the classic protocol). What about a separate project which is a mesh router specifically designed for low-latency transmission of blocks? It could support things like a more sophisticated/configurable routing table, and have some kind of discovery where it tries to optimise its topology. There could even be some way for nodes to prove their hash power, so pools can find each other and directly peer / prioritise sends. I think the most important change is modifying the way Bitcoin Core prioritizes blocks. Right now it uses the first full block verified. Instead, it should consider the first valid header received as highest priority, but only mine on it once it has done full verification of the block. In other words, nodes will mine on whatever full/verified block they have with the earliest header-received time. If another header comes in and the tx list is received before the first tx list is done, then the node will mine the second block *until* it receives and verifies the first block, then it will switch to mining that first block. Most of the time there's no race, it will simply mine the block N-1 for an extra 1-3 seconds until it receives and verifies the full block for the new header. This at least solves part of the problem: nodes are still only mining on full blocks, but priority is given to *headers* that come first which is independent of block size. As long as a block isn't found within the 1-3 seconds, then each miner will switch when they finish receiving and verifying it. If miners are concerned about that 1-3 second gap, they should perhaps focus on making sure the tx they are mining are well-propagated already, so that most of the network has most of the transactions already in their memory pool by the time their block is mined. -- Accelerate Dev Cycles with Automated
Re: [Bitcoin-development] Cut-through propagation of blocks
On 05/24/2014 08:14 PM, Gregory Maxwell wrote: On Sat, May 24, 2014 at 5:04 PM, Alan Reiner etothe...@gmail.com wrote: I think the most important change is modifying the way Bitcoin Core prioritizes blocks. Right now it uses the first full block verified. Instead, it should consider the first valid header received as highest priority, but only mine on it once it has done full verification of the This directly opens an attack where as soon as you find a block you announce the header to the world and then you delay announcing the block content. You can continue to mine on the block but no one else can (or alternatively they break their rule and risk extending an invalid block— bad news for SPV wallets)— then when you find a successor block or someone else finds a competing block you immediately announce the content. It basically means that you can always delay announcing a block and be sure that doing so doesn't deprive you of your winning position. Would this not be solved by putting a expiration on application of this logic? For instance, if you haven't received the full new block within 5-10 seconds (perhaps adjusted based on local bandwidth), then the header-received time is ignored. Or is this too hacky? I suppose this is exactly what Ashley is trying to solve, she's just already made a few more leaps forward in the design process than I have. I'll stop derailing it. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure for P2SH multisig wallets
On 04/26/2014 04:33 PM, Mike Hearn wrote: Let's assume we use one shared branch for everyone. Then two cosigners could need a new receiving address at the same time, and get the next unused address on that branch. This is the part I struggle to understand. There is no shared branch because each user/cosigner has their own unique seed and thus unique key hierarchy, right? What you described above could be an issue if all co-signers shared the same seed but then the scheme wouldn't work. Consider two people with phones, using 2-of-2, using private seeds k1 and k2. Every address generated by either party is: 2-of-2(K1/a'/b/c, K2/a'/b/c) So for any a, b and c you end up with a 2-of-2 address. The seeds/branches will not be used for single-sig receiving... it's always a multisig 2-of-2. In fact it behaves much like a regular wallet, you give an a, b, and c value, and you get an address -- it's just that this wallet always gives you a P2SH multisig address. The problem is that if you follow BIP32 in the the most obvious way, both devices will generate receiving addresses along the last index, i.e. K/a'/b/0, K/a'/b/1, K/a'/b/2,... If I am at one store and my wife at another, we might both give out 2-of-2(K1/a'/b/382, K2/a'/b/382) at the same time not realizing the other one has distributed that address. There's not a good way to coordinate the devices well enough to avoid it. But we don't have to. The solution is to use two separate branches -- both phones will follow/watch both branches, but each only only distributes payment addresses from one such branch. The original proposal here suggested adding a level to the tree using the cosigner index as a branch point for doing this... I recommended simply having 2*N values for b, so that each participant has a receiving line and change line, that won't conflict with other devices. However, all devices will still watch all 2*N branches to know the total balance of the wallet, and will use UTXOs from those branches when constructing spending transactions/proposals. -- 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] 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
Re: [Bitcoin-development] Economics of information propagation
On 04/21/2014 11:40 AM, Ashley Holman wrote: On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd p...@petertodd.org mailto:p...@petertodd.org wrote: That is mistaken: you can't mine on top of just a block header, leaving small miners disadvantaged as they are earning no profit while they wait for the information to validate the block and update their UTXO sets. This results in the same problem as before, as the large pools who mine most blocks can validate either instantly - the self-mine case - or more quickly than the smaller miners. Under the headers first scenario, wouldn't the full block still reach everyone in the same time as it would under the current rules? So the small miner loses nothing in terms of updating their UTXO set, but gains an early heads up alert that a new block is coming. This allows them spend the propagation time working more productively on an empty block in the new chain rather than wasting time on an orphan. It's true that it doesn't solve the problem of larger pools vs smaller pools, but if it doesn't make it any worse then headers-first propagation would be a net benefit to the network since it removes the incentive to make small blocks. I think the most important part is that nodes can reliably decide on first received, regardless of how they subsequently act on it. I believe it would be fine for a node to receive a header and continue mining the old block, or a subsequently-verified competing block, until it has the necessary pieces to fully verify the first header received. If that block data doesn't come, then it will be naturally ignored. But if multiple blocks come at once, even if a competing block verifies first, the node would still switch to considering the first header received as the best block when it later receives proof it is valid (which may only be a couple seconds). In other words, the node will always consider the header-received time as the primary ordering criteria, but will not mine on anything until it has full proof of validity, even if /that/ is out of order. This means that new blocks effectively propagate at the speed of 80 bytes, which limits certain kinds of block-injection/racing attacks. -- 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] bits: Unit of account
I've been a staunch supporter of microbitcoin and would like to do anything I can to make sure that we jump directly to it if we're going to promote changing the default units. And I'm happy to integrate it into Armory as a default (with appropriate explanations and settings/options). I'm not so convinced about the bits name though -- I do like it, but I do also think that word is too overloaded. Though, I think we could get away with it. (Sadly, I still use microbes occasionally (as in *microb*itcoin) when I'm talking to coworkers, because it slips off the tongue and is actually a good combination of brevity and self-explanatory -- it just doesn't instill the right visuals...) We started integrating alternative units into Armory. But, of course, there were a few more loose ends than I expected, which will require some work. We want to put it in but not necessarily change the default right away. I'd /prefer/ we get some commitments from some other wallet developers, so we can make a unified push for it. I'm happy to lead that and make it default as long as I'm not the only one in the world doing it. -Alan On 04/20/2014 11:05 AM, Tamas Blummer wrote: Here is an earlier reference to bits: https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04248.html https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04248.html I forgot that Alan Reiner was also supporting a unit equals to bits : https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04264.html https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04264.html and here the earlier going back to March 2013 and a poll at that time pushing for XBT being 1 bit https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04256.html https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04256.html Regards, Tamas Blummer http://bitsofproof.com On 20.04.2014, at 16:53, Pieter Wuille pieter.wui...@gmail.com mailto:pieter.wui...@gmail.com wrote: I told him specifically to bring it here (on a pull request for Bitcoin Core), as there is no point in making such convention changes to just one client. I wasn't aware of any discussion about the bits proposal here before. On Sun, Apr 20, 2014 at 4:28 PM, Tamas Blummer ta...@bitsofproof.com mailto:ta...@bitsofproof.com wrote: People on this list are mostly engineers who have no problem dealing with magnitudes and have rather limited empathy for people who have a problem with them. They also tend to think, that because they invented money 2.0 they would not need to care of finance's or people's current customs. The importance of their decisions in these questions will fade as people already use wallets other than the core. Bring this particular discussion elsewhere, to the wallet developer. BTW the topic was discussed here several times, you have my support and Jeff Garzik's. Regards, Tamas Blummer http://bitsofproof.com On 20.04.2014, at 15:15, Rob Golding rob.gold...@astutium.com wrote: The average person is not going to be confident that the prefix they are using is the correct one, The use of any 'prefix' is one of choice and entirely unnecessary, and there are already established 'divisions' in u/mBTC for those that feel they need to use such things. people WILL send 1000x more or less than intended if we go down this road, Exceptionally unlikely - I deal every day with currencies with 0, 2 and 3 dp's in amount ranging from 'under 1 whole unit' to tens of thousands - Not once in 20 years has anyone ever 'sent' more or less than intended - oh, they've 'intended' to underpay just fine, but never *unintended*. I propose that users are offered a preference to denominate the Bitcoin currency in a unit called a bit. Where one bitcoin (BTC) equals one million bits (bits) and one bit equals 100 satoshis. I propose that for people unable to understand what a bitcoin is, they can just use satoshi's and drop this entire proposal. Rob -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free
Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
Armory has had Fragmented Backups for over a year, now. Advanced users love it. Though, I would say it's kind of difficult to standardize the way I did it since I was able to implement all the finite field math with recursion, list comprehensions and python arbitrary-big-integers in about 100 lines. I'm not sure how portable it is to other languages. There's obviously better ways to do it, but I didn't need a better way, because I don't need to support fragmentation above M=8 and this was 100% sufficient for it. And I was the only one doing it, so there was no one to be compatible with. I won't lie, there's a lot of work that goes into making an interface that makes this feature usable. The user needs clear ways to identify which fragments are associated with which wallet, and which fragments are compatible with each other. They need a way to save some fragments to file, print them, or simply write them down. They need a way to re-enter fragment, reject duplicates, identify errors, etc. Without it, the math fails silently, and you end up restoring a different wallet. And they need a way to test that it all works. Armory did all this, but it was no trivial task. Including an interface that will test up to 50 subsets of make sure the math produces the same values every time (which still is not sufficient for some users, who won't be satisified til they see they're wallet actually restored from fragments. Also I put the secret in the highest-order coefficient of the polynomial, and made sure that the other coefficients were deterministic. This meant that if print out an M-of-N wallet, I can later print out an M-of-(N+1) wallet and the first N fragments will be the same. I'm not sure how many users would trust this, but we felt it was important in case a user needs to export some fragments, even if they don't increase N. You might consider loading Armory in offline mode, create a wallet, and then do a fragmented backup to see how we did it. I am extremely satisfied with the interface, but it's most definitely an advanced tool. But so is Armory ... which made it a good fit. But it might not be for everyone. -Alan On 03/29/2014 11:44 AM, Matt Whitlock wrote: On Saturday, 29 March 2014, at 11:08 am, Watson Ladd wrote: https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin/ Thanks. This is great, although it makes some critical references to an ACM paper for which no URL is provided, and thus I cannot implement it. A distributed ECDSA notwithstanding, we still need a way to decompose a BIP32 master seed into shares. I am envisioning a scenario in which I might meet my sudden and untimely demise, and I wish to allow my beneficiaries to reconstruct my wallet's master seed after my death. I would like to distribute seed shares to each of my beneficiaries and some close friends, such that some subset of the shares must be joined together to reconstitute my master seed. Shamir's Secret Sharing Scheme is perfect for this use case. I am presently working on extending my draft BIP so that it also applies to BIP32 master seeds of various sizes. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
On 03/29/2014 01:19 PM, Matt Whitlock wrote: I intentionally omitted the parameter M (minimum subset size) from the shares because including it would give an adversary a vital piece of information. Likewise, including any kind of information that would allow a determination of whether the secret has been correctly reconstituted would give an adversary too much information. Failing silently when given incorrect shares or an insufficient number of shares is intentional. I do not believe this is a good tradeoff. It's basically obfuscation of something that is already considered secure at the expense of usability. It's much more important to me that the user understands what is in their hands (or their family members after they get hit by a bus), than to obfuscate the parameters of the secret sharing to provide a tiny disadvantage to an adversary who gets ahold of one. The fact that it fails silently is really all downside, not a benefit. If I have enough fragments, I can reconstruct the seed and see that it produces addresses with money. If not, I know I need more fragments. I'm much more concerned about my family having all the info they need to recover the money, than an attacker knowing that he needs two more fragments instead of which are well-secured anyway. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
On 03/29/2014 02:00 PM, Matt Whitlock wrote: On Saturday, 29 March 2014, at 1:52 pm, Alan Reiner wrote: On 03/29/2014 01:19 PM, Matt Whitlock wrote: I intentionally omitted the parameter M (minimum subset size) from the shares because including it would give an adversary a vital piece of information. Likewise, including any kind of information that would allow a determination of whether the secret has been correctly reconstituted would give an adversary too much information. Failing silently when given incorrect shares or an insufficient number of shares is intentional. I do not believe this is a good tradeoff. It's basically obfuscation of something that is already considered secure at the expense of usability. It's much more important to me that the user understands what is in their hands (or their family members after they get hit by a bus), than to obfuscate the parameters of the secret sharing to provide a tiny disadvantage to an adversary who gets ahold of one. The fact that it fails silently is really all downside, not a benefit. If I have enough fragments, I can reconstruct the seed and see that it produces addresses with money. If not, I know I need more fragments. I'm much more concerned about my family having all the info they need to recover the money, than an attacker knowing that he needs two more fragments instead of which are well-secured anyway. For what it's worth, also omits from the shares any information about the threshold. It will happily return a garbage secret if too few shares are combined. (And actually, it will happily return a garbage secret if too *many* shares are combined, too. My implementation does not have that problem.) Regardless of how does it, I believe that obfuscating that information is bad news from a usability perspective. Undoubtedly, users will make lots of backups of lots of wallets and think they remember the M-parameter but don't. They will accidentally mix in some 3-of-5 fragments with their 2-of-4 not realizing they are incompatible, or not able to distinguish them. Or they'll distribute too many thinking the threshold is higher and end up insecure, or possibly not have enough fragments to restore their wallet thinking the M-value was lower than it actually was. I just don't see the value in adding such complexity for the benefit of obfuscating information an attacker might be able to figure out anyway (most backups will be 2-of-N or 3-of-N) and can't act on anyway (because he doesn't know where the other frags are and they are actually in safe-deposit boxes) -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
Armory does exactly this: it defines the Fragment ID as the first few bytes of the hash of the root pubKey + M-parameter, converted to base58. Then it explains to the user All fragments with the same fragment ID are compatible (which only works if you use deterministic coefficients). Each fragment is then labeled with [FragID]-#1, [FragID]-#2, etc. It became quite useful for organizing the fragments and documenting how I was distributing them, especially if I had printed or saved the same fragment twice by accident. On 03/29/2014 02:16 PM, Tamas Blummer wrote: I also think that we can add usability features if the underlying secret remains well protected. I do not think there is any reason to assume that the knowledge of the degree of the polynomial, would aid an attacker. Similarly a fingerprint of the secret if it is unrelated to the hash used in the polinomyal should leak no useful information, The length of such fingerpring (say 4 bytes) and the degree (1 byte) does not seem a big overhead for me. Remember that the biggest obstacle of Bitcoin is usability not security. Regards, Tamas Blummer http://bitsofproof.com On 29.03.2014, at 18:52, Alan Reiner etothe...@gmail.com mailto:etothe...@gmail.com wrote: On 03/29/2014 01:19 PM, Matt Whitlock wrote: I intentionally omitted the parameter M (minimum subset size) from the shares because including it would give an adversary a vital piece of information. Likewise, including any kind of information that would allow a determination of whether the secret has been correctly reconstituted would give an adversary too much information. Failing silently when given incorrect shares or an insufficient number of shares is intentional. I do not believe this is a good tradeoff. It's basically obfuscation of something that is already considered secure at the expense of usability. It's much more important to me that the user understands what is in their hands (or their family members after they get hit by a bus), than to obfuscate the parameters of the secret sharing to provide a tiny disadvantage to an adversary who gets ahold of one. The fact that it fails silently is really all downside, not a benefit. If I have enough fragments, I can reconstruct the seed and see that it produces addresses with money. If not, I know I need more fragments. I'm much more concerned about my family having all the info they need to recover the money, than an attacker knowing that he needs two more fragments instead of which are well-secured anyway. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
This might be tangential, but the comment about refund chains reminded me. Armory will be implementing multi-sig/linked wallets where a each device has a parallel HDW branch and produces P2SH addresses. For those types of wallets, I plan to allocate two chains /per signing authority/. If you have a shared 2-of-2 wallet split between your phone and your spouse's phone, your phone would distribute addresses on P2SH chain 0 and generate change addresses on P2SH chain 1. Your spouse's phone would use chains 2 and 3. So if you and your spouse switch to a new app that supports M-of-N linked wallets, it should search for coin history along the first 2*N chains. -Alan On 03/26/2014 07:37 PM, Andreas Schildbach wrote: Thanks for starting the discussion on finding a better structure. For me, the most important thing is either we're 100% interoperable or 0%. There should not be anything inbetween, as users will delete seeds without knowing there is still money in them on another implementation. I heard from multiple sources that using this standard some wallets will only see a subset of the addresses/keys of some other wallets. Implementation differences can always happen (and should addresses as bugs), but I think its unacceptable that this source of issues is by design. I suggest we agree on an even simpler least common denominator and wallets that want to implement some feature on top of that can do but are encouraged to pick a totally different cointype. I guess that would mean removing reserved and account. I'm still thinking it might be a good idea to have a separate chain for refunds. Refunds will be rarely used and thus need a much slower moving window than receiving addresses or change. On 03/26/2014 09:49 PM, Mike Hearn wrote: Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure our BIP32 wallet structures would be compatible - and I discovered that only I was planning to use the default structure. Because I'm hopeful that we can get a lot of interoperability between wallets with regards to importing 12-words paper wallets, we brainstormed to find a structure acceptable to everyone and ended up with: /m/cointype/reserved'/account'/change/n The extra levels require some explanation: * cointype: This is zero for Bitcoin. This is here to support two things, one is supporting alt coins based off the same root seed. Right now nobody seemed very bothered about alt coins but sometimes feature requests do come in for this. Arguably there is no need and alt coins could just use the same keys as Bitcoin, but it may help avoid confusion if they don't. More usefully, cointype can distinguish between keys intended for things like multisig outputs, e.g. for watchdog services. This means if your wallet does not know about the extra protocol layers involved in this, it can still import the raw money and it will just ignore/not see the keys used in more complex transactions. * reserved is for other stuff. I actually don't recall why we ended up with this. It may have been intended to split out multisig outputs etc from cointype. Marek, Thomas? * account is for keeping essentially wallets-within-a-wallet to avoid mixing of coins. If you want that. * change is 0 for receiving addresses, 1 for change addresses. * n is the actual key index For bitcoinj we're targeting a deliberately limited feature set for hdw v1 so I would just set the first three values all to zero and that is a perfectly fine way to be compatible. The goal here is that the same seed can be written down once, and meet all the users needs, whilst still allowing some drift between what wallets support. Pieter made the I think valid point that you can't really encode how keys are meant to be used into just an HDW hierarchy and normally you'd need some metadata as well. However, I feel interop between wallets is more important than arriving at the most perfect possible arrangement, which feels a little like bikeshedding, so I'm happy to just go with the flow on this one. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tree-chains preliminary summary
I would echo the need for some kind of moderation. I believe Peter Todd is an extremely intelligent individual, who has a lot to offer the Bitcoin community. He has a firm grasp of a lot of really deep Bitcoin concepts and his *technical* insight is generally positive. Technically. But the way he communicates on this list is *extremely* corrosive and breeds hostility. It makes it a scary place to discuss things, with frequent, public ridicule of everything posted. I agree that I would rather have a friendly environment to discuss technicals, even if it means losing additional technical insight. People who would explicitly insult other contributors intelligence and character on a public list should be subject to some kind of negative reinforcement. Maybe there's solutions other than outright banning. -Alan On 03/25/2014 01:37 PM, Jeff Garzik wrote: On Tue, Mar 25, 2014 at 9:49 AM, Peter Todd p...@petertodd.org wrote: For someone with 'Chief Scientist' as their job title, I'm surprised you think so little of hard evidence and so much of idol worshipping. Peter, take this unprofessional, personal crap off-list. Mike's anecdote of hostility is not an isolated one. Just today, a bitcore developer commented on Peter Todd's ..apocalyptic vision and... negative view on bitcoin which turned off some other developers from participating more interactively. As I commented on IRC, open source projects are no strangers to people who simultaneously (a) make useful contributions and (b) turn potential contributors away with an abrasive or hostile attitude toward others. It's an unsolved problem in OSS, that I saw for 15+ years in the Linux kernel community. For this list, as Mike suggested on IRC, introducing an openly stated moderation policy may be the one route. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
On 03/13/2014 10:32 AM, Jeff Garzik wrote: On Thu, Mar 13, 2014 at 9:53 AM, Mike Hearn m...@plan99.net wrote: BitPay should use mBTC as well. Unless you can point to any major wallets, exchanges or price watching sites that use uBTC by default? I think it is highly optimistic to assume we'll need another 1000x shift any time soon. By now Bitcoin isn't obscure anymore. Lots of people have heard Such hand-wavy, data-free logic is precisely why community coordination is preferred to random apps making random decisions in this manner. mBTC is problematic because you do not need 1000x shift in value to produce annoyances for major accounting packages that are hard-limited to two decimal places. Further, spreadsheets hide information if formatting is configured naively -- that is, if formatting is configured for bitcoin the way it is configured for other currencies. Fundamentally, more than two decimal places tends to violate the Principle Of Least Astonishment with many humans, and as a result, popular software systems have been written with that assumption. I whole-heartedly agree with Jeff. micro-BTC was the way to go to end user confusion and make things easier for software systems which are designed to handle money (i.e. two decimal places). I also echo the sentiment about people being able to handle large numbers well. We've been working with Marty Zigman who's creating a Bitcoin plugin for NetSuite accounting platform, and he was already forced to switch micro-BTC long ago for exactly the reasons described above. I think the system will track up to 3 decimal places without causing all sorts of heartache and automatic rounding. Of course, as Mike said, this ship may have already sailed, but if there's any way to revisit this, I'm there. We're just about to do another Armory release and could support this very easily. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
On 03/13/2014 01:51 PM, Mike Hearn wrote: Well it looks like the consensus is to do it, instead of talking about it. I'm going to make sure we get uBTC into the next Armory release. Hmm - be careful with the word consensus here. A bunch of people on a mailing list does not make consensus ;) If you survey other wallets, you'll find most already switched to mBTC, that it took some effort to do so (look at the size of the patches for instance) and that probably, nobody is super-keen to change again so soon. So uBTC would make you different to most of the other wallets and services in wide usage. If Armory wants to do that, that's no problem, maybe it will be a competitive advantage - just saying, don't quote this thread as indicating some kind of community consensus. Wallets and services that are using mBTC (that I know of) blockchain.info http://blockchain.info MultiBit Bitcoin Wallet (Android) Hive Bitcoinity KnC Wallet (defaults to BTC but can be switched to mBTC in settings, uBTC not an option) Mullvad btcstore.eu http://btcstore.eu Doing a google search for [bitcoin mBTC] and [bitcoin uBTC], the former has a bunch of sites and services with prices in mBTC. The latter only has faucets, as far as I can tell, which sort of makes sense. I actually was not aware that so many had already switched to mBTC. I guess it shows how much I use other wallets. You misunderstood my consensus comment. I was simply stating the consensus of debating on the mailing list endlessly is not as effective as doing it. Thus I was just going to do it and see who follows. But that also assumed there was not a critical mass who'd already switched -- I must admit I'm not so confident anymore... I am/so strongly opposed //to mBTC /compared to uBTC, I was ready to take a small leap of faith (with associated risks), to help push the consensus. Of course it would still remain configurable, but the default will make a big difference. -Alan -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Multisign payment protocol?
I might as well throw in a word about Armory. After our next release in a couple weeks, we will be going full-speed at new wallets and BIP32 integration. Just like Jean-Pierre mentioned, we'll be using parallel trees to generate P2SH addresses after sorting the keys lexicographically. We plan to introduce the concept of a wallet bundle (that name is far from concrete... I'd love a better word). All wallets in a bundle are protected by the same backup, and stored in the same file. The default behavior will be use new branches in the same BIP32 tree when a user creates a new wallet, though we will allow multiple bundles in advanced and expert usermode (which is needed to have watching-only wallets from a different seed created from an offline computer). However, we do plan to allow separate parties to create multisig-intended wallets with public parts that can be exported and combined with other users. We feel this is critical, as it allows for linked wallets in which there was never a single-point of failure from key-generation to signing. This is especially important for contexts where employees may be handling a company's Bitcoins wallets. On this topic, I have gotten a lot of inquiries into BIP 38 and 39. I was not clear whether those BIPs were worth prioritizing ... i.e. is there a general consensus from a variety of wallet developers that they should be supported? Rather, I'm happy to start prioritizing them if others do too, but I haven't spent much time trying to understand them to even know if they're mature, yet. -Alan On 03/11/2014 08:29 PM, Jean-Pierre Rupp wrote: Hello people, We are working on some of this stuff. We had some very early draft on how we envisioned multisig happening. It is all implemented in Haskoin available as multiple repositories in Github. I am happy to see this gathering momentum. Our multisig system uses BIP-0032 HD wallets, and there will soon be BIP-0039 support for keys compatibility. Our wallet uses synced trees rooted at the extended pubkeys of the participants. Currently we are sorting public keys in the scripts to avoid ambiguity. Download haskoin-wallet: cabal install haskoin-wallet Check out the hw command (installed in ~/.cabal/bin/hw). Use importtx to bring transactions into the wallet. You must initialize first with a seed and create an account. It supports both regular and multisig accounts. Perhaps this can lead to interesting discussions on key exchange, and the appropriate handling of wallet metadata. I?d love to work on a proper standard that could lead us to compatible implementations. This document explains how we do it now: http://haskoin.com/~xeno/hd-multisig-wallet.html Cheers! -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Multisign payment protocol?
As far as I'm concerned, the way forward is to scrap BIP 10 and build up something new that is flexible and extensible. Also, my understanding is that there may be room in the payment protocol for this stuff though I'm not sure if it is really adapted well to all the steps: exchanging public keys, creating multi-sig/P2SH addresses, proposing multi-sig spends, bundling meta-data needed for lite/offline nodes, aggregating signatures, and any other details. When I start multisig integration into Armory (very soon!) I'll write a list of requirements for the new format/process and post it here for a wider discussion. Certainly, if the payment protocol can already handle all this, that would be awesome. -Alan On 03/10/2014 08:04 PM, kjj wrote: I was trying to use bip10 for multisig and coinjoin, but there was a problem with it. I'll have to look back at my notes, but I thought I sent you a message about it. And then real life swallowed my bitcoin time... I think the bottom line was that it would be useful in the generic case with just one minor change. If there is interest, and it sounds like there just may be, I can dust off my notes and see where I left it. Probably should do it soon before someone implements it in PB or XML. Alan Reiner wrote: Then of course I tried to do this with BIP 10 https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki when Armory implemented offline-transactions two years ago. I got some positive feedback, but no one wanted to help improve it, etc. I guess nobody else was doing it and/or cared at the time. So I continue to use BIP 10 even though it's pretty crappy. I wanted it to be useful for multisig, too, but it has some deficiencies there (it was done when Armory was extremely young and OP_EVAL was still on the table). However, with all this activity, we should start thinking about that and discussing it. Otherwise, I'll just do my own thing again and probably end up with something that fits my own needs, but not anyone else's. Really though, multisig shouldn't require all the same app to work. -Alan On 03/10/2014 01:49 PM, Gavin Andresen wrote: In my experience, best process for standardizing something is: 1) Somebody has a great idea 2) They implement it 3) Everybody agrees, Great idea! and they copy it. 4) Idea gets refined by the people copying it. 5) It gets standardized. Mutisig wallets are at step 2 right now. BIP is step 5, in my humble opinion... On Mon, Mar 10, 2014 at 1:39 PM, Drak d...@zikula.org mailto:d...@zikula.org wrote: I was wondering if there would be merit in a kind of BIP for a payment protocol using multisig? Currently, setting up a multisig is quite a feat. Users have to exchange public keys, work out how to get the public keys from their addresses. If one of the parties are not savvy enough, an malicious party could easily be setup that was 2 of 3 instead of 2 of 2 where the malicious party generates the multisig address+script and thus be able to run off with funds anyway. It's also terribly complex to generate and keep track of. There's been a nice attempt at creating an browser interface at coinb.in/multisig http://coinb.in/multisig but it still lacks the kind of ease with created by the payment protocol. If there was a BIP then it would go a long way to aiding future usability of multisig wallet implementations. What are your thoughts? Drak -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- -- Gavin Andresen -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases
Re: [Bitcoin-development] Is this a safe thing to be doing with ECC addition? (Oracle protocol)
Note that one of the reasons why this is insecure is because EC point addition is invertible. EC-scalar multiplication is not, thus why EC Diffie-Hellman is secure even when this timing asymmetry exists. A good cryptosystem doesn't have strange restrictions, like your public key can only be public sometimes, but needs to protected like your private key other times. If you have to worry about things like that, you're doing it wrong :) And why we always recommend sticking to well-known, well-studied operations. -Alan On 03/08/2014 03:51 AM, Edmund Edgar wrote: On 8 March 2014 17:10, Alan Reiner etothe...@gmail.com mailto:etothe...@gmail.com wrote: I create a new keypair, c_pub with c_priv which I know (it can be any arbitrary key pair). But I don't give you c_pub, I give you b_pub = c_pub minus a_pub (which I can do because I've seen a_pub before doing this). Sure, I don't know the private key for b_pub, but it doesn't matter... because what b_pub + a_pub = c_pub (mine) You have no way to detect this condition, because you don't know what c_pub/c_priv I created, so you can only detect this after it's too late (after I abuse the private key) Thanks Alan and Forrest, that makes sense. So to salvage the situation in the original case, we have to make sure the parties exchange their public keys first, before they're allowed to see the public keys they'll be combining them with. -- -- Edmund Edgar Founder, Social Minds Inc (KK) Twitter: @edmundedgar Linked In: edmundedgar Skype: edmundedgar http://www.socialminds.jp Reality Keys @realitykeys e...@realitykeys.com mailto:e...@realitykeys.com https://www.realitykeys.com -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Is this a safe thing to be doing with ECC addition? (Oracle protocol)
Note that one of the reasons why this is insecure is because EC point addition is invertible. EC-scalar multiplication is not, thus why EC Diffie-Hellman is secure even when this asymmetry exists. A good cryptosystem doesn't have strange restrictions, like your public key can only be public sometimes, but needs to protected like your private key other times. If you have to worry about things like that, you're doing it wrong :) -Alan On 03/08/2014 05:37 AM, Joel Kaartinen wrote: If both parties insist on seeing a hash of the other party's public key before they'll show their own public key, they can be sure that the public key is not chosen based on the public key they themselves presented. Although, I have to wonder, why not just use multisig? - Joel On 08.03.2014 10:51, Edmund Edgar wrote: On 8 March 2014 17:10, Alan Reiner etothe...@gmail.com mailto:etothe...@gmail.com wrote: I create a new keypair, c_pub with c_priv which I know (it can be any arbitrary key pair). But I don't give you c_pub, I give you b_pub = c_pub minus a_pub (which I can do because I've seen a_pub before doing this). Sure, I don't know the private key for b_pub, but it doesn't matter... because what b_pub + a_pub = c_pub (mine) You have no way to detect this condition, because you don't know what c_pub/c_priv I created, so you can only detect this after it's too late (after I abuse the private key) Thanks Alan and Forrest, that makes sense. So to salvage the situation in the original case, we have to make sure the parties exchange their public keys first, before they're allowed to see the public keys they'll be combining them with. -- -- Edmund Edgar Founder, Social Minds Inc (KK) Twitter: @edmundedgar Linked In: edmundedgar Skype: edmundedgar http://www.socialminds.jp Reality Keys @realitykeys e...@realitykeys.com mailto:e...@realitykeys.com https://www.realitykeys.com -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
I think the solution is simply to encourage Bitcoin software developers to design their software to use this static ID, instead of the full transaction hash.If MtGox had talked those IDs instead of the TX ID, their software would've correctly identified the mutated transactions and there would be no problem. Armory is slightly different, since it doesn't deal with the same stuff as exchanges do. But it didn't have any problems with malleability because it doesn't track anything by ID, it only pays attention to whether inputs and outputs are related to your wallets. It's not necessarily hard to do it this way, people just have to be aware of it. -Alan Sent from my overpriced smartphone On Feb 12, 2014 10:15 AM, Rune Kjær Svendsen runesv...@gmail.com wrote: Instead of trying to remove the possibility of transaction malleability, would it make sense to define a new, canonical transaction hash/ID (cTxID), which would be a hash of the part of the transaction data which we know is not malleable, and have clients use this cTxID internally, thus making the traditional transaction hash irrelevant for a client to function correctly? We already have a non-malleable transaction hash: the hash that is signed, ie. the transaction with each scriptSig replaced by the scriptPubKey it redeems. This could be the cTxID. Or is this simply a too fundamental change to the way bitcoin-qt (and all other clients) work in order to be feasible? As far as I can see, it completely solves the issue of not having a canonical ID for a transaction, but it also increases the computational requirements for a node. For one, as far as I can see, it requires the node to index all transactions, because in order to calculate a cTxID, it would be necessary to fetch all transactions referred to by the transaction in question, in order to pull in the scriptPubKeys that are redeemed. On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd p...@petertodd.org wrote: On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote: Hello all, it was something I planned to do since a long time, but with the recent related issues popping up, I finally got around to writing a BIP about how we can get rid of transaction malleability over time. The proposed document is here: https://gist.github.com/sipa/8907691 I expect most rules to not be controversial. Maybe rules 1 and 3, as they require modifications to wallet software (Bitcoin Core 0.9 and BitcoinJ already implement it, though) and potentially invalidate some script functionality. However, these new rules remain optional and controlled by an nVersion increase. Comments please! You should probably add making CHECKMULTISIG require the dummy value to be exactly equal to OP_FALSE; verifying that in the transaction itself is laborious. A more subtle example is we may want both CHECKSIG and CHECKMULTISIG to fail the transaction if the signature is invalid but not exactly equal to OP_FALSE; some transaction forms are significantly more compact if you can have failed signatures, but that's a source of malleability. (are there counter examples people can think of?) But as I said on IRC, I'm a bit hesitant to bake in assumptions about malleability when we have no solid idea if ECC signatures are or are not malleable on a fundemental level; if whack-a-mole anti-malleability is all we've got it could be ugly if a break is found. Similarly, we may find we missed something, or some needed change makes the malleability rules difficult to work with for some new script type that is required. I'd rather see a new CHECKSIG mode for the case where malleability absolutely must be eliminated - certain multi-party protocols - and fix wallet software instead. (the malleability problems people see are closely related to inability to handle double-spends and reorgs) But I can easily see that being an impossible goal engineering wise... -- 'peter'[:-1]@petertodd.org 0001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1 -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
Agreed. I'm not suggesting that malleability shouldn't be fixed or isn't a problem. I would love to be able to leverage chained TX for Bitcoin contracts. But that in its current state it doesn't have to be complicated to deal with it. Changing the protocol to use these static IDs is a pretty fundamental change that would never happen in Bitcoin. But they can still be useful at the application level to mitigate these issues. Sent from my overpriced smartphone On Feb 12, 2014 11:38 AM, Allen Piscitello allen.piscite...@gmail.com wrote: While that solution does work for many use cases, it does make it much harder to do anything needing chained transactions. Granted, this is the short term solution for current implementations, but having a transaction identifier that does not change does open up other use cases. For example, Alice wants to send coins to a multisignature address with Bob, such that both parties are required to spend the coins. Alice also requires for Bob to send coins to this address as well before they will proceed. Alice cannot guarantee that Bob will cooperate (and vice versa), so before she broadcasts the transaction to send to A+B, she sends Bob a transaction that spends her incoming transaction back to herself, but has a time lock of far into the future. Bob signs this, returns it to Alice, and she broadcasts her funding transaction. At this point, Bob disappears, loses his key, or just decides to spite Alice and her coins are locked. Since she has a refund transaction, she can broadcast it in a month and get her coins back. Except her funding transaction has been modified such that the txhash is different, so her refund is now invalid. She would need Bob to issue a new refund as soon as her funding transaction hits the blockchain if it is modified, which defeats the point of the trustless refund transaction. Longer term it would be more ideal have a canonical identifier for the transaction before it even gets to the chain to support these use cases, even if wallets are able to properly identify the status of it's transactions. Obviously this is a difficult problem to solve and cannot be implemented without breaking changes, but it would be a nice goal to be able to completely remove malleability. There are other important use cases where having a unique identifier just for internal accounting is insufficient. -Allen On Wed, Feb 12, 2014 at 10:22 AM, Alan Reiner etothe...@gmail.com wrote: I think the solution is simply to encourage Bitcoin software developers to design their software to use this static ID, instead of the full transaction hash.If MtGox had talked those IDs instead of the TX ID, their software would've correctly identified the mutated transactions and there would be no problem. Armory is slightly different, since it doesn't deal with the same stuff as exchanges do. But it didn't have any problems with malleability because it doesn't track anything by ID, it only pays attention to whether inputs and outputs are related to your wallets. It's not necessarily hard to do it this way, people just have to be aware of it. -Alan Sent from my overpriced smartphone On Feb 12, 2014 10:15 AM, Rune Kjær Svendsen runesv...@gmail.com wrote: Instead of trying to remove the possibility of transaction malleability, would it make sense to define a new, canonical transaction hash/ID (cTxID), which would be a hash of the part of the transaction data which we know is not malleable, and have clients use this cTxID internally, thus making the traditional transaction hash irrelevant for a client to function correctly? We already have a non-malleable transaction hash: the hash that is signed, ie. the transaction with each scriptSig replaced by the scriptPubKey it redeems. This could be the cTxID. Or is this simply a too fundamental change to the way bitcoin-qt (and all other clients) work in order to be feasible? As far as I can see, it completely solves the issue of not having a canonical ID for a transaction, but it also increases the computational requirements for a node. For one, as far as I can see, it requires the node to index all transactions, because in order to calculate a cTxID, it would be necessary to fetch all transactions referred to by the transaction in question, in order to pull in the scriptPubKeys that are redeemed. On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd p...@petertodd.org wrote: On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote: Hello all, it was something I planned to do since a long time, but with the recent related issues popping up, I finally got around to writing a BIP about how we can get rid of transaction malleability over time. The proposed document is here: https://gist.github.com/sipa/8907691 I expect most rules to not be controversial. Maybe rules 1 and 3, as they require modifications to wallet software (Bitcoin Core 0.9
Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
We're talking about two slightly different things. If their system had tracked by inputs and outputs (or some kind of static ID) , their system wouldn't have been issuing refunds/replacements/cancellations in the first place. I agree with you that the reissuing code should also guarantee that both TX can't be valid... But really their system should do both. Without the I/O based tracking their bookkeeping will be off, regardless of the reissuing code, because they can't properly associate outgoing transactions with customer accounts/actions. Sent from my overpriced smartphone On Feb 12, 2014 1:06 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Wed, Feb 12, 2014 at 7:12 AM, Rune Kjær Svendsen runesv...@gmail.com wrote: Instead of trying to remove the possibility of transaction malleability, would it make sense to define a new, canonical transaction hash/ID (cTxID), which would be a hash of the part of the transaction data which we know is not malleable, and have clients use this cTxID internally, thus making the traditional transaction hash irrelevant for a client to function correctly? This is fine and good. But it only scratches the surface of the problems created by malleability, especially for fancier transaction protocols. Mutation allows you to invalidate a chain of unconfirmed transaction by mutating the parent. This breaks any protocol which depends on creating a precomputed nlocked time refund transaction. So a canonical ID can be used to prevent some buggy behavior it doesn't actually fix the problem. Fortunately the non-fixed parts aren't too critical today. On Wed, Feb 12, 2014 at 8:22 AM, Alan Reiner etothe...@gmail.com wrote: I think the solution is simply to encourage Bitcoin software developers to design their software to use this static ID, instead of the full transaction hash.If MtGox had talked those IDs instead of the TX ID, their software would've correctly identified the mutated transactions and there would be no problem. This is incorrect. MtGox was automatically issuing replacement transactions resulting in double payments. When you attempt to replace/reissue/cancel a transaction you __MUST__ double-spend the original transaction. If the original transaction has not been conflicted then it is possible someone will pull the original transaction out of a hat and both your replacement and the original will be confirmed. It is not safe at any time to look to see if the original has been confirmed yet, and if not reissue-- not because mutation may mean you're looking in the wrong place-- but because the state of the world could change nano-seconds after you looked. If you do double-spend the original then there is no chance that both will go through, you'll have atomic exclusion and only one transaction or the other will be confirmed. -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
On 01/13/2014 04:02 PM, Roy Badami wrote: It's not public. When I say please pay me I also say use this multiplier. Sending a please pay me message is really great for business transactions. But I think the use case that Peter Todd mentions is actually *the* most important currently under-addresesd use case: With stealth addresses the user experience can be as simple as you telling me on the phone hey! send me that 0.234 BTC you owe me!, me clicking on Send to Alan Reiner (verified by PGP) (perhaps again on my off-line second factor device for a multi-sig wallet) and tellling you OK, sent. Lots of work is being done on handling consumer-to-merchant transactions. BIP 70 does a good job of tackling the online purchase case, and the work that Andreas Schildbach is doing with Bluetooth and NFC will improve the options for a payer in a physical PoS transaction who might not have Internet connectivity on their smartphone. But relatively little work (that I know of) is being done on non-transactional personal payments - that is, being able to pay money to friends and other people that you have a face-to-face relationship with. What I want... no need... is to be able to open my wallet, select a friend from my address book, and transfer the $10 I owe them from the bar last night. I don't care - within reason - what process is involved in getting my friend set up in my address book. That may well requires two way communication (e.g. over NFC). But once it's set up, I should be able to just select the payee from the address book and send them some funds. Anything else is just too complciated. I don't know if stealth addresses are the best solution to address this use case, but AFAIK the only current solution to this use case is to store a long-lived Bitcoin address in the addresss book. roy Fair enough. I haven't spent much time thinking about that use case. Though, I question the feasibility of anything that requires O(N) EC multiply operations/sec, where N is the total volume of transactions moving over the network. But I guess if the prefix is big enough, the scanning operations will remain feasible forever. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
I highly recommend that if we make any move towards this, that the software show verification in both/all units. For instance, there should be 3 input fields, one for BTC, one for mBTC one for uBTC. As the user enters a value in one of the fields, it would automatically update the other fields with the converted value as they type. This makes it really difficult to get it wrong... if you're typing 10 into the BTC field, thinking it's mBTC, you'll see 10,000 mBTC showing up in the other box as you type. Similarly, it should display all units on all verification windows. Users may also use it for sanity checking conversion between units. Personally, I'm of the opinion that this change is important in the long run: the current price makes Bitcoin *intimidating* to new users. But I'm also of the opinion that it's freakin' hard to change the base unit in such an established system. There is no easy way to do this that doesn't cause more heartache than it's worth. But it's possible if you make it idiot-proof enough, and roll it out in the least inconvenient way. -Alan On 11/14/2013 06:45 AM, Melvin Carvalho wrote: Rationale === Given the recent rise in value there seems to be anecdotal evidence that 1 bitcoin being so high is putting off a lot of normal buyers, because they feel that putting down $400+ and only getting 1 coin, or having to buy in multiples of 1 whole coin, is too much.. only after it being explained that they can buy fractional amounts to they regain interest, apparently happening increasingly. Straw Poll 6 months ago there was a straw poll on this https://bitcointalk.org/index.php?topic=220322.0 Roughly 2/3 of respondents favoured switching A further 20% said to switch after it hits 1000 Satoshi's comments: Eventually at most only 21 million coins for 6.8 billion people in the world if it really gets huge. But don't worry, there are another 6 decimal places that aren't shown, for a total of 8 decimal places internally. It shows 1.00 but internally it's 1.. If there's massive deflation in the future, the software could show more decimal places. If it gets tiresome working with small numbers, we could change where the display shows the decimal point. Same amount of money, just different convention for where the ,'s and .'s go. e.g. moving the decimal place 3 places would mean if you had 1.0 before, now it shows it as 1,000.00. https://bitcointalk.org/index.php?topic=44.msg267#msg267 Would now be a good time to start thinking about changing the default display in the software. Perhaps initially it could be a dropdown display option, then at some point mbtc becomes the default? -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
I disagree. There's a real perception and usability issue with the current interface combined with the current price. People are intimidated by the current system, even though the price really reflects Bitcoin starting to spread its wings (maybe prematurely, bubble-style, but the price will have to get to this point eventually if Bitcoin will thrive at the target scale). Bitcoin's learning curve is hard enough already. As silly as it sounds, feeling insecure because you only 0.00032 BTC, and then using too many zeroes when paying for your smoothie are problems that can really turn people off. You say Let the market sort it out. Sometimes the market needs direction and consistency. Without us doing anything, we just end up with fragmentation and confusion. I'd much prefer we reach a consensus on a path forward and push that path hard. Because there's always resistance to change, and confusion along the way. The easier and more consistent we can make it, the smoother it will be. We want to avoid: Hey, I'll sell it to you for 382 microbes. What is a microbe? Is that the same as a XBT? I don't know, my wallet uses NBC. Well how much BTC is it? Okay, just send me 0.00038200 BTC Four zeros after the decimal? Yeah... oh wait you just sent me 10x ... Again it sounds silly, but this is a real usability issue. On 11/14/2013 07:37 PM, Daniel F wrote: This is a decentralized currency, and we should avoid centralizing decisions. This is something that impacts the community at large, and deserves input and discussion at every level. I would suggest posting on all possible forums proposal: switch to uBTC, labelled as ISO prefers (XBT?) and see what sort of discussion is generated. If the support is broad, it will be plain from the responses if there is a consensus. Perhaps everyone will agree it is the best course, and we can make an easy change. But we need less core dev fiat not more :) this seems like such a paint-the-bikeshed problem that it's sure to generate vast volumes of discussion, waste a lot of people's time, and all for only a dubious (imo) gain. (case in point - here i am contributing to it :) ). i agree that we should avoid centralizing this. i'll go a step further and note that the client already has a dropdown allowing individuals to choose units. merchants are free to choose to price in different units. exchanges are free to denominate trade in different units. i suggest we just let the market do its thing and not get into trying to 'make a decision' of any sort. -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Auto-generated miner backbone
Sorry guys, I'm a little late to the party here. I skimmed over the paper, and appreciated Peter Todd's recap of it. My first thought was that this seems profit-neutral at best, when you take into account all the races you lose by trying to beat the propagation of other miners' blocks. So given the assumption that Alice is well-connected as Peter mentioned, it seems like this is a concern. But is this a realistic assumption? All miners have an incentive to be thoroughly connected to one another, to make sure they minimize the amount of time they spend mining on forks and that their blocks win with minimal chance of being orphaned. Is it realistic that one miner can somehow monopolize the good connections when the big miners are already trying to do the same thing for honest reasons? If you have a network full of honest miners and this one selfish-miner, it seems that all the honest miners need to do is try to establish those connections to each other as well as Alice does, and Alice will end up orphaning all her profit away. Furthermore, you can de-incentivize it by simply randomizing the order of broadcasts. Although you are maintaining multiple concurrent connections, the data still exits your network card as a serial stream of packets, and it seems that if you randomize who gets your new-block broadcasts first, then it further reduces the Alice's advantage if she's not guaranteed to be first. Sure, she can do it sometimes, but it would seem that even a couple failures to beat the rest of the network is going to erase most/all of what she gained on the blocks/chains that she wins. I liked the statement by Chris WIllmer on the reddit thread: practice theory. The more we can theorize our way to believing the conclusions that this is a problem, the more incentive there is for someone intelligent to actually try it. It's very possible that the conditions needed to execute this attack just cannot be attained in practice. -Alan On 11/04/2013 04:04 PM, Peter Todd wrote: On Mon, Nov 04, 2013 at 02:12:44PM -0500, Ittay wrote: On Mon, Nov 4, 2013 at 10:25 AM, Ittay ittay.e...@cornell.edu wrote: As for the rational motivation of the individual miners - that's a good point! Here is a solution we did not put in the paper due to space constraints that should alleviate your concern: Instead of locally choosing a block at random, have a deterministic pseudo-random mechanism for choosing between competing chains. E.g., take the one whose last block hash is smaller. This way all miners choose the same chain, and the guarantees of our solution hold. I take that back. Speaking of, I'm going to take back my solution as well; I misunderstood your paper. So here's your argument in a ELI5 nutshell: Alice is a miner with some amount of hashing power. She has the ability to detect new blocks on the network extremely effectively for whatever reason; in short she has unusually good knowledge of the state of the network. She is also very good at publishing her blocks and getting them to the majority of hashing power in very little time; she has unusually good connectivity to all miners. (low-latency and high bandwidth) She's so good at this that when she finds a new block, she keeps it a secret! She can get away with this because she knows that the moment Bob finds a block, she can immediately broadcast it to the rest of the network before the other block propagates. Instead of building on Bob's blocks, almost everyone builds on Alice's block, depriving Bob of the revenue. Gradually Alice gets more and more miners because Bob, and other pools, don't pay out as much. You propose a rule where essentially miners extend Bob's block 50% of the time, and show in your paper how that leads to a scenario where Alice needs to have at leastr 1/4 of the total hashing power to succesfully pull this attack off anyway. What I did succesfully show is that for a short-term rational miner they're still better off mining to extend the block they hear about first rather than using your pick-one-at-random rule, because when you hear about a block is important information about whether or not the majority is mining on it. This is true even if others are using the pick-one-at-random rule. (they're better defecting than doing what's right for the whole network) Even worse is that miners have a rational incentive to broadcast such near-target headers to try to encourage other miners to work on the same fork that they are working on. The near-target idea came about for a totally different reason, so it's something that might wind up being implemented anyway. Mike Hearn's idea of making it easy to identify nodes associated with hashing power is still wrong. Although again, it's something that miners themselves have rational incentives to do. (you always want to encourage others to send you their blocks, and you also want to be able to send your blocks to the majority of hashing
Re: [Bitcoin-development] is there a way to do bitcoin-staging?
Michael, Very interesting that you have tackled that off the radar. I didn't know anyone else was working on anything similar. I'm sure you saw the recent Armory-funding announcement, so understandably I have other priorities in recent past and near future, but I think you should connect with Mark Friedenbach about this topic. He solicited donations for working on my idea, and has been doing proof-of-concept for for the last few months. In fact, he was just looking for funding for another 3 months, and Armory Technologies, Inc, just offered up 50 BTC for him to continue (@Mark, whoops, I haven't actually paid you yet; contact me to work out details). For now, my ability to participate directly is limited, but I am still very interested to see the ideas developed further, as well as provide a first test of this whole staging-area idea. I devised it originally for the UBC/Reiner-tree concept, but there's no reason it couldn't be used for any other type of sweeping change to the protocol. -Alan On 10/14/2013 02:43 PM, Michael Gronager wrote: Hi Alan, What you describe in the ultimate blockchain compression I have already coded the authenticated datastructure part of in libcoin (https://github.com/libcoin/libcoin) - next step is to include a p2pool style mining, where a parallel chain serves several purposes: 1. to validate the root hash at a higher frequency than the 10 min 2. to enable distributed mining, easily (part of libcoind) 3. to utilize the soft fork by defining the root hash in coinbase blocks as v3 and once we cross the limit all blocks are v3. I will have a closer look at you bitcoin talk post to see how well my approach and ideas fit to yours. Michael On 20/5/13 08:34 , Alan Reiner wrote: This is exactly what I was planning to do with the inappropriately-named Ultimate Blockchain Compression https://bitcointalk.org/index.php?topic=88208.0. I wanted to reorganize the blockchain data into an authenticated tree, indexed by TxOut script (address), instead of tx-hash. Much like a regular merkle tree, you can store the root in the block header, and communicate branches of that tree to nodes, to prove inclusion (and exclusion!) of TxOuts for any given script/address. Additionally, you can include at each node, the sum of BTC in all nodes below it, which offers some other nice benefits. I think this idea is has epic upside-potential for bitcoin if it works -- even SPV nodes could query their unspent TxOut list for their wallet from any untrusted peer and compare the result directly to the blockheaders/POW. Given nothing but the headers, you can verify the balance of 100 addresses with 250 kB. But also epic failure-potential in terms of feasibility and cost-to-benefit for miners. For it to really work, it's gotta be part of the mainnet validation rules, but no way it can be evaluated realistically without some kind of staging. Therefore, I had proposed that this be merge-mined on a meta-chain first...get a bunch of miners on board to agree to merge mine and see it in action. It seemed like a perfectly non-disruptive way to prove out a particular idea before we actually consider making a protocol change that significant. Even if it stayed on its own meta chain, as long as there is some significant amount of hashpower working on it, it can still be a useful tool. Unfortunately, my experience with merged mining is minimal, so I'm still not clear how feasible/reliable it is as an alternative to direct blockchain integration. That's a discussion I'd like to have. -Alan On 5/19/2013 11:08 AM, Peter Vessenes wrote: I think this is a very interesting idea. As Bitcoiners, we often stuff things into the 'alt chain' bucket in our heads; I wonder if this idea works better as a curing period, essentially an extended version of the current 100 block wait for mined coins. An alternate setup comes to mind; I can imagine this working as a sort of gift economy; people pay real BTC for merge-mined beta BTC as a way to support development. There is no doubt a more elegant and practical solution that might have different economic and crypto characteristics. On Sun, May 19, 2013 at 6:23 AM, Adam Back a...@cypherspace.org mailto:a...@cypherspace.org wrote: Is there a way to experiment with new features - eg committed coins - that doesnt involve an altcoin in the conventional sense, and also doesnt impose a big testing burden on bitcoin main which is a security and testing risk? eg lets say some form of merged mine where an alt-coin lets call it bitcoin-staging? where the coins are the same coins as on bitcoin, the mining power goes to bitcoin main, so some aspect of merged mining, but no native mining. and ability to use bitcoins by locking them on bitcoin to move them to bitcoin-staging and vice versa (ie exchange them 1:1 cryptographically, no exchange
[Bitcoin-development] Optional wallet-linkable address format (Re-request)
Guys, I'd like to reiterate my previous request to support this alternate address serialization in the payment protocol. We got caught up in the specifics of one use case, but didn't acknowledge that it's still a valid address representation that will provide value to those who wish to use it and can be safely ignored by others. Current address format: binary_to_base58( idbyte + hash160(pubkey) + checksum) Alternate format: binary_to_base58( idbyte + parentpubkey + multiplier + checksum) The receiving party will multiply the pubkey by the multiplier, and then hash it to get the 20-byte address to send to. The idea is that you use your BIP 32 parent public key, and then you generate whatever child you want, and only send them the multiplier used (not the chaincode). This preserves privacy, but if the recipient has your parent public key already, they can identify that address being linked to you, but cannot determine any other addresses in your wallet. This form has no drawbacks to the existing address format except for being longer and requiring an extra EC multiplication by the person sending to that address. But the advantage is that it optionally allows the sender to provide more information than currently contained in the 25-byte hash160 form. The discussion about this got side-tracked with the use case I presented, but I believe there are plenty of other uses for this. The particular use case I had in mind was that certain services could be setup (pre-arranged), say between wallet software and a business/exchange. The exchange would like to be able to reliably send addresses to the user for deposit, without risk of MITM, or even if their own public server is compromised. The author of wallet software pre-verifies the public key portion of the service, and either hardcodes it into the software, or hardcodes their own public key into the software and makes the service's signed public key available through query server (allowing the software author to offline-sign replacement keys, or add keys for new service providers, as needed). When the user's software receives a payment address, the software can verify it belongs to that service. You can't use dedicated chain technique, because it would either have to be exchanged with the user on first transaction which half defeats the purpose, or they give them the full public key and chaincode which allows the user to see /all /addresses ever used by the service. Neither one is a reasonable solution. This use case doesn't necessarily scale, but it doesn't have to. It simply allows service providers to skip the SSL and go right to public key exchange/verification for a few of the important services they provide access to, and will provide better security than relying on SSL/PKI. This would simply be one, coexisting option for providing payment details in the absence (or in addition to) SSL/PKI infrastructure. I'm sure there's other use cases, but it seems simple enough and non-disruptive enough that it could be supported easily for no other reason than to support that use case (which I intend to implement in Armory to help verify high-volume services). -Alan On 06/26/2013 11:29 AM, Alan Reiner wrote: Although I'd still prefer my original request, I get much of what I want from your guys' recommendation. It complicates the wallet design, because it requires tracking and associating a matrix of addresses for each wallet, instead of a single linear list. But if this is what it's going to take then I will go along. Right now BIP 32 defines, m/i'/j/k, where j=0 is the external chain used for distributing addresses, and j=1 is the internal chain for sending change. The CONOPs (concept of operations) for the extended wallet would be like Jeremy described: - Chains with j=2 would be independent address chains carved out for individuals relationships - Add wallet code to individually associate each j-value with a particular identity - Update the wallet code to pool all the addresses in all j-chains when calculating the balance of the wallet and/or creating transactions - When choosing to generically Receive Bitcoins, will pick the next address from the j=0 chain - Will have to add extra function to Receive Bitcoins button to allow creation of new contacts/identities. - Change will always go to the next address in j=1, no matter which chains are used to provide inputs. - Add code to figure out lookaheads for each alternate chain. Not just each chain, but looking ahead a couple chains, too. Luckily, the lookahead doesn't have to be very big for chains j=1 - Add an interface to display and choose the different chains in your wallet, and export the pubkeychaincode in some soon-to-be-standardized format. - Add code and interface to receive and track alternate j-chains from other clients/users, and maintain those. Should we try associating incoming and outgoing chains? What happens if they do
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
On 08/07/2013 05:10 PM, Gavin Andresen wrote: I'd like to hear from other wallet implementors. Do you have a notion of 'locked inputs' ? The tricky bit in constructing a transaction but not broadcasting it right away is the inputs must be locked, so they're not accidentally double-spent. I have avoided any notion of locking inputs in Armory for offline wallets. The underlying concept of why a seemingly-random amount of funds are inaccessible at a given time is so non-intuitive and difficult to explain to a non-expert, that I haven't even tried to deal with it. Luckily, most users do one operation at a time, so it's not a real a problem. But as more businesses have started to use Armory, it /will/ become a problem that will need to be addressed /somehow/. I have considered at least marking inputs to indicate to the user that the transaction they are creating may not be valid unless all previous transactions have been broadcast. The user will not necessarily understand why, but they might easily comprehend the solution (and perhaps a button that says Forget all previously created transactions that haven't been broadcast. Press this button if there are no transactions waiting to be broadcast). Even if the user somewhat understands the concepts behind locking, you easily end up with a mess of some coins being locked and rejecting transaction creation somewhat randomly, especially when they create transactions that they later decide not to execute. And you have to give the user a way to manually unlock the outputs which they wouldn't know to use because it's so non-intuitive. I'd much rather say either do one transaction at a time, or bundle payments into a single multi-output transaction. Or risk invalid transactions that have to be re-created and signed. -Alan -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Safe auto-updating
Indeed. You can hardcode a distributor public key in the software, and client software will only trust signed data from that key. Of course, the private key for that data is not kept on the server distributing the signed checksums. Ideally it would be kept offline, and the couple-times-per-year that you actually execute an upgrade, you sign the new checksums offline and upload the signed checksum to the distribution server. Then even if the server is compromised, the client-side software will not accept a bogus checksum because it won't bear the right signature. If you do this, it would be good to also have some kind of revocation process that can be used in the event of the offline key being compromised. You won't be able to switch keys, as that would defeat the purpose (the attacker who compromises the offline key could just issue a replacement with his own). Instead, it would be an irreversible broadcast that would force clients to start rejecting updates from that key. If the key is compromised (and find out), you broadcast the revocation and the users will stop auto-updating, and be given a warning that they should manually upgrade the software through trusted channels. It's not failproof, but it's a decent way to minimize damage if you discover compromise early enough. -Alan On 08/05/2013 11:54 AM, Daniel F wrote: If you want package authentication, you should at least throw in some digital signing, not just a checksum. With a compromised host, both the checksum and binaries can be changed undetectably, but if there's a signature made by a key that is not kept on the host, there's no way to fake a valid binary. There may be other issues people would want to bring up, but surely just a checksum is not sufficient. on 08/05/2013 10:39 AM Wendell said the following: For usability purposes, we at Hive would like to have an auto-updater in our wallet app. What is a safe way to do this? I understand that Bitcoin-QT lacks such an updater for security reasons... Has been thought out in more detail since that decision was made? We have been toying around with the idea of placing one server behind a Tor hidden service, whose only function is to output a checksum of the update package. The theory is that if it is well-secured, it will at least be immune to tampering at the physical hosting level. Any thoughts or advice about any of this? -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Preparing for the Cryptopocalypse
That is a great presentation, thanks for sharing that! Though I question the validity of the claim that ECC is so much more secure than RSA (with appropriate keysizes). My experience from studying quantum computing is that Factoring and DLP are intimately related, such that a break of one is likely to break the other. In fact, I seem to remember that QCs use an efficient DLP-solving circuit to shortcut the factoring problem. But it's been a long time since I looked at it, so I don't remember for sure. Also, it's not clear whether that relationship exists outside the scope of QCs. It's still a good presentation, but they're pushing ECC pretty hard as the answer to the cryptopocalypse, and I'm not convinced that's a real answer. -Alan On 08/04/2013 01:13 PM, Melvin Carvalho wrote: A great presentation on advances in crypto http://www.slideshare.net/astamos/bh-slides -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Preparing for the Cryptopocalypse
Whoops, I didn't mean to run us down the Quantum Computing debate path. I was simply using my experience with QCs as a basis for questioning the conclusion that ECDLP is so much more robust than RSA/factoring problems. It's possible we would simply be jumping from one burning bridge to another burning bridge by rushing to convert everything to ECC in the event of a factoring breakthrough. From the perspective of quantum computers, it seems those two problems are essentially the same. As I said, I remember that one of the problems is solved by using the solution/circuit for the other. But I don't know if this relationship holds outside the realm of QCs. The guy who did this presentation said he's not a mathematician and/or cryptographer, yet he still strongly asserts the superiority of ECDLP. I'm not convinced. On 08/05/2013 01:29 AM, John Dillon wrote: On Mon, Aug 5, 2013 at 3:30 AM, Peter Vessenes pe...@coinlab.com wrote: I studied with Jeffrey Hoffstein at Brown, one of the creators of NTRU. He told me recently NTRU, which is lattice based, is one of the few (only?) NIST-recommended QC-resistant algorithms. We talked over layering on NTRU to Bitcoin last year when I was out that way; I think such a thing could be done relatively easily from a crypto standpoint. Of course, there are many, many more questions beyond just the crypto. Is NTRU still an option? My understanding is that NTRUsign, the algorithm to produce signatures as opposed to encryption, was broken last year: http://www.di.ens.fr/~ducas/NTRUSign_Cryptanalysis/DucasNguyen_Learning.pdf Having said that my understanding is also that the break requires a few thousand signatures, so perhaps for Bitcoin it would still be acceptable given that we can, and should, never create more than one signature for any given key anyway. You would be betting that improving the attack from a few thousand signatures to one is not possible however. In any case, worst comes to worst there are always lamport signatures. If they are broken hash functions are broken and Bitcoin is fundementally broken anyway, though it would be nice to have alternatives that are similar is pubkey and signature size to ECC. -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
On 06/19/2013 08:19 AM, Melvin Carvalho wrote:
Generally in favour of hierarchical deterministic wallets.
Will this new style of address make it into the block chain? I'd be
less keen on that.
I'm finding BIP0032 quite hard to read right now, but perhaps that's
because I'm less familiar with the material than some. However,
there's little things like it never actually defines a deterministic
wallet in the Abstract. But, I'll keep trying to understand and see
if I can use the test vectors.
This has nothing to do with the blockchain. This is simply an alternate
way to encode an address, in the event that you want to prove that this
address is linked to another address. The same thing ends up in the
blockchain, either way.
Either:
(1) I give you a Hash160 address which shows up in the blockchain
or
(2) I give you {PubKey, Mult}, then you compute PubKey*Mult then hash it
to get the same Hash160 I would've given you in (1)
I can always give you version #1, and that's what everyone does right
now. Version #2 is essentially the same, but used if you want to give
the other party extra information (such as the root public key, so that
the next time you send a version#2 address they can see they are from
the same root public key).
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
On 06/19/2013 10:25 AM, Timo Hanke wrote:
Since you mention to use this in conjunction with the payment protocol,
note the following subtlety. Suppose the payer has to paid this address
called destination:
Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||
checksum)
Also suppose the payee has spent the output, i.e. the pubkey
corresponding to destination, which is PubKeyParent * Multiplier[i],
is publicly known. Then anybody can (in retrospect) create arbitrary
many pairs {PublicKeyParent, Multiplier} (in particular different
PublicKeyParent) that lead to the same destination.
Depending on what you have in mind that the transaction should prove
regarding its actual receiver or regarding the receiver's PubKeyParent,
this could be an unwanted feature (or it could be just fine). If it is
unwanted then I suggest replacing
PubKeyParent * Multiplier[i] by
PubKeyParent * HMAC(Multiplier[i],PubKeyParent)
which eliminates from the destination all ambiguity about PubKeyParent.
This modification would not be directly compatible with BIP32 anymore
(unfortunately), but seems to be better suited for use in conjunction
with a payment protocol.
Timo
It's an interesting observation, but it looks like the most-obvious
attack vector is discrete log problem: spoofing a relationship between
a target public key and one that you control. For instance, if you see
{PubA, Mult} produces PubB and you have PubC already in your control
that you want to prove [maliciously] is related to PubB, then you have
to find the multiplier, M that solves: M*PubC = PubB. That's a
discrete logarithm problem.
I'm not as familiar as you are, with the available operations on
elliptic curves, but it sounds like you can produce essentially-random
pairs of {PubX, Mult} pairs that give the same PubB, but you won't have
the private key associated with those public keys. It's an interesting
point, and there may be a reason to be concerned about it. Though, I
don't see it yet.
-Alan
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
On 06/19/2013 02:36 PM, Adam Back wrote:
This maybe simpler and trivially compatible with existing type2 public
keys
(ones that are multiples of a parent public key): send an ECDSA
signature of
the multiplier, and as we know you can compute (recover) the parent
public
key from an the ECDSA signature made using it.
Adam
On Wed, Jun 19, 2013 at 05:28:15PM +0200, Adam Back wrote:
[q-th root with unknown no discrete log artefact]
If it was a concern I guess you could require a proof of knowledge of
discrete log. ie as well as public key parent, multiplier the
address must
include ECDSA sig or Schnorr proof of knowledge (which both demonstrate
knowledge of the discrete log of Q to base G.)
It's a cool trick but requiring a signature on each multiplier defeats
one of the purposes of a deterministic wallet. I don't want to have to
explicitly export a whole bunch of signatures from my offline system
just to exercise this address option. The observer wallet should be
able to do anything it needs to on its own, without help from the
offline wallet.
Unless you mean that there is a one-time signature from the offline
computer that works for all addresses, that can be exported with the
observer wallet...? If all you want to do is prove that /someone/ owns
that private key, you could send {Sign(MagicString), Multiplier}. So
it becomes one signature operation *per wallet*, but creating new
wallets would require going back to the offline computer for that
one-time signature. That's better than the alternative, but it's still
extra bloat for the wallet apps.
Either way, I'm not convinced that these are a problem for the specified
use cases I outlined. In cases where you have a persistent business
relationship, they need to verify the parent public key exchange
anyway. After that, the software doesn't technically require the
transmission of the PubKey, it only needs the Name/ID of the party and
the multiplier and it will fetch the PubKey from its data store. Or it
is transmitted and the payer verifies it's correct. Computing an
alternate {PubKey', Mult'} that produces the same address and then using
it in a MitM attack doesn't work here if the two parties pre-verified
the public keys.
In the case that a business is checking whether the cashout address of a
customer is the same as the last time: if the first payout was not
replaced by an attacker, then the business already has the correct
public key in their DB and a replacement of further payout requests will
fail validation. If the first payout was replaced... well that could've
been done anyway (with or without this alternate form), and the customer
wouldn't have received their money and the whole process would be
flagged and terminated before further transactions.
-Alan
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
On 06/19/2013 03:29 PM, Jeremy Spilman wrote:
If you have two parties who want to form a persistent relationship, by
exchanging and verifying public keys beforehand, then I think the
canonical way to do this with BIP32 is for the parties to exchange
PubKey and *ChainCode*.
I don't understand the use case for handing out individual
multipliers, if what you desire is a persistent relationship. If each
party dedicates a child-wallet for receiving coins, and saves a
PubKey/ChainCode for sending coins, the two parties can transaction
securely forever without ever exchanging any more information, and
without any address reuse.
I think ideally, the default behavior is that wallets always dedicate
a new child node {PubKey, ChainCode} to each party they transact with.
At the presentation layer, you have a contact and each contact has a
transaction history. You can send coins to a contact at any time, and
internally the wallet picks the next address in their sequence. Any
funds received on pubkeys from contact's sequence are attributed to
that contact. The wallet can organize the contacts, and roll-up the
transaction history into 'ledgers' and 'balances' however they want --
it could be based on the underlying BIP32 hierarchy or perhaps not.
The cost of watching large a number of pubkeys, even if you 'look
ahead' 100 pubkeys for each contact, is relatively small versus the
benefits.
What you just described is complimentary to what I am proposing. There
is nothing stopping you from doing it that way, except that it may be
inconvenient in some circumstances. BIP 32 does not prescribe a way to
use multiple chains like you described with the convenient type-2
derivation (though we could create a variant that does). And all
separate chains with their 100-address look-aheads may be fine for your
desktop or mobile device, but maybe not a HW signing device with 128 kB
of memory.
So, some use cases might prefer having a different parent public key
[and chaincode] per contact, some may prefer to synchronize across many
contacts. For instance, maybe there's a benefit to using the same
parent pubkey across multiple services, as a form of identity. If I
don't want that, I use your method. If I do want that, I use my
method. Given its simplicity, I don't know why both can't be options.
Actually, it doesn't have to be specific to the payment protocol, it can
just be alternative address encoding that some apps would use if they
have a need for it.
-Alan
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
On 06/19/2013 05:58 PM, Jeremy Spilman wrote: Hi Alan, “BIP 32 does not prescribe a way to use multiple chains like you described with the convenient type-2 derivation (though we could create a variant that does)” What do you think is missing from BIP32 for this? A wallet creates a child-node using the public / type-2 CDF, hands out the PubKey/ChainCode, and then generally expects transactions to come in starting at /0 and incrementing monotonically. You are suggesting that creating new wallet chains are the only operation needed to achieve the functionality I'm requesting. I disagree. I am okay with using different wallets for different parties */if the user wants to/*. But there are orthogonal use-cases to having a single wallet serve as a single identity that can be used across multiple transactions or services. And doing so is much simpler conceptually for the user, and simpler in implementation for the app developer. BIP 32 already specifies how to use the first three tree levels: M/i/j/k, i~wallet, j~Internal/External, k~address. The first level is actually type-1 derived, and thus we cannot create an arbitrary number of them without pre-computing them from the offline wallet. So it's not free to create new wallets unless we redefine how the levels work. Even if we assume the simplest case where the first level is actually type-2 derived and it costs nothing to create separate wallets for each contact/party: -- Do these extra wallet chains behave as different wallets, or sub-wallets? -- Should their balances be bundled into a single wallet or displayed separately? -- When a user tries to spend, does he have to specify which wallet(s) he's spending from? -- Should the app developer be required to implement a multiple-wallet interface, and handle cross-wallet spending just to achieve this simple mechanism? Sure, they could instead implement a tiered wallet hierarchy with primary wallets and sub-wallets... wait this just got complicated. All that complexity just to support this identity mechanism that can be included purely as an alternative address encoding with a single wallet. With my request, the user can't have one wallet and distribute most of his addresses the normal/anonymous way, but certain apps would choose to use the alternate encoding as a form of identity. If the user feels the need to create a separate wallet for certain operations to separate his identities, that is his option if the software supports multiple wallets. But it's not the only way. To achieve what I'm suggesting is useful and trivial to implement even in the simplest wallet applications. -Alan -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
_*Goal*_: An alternative address format made possible by BIP 32, which
allows one to specify a Wallet ID and One-time payment code, instead
of the standard one-use Base58-Hash160 addresses. This allows parties
with a persistent relationship to be able to prove that payment
addresses they provide each other are linked to a particular wallet,
reducing exposure to MitM attacks without the need for SSL or a web of
trust, and without compromising the privacy of either party.For
instance, this could be used between businesses that frequently do
business, by exchanging and verifying public keys beforehand, or could
be used by an exchange to identify if a customer withdrawal address is
related to their last deposit address, and if not enforce extra
authentication measures.
_*Background*__:_
I haven't been following the payment protocol discussions/development
much, so I apologize if this has already been addressed. I'm calling
it wallet-linkable addresses, which would be an optional second form
for sending someone your address. With BIP 32, the address is computed
by the payee (the person sending the address to receive money):
Standard Address ~ Base58(0x00 || hash160(PubKeyParent *
Multiplier[i]) || checksum)
What I'd like to do is have the option, when specifying an address
through the payment protocol, to send *just* the {PublicKeyParent,
Multiplier[i]} and let the receiver of that address compute the address
on their own. This is no significant burden on the receiver, but it
does provide the useful property that they can recognize when addresses
specified in this way come from the same wallet -- because the
PubKeyParent will be the same. Remember, this is _optional_ for the
person providing the address.
One nice, accidental feature of BIP 32 is that the Multiplier[i] used
above does not actually reveal the chaincode (I think Pieter started
calling it the tweak). It is derived from the chaincode but doesn't
reveal it. Therefore, the payer sees the parent public key, but that's
not useful to derive any of the other addresses unless they also have
the chaincode. But they can verify that the PublicKeyParent is
identical between transactions, and thus is accessible only to that
wallet. It allows them validate a specific address provided by the
payee, but not generate or identify any other addresses.
*_Use Cases:_*
(1) So, just like with PGP/GPG, when two parties decide they will start
a relationship, they can start by exchanging the public keys of their
wallet and verify them in a reliable manner. After that, when one party
requests a payment address from the other, they can optionally send
{PubKey, Multiplier}, and the payer's software will identify the owner
of that address, or let you select who you think the address belongs to
and it will verify it. If the payee's system is compromised and address
is replaced, the address received by the payer won't validate. This
doesn't help if the side sending the money is compromised.
(2) When a customer first provides a deposit to an exchange, it will
send money from an address in their wallet and the software will provide
the exchange the {PubKey,Mult}. When the customer later provides a
withdrawal address, the site can automatically trust the address as long
it is provided in the alternate form and the public keys match. If they
don't, it might be the same customer just requesting a withdrawal to a
different wallet, which is fine, but they'll have to go through an extra
verification step to do so.
_*Downsides:*_
Multi-sig/P2SH - The only way this works with P2SH, violates one of the
goals of P2SH slightly, but may not matter much if it's all done under
the hood by the software. Instead of providing a 20-byte hash of a
script, you provide all the public keys and multipliers for the
individual addresses. The payer's software automatically verifies all
addresses and creates the P2SH script itself (after a divine decree that
public keys will always be sorted lexicographically in the multi-sig
script). The blockchain still benefits from the compression of moving
the bulky scripts to the TxIn, but it does require revealing more
information than is necessary for the payer to pay the payee. But it
may not /really/ be a problem, given the benefits. It might just be
slightly longer strings to exchange during initialization and for each
transaction.
I have various reasons I'd like to use this, and it'd be nice to have
some community backing, so I don't have to twist anyone's arm to trust
me that it's legit.
-Alan
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting
One major problem I see with this, no matter how well-thought-out it is, it's unlikely that those with money will participate. Those with the most stake, likely have their private keys behind super-secure accessibility barriers, and are not likely to go through the effort just to sign votes. Not only that, but it would require them to reveal their public key, which while isn't technically so terrible, large amounts of money intended to be kept in storage for 10+ years will prefer to avoid any exposure at all, in the oft-chance that QCs come around a lot earlier than we expected. Sure, the actual risk should be pretty much non-existent, but some of the most paranoid folks are probably the same ones who have a lot of funds and want 100.00% of the security that is possible. They will see this as wildly inconvenient. I think this a great thought experiment, and I'd like to see where this idea goes, in terms of designing ways for a decentralized community to find consensus for important decisions, but I don't think that any idea that requires users to dig up their private keys is going to be feasible (or possibly reconstruct them from pieces and/or get multiple signatures). Especially if the system requires some kind of persistent voting. -Alan On 06/10/2013 12:46 PM, Mark Friedenbach wrote: John, What you are recommending is a drastic change that the conservative bitcoin developers probably wouldn't get behind (but let's see). However proof-of-stake voting on protocol soft-forks has vast implications even beyond the block size limit. Within Freicoin, we have looked at is as a possibility for determining how to distribute the demurrage, a proposal we are calling 'Republicoin' due to the fact that with proxy voting we expect a system to emerge similar to the government budgeting in parliamentary republics. Distributed, non-coersive government by protocol, if you will. So anyway, even if you get shot down, please continue to pursue this proposal. It very likely has uses that you haven't thought of yet. Cheers, Mark On 6/9/13 9:09 PM, John Dillon wrote: It has been suggested that we leave the decision of what the blocksize to be entirely up to miners. However this leaves a parameter that affects every Bitcoin participant in the control of a small minority. Of course we can not force miners to increase the blocksize if they choose to decrease it, because the contents of the blocks they make are their decision and their decision only. However proposals to leave the maximum size unlimited to allow miners to force us to accept arbitrarily large blocks even if the will of the majority of Bitcoin participants is that they wish to remain able to validate the blockchain. What we need is a way to balance this asymetrical power relationship. Proof-of-stake voting gives us a way of achieving that balance. Essentially for a miner to prove that the majority will of the poeple is to accept a larger blocksize they must prove that the majority has in fact voted for that increase. The upper limit on the blocksize is then determined by the median of all votes, where each txout in the UTXO set is one vote, weighted by txout value. A txout without a corresponding vote is considered to be a vote for the status quo. To allow the voting process to continue even if coins are lost votes, including default votes, are weighted inversely according to their age in years after 1 year. IE a vote with weight 1BTC that is 1.5 years old will be recorded the same as a 1 year old vote weighted as 0.67BTC, and a 1 day old and 6 months old UTXO are treated equivalently. The 1 year minimum is simply to make voting required no more than once per year. (of course, a real implementation should do all of these figures by block height, IE after 52,560 blocks instead of after 1 year) A vote will consist of a txout with a scriptPubKey of the following form: OP_RETURN magic vote_id txid vout vote scriptSig Where scriptSig is a valid signature for a transaction with nLockTime 500,000,000-1 spending txid:vout to scriptPubKey: OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL vote_id is the ID of the specific vote being made, and magic is included to allow UTXO proof implementations a as yet unspecified way of identifying votes and including the weighted median as part of the UTXO tree sums. (it also allows SPV clients to verify the vote if the UTXO set is a Patricia tree of scriptPubKeys) vote is just the numerical vote itself. The vote must compute the median, rather than the mean, so as to not allow someone to skew the vote by simply setting their value extremely high. Someone who still remembers their statistics classes should chime in on the right way to compute a median in a merkle-sum-tree. The slightly unusual construction of votes makes implementation by wallet software as simple as
Re: [Bitcoin-development] Revocability with known trusted escrow services?
The two most basic ways would be simply: (1) You create your transactions having a locktime of X days and has sequence numbers such that it can be replaced exactly once. The replacement, can be executed within 30 days. (2) You simply send money to 1-of-2 transactions: me-or-you. If the person who is receiving it wants it, they have to sign for it by sending it to one of their own single-sig addresses. Otherwise, you can return it to yourself at some point in the future. I don't totally understand the goal, and how/if these solutions actually achieve such goal. But it does add a way for transactions to exist a non-final state for some amount of time. But in both cases, accessibility is still binary: you have complete access to it, until you don't. Which might be seen as the point of irrevocable transfer. -Alan On 06/05/2013 08:19 PM, Peter Vessenes wrote: So, this http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1 article got posted today, noting that FinCEN thinks irrevocable payments are money laundering tools. I will hold my thoughts about the net social good of rent-seeking large corporations taking money from consumers over fraudulent reversals. Actually, I won't, I just said it. At any rate, it got me thinking, can we layer on revocability somehow without any protocol change, as an opt-in? My initial scheme is a trusted (hah) escrow service that issues time promises for signing. If it doesn't receive a cancel message, it will sign at the end of the time. The addresses would be listed by the escrow service, or in an open registry, so you could see if you were going to have a delay period when you saw a transaction go out. This seems sort of poor to me, it imagines that mythical thing, a trusted escrow service, and is vulnerable to griefing, but I thought I'd see if some of the brighter minds than me can come up with a layer-on approach here. When I think about it, I can imagine that I would put a good number of my coins in a one day reversible system, because I would have warning if someone wanted to try and spend them, and could do something about it. I'm not sure if it gets me anything over a standard escrow arrangement, though. Peter -- CoinLab LogoPETER VESSENES CEO *pe...@coinlab.com mailto:pe...@coinlab.com * / 206.486.6856 / SKYPE: vessenes 71 COLUMBIA ST / SUITE 300 / SEATTLE, WA 98104 -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 2BTC reward for making probabalistic double-spending via conflicting transactions easy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You can do this right now, with Armory. If you switch Armory to Expert usermode, you can combine coin-control with unsigned transactions to do exactly this. It's because Armory doesn't lock coins used in previous unsigned transactions, until they're actually broadcast and confirmed to be out in the wild. This was done for simplicity to avoid people getting arbitrarily-locked coins, even though it means you end up accidentally double-spending if you try to create two different unsigned transactions from the same wallet without signbroadcasting the first one. So here's what you do: (1) Switch to Expert usermode in Armory (2) Open any wallet (you don't need a watch-only wallet, full wallet is fine) (3) In the Send Bitcoins window, click coin-control (4) Create a transaction using one sufficiently large input (5) Click Create Unsigned Transaction and save it (6) Repeat 3-5 with the same coin, but sending to yourself, specify a larger fee (7) Go into Offline Transactions and Sign and Broadcast Transactions (8) Load tx1, sign broadcast (9) Load tx2, sign broadcast This only works if your Bitcoin-Qt/bitcoind client has the replace-by-fee patch, since Armory uses Bitcoin-Qt/bitcoind as a gateway to the network. Otherwise, the second tx will be DOA. But you don't have to mess with Armory other than switching it to Expert mode to get to the coin-control feature. - -Alan P.S. -- If you try this, Armory is likely to not show the second tx as having ever happened (Bitcoin-Qt will send it back to us and we ignore it because we already have a tx). But if your Bitcoin node has the modification, it /will/ reach the network On 05/15/2013 08:19 AM, Peter Todd wrote: On Wed, May 15, 2013 at 07:38:27AM -0400, Peter Todd wrote: So I'm offering 2BTC for anyone who comes up with a nice and easy to use command line tool that lets you automagically create one version of the transaction sending the coins to the desired recipient, and another version sending all the coins back to you, both with the same transaction inputs. In addition to creating the two versions, you need to find a way to broadcast them both simultaneously to different nodes on the network. One clever approach might be to use blockchain.info's raw transaction POST API, and your local Bitcoin node. Oh, and while we're at it, a good starting point for your work would be Gavin's spendfrom utility in the contrib/spendfrom directory in the Bitcoin-QT respository. Also please do keep in mind that it's much better for the community if an attack is demonstrated first, followed by releasing the code some time later. -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRk441AAoJEBHe6b77WWmFZNQP/02t6cQkhih/CcA1oSCM72np KMRW0Z+piHShORxLyhMX3cIpi3ICJ2lJ/Pm6GfDn74oSHq8wipIFoV88xhy810bL MnJtbPH900v8PHh/ji2nWMig9NibeUa1zV9/tp31rYjUT3mmMoC4yQlyxKII8GWK iignkAHV/UL5kQGmhmr1RKN127cthSMeIzAYWXfIWVObPNm85pvizVZdgqzSK73h vwdfeFOelNbVn8ZCNT19OsxWfAKZSaBMywAX95wQBs0BtY2ZgDRmeXa6MdQKpXGW KP3O2zjjJC2CKc4+L6elMfsoL1doEsk35w/GuI4HZK4MLAI8BChi6ZPnAYjdRvir eHeszyxkKDCEaJ9JPLA/AszqkYHIB+56wTtrpVb1duyTwuqgVT5dcpMPIH8bDqjq k3I8C9zCSeQ6JgyvOd8grKJchRtq0SOWYt2bB3ytePzwOs+W+6mRenb/WtMt2dQg ntDTEIG7pCsWHenipeTBzvJNqeSsAAoIXnkGY20iDxCB+uFkTzisoCQqpOIglArm vD+Cl2nv3OKU3NTVTUt2VinoFskezI7xvsxHD8xs2V/hrlpPbPRAo+l7ER6aTazj wrONfmllHSE2XCM7wb/bX3gBNmsM3zUIgSBmNSH/SQeTy8PvwvlkZ/RRYmtVSmHL rUTp7x4U63JiIDO1jj+T =JiPo -END PGP SIGNATURE- -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cold Signing Payment Requests
There's some good discussion about that here:
https://bitcointalk.org/index.php?topic=130749.msg1398972#msg1398972
thanke came up with this first, and then I reinvented it, and now you
have. But the thread has some good discussion about how to move
forward. I'm a big fan of putting the lower-case root hash160 in your
subdomain and getting and SSL cert for that. Feel free to contribute to
that thread if you find it compelling.
-Alan
On 04/24/2013 07:01 PM, Jeremy Spilman wrote:
Payment Protocol uses x509 certs to sign a Payment Request. This allows
wallets to display meta-data from the cert to the payer instead of the
address, which should make it easier to verify where money is being sent, and
make it harder for an attacker to change the address displayed to a user so
that coins are not sent to the wrong place.
The difficulty is that Payment Requests must be generated live, and therefore
the key used to sign those requests must also be live, exposing the key to
theft similar to a hot wallet. Steal the key, forge payment requests, and the
payer sees a 'green box' but the coins go to the attacker. The question... is
there a way to sign something once, with a key kept offline, which verifies
the address in the Payment Request belongs to the payee?
1) Given a 'parent' cert which is kept offline, and a child certificate of
'parent' which is kept hot on the payment server.
2) Given a public key and chain code { pubKey, code } under BIP32 we generate
child keys as I = HMAC(code, Kpar || i), Ki = I[0:32] * Kpar.
3) If we sign Kpar with the parent cert's key offline, we can sign the
remaining less critical data (address, I[0:32], amount, description, etc.)
with the child cert's key.
4) The payer verifies Kpar, and verifies the address by calculating
Hash160(Kpar * I[0:32])
In fact, there's no requirement to use BIP32 to calculate I[0:32], it could
also just be randomly generated.
Any I[0:32] included in the Payment Request, even if it is tampered with,
will correspond to an address for which the payee can calculate the
corresponding private key.
So the idea is your 'most trusted' cert would be used offline only to sign a
Kpar once, and a 'less trusted' cert would be used to sign the other stuff,
like 'amount', 'description', 'merchant-data', and the 'I[0:32]' as well.
I'm not an expert on x509, but I imagine the trouble is, how does the payer
know which cert is which? I was originally thinking the parent cert would be
an intermediate CA cert used to sign the child cert, but I guess good look
getting one of those, even with a name constraint, from a Root CA. I'm not
sure if you can do better than just a 'convention' such as one is an EV cert
and one is not. Perhaps the less trusted cert is actually self-signed using
the EV cert, but that requires special validation, since its no longer a
standard certificate chain. I would love to hear a better idea.
Any comments if this is something worth pursuing? I think there are
definitely benefits if merchants can keep the key signing the address offline.
Thanks,
--Jeremy
--
Try New Relic Now We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Try New Relic Now We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Anti DoS for tx replacement
One of the big topics of recent past on IRC is malleability of
transactions: to what extent can someone /else /change your signed
transaction without affecting its validity? In the past I used to
consider this just annoying, but not so malicious. But in terms of HFT,
it sounds like malicious behavior is possible:
To recap the procedure:
(1) Alice creates a transaction, Tx1, for 10 BTC to a 2-of-2-{Alice,
Bob} address. It has a locktime of 30 days in the future.
(2) Before signing the transaction, she gets Bob to sign a transaction,
Tx2, from 2-of-2-{Alice, Bob} back to herself. That transaction
references the Tx1 by hash.
(3) Any time in the next 30 days, Alice can sign an alternate Tx2
transactions reducing the amount returned to self and increasing amount
to Bob, as a method of paying Bob more. Bob doesn't need to broadcast
anything except for the last one, 29 days later.
It was originally conceived that Bob couldn't do anything malicious,
because Alice gets Bob to sign Tx2-spending-Tx1 before she gives him
Tx1. The problem is that Bob can follow her process, then
broadcast/mine Tx1' (Tx1-prime), which has a different number of 0x00
pad bytes in the signatures, or flips the sign of one of the s-values
in the signature, thus changing the hash of Tx1.
By doing this, Bob has now created a transaction, Tx1', that Tx2 no
longer returns to Alice. It's not flat-out theft, because Tx1 still
sends to a 2-of-2 address requiring both of their signatures. But Bob
didn't risk anything to do this, besides his reputation/trust. He now
has Alice's money locked and can hold it for ransom, since she needs his
signature to do move it. He could offer his signature for half of it.
Of course, these types of HFT contracts will usually be between parties
that have some mutual respect/history. Thus, they are not usually
zero-trust. But we should find a way to try to close that, if
possible. For instance, if the malleability was reduced to one bit, you
could just have Bob sign two different transactions before Alice
broadcasts Tx1. The two tx would be from either variant. But I know
there's too many bits of malleability in the transaction serialization
for that to work. Is there any way to avoid this?
-Alan
On 04/17/2013 05:48 AM, Mike Hearn wrote:
When this system was first being discussed, Gavin was concerned that
miner incentives were to ignore replacements because it meant extra
work and the replacement might have equal or lower fees than before
(or indeed, no fees). He proposed two solutions: one is to
progressively raise the fee on each replacement. The other is to
specify lock time in terms of blocks and then step it backwards once
for each replacement, thus ensuring that by replacing the transaction
you get to claim any attached fee earlier.
It should be apparent that both solutions can be implemented by
whichever application is running the contract - the core Bitcoin
network and software is agnostic either way.
Now, Gavin and I disagreed on whether this would actually be
necessary. As I already pointed out, both solutions seriously reduce
the utility of HFT because they limit how often you can update the
contract. Instead of an online game billing you per second, maybe it
can only do it per minute or per 10 minutes with the lock time
solution because otherwise you run out of blocks, and with
ever-increasing fees perhaps the contract becomes too expensive to
justify after a while.
So it'd be nice if this ended up not being necessary. Experience
indicates that rational miners typically don't pursue a short-termist
profit-at-any-cost agenda - free transactions have always been
included in blocks, miners include transactions even though you could
avoid a lot of complexity by just not including any at all, etc. Some
miners like BTC Guild have actually sacrificed significant amounts of
money for the good of the system. You can see this in terms of
rational self interest - miners earn Bitcoins thus it's in their
interest for Bitcoins to be as useful as possible, as that is what
gives them value. Or you can see it in terms of ideologically-driven
altruism. Or both.
If I were to implement an application that used tx replacement, I
would probably start with replacements that don't change the fees and
don't count down the lock time field. We can then observe whether
miners bother changing their software to behave differently, or
whether the inherent utility of the application is enough to convince
them to play by the default rules. Ideally at least one application
made possible by this feature is a killer app - something so useful
/ unique / compelling that people want to obtain Bitcoin just to use
it. If someone can find such an app, then rational miners should want
tx replacement to work as reliably as possible because it boosts the
value of their earnings.
There are some other misc details - reactivation requires that we bump
the protocol version and
Re: [Bitcoin-development] RFC: extend signmessage/verifymessage to P2SH multisig
If we're going to extend/expand message signing, can we please add a
proper ASCII-armored format for it? Really, anything that encodes the
signed message next to the signature, so that there's no ambiguities
about what was signed. You can keep the bare signatures as an option
for backwards compatiblity, but offer this as the primary one.
What we really want is to have the user copy an ASCII-armored block of
text into the client (or we could have a URI-extension for this), and
the app pops up with a window that says The following message has a
valid signature from address 1XKjf32kJbf...: message.
I know people argue they'd like to get away from raw addresses and
copy-and-paste. But it'll be a while before that happens, and there's a
lot of demand for Armory to become compatible with Bitcoin-Qt signing.
People are obviously using it.
-Alan
On 04/14/2013 01:09 AM, Peter Todd wrote:
Currently signmessage/verifymessage only supports messages signed by a
single key. We should extend that to messages signed by n-of-m keys, or
from the users point of view, P2SH multisig addresses.
rpc.cpp:signmessage() returns the output of SignCompact(). That in turn
starts with a header byte marking the signs of the various keys to allow
for key recovery. The header byte can be one of 0x1B, 0x1C, 0x1D or 0x1E
For multisig signmessage signatures this is extended:
01 varint n varint m sig or key {sig or key, ...}
Each signature or key can be one of the following forms:
sig: 1B/1C/1D/1E 32 byte r 32 byte s
compress key: 02/03 32 byte x
uncompressed key: 04 32 byte x 32 byte y
Note that we have to provide all pubkeys, even if they aren't used for a
given signature, to allow the P2SH address to be reconstructed.
Decoding/encoding is a bit code-intensive due to the all the cases, but
on the other hand this format keeps the size down to an absolute
minimum. Alternatively I could use length bytes.
The format is backwards compatible in the sense that older versions will
fail safely on new signatures, even ones that have been truncated.
Similarly new signatures are easily distinguished from old, and going
forward if we for some reason need yet another signature format the
leading byte can be incremented.
Signing incomplete signatures on messages can be handled by converting
pubkeys to signatures. Similarly the RPC signmessage command can be
extended with an optional existing signature option.
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] New webpage: Offline Backups
I noticed the new webpage is up on bitcoin.org. I still have mixed feelings about it, but I noticed there is a You need to know! section that suggests offline backups. As long as you are featuring Armory and Electrum on the wallets page, you should be including them in that blurb as options for offline storage. It's kind of silly to say /You must do this! But we have no recommendations for how. At all. Good luck/! At least have a dedicated page or (not-ideally, forum post) describing the various options and leads for them to follow for actually doing it. -Alan -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 plan
On 03/16/2013 09:13 PM, Gavin Andresen wrote: I chose May 15 arbitrarily; two months seems like a reasonable 'quick' amount of time to give people to upgrade/workaround. Maybe you should wait until after the Bitcoin Conference -- if something goes wacky on May 15th but then everyone is getting on a plane to go to San Jose two days later, it may create unnecessary stress. It's probably not a big deal, but if the date is arbitrary anyway, why not just push back one more week? -Alan -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Some PR preparation
I'm sure it won't be long before Slashdot and a variety of sources start reporting on this event. Bitcoin has been in the media a lot lately, so this story is likely to get some attention. The blowback of this event is mostly psychological, so I think it would be exceptionally wise to start preparing PR comments that can be posted on articles immediately after they go public. This event is likely draw much more negative attention than it deserves, and getting some positiveinformed comments posted up front will potentially make a difference in the way the story is received. Undoubtedly, many articles (and especially commenters) will shape this into the end of Bitcoin. I would describe it as there was a short and mostly-harmless lapse in the ability of the network to reach a consensus, causing transactions to get delayed by a few hours. It *really* needs to be emphasized that coins are safe, and nothing anyone has/could do will change that. And that it would've been extremely difficult to exploit for gain. Transactions got delayed while a bug was fixed. End of story. Hell, someone here should submit their own slashdot article about it! 100% chance this hits slashdot -- it might as well be written by someone who understands it. Similarly, we could be sending sources information to pre-empt misinformation being spread about it. Unfortunately, I have to go to bed, so I can't really do much. I just wanted folks to be on the lookout and be ready to respond to the crazy stuff that's going to hit the media in the next 12 hours. -Alan -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Some PR preparation
On Tue, Mar 12, 2013 at 8:10 AM, Luke-Jr l...@dashjr.org wrote: I think we should be careful not to downplay the reality either. For a number of hours, transactions could have received up to N confirmations and then still been reversed. While we could contact the bigger payment processors, I saw people still trying to buy/sell on OTC, whom could have been scammed even by taking standard precautions. I don't want to misrepresent what happened, but how much of that was really a risk? The block was rejected, but the transactions were not. Any valid transactions to hit the network would get added to everyone's memory pool and mined in both chains. Thus all nodes would still reject double-spend attempts. As far as I understood it, you would've had to have majority mining power on one of the chains (and both had non-negligible computing power on them), so double-spending still required an exceptional amount of resources -- just not the normal 50% that is normally needed. Perhaps... 10%? But how many people can even have 10%? In addition to that, a victim needs to be found that hasn't seen the alert, is willing to execute a large transaction, and is on the wrong side of the chain. Is this incorrect? Yes, there was less resources needed to execute an attack -- but it still required a very powerful attacker, way outside the scope of regular users. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Thu, Dec 6, 2012 at 11:56 AM, Gavin Andresen gavinandre...@gmail.comwrote: When I say pass around I'm not thinking of users copying and pasting, that would be a terrible user experience; all of that communication needs to happen automatically behind the scenes. Lets tackle that after we've got the simpler customer-pays-merchant flow working nicely (funded-escrow-pays-merchant is a subset of that, anyway). I think that the pass around method needs to happen in addition to the methods of transparent protocols that occur behind the scenes. For one, there's a lot of CONOPs that need to be worked out by getting knowledgeable people using it, and providing feedback about how it could/should/will be used and how it could be improved. The pass-around method is simpler to implement and still usable by the types of users that will be using it in the beginning -- experts. Also, I see that for very large, important multi-sig tx/contracts/escrow, the manual method might be preferred -- much the same way many people prefer manual-transmission cars even though automatics are easier -- some people/organizations will want the control. I'm all for protocols that enable higher-level access to this functionality, I'm just saying there should be lower-level access, too. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
Our divergence is on two points (personal opinions): (1) I don't think there is any real risk to the centralization of the network by promoting a SPV (purely-consuming) node to brand-new users. In my opinion (but I'm not as familiar with the networking as you), as long as all full nodes are full-validation, the bottleneck will be computation and bandwidth, long before a constant 10k nodes would be insufficient to support propagating data through the network. In fact, I was under the impression that connectedness was the real metric of concern (and resilience of that connectedness to large percentage of users disappearing suddenly). If that's true, above a certain number of nodes, the connectedness isn't really going to get any better (I know it's not really that simple, but I feel like it is up to 10x the current network size). (2) I think the current experience *is* really poor. You seem to suggest that the question for these new users is whether they will use full-node-or-lite-node, but I believe it will be a decision between lite-node-or-nothing-at-all (losing interest altogether). Waiting a day for the full node to synchronize, and then run into issues like blkindex.dat corruption when their system crashes for some unrelated reason and they have to resync for another day... they'll be gone in a heartbeat. Users need to experience, as quickly and easily as possible, that they can move money across the world, without signing up for anything or paying any fees. After they understand the value of the system and want to use it, they are much more likely to become educated and willing to support the network with full node. -Alan On 12/04/2012 07:27 PM, Gregory Maxwell wrote: On Tue, Dec 4, 2012 at 5:44 PM, Alan Reiner etothe...@gmail.com wrote: Greg's point looks like it's veering towards we don't want to grow the network unless we're going to get more full nodes out of it. No… There is no fundamental completion between taking what actions we can to maximize the decentralization of the network and making the software maximally friendly and painless to get started with and use. It's possible— not even deep rocket science— to create software that accommodates both. And because of this, I don't think it's acceptable to promote solutions which may endanger the decentralization that makes the system worthwhile in the first place. If the current experience is so poor that you'd even consider talking about promoting directions which reduce its robustness then thats evidence that it would be worth finding more resources to make the experience better without doing anything the that reduces the model, even if you've got an argument that maybe we can get away with it. If there isn't interest in putting in more resources to make these improvements then maybe the issue isn't as bad as we think it is? I think it is very much in everyone's interest here to encourage new users to start using Bitcoin, even if they don't support it. Absolutely— and yet that has nothing to do with promoting software to users which only consumes without directly contributing and which doesn't even have the capability to do so even if the user wants to (or much less, is indifferent). -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
On 12/03/2012 10:02 AM, Gregory Maxwell wrote: (1) Make client software aggressive about sweeping up dust inputs: Any time a transaction is created that has change keep adding in extra inputs— smallest to largest— until an additional one would increase the cost of the transaction by 0.0001 BTC or more — the only major complication is doing this without concurrently harming privacy which is why it's not done yet in the reference client. FYI, Armory uses exactly this logic to try to clean up dust outputs in the user's transactions. However, there's enough conditions on it, that I don't know how often it triggers. Recommendations are welcome for how to improve it. Right now, if the transaction has less than 5 inputs, there exists dust UTXOs from addresses already included in the transaction, and those UTXOs are sufficiently small in priority, then the Armory will add them to the input side and increase the change accordingly. Looking it just made me realize I lost the last condition of making sure the tx already has a change output -- don't want to turn a free tx into a fee-needed tx just to do this. (reorganized the code https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine.py#L5279 recently, and must have fell through the cracks). Perhaps it could be improved by cleaning up dust from *any* address by default (not just ones already included in the tx), with the option for the user to disable that behavior. After all, anonymity was never a core feature of the network -- I think it makes sense that the logic would reduce anonymity by default in exchange for a cleaner network, with a clear option to opt-out of that logic if user cares. I think most users don't actually care... -Alan -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
These are all valid points. I hadn't really thought much about this point until you all just brought it up. The reason I so quickly spout off that phrase, is that I endlessly get requests from Armory users to implement more anonymity-based features. When I say there are bigger priorities, they suggest that anonymity is a core benefit of Bitcoin and I should be supporting it. I'm not against anonymity, and I most certainly favor privacy, but my goal was to produce a versatile client, not one focused on any one aspect -- there are plenty of people who use it for other reasons than anonymity. However, I do like Greg's comment about attacks against a blind-dust-inclusion algorithm, and suggestion to maintain a clustering of already-linked addresses. That's not terribly difficult to do with the transaction history in hand, and it could increase how often the logic triggers. I suppose these hardcore SD players probably have a lot of one-satoshi outputs that could use vacuuming... On Mon, Dec 3, 2012 at 11:18 AM, Stephen Pair step...@bitpay.com wrote: On Mon, Dec 3, 2012 at 10:30 AM, Mike Hearn m...@plan99.net wrote: Second thing, it's best to carefully separate anonymity from privacy. Privacy is supposed to be a feature of the system (it says so in Satoshis paper) because people demand it. If I loan a tenner to my friend and he is able to find out what I earned last month, then that trade was neither anonymous nor private. In this case I want privacy but anonymity isn't useful. Mixing up anonymity with privacy is not only a public relations problem, but can lead to confusion from users when they, eg, try and buy Bitcoins from an exchange and are asked to provide ID proofs. I would like to second this point...privacy is essential because the market demands it. If Bitcoin doesn't do it well (and I would argue that it doesn't today), then eventually a competitor to Bitcoin will do it better and that would be the beginning of the end for Bitcoin. Debates about whether it was or wasn't a core feature are pointless. -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 35: add mempool message
On Thu, Aug 16, 2012 at 2:04 PM, Jeff Garzik jgar...@exmulti.com wrote: On Thu, Aug 16, 2012 at 1:56 PM, Pieter Wuille pieter.wui...@gmail.com wrote: I suppose it is interesting in general for nodes to get a memory pool refill at startup anyway. Yes. An inv message is always returned, even if empty. I'm not sure about this last. What is it good for? inv packets can always be sent, even not in response to others, so it is not that this gives you an acknowledgement the mempool is updated? A simple guarantee of 1:1 correspondence between request and response. The bitcoin protocol sometimes simply elides a response when the response would be empty, and this makes it difficult to know whether a request is timing out or already processed. Sending a ping(nonce) after each P2P command is another way of achieving same :) Is there a problem with sending unrecognized messages to nodes? If we create a new message type specifically asking for memory pool transactions, and we broadcast it to all nodes that we are connected to, and none of them respond, then either there are no tx in their memory pools, or they don't recognize the message and ignore it. Either way, you're not going to get any extra information out of them. If you really care, a simple ping can identify whether they're still connected and should've responded (as Jeff said). As long as the older node won't cut you off for sending one unrecognized request, it seems that you can get by fine without requiring that bit. I guess it depends on the utility of definitively identifying whether a node supports the functionality. I personally don't feel like it's critical, especially considering that this is most useful only during the transient period when it's not normal for nodes to support it yet. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Random order for clients page
I generally agree with Greg. I don't see anything he's said or done as anti-alt-client. As an alt-client developer, I'm happy to see my client on the main page, but I'm also happy if that clients page is simply an acknowledgement that there's more to the Bitcoin world than just the Bitcoin-Qt client, and a link of where to find more information (i.e. the wiki). I would still * prefer* to have the page the way it is, because I think alt clients should be more accessible and word will spread better where it is now -- but I also recognize the inherent difficulty of gaining any kind of consensus of how it should be organized, what goes on the list, etc, and no matter how you do it, someone will complain about it being unfair or not right. We either have to have a czar who is trusted to make responsible decisions, and complaints of being unfair or recommendations for improvements can go through that person, but ultimately it is that person who makes the call. Or we just move it to another page that is less strictly controlled and where these things matter less. Trying to gain consensus among an amalgamation of developers all with competing priorities and products is a terrible way to try to agree on stuff. -Alan On Mon, Jul 9, 2012 at 1:46 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki zgen...@yahoo.com wrote: JS randomisation is bad. People shouldn't need JS to view a webpage. JS randomization doesn't imply needing JS to view the page. It implies needing JS to see it in random order. You could also combine it with the server-side randomization if you care about non-js being non random, though I don't think it matters. As others have pointed out I don't generally think the randomization is good in principle, but if its done it should at least achieve its goals. Only you have a problem with this page. I don't see why Bitcoin-Qt needs to be first either when it dominates the front page. It is perfectly fine as it is. I'll let other people speak for themselves, but I did consult others before reverting your last batch of changes. More generally, we have pull requests in order to get some peer review of changes. Everyone should use them except for changes which are urgent or trivially safe. (Presumably everyone with access knows how to tell if their changes are likely to be risky or controversial) You are not a developer of any alternative clients, and this is a webpage for Bitcoin clients. I have made a change to remove a source of disputes, and make the process more fair and equal. Your suggestion to remove the clients page is your bias towards thinking that there should be only one Bitcoin client that everyone uses (the one which you contribute towards). I'm strongly supportive diversity in the Bitcoin network, and some alt client developers can speak to the positive prodding I've given them towards becoming more complete software. If I've said anything that suggests otherwise I'd love to be pointed to it in order to clarify my position. Unfortunately none of the primary alternatives are yet complete, the network would be non-function if it consisted entirely of multibit or electrum nodes (and as you've noted armory uses a local reference client as its 'server'). The distinction between multiple kinds of clients in terms of security and network health are subtle and can be difficult to explain even to technical users and so until something changes there the reference client needs to be the option we lead with. People should us it unless their use-case doesn't match. When it does they'll know it and they'll be looking. We don't need to make one of those recommendations a primary option. I like the proposals of moving this stuff to the Wiki as the wiki already contains tons of questionable (and sometimes contradictory) advice and so there is less expectation that placement there implies any vetting. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats.
Re: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite node
I hope that someone else here would chime in on the issue raised in the thread, about using a tree-structure that has multiple valid configurations for the same set of unspent-TxOuts. If you use any binary tree, you must replay the entire history of insertions and deletions in the correct order to get the tree structure and correct root. Along those lines, using something like a red-black tree, while theoretically well-known, could be subject to implementation errors. One implementation of a red-black tree may do the rebalancing differently, and still work for it's intended purpose in the majority of applications where it doesn't matter. One app developer updates their RB tree code which updated the RB-tree optimizations/rebalancing, and now a significant portion of the network can't agree on the correct root. Not only would that be disruptive, it would be a disaster to track down. If we were to use a raw trie structure, then we'd have all the above issues solved: a trie has the same configuration no matter how elements are inserted or deleted, and accesses to elements in the tree are constant time -- O(1). There is no such thing as an unbalanced trie. But overall space-efficiency is an issue. A PATRICIA tree/trie would be ideal, in my mind, as it also has a completely deterministic structure, and is an order-of-magnitude more space-efficient. Insert, delete and query times are still O(1). However, it is not a trivial implementation. I have occasionally looked for implementations, but not found any that were satisfactory. So, I don't have a good all-around solution, within my own stated constraints. But perhaps I'm being too demanding of this solution. -Alan On 06/19/2012 12:46 PM, Andrew Miller wrote: Peter Todd wrote: My solution was to simply state that vertexes that happened to cause the tree to be unbalanced would be discarded, and set the depth of inbalance such that this would be extremely unlikely to happen by accident. I'd rather see someone come up with something better though. Here is a simpler solution. (most of this message repeats the content of my reply to the forum) Suppose we were talking about a binary search tree, rather than a Merkle tree. It's important to balance a binary search tree, so that the worst-case maximum length from the root to a leaf is bounded by O(log N). AVL trees were the original algorithm to do this, Red-Black trees are also popular, and there are many similar methods. All involve storing some form of 'balancing metadata' at each node. In a RedBlack tree, this is a single bit (red or black). Every operation on these trees, including search, inserting, deleting, and rebalancing, requires a worst-case effort of O(log N). Any (acyclic) recursive data structure can be Merkle-ized, simply by adding a hash of the child node alongside each link/pointer. This way, you can verify the data for each node very naturally, as you traverse the structure. In fact, as long as a lite-client knows the O(1) root hash, the rest of the storage burden can be delegated to an untrusted helper server. Suppose a lite-client wants to insert and rebalance its tree. This requires accessing at most O(log N) nodes. The client can request only the data relevant to these nodes, and it knows the hash for each chunk of data in advance of accessing it. After computing the updated root hash, the client can even discard the data it processed. This technique has been well discussed in the academic literature, e.g. [1,2], although since I am not aware of any existing implementation, I made my own, intended as an explanatory aid: https://github.com/amiller/redblackmerkle/blob/master/redblack.py [1] Certificate Revocation and Update Naor and Nissim. 1998 http://static.usenix.org/publications/library/proceedings/sec98/full_papers/nissim/nissim.pdf [2] A General Model for Authenticated Data Structures Martel, Nuckolls, Devanbu, Michael Gertz, Kwong, Stubblebine. 2004 http://truthsayer.cs.ucdavis.edu/algorithmica.pdf -- Andrew Miller -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security,
Re: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite node
On 06/19/2012 01:59 PM, Gregory Maxwell wrote: On Tue, Jun 19, 2012 at 1:33 PM, Alan Reineretothe...@gmail.com wrote: One app developer updates their RB tree code which updated the RB-tree optimizations/rebalancing, and now a significant portion of the network can't agree on the correct root. Not only would that be disruptive, it would be a disaster to track down. This is why good comprehensive tests and a well specified algorithim are important. The tree update algorithm would be normative in that scheme. Worrying that implementers might get it wrong would be like worrying that they'd get SHA256 wrong. The point is not that they get it *wrong*, it's that the implement it *differently*. Given a set of 100 TxOuts, there's a seemingly-infinite number of ways to construct a binary tree. Put them in in a different order, and you get a different tree. *They're all correct and legal* in terms of satisfying expectations of insert, delete and query runtime -- but they will produce different root hashes. And the differences in underlying structure are completely transparent to the calling code. I'm extremely uncomfortable with the idea the you can have all the nodes in the tree, but have to replay X years of blockchain history just to get the same tree configuration as someone else. However, a trie configuration is history-independent -- given an unspent-TxOut list, there's only one way to construct that tree. That's an important property to me. I can't tell if you're joking about Judy structures: I've never heard of them. But I'll look into it anyway... -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite nodes
All, With the flurry of discussion about blockchain compression, I thought it was time to put forward my final, most-advanced idea, into a single, well-thought-out, *illustrated*, forum post. Please check it out: https://bitcointalk.org/index.php?topic=88208.0 This is a huge undertaking, but it has some pretty huge benefits. And it's actually feasible because it can be implemented without disrupting the main network. I'm sure there's lots of issues with it, but I'm putting it out there to see how it might be improved and actually executed. *Summary: */Use a special tree data structure to organize all unspent-TxOuts on the network, and use the root of this tree to communicate its signature between nodes. The leaves of this tree actually correspond to addresses/scripts, and the data at the leaf is actually a root of the unspent-TxOut list for that address/script. To maintain security of the tree signatures, it will be included in the header of an alternate blockchain, which will be secured by merged mining. This provides the same compression as the simpler unspent-TxOut merkle tree, but also gives nodes a way to download just the unspent-TxOut list for each address in their wallet, and verify that list directly against the blockheaders. Therefore, even lightweight nodes can get full address information, from any untrusted peer, and with only a tiny amount of downloaded data (a few kB). /* * Alright, tear it up! -Alan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite nodes
Hi Alberto, Your thread was part of the inspiration for the idea that I proposed. But as I read it more, I see that I originally misunderstood it (mistaking it for a simpler unspent-TxOut tree idea). Even after reading it, I'm not entirely clear how your proposal would work, but I see that you proposed something very similar. I just want to clarify that there are two, major orthogonal pieces to both proposals: (1) The method for creating unspent-TxOut-tree roots/fingerprints for verification (2) Using an alternate blockchain to maintain and distribute those fingerprints There are multiple ways to do both of those. You proposed a different tree structure (which I haven't entirely figured out, yet), and putting those fingerprints in the main chain header. In my proposal, (2) is to avoid inducing a blockchain fork, or even changing the protocol at all. By using a separate blockchain, it can be done non-disruptively, and could even be thrown out and re-worked if we were to find an issue with it later. The availability of merged mining makes it possible to get [almost] the same security as changing the protocol, but without the disruption of hard-forking. (I expect that if there's not too much computational overhead and the software is already written, most miners would sign on) I'll read into your page a little more. I don't want to take credit away from you, since you clearly had a comparable idea developed long before me :) -Alan On 06/17/2012 06:46 PM, Alberto Torres wrote: Hi, I did describe a very similar thing back in January (also illustrated, and, if I'm not mistaken, more simple and efficient to recalculate), and I wanted to do a prototype, but I have been very busy with other projects since then. https://en.bitcoin.it/wiki/User:DiThi/MTUT I just saw Gavin left a comment in the talk page, I'm sorry I haven't seen it earlier. I think armory is the perfect client to implement such an idea. I sort of waited it to be able to run in my laptop with 2 GB of RAM before being sucked into other projects. I even lost track of its development. I hope this gets developed. I will be able to help after summer if this is still not done. DiThi P.S: Sorry Peter, I've sent you the message privately by mistake. Also, I don't quite understand your concern of unbalancing the tree. 2012/6/17 Peter Toddp...@petertodd.org: On Sun, Jun 17, 2012 at 02:39:28PM -0400, Alan Reiner wrote: All, With the flurry of discussion about blockchain compression, I thought it was time to put forward my final, most-advanced idea, into a single, well-thought-out, *illustrated*, forum post. Please check it out: https://bitcointalk.org/index.php?topic=88208.0 This is a huge undertaking, but it has some pretty huge benefits. And it's actually feasible because it can be implemented without disrupting the main network. I'm sure there's lots of issues with it, but I'm putting it out there to see how it might be improved and actually executed. *Summary: */Use a special tree data structure to organize all unspent-TxOuts on the network, and use the root of this tree to communicate its signature between nodes. The leaves of this tree actually correspond to addresses/scripts, and the data at the leaf is actually a root of the unspent-TxOut list for that address/script. To maintain security of the tree signatures, it will be included in the header of an alternate blockchain, which will be secured by merged mining. This provides the same compression as the simpler unspent-TxOut merkle tree, but also gives nodes a way to download just the unspent-TxOut list for each address in their wallet, and verify that list directly against the blockheaders. Therefore, even lightweight nodes can get full address information, from any untrusted peer, and with only a tiny amount of downloaded data (a few kB). /* How are you going to prevent people from delibrately unbalancing the tree with addresses with chosen hashes? One idea that comes to mind, which unfortunately would make for a pseudo-network rule, is to simply say that any *new* address whose hash happens to be deeper in the tree than, say, 10*log(n), indicating it was probably chosen to be unbalanced, gets discarded. The new address part of the rule would be required, or else you could use the rule to get other people's addresses discarded. Having said that, such a rule just means that anyone playing games will find they can't spend *their* money, and only with pruning clients. Unrelated people will not be effected. The coins can also always be spent with a non-pruning client to an acceptable address, which can later re-spend on a pruning client. It also comes to mind is that with the popularity of firstbits it may be a good idea to use a comparison function that works last bit first... It's merkles all the way down... -- 'peter'[:-1]@petertodd.org
[Bitcoin-development] A tangent about BIP 10
On Thu, Jun 14, 2012 at 9:22 AM, Gavin Andresen gavinandre...@gmail.comwrote: I've been asked a couple of times: why doesn't signrawtx handle the BIP 0010 (https://en.bitcoin.it/wiki/BIP_0010) transaction format? I considered parsing/writing BIP 10 format for raw transactions, but decided that reading/writing BIP 10 format should happen at a higher level and not in the low-level RPC calls. So 'raw transactions' are simply hex-encoded into JSON strings, and encoding/decoding them is just a couple of lines of already-written-and-debugged code. BIP 10 https://en.bitcoin.it/wiki/BIP_0010 could use some improvement. I created it for offline and multi-sig tx but there was no reception to it because no one was using offline or multi-sig tx at the time except for Armory (which only currently implements offline tx). So I made something that fit my needs, and it has served its purpose well for me. But I also think it could be expanded and improved before there is wider adoption of it. It's a little clunky and not very rigorous. Elements of it that I'd really like to keep: (1) Some aspects of human-readability -- even if regular users will never look at it, it should be possible for advanced users to manually copypaste the data around and see what's going on in the transaction and what signatures are present. I'm thinking of super-high-security situations where manual handling of such data may even be the norm. (2) Should be compact -- I took the concept of ASCII-armoring from PGP/GPG, because, for the reason above, it's much easier and cleaner to view/select when copied inline. If a random user accidentally runs across it, it will partially self-identify itself (3) Includes all previous transactions so the device can verify transaction inputs without the blockchain. Things that could be added: -- It needs a BIP16 script entry (this was created for vanilla multi-sig before BIP 16 was created) -- Comment lines -- Version number -- Use base58/64 encoding -- Rigorous formatting spec -- Binary representation -- A better name than Tx Distribution Proposal I'll be releasing the Beta version of Armory soon, and after that, I'll probably be thinking about a multi-signature support interface. That would be a good time for me to tie in a better version of BIP 10 -- one that is compatible with other clients implementing the same thing. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Full Clients in the future - Blockchain management
Devs, I have decided to upgrade Armory's blockchain utilities, partly out of necessity due to a poor code decision I made before I even decided I was making a client. In an effort to avoid such mistakes again, I want to do it right this time around, and realize that this is a good discussion for all the devs that will have to deal with this eventually... The part I'm having difficulty with, is the idea that in a few years from now, it just may not be feasible to hold transactions file-/pointers/ in RAM, because even that would overwhelm standard RAM sizes. Without any degree of blockchain compression, I see that the most general, scalable solution is probably a complicated one. On the other hand, where this fails may be where we have already predicted that the network will have to split into super-nodes and lite nodes. In which case, this discussion is still a good one, but just directed more towards the super-nodes. But, there may still be a point at which super-nodes don't have enough RAM to hold this data... (1) As for how small you can get the data: my original idea was that the entire blockchain is stored on disk as blk.dat files. I store all transactions as 10-byte file-references. 10 bytes would be -- X in blkX.dat (2 bytes) -- Tx start byte (4 bytes) -- Tx size bytes (4 bytes) The file-refs would be stored in a multimap indexed by the first 6 bytes of the tx-hash. In this way, when I search the multimap, I potentially get a list of file-refs, and I might have to retrieve a couple of tx from disk before finding the right one, but it would be a good trade-off compared to storing all 32 bytes (that's assuming that multimap nodes don't have too much overhead). But even with this, if there are 1,000,000,000 transactions in the blockchain, each node is probably 48 bytes (16 bytes + map/container overhead), then you're talking about 48 GB to track all the data in RAM. mmap() may help here, but I'm not sure it's the right solution (2) What other ways are there, besides some kind of blockchain compression, to maintain a multi-terabyte blockchain, assuming that storing references to each tx would overwhelm available RAM? Maybe that assumption isn't necessary, but I think it prepares for the worst. Or maybe I'm too narrow in my focus. How do other people envision this will be handled in the future. I've heard so many vague notions of well we could do /this/ or /that/, or it wouldn't be hard to do /that/ but I haven't heard any serious proposals for it. And while I believe that blockchain compression will become ubiquitous in the future, not everyone believes that, and there will undoubtedly be users/devs that /want/ to maintain everything under all circumstances. -Alan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fwd: Re: Full Clients in the future - Blockchain management
(response from Doug forwarded below) It's a very good point. I have no experience with database engines. I had assumed that in most cases, data could always be indexed in RAM, and wanted to know where to go when that's not the case. I will look into that solution, further. I am very interested to solve the blockchain compression problem, and think I've got a great way that will not just compress the blockchain, but improve the network for lightweight clients. But the idea is not fully formed yet, so I was holding off... Original Message Subject: Re: [Bitcoin-development] Full Clients in the future - Blockchain management Date: Sat, 2 Jun 2012 12:07:44 -0500 From: Douglas Huff m...@jrbobdobbs.org To: Alan Reiner etothe...@gmail.com I think you're trying to solve something a little out of scope, really. Most of the issues aren't really issues for other clients using established storage mechanisms (bdb,SQLite,etc) and they're using them precisely because this is a problem that people have been working on for decades and a poor candidate for reinvention. If you really look at what you're proposing it's fundamentally how bdb operates except your indexing format is usage domain specific and you're in charge of all the resource management semantics. While at the same time you'll be missing many of the newer features that make working with/recovering/diagnosing issues in the storage layer easier. If you're really wanting to talk about pruning methods to prevent the massive amount of duplicated; but no longer pertinent, data that's a different story and please continue. :) -- Douglas Huff On Jun 2, 2012, at 10:40, Alan Reiner etothe...@gmail.com mailto:etothe...@gmail.com wrote: Devs, I have decided to upgrade Armory's blockchain utilities, partly out of necessity due to a poor code decision I made before I even decided I was making a client. In an effort to avoid such mistakes again, I want to do it right this time around, and realize that this is a good discussion for all the devs that will have to deal with this eventually... The part I'm having difficulty with, is the idea that in a few years from now, it just may not be feasible to hold transactions file-/pointers/ in RAM, because even that would overwhelm standard RAM sizes. Without any degree of blockchain compression, I see that the most general, scalable solution is probably a complicated one. On the other hand, where this fails may be where we have already predicted that the network will have to split into super-nodes and lite nodes. In which case, this discussion is still a good one, but just directed more towards the super-nodes. But, there may still be a point at which super-nodes don't have enough RAM to hold this data... (1) As for how small you can get the data: my original idea was that the entire blockchain is stored on disk as blk.dat files. I store all transactions as 10-byte file-references. 10 bytes would be -- X in blkX.dat (2 bytes) -- Tx start byte (4 bytes) -- Tx size bytes (4 bytes) The file-refs would be stored in a multimap indexed by the first 6 bytes of the tx-hash. In this way, when I search the multimap, I potentially get a list of file-refs, and I might have to retrieve a couple of tx from disk before finding the right one, but it would be a good trade-off compared to storing all 32 bytes (that's assuming that multimap nodes don't have too much overhead). But even with this, if there are 1,000,000,000 transactions in the blockchain, each node is probably 48 bytes (16 bytes + map/container overhead), then you're talking about 48 GB to track all the data in RAM. mmap() may help here, but I'm not sure it's the right solution (2) What other ways are there, besides some kind of blockchain compression, to maintain a multi-terabyte blockchain, assuming that storing references to each tx would overwhelm available RAM? Maybe that assumption isn't necessary, but I think it prepares for the worst. Or maybe I'm too narrow in my focus. How do other people envision this will be handled in the future. I've heard so many vague notions of well we could do /this/ or /that/, or it wouldn't be hard to do /that/ but I haven't heard any serious proposals for it. And while I believe that blockchain compression will become ubiquitous in the future, not everyone believes that, and there will undoubtedly be users/devs that /want/ to maintain everything under all circumstances. -Alan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263
Re: [Bitcoin-development] Punishing empty blocks?
I like the concept except that it only works if every node connected to the miner enforces the rule (if it works). Once any one of the nodes forwards the block, other nodes see it coming from a node that can pass the challenge. I don't think any solution based on node queries will succeed, especially if it requires spontaneous super-majority-of-nodes acceptance. I think it's gotta be based on the block itself and each nodes' own info. If you could spontaneously get all miners to agree not to build off of anti-social blocks (however that is defined) , it would have a chance of making a difference, but individual miners would have an advantage building off the antisocial block because they only need to produce one to create the longest chain (and collect reward) while the miners following the rules need two blocks. --Sent from my overpriced smartphone On May 25, 2012 3:48 AM, Christian Decker decker.christ...@gmail.com wrote: How about a simple proof of work test? This one though does not ask for CPU work but asks the miner for a random old transaction. If the miner really stores the entire blockchain he will not have any problem answering to that getdata request, whereas a botnet would have to ask someone else for it, which could be detected if the response time deviates too much from what has been previously measured (compare it against getdata for the block they advertise). It's not perfect but it allows an estimate of whether it is a chainless miner. Regards, Chris -- Christian Decker On Fri, May 25, 2012 at 3:17 AM, Jeff Garzik jgar...@exmulti.com wrote: On Thu, May 24, 2012 at 8:57 PM, Luke-Jr l...@dashjr.org wrote: Block times are not accurate enough for that. The times in your log are very accurate, assuming your system clock is remotely accurate. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] URI Handling in Bitcoin-Qt
On 05/03/2012 01:46 AM, Wladimir wrote: Label is a label for the destination address, message is a freeform message describing the transaction. I don't think the message is currently stored in the Satoshi client. That feature is somewhere on our way-too-long issue and todo list. But I understand that you want to add transaction meta-data fields such as contact information, bought items, item prices? I don't want to add fields to the URI-spec, I just want to add them /to the client/. To me, it is ideal to have separate strings for labeling /addresses/ vs labeling /transactions/ -- i.e. different strings would show up in the address book (owner info) than what shows up in the transaction history (purchase info). I say it's ideal because that concept seems to fit perfectly with availability of label= and message= fields in BIP 21, but it won't actually work if Bitcoin-Qt won't/can't do it that way. For now, it seems that I should count on all important information being in the /label/ field, since users creating URLs would have to assume anything in the /message/ field will not be saved. Though I imagine the message data will be /displayed/ after the URI is clicked, just not saved. To expand the concept slightly further, it might make sense in the future for users to populate the /message/ and /label /fields with lots of data, using newlines. The first line would be used as a summary and displayed in the address book and ledger. The extra lines would all be displayed when the user opens up a details window. All of it would be automatically generated by the merchant, and the purchaser would end up with detailed documentation on every purchase they've made for zero effort. -Alan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] new bitcoin.org clients page
Btw, I sent updated text to Genjix Armory. I hope that gets included or reviewed. And I agree about the $4k donations thing. That's complete immaterial for this page. Though the rest of the description there is reasonable, and might even be better than what I sent Genjix. -Alan On Wed, May 2, 2012 at 9:42 AM, Mike Hearn m...@plan99.net wrote: Bitcoin-qt is translated into a pretty broad set of languages (now— I cant tell you how many of them are _good_). Listing language just under multibit makes it sound like a distinguishing characteristic. Fair enough then, let's take that out. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] new bitcoin.org clients page
Oh, like I did 3 hours ago? Gah! I replied directly to grarpamp by accident. Sorry if this seems out of place now... I'm all for sorting the clients by ease of use. We want the smoothest first experience greeting users new to Bitcoin. I have grand plans of defaulting Armory to a standard user mode that is standalone, easy to use, etc. But until then, Armory will remain an a power-users thing, and I'd prefer not to have Bitcoin n00bs emailing me for support before they know what Bitcoin-Qt is, or, more likely, installing Armory alone and then walking away when nothing works. As someone else mentioned previously, the advanced stuff will generally be found by advanced users. I think it should still receive exposure through these means, but not on the top/first row. I personally think the page should say something like New to Bitcoin? Start experiencing Bitcoin with My Phone menu of phone options, or My Desktop menu of desktop options Put the top 3 on each and either a button for More Options, or a short list of other options without screenshots, and just descriptions with links. Ideally, it would be sorted by popularity, because that's probably the most important metric that ties together all features into a single number, but we don't have good stats on that. For now, we settle this by putting Bitcoin-Qt up front, and sort everything else by how easy it is for users to get started and perceived popularity and disagreements can be settled by semi-regular rotation. For now, I don't think ordering is super important. No one here is threatening lawsuits for improper placement, and the rotation will be good to keep the main Bitcoin page looking less stagnant, and slowly exposing repeat visitors to the variety of options available. --Alan On Wed, May 2, 2012 at 3:25 PM, Amir Taaki zgen...@yahoo.com wrote: This is like the most annoying thing about email. Often with group emails, we'll be having a conversation then someone will click reply instead of group reply and the convo will go on for a while. Eventually I'll realise the persons are missing and add them back in. On Yahoo mail (which I use for spam/mailing lists), to do reply all involves clicking a tab, scrolling down and clicking Reply All. Normally I instead go through the steps of reply, delete To, re-enter bitco... select drop down, click send. Anyone know how to make reply all the default in mutt? And how can I exclude it from re-including my own email when I do a group reply so I don't get the same email again. - Original Message - From: Jeff Garzik jgar...@exmulti.com To: grarpamp grarp...@gmail.com Cc: bitcoin-development@lists.sourceforge.net Sent: Wednesday, May 2, 2012 7:29 PM Subject: Re: [Bitcoin-development] new bitcoin.org clients page On Wed, May 2, 2012 at 12:58 PM, grarpamp grarp...@gmail.com wrote: Try Reply to All That puts the sender in 'to' and list in 'cc', which dupes to the sender and eventually blows out the to and cc lines as everyone chimes in and doesn't trim. 'reply to' solves most of that. assuming the list sw can do it. Reply-To Munging Considered Harmful http://www.unicom.com/pw/reply-to-harmful.html -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net
Re: [Bitcoin-development] new bitcoin.org clients page
I'm not sure what designed for occasional use means. Many users of other clients use them exclusively without touching other clients. Armory is designed to be your only wallet (if bitcoind[d/-qt] is running in bkgd). I'm sure the other clients are the same. Instead, I think that line would be replaced by a blurb about the target audience. Designed for Advanced Users. Designed for Quick Setup and Instant usability. Btw, Armory now has full installers for both Windows and Linux (Ubuntu/Debian), with uninstallers and automatic URI registration On Wed, May 2, 2012 at 3:34 PM, Gary Rowe g.r...@froot.co.uk wrote: How about keeping it simple? Bitcoin-Qt * Requires the entire blockchain * Standalone client * Designed for continuous operation * Available for Windows, Mac, Linux with installer * Developed in C * Website: https://bitcoin.org MultiBit * Requires a reduced blockchain * Standalone client * Designed for occasional use * Available for Windows, Mac, Linux with installer * Developed in Java * Website: http://multibit.org Armory * Requires the entire blockchain * Dependent client of Bitcoin-Qt * Designed for occasional use * Available for Windows (64-bit only), Mac, Linux (self-build) * Developed in Python * Website: http://bitcoinarmory.com/ Electrum * Requires no blockchain * Dependent client of Bitcoin-Qt (on server) * Designed for occasional use * Available for Windows, Linux (self-build) * Developed in Python * Website: http://ecdsa.org/electrum/ Bitcoin Wallet (Android client) * Requires a reduced blockchain * Standalone client * Designed for occasional use on mobile * Available for Android only * Developed in Java * Website: https://play.google.com/store/apps/details?id=de.schildbach.wallethl=en On 2 May 2012 20:25, Amir Taaki zgen...@yahoo.com wrote: This is like the most annoying thing about email. Often with group emails, we'll be having a conversation then someone will click reply instead of group reply and the convo will go on for a while. Eventually I'll realise the persons are missing and add them back in. On Yahoo mail (which I use for spam/mailing lists), to do reply all involves clicking a tab, scrolling down and clicking Reply All. Normally I instead go through the steps of reply, delete To, re-enter bitco... select drop down, click send. Anyone know how to make reply all the default in mutt? And how can I exclude it from re-including my own email when I do a group reply so I don't get the same email again. - Original Message - From: Jeff Garzik jgar...@exmulti.com To: grarpamp grarp...@gmail.com Cc: bitcoin-development@lists.sourceforge.net Sent: Wednesday, May 2, 2012 7:29 PM Subject: Re: [Bitcoin-development] new bitcoin.org clients page On Wed, May 2, 2012 at 12:58 PM, grarpamp grarp...@gmail.com wrote: Try Reply to All That puts the sender in 'to' and list in 'cc', which dupes to the sender and eventually blows out the to and cc lines as everyone chimes in and doesn't trim. 'reply to' solves most of that. assuming the list sw can do it. Reply-To Munging Considered Harmful http://www.unicom.com/pw/reply-to-harmful.html -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net
Re: [Bitcoin-development] new bitcoin.org clients page
I think it's perfectly reasonable to debate ordering. I personally don't think Armory should be up front, because it's not intended for beginners. How's that for honesty? I don't think anyone is trying to game the system right now, I think we're trying to come up with a reasonable mechanism for appealing to new users and get the community more connected. And make sure everyone understands the system. On the other hand, perhaps it's better to take the acceptable 80% solution, and revise it over time... Amir, I don't have access to the page. I've never been able to view it. Changing my hosts file doesn't seem to do anything. Can you just forward me the text? I'll send you an approval email. On Wed, May 2, 2012 at 3:43 PM, Amir Taaki zgen...@yahoo.com wrote: This discussion about ordering is absolutely retarded. Once the list fills up, then it won't matter. For now I'm deciding the ordering with Bitcoin-Qt first and the others ordered however. That was nobody can try to game the system (it remains unexploitable). If there are no objections, then I am going to merge this branch. The forum thread is divulging into a mess all over the place, and this conversation can go on forever discussing the silly fine details: http://hackerspaces.org/wiki/The_Bikeshed_Anti-PatternProblem: You suggest creating something new for your hackerspace, like a bikeshed. But now all anyone will discuss is its colour. No bikeshed will be built. Armory MultiBit, are you OK with that description? I will check with ThomasV about Electrum. From: Gary Rowe g.r...@froot.co.uk To: bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net Sent: Wednesday, May 2, 2012 8:34 PM Subject: Re: [Bitcoin-development] new bitcoin.org clients page How about keeping it simple? Bitcoin-Qt * Requires the entire blockchain * Standalone client * Designed for continuous operation * Available for Windows, Mac, Linux with installer * Developed in C * Website: https://bitcoin.org MultiBit * Requires a reduced blockchain * Standalone client * Designed for occasional use * Available for Windows, Mac, Linux with installer * Developed in Java * Website: http://multibit.org Armory * Requires the entire blockchain * Dependent client of Bitcoin-Qt * Designed for occasional use * Available for Windows (64-bit only), Mac, Linux (self-build) * Developed in Python * Website: http://bitcoinarmory.com/ Electrum * Requires no blockchain * Dependent client of Bitcoin-Qt (on server) * Designed for occasional use * Available for Windows, Linux (self-build) * Developed in Python * Website: http://ecdsa.org/electrum/ Bitcoin Wallet (Android client) * Requires a reduced blockchain * Standalone client * Designed for occasional use on mobile * Available for Android only * Developed in Java * Website: https://play.google.com/store/apps/details?id=de.schildbach.wallethl=en On 2 May 2012 20:25, Amir Taaki zgen...@yahoo.com wrote: This is like the most annoying thing about email. Often with group emails, we'll be having a conversation then someone will click reply instead of group reply and the convo will go on for a while. Eventually I'll realise the persons are missing and add them back in. On Yahoo mail (which I use for spam/mailing lists), to do reply all involves clicking a tab, scrolling down and clicking Reply All. Normally I instead go through the steps of reply, delete To, re-enter bitco... select drop down, click send. Anyone know how to make reply all the default in mutt? And how can I exclude it from re-including my own email when I do a group reply so I don't get the same email again. - Original Message - From: Jeff Garzik jgar...@exmulti.com To: grarpamp grarp...@gmail.com Cc: bitcoin-development@lists.sourceforge.net Sent: Wednesday, May 2, 2012 7:29 PM Subject: Re: [Bitcoin-development] new bitcoin.org clients page On Wed, May 2, 2012 at 12:58 PM, grarpamp grarp...@gmail.com wrote: Try Reply to All That puts the sender in 'to' and list in 'cc', which dupes to the sender and eventually blows out the to and cc lines as everyone chimes in and doesn't trim. 'reply to' solves most of that. assuming the list sw can do it. Reply-To Munging Considered Harmful http://www.unicom.com/pw/reply-to-harmful.html -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list
Re: [Bitcoin-development] new bitcoin.org clients page
Hey, looks good! I'm glad to see them sorted alphabetically :) A couple comments: I don't think the entries for wallet security and backups accurately describe Armory. Wallet Security should say Encrypt/Offline or something to to that effect -- after all, offline wallets are the holy grail feature of the Armory. And backups should say something like One-time Printable if it fits within the box. Otherwise, I really like the layout and design. Although despite the fact I enjoy being first on the list, I think Bitcoin-Qt should still go first. It is the reference client, and I think it's relevant that it is the de-facto client for the majority of users, and the one with the most quality control and stability. -Alan On Mon, Apr 30, 2012 at 1:50 PM, Amir Taaki zgen...@yahoo.com wrote: Check it :) https://github.com/bitcoin/bitcoin.org/pull/34 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] new bitcoin.org clients page
Actually I was looking at a screenshot someone sent me because I couldn't seem to access it even after changing the hosts file (I assumed it was recent, but I guess not). It just looked like the regular Bitcoin page (despite doing a ping on the command line and seeing the expected IP). Was there a specific link to click on?Am I blind? Is there a process we should use to submit how we think our program should be represented on the clients page? -Alan On Mon, Apr 30, 2012 at 2:31 PM, Amir Taaki zgen...@yahoo.com wrote: Are we looking at the same list? Because here is the order I added: Bitcoin-Qt, Armory, Electrum and MultiBit. Maybe try CTRL-F5 to force a refresh of your browser. Also about the descriptions: yeah I know. I think it's better to put this up first and then have everyone submit their own descriptions and screenshots. Otherwise it'll be a nightmare to coordinate until everything is perfect. I did message you on IRC today but maybe you were offline. I didn't copy paste the Armory description from the website because it really sounds too spammy like a sales pitch. Here I was trying to give an even handed balanced overview of all the clients. For each client I was trying to empaphise a 'theme'. Bitcoin-Qt is stability. Armory is advanced. Electrum is convenient. MultiBit is ease of use. From: Alan Reiner etothe...@gmail.com To: Amir Taaki zgen...@yahoo.com Cc: bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net Sent: Monday, April 30, 2012 7:23 PM Subject: Re: [Bitcoin-development] new bitcoin.org clients page Hey, looks good! I'm glad to see them sorted alphabetically :) A couple comments: I don't think the entries for wallet security and backups accurately describe Armory. Wallet Security should say Encrypt/Offline or something to to that effect -- after all, offline wallets are the holy grail feature of the Armory. And backups should say something like One-time Printable if it fits within the box. Otherwise, I really like the layout and design. Although despite the fact I enjoy being first on the list, I think Bitcoin-Qt should still go first. It is the reference client, and I think it's relevant that it is the de-facto client for the majority of users, and the one with the most quality control and stability. -Alan On Mon, Apr 30, 2012 at 1:50 PM, Amir Taaki zgen...@yahoo.com wrote: Check it :) https://github.com/bitcoin/bitcoin.org/pull/34 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Trusted identities
On 04/26/2012 01:30 PM, Peter Todd wrote: More difficulty shortens the safe time we can transact large volumes in, which is good for the network. I'm not sure of the current implementation of replacement transactions, can anyone on the core team speak to this? Can I replace transactions, or is that part of the spec unimplemented or deprecated right now? My understanding is it's completely disabled. Went on a scavenger hunt with Gavin a couple weeks concerning tx replacement. The conclusion was that if, (1) Transaction has lock-time in the future AND (2) Transaction has non-maximum sequence number Then the transaction will both propagate and be accepted into nodes' memory pools, but will not go into any block until locktime expires. If the lock-time is in the past OR sequence number on all TxIns is 0x, then it will be immediately valid and included in the blockchain. But the actual replacement mechanism is disabled. Therefore, the nodes accept the tx as if it's replaceable, but don't allow it to be replaced. This means that it is effectively replaceable *once*, but only if you inject a final transaction into the blockchain. You can't broadcast a final version of the same tx, because it will conflict with the non-final one sitting in all the other nodes' memory pools. You need a miner to agree to remove the non-final tx from their memory pool and specifically include your replacement. -Alan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior
My one big concern about this that users find a way to exploit this behavior for themselves. If it's too easy for users to create tx they know will get stuck and expire, it's no different than letting them cancel their zero-conf transactions. i.e. I pay 0.5 BTC in a store for a candy bar, so I send it using a combination of inputs and fees that I know will lead to it being stuck and expire. On the other hand, if such conditions are deterministic enough, it could be detected by the recipient and flagged. It's not a huge deal, but it's something to consider. -Alan On Thu, Apr 12, 2012 at 2:38 PM, Jeff Garzik jgar...@exmulti.com wrote: Not sure whether this rises to the level of a BIP or not, as it is largely an implementation change. One of my From-Day-One complaints about bitcoin is that transactions behavior could be far more deterministic (predictable), from a user standpoint. Transactions in the current system can easily remain in limbo forever. One big step in making transactions behave more predictably would be to remove transactions from the memory pool, if they have not made it into a block for a couple days. i.e. 1. N = 1 or 2 or whatever the community prefers. Ideally enough time for a third-tier miner, mining strange TXs, finds a block. 2. H1 = height of block chain, when a TX is received 3. H2 = H1 + (144 * N) 4. If block chain height reaches H2, and TX has not made it into a block, drop TX from memory pool Although this only impacts a small amount of TX's ultimately, what it does do is give us the ability -- once miners have upgraded to this rule -- to tell bitcoin users that their transactions expire after N days. Backwards compatibility should not be an issue; clients are free to retransmit their TX at any time, as usual, thereby resetting the clock for all peers who have forgotten the TX in question. Once in place, clients may then implement code that notices a TX has expired (read: likely to have been forgotten by the network, assuming they themselves have stopped retransmitting it). Then you can start working on wallet/coin recovery, perhaps resending with a higher fee etc. The above change is not really fill-or-kill but it should be a big step, opening the door to deterministic TX behavior. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Signature Blocks and URI Sign Requests
On 04/03/2012 02:46 PM, Gavin Andresen wrote: RE: signature blocks and BIP 10: We should avoid reinventing the wheel, if we can. I think we should extend existing standards whenever possible. So: could we encode signature blocks or BIP-10 transactions using S/MIME ? Or is there a more appropriate sign a message standard we could/should use? You're glossing over little details like what character encoding is used for the message, but I'd rather leverage all the work already done by the IETF to nail down all those little details rather then re-discover them and come up with our own solutions. I'm glossing over details because I actually have no experience dealing with character encodings, or the implementation specifics of existing solutions (PGP or S/MIME). That's why I'm emailing this list: I want to figure this stuff out, and at the same time try to converge on something that is efficient and can be interoperable between Armory and the Satoshi client (wallets, signature collection, sig blocks). I don't go into these things solely to reinvent stuff. My primary motivation for both ideas I have pitched so far (BIP 0010 and the sig blocks) is the versatility. I like the encoding-independent, visual compactness of PGP ASCII-armored text blocks, but I don't like their opaqueness. PGP vs my signature blocks basically look the same to a casual user, but even a moderately-knowledgeable user can appreciate the human-readable components of it. You can visually identify if signatures are missing from sig-collection packet, or see that you signed with the wrong address without having to load an external program. But that isn't a critical requirement, it's just my personal preference. I'm fine with existing systems if it sidesteps a lot of problems and there's easy interface to it.But, I don't want to have another BSDDB-wallet situation where we end up with 10x more capability than we need, and pay for it with 10x the complexity (at least in this case, using PGP is an existing crypto/security-sensitive technology). I have made simplicity one of my goals in Armory. Alternatively, we could change the discussion to a requirements discussion, to first figure out what we need in order to address multi-signature collection, etc. Then evaluate competing ideas based on their qualities relative to the requirements. -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Signature Blocks and URI Sign Requests
I would like to propose two things that are closely related. I will start making BIPS if there's positive feedback. Sorry it's so long, but I felt both should be in the same email... _*(1) Signature Blocks* -- A more-robust, versatile, message-signing exchange_ Satoshi client 0.6.0 introduced message signing, but I've been fairly unimpressed with the implementation. Strictly speaking, it works, but it's really not intended for regular users. There is no indication of what message was signed or what address signed it. Key recovery works for the computers processing it, but the user has no idea what this chunk of random data is. They don't even know if the message they thought they signed is what's in the signature (along the lines of the copypaste virus, the message could be switched out without the user noticing). I have implemented Signature Blocks https://bitcointalk.org/index.php?topic=56424.msg776163#msg776163 in Armory (as of v0.55), which is a fully-functional expansion on the idea. Along the lines of BIP 10, a signature block is a human-readable chunk of data that immediately identifies the address and the message that are being signed. It is easily copypasted via email or text files, and is fairly compact for visual identification. Click the link above to see an example signature block and an Armory screenshot of the UI (which needs improvement, but still usable). The verification process will include: -- Check that the public key (included or recovered) matches the address field. -- Verify that the signature matches the included message for this public key -- The message is properly formatted with a standardized character set and escape/replacement scheme for things like newlines or double-quotes. gmaxwell already pointed out that key recovery makes the Public Key field pointless. Okay fine -- I just don't have key recovery implemented yet in Armory, and when I do I can ditch that field (or simply make it optional). The point is to create a versatile, human-readable standardized form, much like the BIP 0010 signature-collection scheme https://en.bitcoin.it/wiki/BIP_0010. _*(2) Sign-Message URI scheme***-- Request signed messages from users using URIs_ I had the idea that for certain services, the first funding address could be used to identify the owner of an account, and all account maintenance (such as cashouts) be done through signed messages with this address. For instance, the user would need both a login password *and* a signed message in order to make a withdrawal or purchase: (Please withdraw 12.3 BTC from acct 1828349132 to address 1Hfr3jk2093f)_signed_by_A This gives the service the ability to use two separate factors to authenticate the request (usernamepassword *and* access to unencrypted wallet). This /could/ work with manual signature blocks alone... but it's too many steps for regular users. However, I think it's workable if we expand bitcoin URIs to include Signature Requests. The URI scheme would add a few parameters to the scheme, and would have to have further replacement rules to make sure that messages are handled properly. The general CONOPs would be (*Con*cept of *Op*eration*s*): -- User navigates to Withdraw funds on webpage -- Webpage has you fill in the details: from-account, to-address, withdrawal amount -- Webpage produces a clickable URI link that loads all the information into your client, including addr-reqd-for-sig -- Client asks for confirmation and passphrase (if necessary) then produces a signature (and sig block if necessary) -- URI may include reply-to field that tells it where to send the siganture when it's ready So the extra tags that would be needed would probably be: *requestSig*=True: Flag to identify that this is a signing request URI *sigNeeded*=1Qjf3392k31h The address that needs to sign the message *message*=Please%20withdraw%2012.3%20BTC%20to%20addr%201Hfr3jk2093f Some encoding of the message that can be parsed the same way on all systems *replyurl*=http://requestor.com/sig_replies.asp?; (Optional) After signing, application will submit the signature to the replyurl The reply url could be simply an http URL which will use bitcoin URI syntax, with the fields above copied. Therefore, to complete the above request, the application handling the request will simply send an HTTP request to: http://requestor.com/sig_replies.asp?*sigNeeded*=1Qjf3392k31h*message*=...*signature*=1fb1893ac193...*replySig*=True Any thoughts? (I have no doubts that there are :) ) -Alan -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free.
Re: [Bitcoin-development] Alternative to OP_EVAL
I haven't been much a part of these brainstorming discussions, and so I'm really looking at this from a bird's eye view, without any bias towards any particular idea. I do see what appears to be relevant concerns, brought up just before new, powerful functionality is injected into 50%+ of the nodes on the network. I cannot tell from my position if there is/has been consistent concern for OP_EVAL proposal, or if it's mostly a transient response to hearing about recursion in the scripting engine, etc (like myself, originally). I haven't debated this topic much, so I'm not in a position to personally comment on any proposals. (Though, this all feels very similar to the problem of hash-table collisions in HTTP POSThttp://www.securityweek.com/hash-table-collision-attacks-could-trigger-ddos-massive-scale ). However, I would like to remind everyone that we/you are messing with a $20+ million dollar *thing*. There's more than just a piece of software at stake -- whatever goes in needs to be as hard as diamond. If we open up a hole that allows someone to satisfy arbitrary scripts, or create one-packet DoS/crash attacks, that could be devastating for Bitcoin. Roconner is persuasive enough to make *me* think that not all corners of this functional space has been explored properly. And while my opinion doesn't matter, I'm concerned that others may feel too invested in the current design path to want to go backwards. Again, I don't know one way or another, I just want to warn against pride getting priority over security. At the very least, you should consider consequences and recovery path of such unanticipated problems. If the things that could go wrong are devastating, let's lean towards a more conservative solution (like sandboxing the sub-scripting engine). Remember, the network is working just fine *without *OP_EVAL, and while OP_EVAL provides some really nice benefits, I don't think the benefits over regular multi-sig are worth the consequences of making a mistake in this multi-million dollar beast. Okay, back to your regularly-scheduled debating... -Alan On Thu, Dec 29, 2011 at 2:08 PM, Pieter Wuille pieter.wui...@gmail.comwrote: On Thu, Dec 29, 2011 at 01:55:03AM -0500, rocon...@theorem.ca wrote: Gavin asked me to come up with an alternative to OP_EVAL, so here is my proposal. OP_CODEHASH Initial Proposal If we're again brainstorming about alternatives for OP_EVAL, I'll do my own. It is called OP_CHECKEDEVAL, and is specified as follows: * It looks at the two elements most recently (in code position) pushed by a literal, and not yet consumed by another OP_CHECKEDEVAL. These are S (the serialized script), and H (its hash). This implies it defines its own literal-only stack, where all literals push to, and only OP_CHECKEDEVAL pops from. This special stack has the advantage of allowing static analysis - one does not need to execute any operations to find out which data will end up on it. Note that skipped code (inside the ignored part of an IF-THEN-ELSE) can still push to the literal stack. * For the outer script, it does not have any effect at all, except for: * 2 elements popped from the literal-only stack * potentially causing failure It does not touch the main stack, alt stack or any other part of the execution state not listed above. * Failure is caused when either of these conditions hold: * No two elements remain on the literal-only stack * The Hash(S) != H * The inner script execution caused failure * For the execution of the inner script: * It is executed in a completely new and independent execution environnement * It executes the deserialized S * It inherits the main stack and alt stack (without the serialized script and the hash themselves) from the outer execution. This requires OP_CHECKEDEVAL to immediately follow the push of script and hash, so the code in the pair script OP_CHECKEDEVAL can be parsed and interpreted as code, allowing static analysis. As OP_CHECKEDEVAL has absolutely no effects except for potentially causing failure, it is very similar to the OP_NOPx it would replace, and guarantees that interpreting OP_CHECKEDEVAL as OP_NOPx can never cause the script to become invalid if it wasn't already. A basic pay-to-script-hash scriptPubKey is very short: scriptHash OP_CHECKEDEVAL And it is redeemed using: script inputs script Furthermore, the implementation is very similar to what was already done for OP_EVAL. Modifications: * EvalScriptInner needs less by-ref arguments, as it cannot modify the parent's state. * A literal-only stack needs to be maintained. I believe this combines all advantages: * Easy spend-to-script-hash (shorter than OP_EVAL) * Backward compatible (guaranteed by construction, instead of separately enforced like with OP_EVAL) * Statically analyzable (though it requires deserializing the script data). * Possibility to introduce a new language inside (not
Re: [Bitcoin-development] Protocol extensions
The whole point of having headers built at a constant size and generation rate is to minimize the amount of data needed to understand of the blockchain while simultaneously maximizing integrity/security in the presence of untrusted nodes. Barring the 50%-attack, you only need a couple honest nodes out of 50 to stay safe (as long as you're waiting for your 6 confirmations). In fact, I would argue that a full node (Satoshi client), has the same level of security as a headers-only client... because they both base *all* their verification decisions on computations that end with comparing hashes to the longest-chain headers. In the case that an attacker figures out how to isolate your node entirely and start feeing you poisoned blocks, then you are vulnerable with any kind of node, full or lightweight. I don't see where the reduced security is. The only issue I see is that a truly light-weight, headers-only node will be having to download an entire block to get one transaction it needs. This would be significantly alleviated if nodes can start requesting merkle-trees directly, even without merkle-branch-pruning. If a node can ask for a tx and the tx-hash-list of the block that incorporated that tx, he can easily verify his tx against his no-need-to-trust-anyone headers, and doesn't have to download MBs for every one. As for blockchain pruning... I think it's absolutely critical to find a way to do this, /for all nodes/. I am swayed by Dan Kaminsky's scalability warnings, and my instinct tells me that leaving full verification to a select few deep-pockets nodes in the future opens up all sorts of centralization/power-corporation issues that is contrary to the Bitcoin concept. It is in everyone's best interest to make it as easy as possible for /anyone/ to act as a full node (if possible). As such, I believe that the current system of minimizing TxOut size is the right one. TxIns take up 0 bytes space in the long-run when taking into account any blockchain pruning/snapshot idea (except for nLocktime/seq transactions where the TxIn might have to be saved). -Alan On 12/18/2011 12:09 PM, theymos wrote: On Sat, Dec 17, 2011, at 05:27 PM, Jordan Mack wrote: I don't like the idea of a header only client, unless this is just an interim action until the full block chain is downloaded in the background. Development of these types of clients is probably inevitable, but I believe that this breaks the most fundamental aspects of Bitcoin's security model. If a client has only headers, it cannot do full verification, and it is trusting the data from random anonymous peers. A headers-only client is much better than trusting anyone, since an attacker needs50% of the network's computational power to trick such clients. For everyone to keep being a full node, hardware costs would need to constantly go down enough for all nodes to be able to handle enough transactions to meet demand. If hardware doesn't become cheap enough quickly enough, either some people would be unable to handle being full nodes, or the max block size wouldn't rise enough to meet demand and transaction fees would become noncompetitive. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Addressing rapid changes in mining power
I can substantiate Gavin's point quite powerfully: a couple months ago I did a search for the hardest block in the network and found a *very **impressive* one: https://bitcointalk.org/index.php?topic=29675.0 That block has a difficulty of **36 billion** when the network had a difficulty of **1.5 million**, which is 24,000 times harder than the target. If we were going by the /actual /hardest chain instead target-based-hardest chain, /then this block produced in July would might still represent the longest chain!/ Yes, that means that whichever miner produced this block, could've held onto it for 2-4 months without doing anything else, and then broadcast it to fork the blockchain from a block produced months ago. That's not theoretical, that's real data in the blockchain and it would be a disaster. -Alan On 11/23/2011 10:09 AM, Gavin Andresen wrote: On Wed, Nov 23, 2011 at 9:38 AM, Christian Decker decker.christ...@gmail.com wrote: At some point you might find an incredibly hard block that makes your forked chain the hardest one in the network Seems to me that's the real problem with any hardest block found in X minutes scheme. If I get lucky and find a really extremely hard block then I have an incentive to keep it secret and build a couple more blocks on top of it, then announce them all at the same time. If the rest of the network rejects my longer chain because I didn't announce the extremely hard block in a timely fashion... then how could the network ever recover from a real network split? A network split/rejoin will look exactly the same. Bitcoin as-is doesn't have the I got lucky and found an extremely hard block problem because the difficulty TARGET is used to compute chain difficulty, not the actual hashes found. --- PS: I proposed a different method for dealing with large hash power drops for the testnet on the Forums yesterday, and am testing it today. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...
Michael, thanks for taking time to read the proposal. Responses are
inline, below.
I am not sure where you prefer the discussion on the content of the BIP - but
now you get it here, but feel free to redirect...
Likes:
* inclusion of prevout txout scripts - could prove handy
* that it is a proposal to do this similarly on all clients
The txout scripts are not just handy, they /need/ to be included in the
txin scripts for signing. By putting them there already, the parser
only has to blank out the others txins, add the hashcode, and pass it to
the ECDSA code for signing (if you're not familar with OP_CHECKSIG, see
my diagram here https://bitcointalk.org/index.php?topic=29416.0). I
think this feature is *critical* to adoption, as it works for the most
lightweight clients that might not even contain blockheaders --
everything you need to understand and sign the the transaction is
included (except for the txin values).
For that reason, this doubles as a convenient way to do offline
wallets/signing: you don't have to keep transporting 700 MB of
blockchain to the offline computer just so it can sign your transactions.
Dislikes:
* the format - I guess I would prefer a normal JSON format - where the scripts
gets populated step by step. As for the scriptPubKey (now an awful name...) it
would be easy to just add it to the JSON, or have the prevouts simply be the
actual txouts instead of {hash,n}.
I see the benefit of JSON for dynamic information with lots of optional
fields. But this information is fairly static -- if there's extra
information developers need for this process, it can be added. I don't
see a lot of variation in the amount/types of data to be included here.
The core benefit follows PGP messages: compact, easy-to-identify,
blocks of text, that can be included inline in an email as easily as it
can be supplied as a file/attachment, and only requires code that's
already available in a BTC developer toolbox. I can even remove the
numsigs counter, as it's easy enough to search for the END-TXDP line.
Think about a non-developer opening a file and trying to identify it:
JSON looks like code, this looks like... BEGIN-TXDP--- (now that
I think about it, BEGIN-TRANSACTION-9fj3fsQ might be better...)
Comments:
* it is good to have this proposal, but I think that once we see ways to
communicate it they could very well radically steer how a format should look.
Take e.g. the discussion we had with Gavin yesterday, if we had chosen to move
in that direction BIP0010 would had been useless. So perhaps a bit premature?
If we start talking about in-blockchain techniques, I agree with you.
But If that idea is discarded, *all* out-of-band solutions are going to
require encoding this exact information somehow. I think offering this
solution before developers start asking the question of how to do it is
exactly what's needed.
-Alan
Cheers,
Michael
On 10/11/2011, at 04:00, Alan Reiner wrote:
The purpose of creating BIP 0010 now, is to encourage a standard that
developers want to adopt, from the outset. Every developer who is planning to
touch multi-signature transactions, is going to have to solve the problem of
multi-sig tx exchanges, eventually. By offering an excellent solution before
they've started asking the question, there's a good chance people will use it.
Hear me out...
Protocols get fragmented when there's multiple competing ways to do something,
each having some advantages the others don't have. This leads to developers
with differing priorities picking different ones, or creating their own.
However, I believe that the problem BIP 0010 seeks to solve is a fairly
straightforward problem. There's not a lot of variety in the solutions that
could compete against it. People just need a way to pass this data around, and
they want it to be as convenient to use, and as easy to implement as possible.
In that sense, I think BIP 0010 (or some future variant) is fairly optimal as a
building block for higher-level protocols.
If anyone has ideas for why someone would want to create a competing idea to
BIP 0010 (besides not being aware of it when they start), I'd like to discuss
it. I'm fairly confident that any such ideas could just be added to BIP 0010
and thus reset the question of why anyone would need a competing idea.
On 11/09/2011 03:03 PM, Michael Grønager wrote:
My main concern when it comes to introducing other protocols is that they might
never be standard (I think a great number of clients will emerge - and this
would be a thing to compete on). If it is part of the p2p network it will be a
seamless standard and easy for everyone to use, even across different clients.
But I share your concern on the
/M
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
