Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
On Mon, Jun 01, 2015 at 09:01:49PM +0100, Roy Badami wrote: What do other people think? Would starting at a max of 8 or 4 get consensus? Scaling up a little less than Nielsen's Law of Internet Bandwidth predicts for the next 20 years? (I think predictability is REALLY important). TL;DR: Personally I'm in favour of doing something relatively uncontroversial (say, a simple increase in the block size to something in the 4-8GB range) with no further increases without a further hard fork. And the other bit I should have added to my TL;DR: If we end up spending a significant proportion of the next 20 years discussing the then _next_ hard fork, that's a *good* thing, not a *bad* thing. Hard forks need to become, if not entirely routine, then certainly less scary. A sequence of (relatively) uncontroversial hard forks over time is way more likely to gain consensus than a single hard fork that attempts to set a schedule for block size increases out to 2035. IMHO. I'm not sure how relevent Nielsen's Law really is. The only relevent data points Nielsen has really boil down to a law about how the speed of his cable modem connection has changed during the period 1998-2014. Interesting though that is, it's not hugely relevent to bandwidth-intensive operations like running a full node. The problem is he's only looking at the actual speed of his connection in Mbps, not the amount of data usage in GB/month that his provider permits - and there's no particular reason to expect that both of those two figures follow the same curve. In particular, we're more interested in the cost of backhaul and IP transit (which is what drives the GB/month figure) than we are in improvements in DOCSIS technology, which have little relevence to node operators even on cable modem, and none to any other kind of full node operator, be it on DSL or in a datacentre. More importantly, I also think a scheduled ramp up is an unnecessary complication. Why do we need to commit now to future block size increases perhaps years into the future? I'd rather schedule an uncontroversial hard fork now (if such thing is possible) even if there's a very real expectation - even an assumption - that by the time the fork has taken place, it's already time to start discussing the next one. Any curve or schedule of increases that stretches years into the future is inevitably going to be controversial - and more so the further into the future it stretches - simply because the uncertainties around the Bitcoin landscape are going to be greater the further ahead we look. If a simple increase from 1GB to 4GB or 8GB will solve the problem for now, why not do that? Yes, it's quite likely we'll have to do it again, but we'll be able to make that decision in the light of the 2016 or 2017 landscape and can again make a simple, hopefully uncontroversial, increase in the limit at that time. So, with the proviso that I think this is all bike shedding, if I had to pick my favourite colour for the bike shed, it would be to schedule a hard fork that increases the 1GB limit (to something in the 4-8GB range) but with no further increases without a further hard fork. Personally I think trying to pick the best value of the 2035 block size now is about as foolish as trying to understand now the economics of Bitcoin mining many halvings hence. NB: this is not saying that I think we shouldn't go above 8GB in the relatively foreseeable future; quite the contrary, I strongly expect that we will. I just don't see the need to pick the 2020 block size now when we can easily make a far better informed decision as to the 2020 block size in 2018 or even 2019. As to knowing what the block size is going to be for the next 20 years being REALLY important? 100% disagree. I also think it's impossible, because even if you manage to get consensus on a block size increase schedule that stretches out to 2035 (and my prediction is you won't) the reality is that that block size schedule will have been modified by a future hard fork long before we get to 2035. What I personally think is REALLY important is that the Bitcoin community demonstrates an ability to react appropriately to changing requirements and conditions - and we'll only be able to react to those conditions when we know what they are! My expectation is that there will be several (hopefully _relatively_ uncontroversial) scheduled hard forks between now and 2035, and each of those will be discussed in suitable detail before being agreed. And that's as it should be. roy -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Mechanics of a hard fork
I'd love to have more discussion of exactly how a hard fork should be implemented. I think it might actually be of some value to have rough consensus on that before we get too bogged down with exactly what the proposed hard fork should do. After all, how can we debate whether a particular hard fork proposal has consensus if we haven't even decided what level of supermajority is needed to establish consensus? For instance, back in 2012 Gavin was proposing, effectively, that a hard fork should require a supermajority of 99% of miners in order to succeed: https://gist.github.com/gavinandresen/2355445 More recently, Gavin has proposed that a supermoajority of only 80% of miners should be needed in order to trigger the hard fork. http://www.gavintech.blogspot.co.uk/2015/01/twenty-megabytes-testing-results.html Just now, on this list (see attached message) Gavin seems to be aluding to some mechanism for a hard fork which involves consensus of full nodes, and then a soft fork preceeding the hard fork, which I'd love to see a full explanation of. FWIW, I think 80% is far too low to establish consensus for a hard fork. I think the supermajority of miners should be sufficiently large that the rump doesn't constitute a viable coin. If you don't have that very strong level of consensus then you risk forking Bitcoin into two competing coins (and I believe we already have one exchange promissing to trade both forks as long as the blockchains are alive). As a starting point, I think 35/36th of miners (approximately 97.2%) is the minimum I would be comfortable with. It means that the rump coin will initially have an average confirmation time of 6 hours (until difficulty, very slowly, adjusts) which is probably far enough from viable that the majority of holdouts will quickly desert it too. Thoughs? roy---BeginMessage--- For reference: the blog post that (re)-started this debate, and which links to individual issues, is here: http://gavinandresen.ninja/time-to-roll-out-bigger-blocks In it, I asked people to email me objections I might have missed. I would still appreciate it if people do that; it is impossible to keep up with this mailing list, /r/bitcoin posts and comments, and #bitcoin-wizards and also have time to respond thoughtfully to the objections raised. I would very much like to find some concrete course of action that we can come to consensus on. Some compromise so we can tell entrepreneurs THIS is how much transaction volume the main Bitcoin blockchain will be able to support over the next eleven years. I've been pretty clear on what I think is a reasonable compromise (a one-time increase scheduled for early next year), and I have tried to explain why I think it it is the right set of tradeoffs. There ARE tradeoffs here, and the hard question is what process do we use to decide those tradeoffs? How do we come to consensus? Is it worth my time to spend hours responding thoughtfully to every new objection raised here, or will the same thing happen that happened last year and the year before-- everybody eventually gets tired of arguing angels-dancing-on-the-head-of-a-pin, and we're left with the status quo? I AM considering contributing some version of the bigger blocksize-limit hard-fork patch to the Bitcoin-Xt fork (probably target a hobbyist with a fast Internet connection, and assume Nelson's law to increase over time), and then encouraging merchants and exchanges and web wallets and individuals who think it strikes a reasonable balance to run it. And then, assuming it became a super-majority of nodes on the network, encourage miners to roll out a soft-fork to start producing bigger blocks and eventually trigger the hard fork. Because ultimately consensus comes down to what software people choose to run. -- -- Gavin Andresen -- 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 ---End Message--- -- 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
Re: [Bitcoin-development] Mechanics of a hard fork
On the other hand, if 99.99% of the miners updated and only 75% of merchants and 75% of users updated, then that would be a serioud split of the network. But is that a plausible scenario? Certainly *if* the concensus rules required a 99% supermajority of miners for the hard fork to go ahead, then there would be absoltely no rational reason for merchants and users to refuse to upgrade, even if they don't support the changes introduces by the hard fork. Their only choice, if the fork succeeds, is between the active chain and the one that is effectively stalled - and, of course, they can make that choice ahead of time. roy -- 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] Mechanics of a hard fork
On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote: I would not modify my node if the change introduced a perpetual 100 BTC subsidy per block, even if 99% of miners went along with it. Surely, in that scenario Bitcoin is dead. If the fork you prefer has only 1% of the hash power it is trivially vulnerably not just to a 51% attack but to a 501% attack, not to mention the fact that you'd only be getting one block every 16 hours. A hardfork is safe when 100% of (economically relevant) users upgrade. If miners don't upgrade at that point, they just lose money. This is why a hashrate-triggered hardfork does not make sense. Either you believe everyone will upgrade anyway, and the hashrate doesn't matter. Or you are not certain, and the fork is risky, independent of what hashrate upgrades. Beliefs are all very well, but they can be wrong. Of course we should not go ahead with a fork that we believe to be dangerous, but requiring a supermajority of miners is surely a wise precaution. I fail to see any realistic scenario where 99% of miners vote for the hard fork to go ahead, and the econonomic majority votes to stay on the blockchain whose hashrate has just dropped two orders of magnitude - so low that the mean time between blocks is now over 16 hours. And the march 2013 fork showed that miners upgrade at a different schedule than the rest of the network. On May 7, 2015 5:44 PM, Roy Badami r...@gnomon.org.uk wrote: On the other hand, if 99.99% of the miners updated and only 75% of merchants and 75% of users updated, then that would be a serioud split of the network. But is that a plausible scenario? Certainly *if* the concensus rules required a 99% supermajority of miners for the hard fork to go ahead, then there would be absoltely no rational reason for merchants and users to refuse to upgrade, even if they don't support the changes introduces by the hard fork. Their only choice, if the fork succeeds, is between the active chain and the one that is effectively stalled - and, of course, they can make that choice ahead of time. roy -- 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] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
In this case there is no need for P2P communication, just pay to an address you already have for the other party. If you want to avoid address reuse, use stealth addressing. But yes, if you don't have a stealth address for the other party you can certainly communicate in private as peers where you trust that you share a public key. The core issue here is really bootstrapping of that trust in an ad hoc manner. Something interactive might still be nicer, though, to avoid the risk of paying to an address that the payee no longer has the private key for. Nooo!! Don't pay to that address. I lost my old phone so I generated a new wallet. roy -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
Personally I like the simplicity of tapping two phones together to make payment - it should be quicker and easier than scanning QR codes and it's a trust model that's hard to misunderstand. Is NFC good enough for that? I fear even with NFC it is possible to produce a device with longer range than one would expect. What happened to the idea of tapping two devices together and then comparing the timing of the tap (as detected by the phones' accelerometers) to make spoofing a transaction harder? I remember hearing about that years ago - is that still a thing? roy On Thu, Feb 05, 2015 at 02:10:51PM -0800, Eric Voskuil wrote: A MITM can receive the initial broadcast and then spoof it by jamming the original. You then only see one. e On Feb 5, 2015, at 2:07 PM, Paul Puey p...@airbitz.co wrote: So if you picked up the BLE broadcast request. All you know is that *someone* within 100m is requesting bitcoin at a certain address. Not necessarily who. The *name* is both optional, and possibly just a *handle* of the user. If I'm sitting 5 ft away from someone at dinner and wanted to pay them via BLE, I might see Monkey Dude on my list and simply ask him is that you? If so, I send it. If there are two Monkey Dude's Then I have to bother with the address prefix, but not otherwise. On Thu, Feb 5, 2015 at 1:46 PM, Eric Voskuil e...@voskuil.org wrote: BLE has an advertised range of over 100m. http://www.bluetooth.com/Pages/low-energy-tech-info.aspx In the case of mass surveillance that range could most likely be extended dramatically by the reviewer. I've seen WiFi ranges of over a mile with a strong (not FCC approved) receiver. WiFi hotspots don't have strong identity or a guaranteed position, so they can't be trusted for location. e On Feb 5, 2015, at 1:36 PM, Mike Hearn m...@plan99.net wrote: This sounds horrible. You could basically monitor anyone with a wallet in a highly populated area and track them super easily by doing facial recognition. We're talking about BLE, still? The radio tech that runs in the so called junk bands because propagation is so poor? My watch loses its connection to my phone if I just put it down and walk around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't going to be enabling mass surveillance any time soon. It barely goes through air, let alone walls. Anyway, whatever. I'm just bouncing around ideas for faster user interfaces. You could always switch it off or set it to be triggered by the presence of particular wifi hotspots, if you don't mind an initial bit of setup. Back on topic - the debate is interesting, but I think to get this to the stage of being a BIP we'd need at least another wallet to implement it? Then I guess a BIP would be useful regardless of the design issues. The prefix matching still feels flaky to me but it's hard to know if you could really swipe payments out of the air in practice, without actually trying it. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
For peer-to-peer payments, how common do we think that the payment is of an ad hoc nature rather than to a known contact? If I want to pay my friends/colleagues/etc over a restaurant table there's no reason why I couldn't already have their public keys in my contact list - then it would be pretty straightforward to have a watertight mechanism where I would know who I was paying. You could probably even relatively securely bootstrap a key exchange over SMS, relying only on the contacts already having each other in their phonebooks. As for comsumer-to-merchant transactions where the merchant is a bricks and mortar merchant, IMHO it absolutely has to be pay that terminal over there. It's the trust model we all currently use - whether paying cash or card - and it's the only trust model that works IMHO (and customers and businesses alike are well aware of the risks of a fraudster standing behind the counter pretending to be an employee accepting payment - and by and large are pretty good at mitigating it). OTOH as we've discussed here before there are many use cases where the custoemr doesn't actually know or care about the name of the shop or bar they walked into but is pretty damn sure that they need to make payment to the person over there behind the counter. Granted, there are cases taht dont' fall into either of the above - but they're the cases that are (a) harder to figure out how to authenticate and consequently (b) the use cases that are going to be most subject to attempted fraud. roy On Thu, Feb 05, 2015 at 03:02:56PM -0800, William Swanson wrote: On Thu, Feb 5, 2015 at 2:10 PM, Eric Voskuil e...@voskuil.org wrote: A MITM can receive the initial broadcast and then spoof it by jamming the original. You then only see one. You are right, of course. There is no way to make Bluetooth 100% secure, since it is an over-the-air technology. You could try securing it using a CA or other identity server, but now you've excluded ad-hoc person-to-person payments. Plus, you need an active internet connection to reach the CA. You can try using proximity as a substitute for identity, like requiring NFC to kick-start the connection, but at that point you might as well use QR codes. This BIP is not trying to provide absolute bullet-proof security, since that's impossible given the physical limitations of the Bluetooth technology. Instead, it's trying to provide the best-possible security given those constraints. In exchange for this, we get greatly enhanced usability in common scenarios. There are plenty of usable, real-world technologies with big security holes. Anybody with lock-picking experience will tell you this, but nobody is welding their front door shut. The ability to go in and out is worth the security risk. Bluetooth payments add a whole new dimension to real-world Bitcoin usability. Do we shut that down because it can't be made perfect, or do we do the best we can and move forward? -William -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships
Why is this? Well, in most jurisdictions financial laws a custodial relationship is defined as having the ability, but not the right, to dispose of an asset. So if I leave my window open while I'm out and there's some cash on my desk, visible from the street, then every passer by now has a custodial relationship with me? Your example of a malicious software update seems more akin to a theft like that (which is clearly not a custodial relationship) rather than a true custodial relationship. roy -- 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] Area of Focus
Why would we want to have anything to do with people who are hosting malware? Or do I misunderstand? On Sat, Dec 20, 2014 at 08:57:53AM +, Matt Corallo wrote: There was recently some discussion around dnsseeds. Currently some dnsseeds are getting blocked by ISPs because the hosts they pick up (which run bitcoin core nodes) often run rather web servers alongside which serve malware or whatever else and thus end up on IP-based malware blacklists. Of course we really dont want to move off of DNS because it has this big built-in anonymity network where the DNS seed servers only get information about your ISP, not you, and its cached so you dont get as much information about how many users are making those requests. A potential solution might be supporting some subdomain which has results XORed with some constant mask to tweak the real IP. Additionally, it might be cool to stuff a TXT//whatever record with a signature of the results provided by the DNSseed operator. Matt On 12/20/14 07:42, Will Bickford wrote: Hi all, I'm looking to help with Bitcoin core development in my spare time (a few hours per week). A little bit about me: * I use C++ and Qt daily * I love to automate and enhance software systems * I enjoy root causing and fixing issues I saw Gavin say we needed help with testing in a Reddit AMA a while ago. I'm curious where I can make the best impact. Any feedback would be appreciated. Thanks! Will Bickford In Google We Trust -- 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=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
On Tue, Jun 24, 2014 at 10:21:46AM -0400, Jeff Garzik wrote: On Tue, Jun 24, 2014 at 9:27 AM, Mike Hearn m...@plan99.net wrote: Wallets would then be able to persist this data to disk and compete on cool visualisations for how much money you saved over time. heh, this is a cool idea. It also seems like it would be subject to instant inflation, as it's unprovable, and a rational economic actor may choose to exaggerate such numbers. It also seems collectively rational by some points of view for all bitcoin actors to inflate this number. Rather than offering discounts, how about offering automatic cashback? I know they're kinda stupid, but I gather cashback deals are very commonplace in the US and (probably as a result) not unheard of elsewhere. So you add an optional cashback_to field to the Payment message, distinct from but conceptually similar to the refund_to field. The wallet can tally up how much cashback is received, without having to trust the merchants. Much harder to game, AFAICS. roy -- 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] moving the default display to mbtc
the SI prefixes. People *do* use 63k USD, $63k, and $3M. I'll be the first one As a counter argument, many sources (including the BBC) abbreviate million to 'm' (and billion to 'bn'), e.g. $3m, $3bn. I think any similarity with SI units here is coincidental. roy -- 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] BIP70 implementation guidance
*Extended validation certs* When a business is accepting payment, showing the name of the business is usually better than showing just the domain name, for a few reasons: 1. Unless your domain name *is* your business name like blockchain.info, it looks better and gives more info. 2. Domain names are more phishable than EV names, e.g. is the right name bitpay.com or bit-pay.com or bitpay.co.uk? 3. More important: Someone who hacks your web server or DNS provider can silently get themselves a domain name SSL cert issued, probably without you noticing. Certificate transparency will eventually fix that but it's years away from full deployment. It's much harder for a hacker to get a bogus EV cert issued to them because there's a lot more checking involved. EV certs still have the domain name in the CN field, but they also have the business name in the OU field. Well, many certs have something in the O field. That has nothing to do with EV - EV just mandates a particular set of validation requirements. In theory we are supposed to have extra code to check that a certificate really was subject to extended validation before showing the contents of this field. In practice either bitcoinj nor Bitcoin Core actually do, they just always trust it. It'd be nice to fix that in future. I agree that blindly showing the O field may not be ideal - there *may* conceivably be some CAs that include it without validation on their cheap certs (although most cheap certs simply don't include it). But it's not clear that EV or not is the right criterion here - there are certainly non-EV certs out there that are organisation validated. You should show the organisation data instead of the domain name if you find it, for EV certs. I have really mixed feelings about giving this privileged treatment exclusively to EV certs, for the simple reason that the rules around EV certs are iniquitous and some businesses are excluded. e.g. in the UK sole traders (that is, unincorporated businesses) can't get EV certs because the UK doesn't maintain a trade register of such businesses and therefore such businesses are incapable of satisfying the EV rules. That said, EV certs are here, now, and (sadly) supporting them is better than doing nothing... roy -- 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] Warning message when running wallet in Windows XP (or drop support?)
On Wed, Apr 16, 2014 at 05:20:41PM +0200, Pieter Wuille wrote: On Wed, Apr 16, 2014 at 5:12 PM, Kevin kevinsisco61...@gmail.com wrote: I think we should get to the bottom of this. Should we assume that xp is not secure enough? Yes. Do we need a similar warning for OS X 10.6? The EOL of that one is *far* less well known than XP (because of Apple's failure to communicate product lifecycles). roy What is this warning? Windows XP is no longer maintained. Don't use such a system for protecting your money. Who is issuing this warning? Microsoft: http://windows.microsoft.com/en-us/windows/end-support-help The suggestion here is to make Bitcoin Core detect when it's running on Windows XP, and warn the user (they are likely unaware of the risks). -- Pieter -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
On Fri, Mar 28, 2014 at 09:56:57PM +0100, Andreas Schildbach wrote: On 03/28/2014 07:19 PM, Mike Hearn wrote: Ok, why don't fix this in the spec for now, by defining a fixed expiry time. In the EU, most products are covered by a 2 years warranty, so it seems appropriate to pick 2.5 years (30 months) -- allowing for some time to ship the product back and forth. Yeah I was thinking something like that on the walk home. But 2 years is a long time. Do we have enough RAM for that? It depends on usage stats, script size, etc... Plus warranties usually result in the defective goods being replaced rather than a monetary refund, right? Usually yes. The next smaller unit of time in Germany would be two weeks, the so-called Fernabsatzgesetz. It allows you to send back mail-orders and usually you want the money back. Don't know if that made it into EU law or how it applies to other countries. It's EU law, but the Distance Selling Directive only says at least seven days, so the exact period probably varies by country (in the UK it is 7 days). But the clock only starts ticking when you receive the goods, and the Distance Selling Directive allows the supplier 30 days to execute the order (I *think* the 30 days always has to include shipping, because for consumer contracts title doesn't pass until the goods are delivered, so the order wouldn't be considered complete until then). So I think latest possible deadline for returning the goods for refund could be up to 30 days to execute the order plus at least 7 days (with some countries allowing more). Plus, conceivably, shipping time, if some member states have chosen to interpret the 30 day execution differently. So I think this adds up to a couple of months, give or take. In practice, though, even a couple of months is a bit on the short time. What if the goods are delayed. How many people have had miner orders outstanding for the best part of a year? roy -- ___ 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
Right now there are also people simply taking base58-encoded private keys and running them through -split. It has a lot going for it, since it can easily be reassembled on any Linux machine without special software (B Poettering's Linux command line implementation[1] seems to be included in most Linux distros). roy [1] http://point-at-infinity.org// On Sat, Mar 29, 2014 at 12:59:19PM -0400, Alan Reiner wrote: 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 -- ___ 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 Sat, Mar 29, 2014 at 01:42:01PM -0400, Matt Whitlock wrote: On Saturday, 29 March 2014, at 5:28 pm, Roy Badami wrote: Right now there are also people simply taking base58-encoded private keys and running them through -split. It has a lot going for it, since it can easily be reassembled on any Linux machine without special software (B Poettering's Linux command line implementation[1] seems to be included in most Linux distros). roy [1] http://point-at-infinity.org// Respectfully, it's also possible to take a base58-encoded private key and run it through GPG, which is included in most Linux distros. But yet we have BIP38. And yet, how many wallets can import BIP38 keys? If someone gave me one I would have no idea what software (if any) can understand it (nor would I have any idea how to generate one in the first place). Anyway, I'm not arguing against standardising these things - if people are going to implement this then of course it's beneficial that they implement it compatibly. It was just a simple observation - make of it what you will. roy -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
On Fri, Mar 21, 2014 at 12:02:44AM +0100, Mike Hearn wrote: It's not unusual, in a face-to-face transaction at a bricks-and-mortar establishment, that you know neither the legal name of the entity running the establishment I'd hope that people can get certs for their actual business name, but sometimes it does differ yes. The actual example I was thinking of is that of traditional British pubs. Often a company will own several pubs - however the pubs themselves will typically have individual traditional pub names. The name of the company might not be at all prominently advertised in the pubs. Traders at music festivals are another example that comes to mind (they often accept credit cards if they sell higher value items so why not Bitcoin?) In this example there often are no clearly advertised business names - at least, that the customer will be aware of. roy -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
On Thu, Mar 20, 2014 at 07:31:27PM +0100, Mike Hearn wrote: Yes, this overlaps somewhat with the PKI signing in BIP70, but not entirely - you might want to serve unsigned payment requests, but still have confidentiality and authenticity for a local face to face transaction. The signing and encryption does different things I'm not sure if this what you're getting at, but in a common face-to-face scenario, it really doesn't overlap so much (in that the PKI in BIP70 isn't really helpful). It's not unusual, in a face-to-face transaction at a bricks-and-mortar establishment, that you know neither the legal name of the entity running the establishment, nor any electronic identifier (domain name, email address) that might be presented to you in an X.509 certificate, even if such a certificate is presented in the PaymentRequest. In many cases I want/need to simply be assured that I am paying the person/organisation which operates that machine behind the counter, right there. In many ways I'll miss the simplicity of BIP21 QR codes for face-to-face transactions - because in this use case the payment protocol complicates (and in many cases weakens) the assurance that you really are paying the entity that prepared the QR code. roy -- 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 Fri, Mar 14, 2014 at 03:05:25PM +0100, Andreas Schildbach wrote: btw. None of Bitcoin Wallet's users complained about confusion because of the mBTC switch. In contrast, I get many mails and questions if exchange rates happen to differ by 10%. At the moment, I imagine the vast majority of Bitcoin users are familliar with SI units and know what milli- and micro- mean. I doubt that is true of the general population, though. roy -- 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] BIP70 message delivery reliability
On Thu, Jan 30, 2014 at 07:03:57PM +0700, Chuck wrote: On 1/30/2014 7:02 PM, Pieter Wuille wrote: On Thu, Jan 30, 2014 at 12:59 PM, Mike Hearn m...@plan99.net wrote: With the way it works in bitcoinj, the tx is only committed to the wallet if the server accepts the Payment message and ACKs it. So the tx would not be retried if there's a failure submitting or some kind of internal server error, and the UI would show that the payment failed. That seems straightforward and how I'd expect things to work as a user. That's one right way to do it imho, but not what is suggested or required by the specification, and not what bitcoin core master currently implements. If you sent the Payment message and the server goes silent after receiving it, you retry to delivery. However, the merchant can broadcast the transactions and force them into your wallet anyway. You could, quite likely, pay and never get an ACK. I think in that case, you absolultely have to invalidate all the transactions in the Payment message by broadcasting a send-to-self transaction as soon as possible; until that point your wallet balance is indeterminate. Otherwise what will happen if the merchant did in fact receive the Payment message, and then processes it (and broadcasts the transaction) after some delay? Then what the user will see is: an apparently failed attempt to pay, leaving their wallet balance unchanged. Then, perhaps many hours later, their wallet balance will appear to spontaneously decrement. roy -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
On Mon, Jan 27, 2014 at 09:11:08AM -0800, Jeremy Spilman wrote: On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach andr...@schildbach.de wrote: SCAN TO PAY For scan-to-pay, the current landscape looks different. I assume at least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded into a QR-code. Nevertheless, I tried to encode a payment request into the bitcoin URL. I used my existing work on encoding transactions into QR-codes. Steps to encode: Really interesting work. When using scan-to-pay, after the payer scans the QR code with the protobuf PaymentRequest (not a URL to download the PaymentRequest) are they using their own connectivity to submit the Payment response? If we assume connectivity on the phone, might as well just get a URL from the QR code and re-use existing infrastructure for serving that? My first thought was likewise. In the case where the phone needs Internet connectivity anyway, why not include an HTTPS URL in a BIP 72 URL? I'm assuming that every client will have to support this is any case, since it's effectively mandated by the BIP, so why add another mode of operation? However, PaymentRequest-over-QR-code does seem to me to have one rather attractive advantage: the authentication model is orders of magnitude simpler and more intuitive for a face-to-face transaction than anything else. You're saying pay the coins to that thing over there displaying that QR code. Which, most of the time, is exactly what you want. In the web case, it's fine to ignore the case where the URL domain has been subverted (and an cert obtained by the attacker) because in that case you've lost before you even get to payments (MitM attacker shows you a modified web page with different payment details). But the face-to-face case isn't intrinsically dependent on SSL security, and it's nice not to introduce that attack vector... roy -- 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] Stealth Addresses
On Wed, Jan 15, 2014 at 11:17:33PM +, I wrote: How about just calling them 'type S addresses'? (Assuming they're encoded in such as way that they actually start with 's'. Otherwise whatever prefix is actually used, obviously.) -- 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] Stealth Addresses
On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote: Signing a payment request for an individual is easy, anyway, depending on the kind of ID you want. If you want to sign with an email address, just go here with a browser like Chrome/Safari/IE that uses the system keystore: http://www.comodo.com/home/email-security/free-email-certificate.php Having now read that page, I'll just leave you with the first bullet point from it: * Digital signature ensures confidentiality (I'm not trying to make any particular point here - I just couldn't resist) roy -- 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] Stealth Addresses
I was thinking that people could upload a payment protocol file somewhere once (like to their personal web page, or shared via dropbox or google drive or some custom new pastebin style service), and then just encode a regular bitcoin URI into the qrcode on the billboard. That does require trusting the third party not to later tamper with the payment request, though. (I'm assuming that a signed payment request is not always going to be all that useful in the case of private individuals, even assuming the payee is willing to sign up for one.) Likewise, I could attach a payment request to an email and send it to you, and now you can pay me whenever you want forever. That certainly sounds like a plausible use case. You do still have the problem that e-mail is an insecure channel, but it's no worse than exchanging Bitcoin addreses over e-mail as things stand at the moment. roy -- 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] Stealth Addresses
Likewise, I could attach a payment request to an email and send it to you, and now you can pay me whenever you want forever. That certainly sounds like a plausible use case. You do still have the problem that e-mail is an insecure channel, but it's no worse than exchanging Bitcoin addreses over e-mail as things stand at the moment. On further reflection, I'm not sure I understand this use case of the payment protocol. Since a PaymentRequest currently contains the Outputs that specify the addresses to send to, reusing a PaymentRequest like this without using stealth addresses implies address reuse. (Granted there are alternative solutions to stealth addresses, such as a BIP32-style derivation.) roy -- 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] Stealth Addresses
On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote: Signing a payment request for an individual is easy, anyway, depending on the kind of ID you want. If you want to sign with an email address, just go here with a browser like Chrome/Safari/IE that uses the system keystore: http://www.comodo.com/home/email-security/free-email-certificate.php Ok, cool, I wasn't aware of such services, and I can certainly see they could be useful. But it's not that great for the business card scenario. As far as I can see, using it in that scenario would have to rely on the payer scanning the QR code on the business card, and then check that the email address displayed by their wallet matched the email address printed on the business card. roy -- 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] 0.8.6 release candidate 1
On Mon, Dec 09, 2013 at 02:55:02PM +, Drak wrote: On 9 December 2013 13:52, Roy Badami r...@gnomon.org.uk wrote: On Mon, Dec 09, 2013 at 01:39:51PM +, Drak wrote: Someone needs to update the bitcoin.org website, it still points downloads to 0.8.5 Perhaps because 0.8.6 hasn't been released yet? Or did I miss the announcement? I think it makes sense that release candidates are not promoted on bitcoin.org. It was released and it's all over bitcointalk/reddit Oh, I see - so it was. It wasn't announced here though - is there some other list I need to be on, too? It would be nice if announcements like this were posted to a mailing list as well as bitcointalk.org (is there a bitcoin-announce list that I missed? If not, maybe there should be) roy -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
But the reality is that in many applications you need to provide a single URL. Consider existing point-of-sale systems that display QR codes for the user to scan. They live within the limitations of existing bitcoin URLs, but would no doubt benefit from the payments protocol. It's not realistic for the terminal operator in a retail establishment to have to select which protocol will be used before generating the QR code - so the effect of your proposal is to require lowest common denominator and effectively prevent such systems from using the payments protocol (at least until it is sufficiently ubiquitous that they feel happy to simply require its use). roy On Wed, Aug 07, 2013 at 11:54:44PM +0200, Pieter Wuille wrote: I see payment URIs rather as a replacement for bitcoin: URI rather than an extension. It solves everything they did in a much cleaner way, Given that bitcoin: have gotten some traction, we probably want to reuse the moniker, but replace the rest entirely. In other words, if a request is specified, nothing else should be. There is just no useful way to combine them either - payments generalize destinations to arbitrary scripts, messages are handled inline, amounts are defined inline. And if you want to rely on the payment infrastructure to work, you cannot risk people using the old-style static address in the URI. On Wed, Aug 7, 2013 at 11:47 PM, Roy Badami r...@gnomon.org.uk wrote: Very brief comment on BIP 72: I wonder if there should be some discussion included in the specification as to how the BIP 21 amount, message and label parameters should be processed when the payment protocol is used. Presumably amount should be completely ignored? But is the total amount requestd by the PaymentRequest required to match the amount parameter (when present)? Is the client permitted to complain if they don't? And what about message? Presumably the memo from PaymentDetails should take precedence, but if it's not present, and message is? I think this is an area perhaps more suited to SHOULDs and MAYs rather than MUSTs, but it is probably worthy of mention... roy -- 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 -- 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] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks
Sure they are paying themselves, but given bitcoin network difficulty is uso high, simply obtaining payments-go-myself-as-miner transactions is itself difficult. Not for pool operators it isn't. Nor for people buying hashing power from a GPUMAX-type service, if such services still exist (or should they exist again in future). -- 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] bitcoin pull requests
The attack Schneier is talking about is a collision attack (i.e. it creates two messages with the same hash, but you don't get to choose either of the messages). It's not a second preimage attack, which is what you would need to be able to create a message that hashes to the same value of an existing message. (And it neither have anything to do with the birthday paradox, BTW - which relates to the chance of eventually finding two messages that hash to the same value by pure change) If someone gets malicious code into the repo, it's going to be by social engineering, not by breaking the cyrpto. roy On Tue, Apr 02, 2013 at 12:27:51AM +0200, Melvin Carvalho wrote: On 2 April 2013 00:10, Will w...@phase.net wrote: The threat of a SHA1 collision attack to insert a malicious pull request are tiny compared with the other threats - e.g. github being compromised, one of the core developers' passwords being compromised, one of the core developers going rogue, sourceforge (distribution site) being compromised etc etc... believe me there's a lot more to worry about than a SHA1 attack... Not meaning to scare, just to put things in perspective - this is why we all need to peer review each others commits and keep an eye out for suspicious commits, leverage the benefits of this project being open source and easily peer reviewed. Very good points, and I think you're absolutely right. But just running the numbers, to get the picture, based of scheiner's statistics: http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html We're talking about a million terrahashes = 2^60 right? With the block chain, you only have a 10 minute window, but with source code you have a longer time to prepare. Couldnt this be done with an ASIC in about a week? Will On 1 April 2013 23:52, Melvin Carvalho melvincarva...@gmail.com wrote: On 1 April 2013 20:28, Petr Praus p...@praus.net wrote: An attacker would have to find a collision between two specific pieces of code - his malicious code and a useful innoculous code that would be accepted as pull request. This is the second, much harder case in the birthday problem. When people talk about SHA-1 being broken they actually mean the first case in the birthday problem - find any two arbitrary values that hash to the same value. So, no I don't think it's a feasible attack vector any time soon. Besides, with that kind of hashing power, it might be more feasible to cause problems in the chain by e.g. constantly splitting it. OK, maybe im being *way* too paranoid here ... but what if someone had access to github, could they replace one file with one they had prepared at some point? On 1 April 2013 03:26, Melvin Carvalho melvincarva...@gmail.com wrote: I was just looking at: https://bitcointalk.org/index.php?topic=4571.0 I'm just curious if there is a possible attack vector here based on the fact that git uses the relatively week SHA1 Could a seemingly innocuous pull request generate another file with a backdoor/nonce combination that slips under the radar? Apologies if this has come up before ... -- Own the Future-Intelreg; Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Own the Future-Intelreg; Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Own the Future-Intelreg; Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoin pull requests
And the moment I hit send I realised it's not necessarily true. Conceivably, a collision attack might help you craft two commits (one good, one bad) with the same hash. But I still maintain what I just posted is true: if someone gets malicious code into the repo, it's going to be by social engineering, not by breaking the cyrpto. roy On Mon, Apr 01, 2013 at 11:51:07PM +0100, Roy Badami wrote: The attack Schneier is talking about is a collision attack (i.e. it creates two messages with the same hash, but you don't get to choose either of the messages). It's not a second preimage attack, which is what you would need to be able to create a message that hashes to the same value of an existing message. (And it neither have anything to do with the birthday paradox, BTW - which relates to the chance of eventually finding two messages that hash to the same value by pure change) If someone gets malicious code into the repo, it's going to be by social engineering, not by breaking the cyrpto. roy On Tue, Apr 02, 2013 at 12:27:51AM +0200, Melvin Carvalho wrote: On 2 April 2013 00:10, Will w...@phase.net wrote: The threat of a SHA1 collision attack to insert a malicious pull request are tiny compared with the other threats - e.g. github being compromised, one of the core developers' passwords being compromised, one of the core developers going rogue, sourceforge (distribution site) being compromised etc etc... believe me there's a lot more to worry about than a SHA1 attack... Not meaning to scare, just to put things in perspective - this is why we all need to peer review each others commits and keep an eye out for suspicious commits, leverage the benefits of this project being open source and easily peer reviewed. Very good points, and I think you're absolutely right. But just running the numbers, to get the picture, based of scheiner's statistics: http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html We're talking about a million terrahashes = 2^60 right? With the block chain, you only have a 10 minute window, but with source code you have a longer time to prepare. Couldnt this be done with an ASIC in about a week? Will On 1 April 2013 23:52, Melvin Carvalho melvincarva...@gmail.com wrote: On 1 April 2013 20:28, Petr Praus p...@praus.net wrote: An attacker would have to find a collision between two specific pieces of code - his malicious code and a useful innoculous code that would be accepted as pull request. This is the second, much harder case in the birthday problem. When people talk about SHA-1 being broken they actually mean the first case in the birthday problem - find any two arbitrary values that hash to the same value. So, no I don't think it's a feasible attack vector any time soon. Besides, with that kind of hashing power, it might be more feasible to cause problems in the chain by e.g. constantly splitting it. OK, maybe im being *way* too paranoid here ... but what if someone had access to github, could they replace one file with one they had prepared at some point? On 1 April 2013 03:26, Melvin Carvalho melvincarva...@gmail.com wrote: I was just looking at: https://bitcointalk.org/index.php?topic=4571.0 I'm just curious if there is a possible attack vector here based on the fact that git uses the relatively week SHA1 Could a seemingly innocuous pull request generate another file with a backdoor/nonce combination that slips under the radar? Apologies if this has come up before ... -- Own the Future-Intelreg; Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Own the Future-Intelreg; Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Key retirement and key compromise
On Mon, Mar 25, 2013 at 02:10:53PM -0700, Gregory Maxwell wrote: On Mon, Mar 25, 2013 at 1:49 PM, Roy Badami r...@gnomon.org.uk wrote: I'm not envisaging something as drastic as changing the rules to make transactions to revoked addresses invalid - just an overlay protocol. Although to be useful such a protocol would have to be pretty much universally implemented by clients. That is quite drastic enough, as it requires adding more perpetual data that must remain in fast lookup for all validating nodes (the set of revoked 'addresses'). Maybe it should be possible for addresses to contain expiry dates, so that revocation lists don't need to hang around forever. Keep in mind that this is only improvement for what is a usually inadvisable usage of Bitcoin to begin with... you should not be reusing addresses. It may be inadvisable but in many cases it is pretty much unavoidable as Bitcoin stands today. Granted, the payment protocol will help with that in many use cases... roy -- Own the Future-Intelreg; Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocksize and off-chain transactions
On Wed, Mar 13, 2013 at 07:28:06PM +0100, Pieter Wuille wrote: IMHO, the way to go is first get a 0.8.1 out that mimics the old behaviour - just as a stopgap solution. Presumably not emulate too precisely, at least if your initial report that the block caused 0.7 to 'get stuck' was correct. A network that has a mix of 0.8.1 nodes (which will reject the block) and 0.7 nodes (which will hang when receiving the block?) would appear to remove the fork risk. Is it obvious that no other serious problems remain in such a network? (Although I note your proposal to patch 0.7 too, so hopefully the network wouldn't remain in that state for very long) roy -- 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 ideas
On Wed, Mar 13, 2013 at 09:14:03PM +, Luke-Jr wrote: On Wednesday, March 13, 2013 9:06:44 PM Andy Parkins wrote: On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote: Here's a simple proposal to start discussion from... It seems to me that the biggest failure was not the development of two chains, but the assurance to users (by the client) that their transactions were confirmed. These are both the same thing. The idea of the client detecting/warning about not-trivial forking seems worthwhile too, though, assuming it doesn't already (AIUI it doesn't). I don't know if there's any automatic monitoring for forks, but if not I would assume that the core devs and/or Bitcoin Foundation would be planning to put some in place. But there's no reason I can see why end users clients should't be warning of such situations, too, when they can (obviously they won't always be aware of the fork). roy -- 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 ideas
On Wed, Mar 13, 2013 at 02:27:01PM -0700, Gregory Maxwell wrote: On Wed, Mar 13, 2013 at 2:22 PM, Roy Badami r...@gnomon.org.uk wrote: The idea of the client detecting/warning about not-trivial forking seems worthwhile too, though, assuming it doesn't already (AIUI it doesn't). It does warn??? if its heard the fork and its on the lower difficulty side. Extending that to also alert if its on the winning side and the fork is long enough might be wise, though I have a little concern that it'll be mistaken to be more dependable than it would be. Still, it would have meant that all 0.8 users would have immediatley been told that something was wrong. I don't know to what extent it was luck that this was dealt with as promptly and efficiently as it was, but to the extent that luck was involved, a slew of 0.8 users shouting in various places wtf is going on couldn't but help in reducing the element of luck if something similar were to happen again. roy -- 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] Warning: many 0.7 nodes break on large number of tx/block; fork risk
clients are anyway keeping, and re-relaying, their own transactions and hence it would mean only little, and only little for clients. Not all end-user clients are always-on though -- 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] Secure download
Would be nice to have a secure page at bitcoin.org, though, rathar than having to go to github - certs from somewhere like Namecheap should cost you next to nothing. And Namecheap now accept Bitcoin :-) (Complete coincidence - I didn't know that when I posted) roy -- 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_feb ___ 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 Mon, Dec 03, 2012 at 10:28:13PM +0100, Mike Hearn wrote: Witness the absurd design of SMTP that means you can't start a paragraph with the word From because that's a new-message marker! Actually that has absolutely nothing to do with SMTP. It's down to the file format of the standard BSD UNIX mailbox (which uses lines beginning with 'From ' to delimit messages). roy -- 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] Payment Protocol Proposal: Invoices/Payments/Receipts
On Mon, Dec 03, 2012 at 05:34:12PM -0500, Jeff Garzik wrote: You shouldn't need to escape and unescape data that is not being interpreted in any way. Funilly enough pretty much all low-level links that make up the Internet use either bit-stuffing or byte-stuffing to escape a particular bit sequence or byte that terminates an HDLC frame. I'm not particularly agreeing or disagreeing with you on the suitability for the case at hand, but as an absolute your statement doesn't hold water. The use of a terminator for a variable-length data structure rather than a length prefix is a design desicion that has little-to-nothing to do with the debate of text-versus-binary. Anyone remember Holerith constants? roy -- 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] Payment Protocol Proposal: Invoices/Payments/Receipts
I'd still like to understand the rationale for having the merchant broadcast the transaction - it seems to add complexity and create edge cases. How about this as an alternative proposal: The buyer's client prepares the transaction and computes its txid. It then sends a ValidatePurchase message to the merchant containing the proposed Outputs and a copy of the merchant_data along with the txid. Assuming the proposed payment is accepted as valid by the merchant, the buyer's client simply broadcasts the pre-prepared transaction in the normal way, and it is the merchant's responsibility to watch for this transaction to arrive over the p2p network/blockchain to complete the purchase. (So if the merchant rejects the purchase at the ValidatePurchase stage, they never get to see the transaction that the buyer prepared, and there's therefore no need for a send-to-self to cancel it.) An optional RequestReceipt message (perhaps containing the merchant_data and txid) can be sent by the client after the transaction has been broadcast - but by making this explicitly optional it forces the merchant to rely on seeing the bitcoin transaction to 'commit' the payment and not on the RequestReceipt message. As far as I can see this proposal has no edge cases where the buyer and merchant have differing ideas as to whether the transaction has 'comitted' - or at least, no more edge cases than the standard bitcoin protocol has. roy -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ 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, Nov 29, 2012 at 06:31:24PM +0100, Mike Hearn wrote: I'd still like to understand the rationale for having the merchant broadcast the transaction There are several reasons for this: [snip] All good reasons, thanks for the explanation. Though I still like my idea of a ValidatePurchase message that allows a buyer to ask a merchant would you accept this payment? without actually supplying a signed transaction. Make it optional if you care about minimising the number of round trips, e.g. for fast NFC payments. Having such a message reduces the extent to which you need to trust the merchant not to spend a transaction that they've rejected. (And in the non-Internet connected case this is particularly useful since the client won't have the ability to broadcast a pay-to-self transaction.) roy -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
