[Bitcoin-development] Post-0.7.1 tree freeze for ultraprune
Proposal: following 0.7.1 release, freeze the tree. Do not pull anything, until ultraprune is pulled (or rejected, but I think the latter is unlikely). Common sense exceptions still apply (critical bug fixes, etc.) Ultraprune does not need to be "perfect" to be pulled... this pull would occur at the beginning of 0.8, leaving lots of room for hammering out final details in-tree. The main hurdle is really getting everyone to ACK the overall design and direction of the ultraprune branch, especially Gavin. Collecting those high-level design ACKs is more important to bitcoin overall than even fine-grained code review; code mistakes can be fixed in-tree during 0.8 development, once we all agree this is the correct _design_. The real code mistakes and "sharp edges" will only be found now with wide field testing. For the record: yes, Design-ACK from me. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Electrum security model concerns
> I tried in IRC and got no response. These messages are copying the > only contact email address I could find. Forum private message may work better. > I think this is very hard because this matter is rapidly politicized. > There are some in the community who will instantly allege misconduct > when there is a mis-agreement. Yeah, but that's only an issue if it ends up being an intractable disagreement between the people who are reviewing changes to the core site. The clients page itself was contentious but we still arrived at something reasonably professional looking and moved on. > discussion here... instead of, e.g. starting the process to remove it > from the bitcoin.org clients page. I don't think it should be removed. At most the description should be updated to point to a discussion of the tradeoffs of that class of apps (same for BitcoinSpinner). -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Electrum security model concerns
On Wed, Oct 10, 2012 at 7:19 AM, Mike Hearn wrote: > +gary > >> Electrum also has a daemon for merchants. > > Well, I suggest taking it up with Thomas directly. A thread here won't do > much. I tried in IRC and got no response. These messages are copying the only contact email address I could find. > I thought it used SSL. Maybe I'm thinking of BCCAPI which is a similar > approach. Yes, so do a lot of people. It doesn't. > I think communicating transaction confidence to users is something of > an open UI design problem right now. I agree that hiding it entirely > seems suboptimal, but in reality explaining what the risks are for a There is a middle ground: You can not hide it without explaining it. AFAICT we don't see ~any questions about the reference client waiting for six confirmations before saying confirmed. > given number confirmations is difficult. Given the lack of actually > reported double-spends against unconfirmed transactions, I can > understand this choice, even if I wouldn't recommend it. There have been a great many circulated on the network. People don't report all losses— e.g. we've never seen a report from those who've burned hundreds of bitcoins in fees on transactions. > of the security models involved. It may be worth adding one-liners > that link to a page explaining different security models (full, SPV, > superlight). Perhaps. > One thing I'm really hoping we can find and get agreement on is > somebody clueful and trustworthy to work on the bitcoin.org website. I think this is very hard because this matter is rapidly politicized. There are some in the community who will instantly allege misconduct when there is a mis-agreement. Basically: No one sane should want the job, and anyone who wants should on no account be allowed to have it. At this point I think we also will get better results communicating among technical people in order to get the development focus adjusted in a way that mitigates those risks that can be mitigated and those cautions that can be offered offered. After all, if the Electrum project is _unwilling_ to disclose the limitations of their implementation and security model on their own site, even after having them pointed out then someone updating Bitcoin.org to include them will be politically contentious. I want to make sure that we've followed all reasonable avenues before going that route— first I attempted informally on IRC, now I've brought the discussion here... instead of, e.g. starting the process to remove it from the bitcoin.org clients page. > Bitcoin, the project, needs a stronger voice than it currently has, > partly to speak about such issues. For instance, an FAQ that isn't on I agree, thats why I started this thread. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Electrum security model concerns
Just to chime in on the MultiBit Merchant aspect. The architecture is that MBM is a Java backend, but executes as a simple command line: java -jar mbm.jar server config.yml As Mike expects, MBM offers a RESTful API using HAL+JSON. It provides a comprehensive set of order and invoice processing, accounting, inventory/delivery management and customer account handling facilities for use with a wide variety of online business models. There will be a variety of front ends, one of which is an online shop. They also have the same startup command structure. Since most folks are shy of using any technology, it is likely that MBM+ will be offered as part of a SaaS type solution. This allows anyone who doesn't have the knowledge to configure it for themselves to make use of it. MBM will use BitcoinJ and will depend on a bucket of public keys for transactions until the HD support is in place to allow generation of public keys without private keys being present. This removes the need for private keys to be present on the servers, and allows consumers of the SaaS model to provide their own transaction keys. The code is released under MIT license so anyone, anywhere can use it to build the Bitcoin economy. More info: https://github.com/gary-rowe/MultiBitMerchant/wiki/Introduction http://gary-rowe.com/agilestack/2012/06/06/multibit-merchant-genesis/ On 10 October 2012 12:19, Mike Hearn wrote: > +gary > > > Electrum also has a daemon for merchants. > > Well, I suggest taking it up with Thomas directly. A thread here won't do > much. > > > Considering the dislike of > > Java that exist reflexively in much of the non-java community and the > > greater ease of deployment and the integration of type-2 split key > > management > > I'm hoping that MultiBit Merchant will provide something similar based > on bcj, ie, you don't have to actually be a Java developer to use it, > it can just talk to your app via POSTs and GETs. > > WRT deterministic wallets, yes, right now that's indeed a competitive > advantage of Electrum. So much code to write, so little time. > > > Generally for thin clients— a lying server can make clients think > > they've received confirmed payments they haven't, and unless the > > client is constructed to be a bit less thin a lying server can lie > > about input values and cause thin clients to spend large values to > > fees. > > Yes indeed. This also gives [hacked] server operators a way to steal > money from users without private keys, they can get clients to create > some very high fee transactions and then provide them directly to a > miner who promises to cut them in (or they can mine themselves, of > course). > > > Beyond that the protocol between the clients and servers is > > unauthenticated cleartext JSON in TCP. > > I thought it used SSL. Maybe I'm thinking of BCCAPI which is a similar > approach. > > > that the payment is unconfirmed. There is a "pro" mode, that shows > > 'processing' for unconfirmed transactions > > I think communicating transaction confidence to users is something of > an open UI design problem right now. I agree that hiding it entirely > seems suboptimal, but in reality explaining what the risks are for a > given number confirmations is difficult. Given the lack of actually > reported double-spends against unconfirmed transactions, I can > understand this choice, even if I wouldn't recommend it. > > > My only question is will they know this because we as a community and > > the authors of the thin clients provided clear explanations and > > appropriate caution > > Well, I pushed for English-text explanations of clients on bitcoin.org > rather than a feature matrix, for this kind of reason :) Unfortunately > the current texts are too small to really give a detailed explanation > of the security models involved. It may be worth adding one-liners > that link to a page explaining different security models (full, SPV, > superlight). > > One thing I'm really hoping we can find and get agreement on is > somebody clueful and trustworthy to work on the bitcoin.org website. > Bitcoin, the project, needs a stronger voice than it currently has, > partly to speak about such issues. For instance, an FAQ that isn't on > the wiki would be good. And a simple "Welcome to Bitcoin" flow on the > bitcoin.org website that guides people to appropriate clients, teaches > them the security basics, etc, would be excellent. > -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Electrum security model concerns
+gary > Electrum also has a daemon for merchants. Well, I suggest taking it up with Thomas directly. A thread here won't do much. > Considering the dislike of > Java that exist reflexively in much of the non-java community and the > greater ease of deployment and the integration of type-2 split key > management I'm hoping that MultiBit Merchant will provide something similar based on bcj, ie, you don't have to actually be a Java developer to use it, it can just talk to your app via POSTs and GETs. WRT deterministic wallets, yes, right now that's indeed a competitive advantage of Electrum. So much code to write, so little time. > Generally for thin clients— a lying server can make clients think > they've received confirmed payments they haven't, and unless the > client is constructed to be a bit less thin a lying server can lie > about input values and cause thin clients to spend large values to > fees. Yes indeed. This also gives [hacked] server operators a way to steal money from users without private keys, they can get clients to create some very high fee transactions and then provide them directly to a miner who promises to cut them in (or they can mine themselves, of course). > Beyond that the protocol between the clients and servers is > unauthenticated cleartext JSON in TCP. I thought it used SSL. Maybe I'm thinking of BCCAPI which is a similar approach. > that the payment is unconfirmed. There is a "pro" mode, that shows > 'processing' for unconfirmed transactions I think communicating transaction confidence to users is something of an open UI design problem right now. I agree that hiding it entirely seems suboptimal, but in reality explaining what the risks are for a given number confirmations is difficult. Given the lack of actually reported double-spends against unconfirmed transactions, I can understand this choice, even if I wouldn't recommend it. > My only question is will they know this because we as a community and > the authors of the thin clients provided clear explanations and > appropriate caution Well, I pushed for English-text explanations of clients on bitcoin.org rather than a feature matrix, for this kind of reason :) Unfortunately the current texts are too small to really give a detailed explanation of the security models involved. It may be worth adding one-liners that link to a page explaining different security models (full, SPV, superlight). One thing I'm really hoping we can find and get agreement on is somebody clueful and trustworthy to work on the bitcoin.org website. Bitcoin, the project, needs a stronger voice than it currently has, partly to speak about such issues. For instance, an FAQ that isn't on the wiki would be good. And a simple "Welcome to Bitcoin" flow on the bitcoin.org website that guides people to appropriate clients, teaches them the security basics, etc, would be excellent. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Long stalling periods
Hi. I've removed by blockchain information and started redownloading it, on a fast connection, using the latest git version (tagged v0.7.1rc1), on a SSD disk. Everything goes very fast, except that a lot of duplicate blocks are processed. New blocks arrive quickly, then a lot of duplicates seem to be processed at a much quieter pace, while the chain height does not increase anymore. Is that expected? Isn't there a way to limit unneeded blocks downloads? SetBestChain: new best=a664b1f5 height=114310 work=2478070628744107557 date=03/20/11 22:08:47 ProcessBlock: ACCEPTED received block 64fbb040 SetBestChain: new best=64fbb040 height=114311 work=2478397878545837400 date=03/20/11 22:12:52 ProcessBlock: ACCEPTED received block 6c7d5cf8 SetBestChain: new best=6c7d5cf8 height=114312 work=2478725128347567243 date=03/20/11 22:14:27 ProcessBlock: ACCEPTED received block 9d72b51c SetBestChain: new best=9d72b51c height=114313 work=2479052378149297086 date=03/20/11 22:50:22 ProcessBlock: ACCEPTED received block 14d91e7f SetBestChain: new best=14d91e7f height=114314 work=2479379627951026929 date=03/20/11 23:15:37 ProcessBlock: ACCEPTED received block 034002cb SetBestChain: new best=034002cb height=114315 work=2479706877752756772 date=03/20/11 23:24:47 ProcessBlock: ACCEPTED received block 32c97ae9 SetBestChain: new best=32c97ae9 height=114316 work=2480034127554486615 date=03/20/11 23:28:03 ProcessBlock: ACCEPTED received block 55503e82 SetBestChain: new best=55503e82 height=114317 work=2480361377356216458 date=03/20/11 23:36:16 SetBestChain: new best=b7ce72e8 height=114318 work=2480688627157946301 date=03/20/11 23:37:44 SetBestChain: new best=76788899 height=114319 work=2481015876959676144 date=03/20/11 23:46:41 SetBestChain: new best=d04ffc5a height=114320 work=2481343126761405987 date=03/20/11 23:55:28 SetBestChain: new best=514f0116 height=114321 work=2481670376563135830 date=03/21/11 00:02:01 SetBestChain: new best=22f1d1a0 height=114322 work=2481997626364865673 date=03/21/11 00:08:11 SetBestChain: new best=370e907e height=114323 work=2482324876166595516 date=03/21/11 00:18:39 SetBestChain: new best=dab36141 height=114324 work=2482652125968325359 date=03/21/11 00:27:57 SetBestChain: new best=9f9401c1 height=114325 work=2482979375770055202 date=03/21/11 00:31:44 SetBestChain: new best=0e774dae height=114326 work=2483306625571785045 date=03/21/11 00:48:00 SetBestChain: new best=b751fde0 height=114327 work=2483633875373514888 date=03/21/11 00:55:10 SetBestChain: new best=b377b247 height=114328 work=2483961125175244731 date=03/21/11 01:03:44 SetBestChain: new best=8a324822 height=114329 work=2484288374976974574 date=03/21/11 01:13:59 SetBestChain: new best=4270b478 height=114330 work=2484615624778704417 date=03/21/11 02:19:15 SetBestChain: new best=6b3f7c56 height=114331 work=2484942874580434260 date=03/21/11 02:47:57 SetBestChain: new best=9bc3a829 height=114332 work=2485270124382164103 date=03/21/11 02:55:29 SetBestChain: new best=308b5ad5 height=114333 work=2485597374183893946 date=03/21/11 02:55:44 SetBestChain: new best=7637ea6e height=114334 work=2485924623985623789 date=03/21/11 03:10:04 SetBestChain: new best=0006acb7 height=114335 work=2486251873787353632 date=03/21/11 03:20:49 SetBestChain: new best=ab316f00 height=114336 work=2486579123589083475 date=03/21/11 03:43:16 SetBestChain: new best=5e87ca89 height=114337 work=2486906373390813318 date=03/21/11 03:44:37 SetBestChain: new best=adbb9bf5 height=114338 work=2487233623192543161 date=03/21/11 03:50:07 SetBestChain: new best=97ccfcf2 height=114339 work=2487560872994273004 date=03/21/11 04:02:14 SetBestChain: new best=0ab6f760 height=114340 work=2487888122796002847 date=03/21/11 04:04:52 SetBestChain: new best=99fc0aab height=114341 work=2488215372597732690 date=03/21/11 04:11:18 SetBestChain: new best=38f85ffc height=114342 work=2488542622399462533 date=03/21/11 04:21:02 SetBestChain: new best=8cf7ad33 height=114343 work=2488869872201192376 date=03/21/11 04:32:41 SetBestChain: new best=26f435ba height=114344 work=2489197122002922219 date=03/21/11 04:40:07 SetBestChain: new best=a234fe35 height=114345 work=2489524371804652062 date=03/21/11 05:04:04 SetBestChain: new best=8f808957 height=114346 work=2489851621606381905 date=03/21/11 05:06:09 SetBestChain: new best=bb884dcb height=114347 work=2490178871408111748 date=03/21/11 05:11:53 SetBestChain: new be
