* [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org @ 2013-06-27 17:10 Jim 2013-06-27 17:30 ` Jeff Garzik 2013-06-27 17:56 ` Gregory Maxwell 0 siblings, 2 replies; 47+ messages in thread From: Jim @ 2013-06-27 17:10 UTC (permalink / raw) To: bitcoin-development Hello Everybody, Over the last few months we have been steadily adding functionality to MultiBit including: + encrypted wallets + sign and verify message + stability improvements and bug fixes. As a result of these efforts I think MultiBit is now suitable for the entry level Bitcoin user. I propose that we put MultiBit as the default desktop client on the bitcoin.org "Choose your wallet" page. I think a typical new user comes to bitcoin.org from a google search or a Bitcoin news article. We want them to peruse the bitcoin.org site and try out a wallet. They should be able to get MultiBit up and running in a tea break. Then perhaps they get a colleague to send them some bitcoin from an Android phone by zapping a QR code. We say: "Welcome to the Bitcoin economy !" There is plenty MultiBit cannot do of course. However if in the first ten minutes we get the new user interested there is a good chance they will go on to explore other Bitcoin wallets and solutions. Let me know if you think this is a good idea (or not!) and if you have any questions. Jim https://multibit.org ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-27 17:10 [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org Jim @ 2013-06-27 17:30 ` Jeff Garzik 2013-06-27 18:04 ` Luke-Jr 2013-06-28 9:10 ` Mike Hearn 2013-06-27 17:56 ` Gregory Maxwell 1 sibling, 2 replies; 47+ messages in thread From: Jeff Garzik @ 2013-06-27 17:30 UTC (permalink / raw) To: Jim; +Cc: bitcoin-development On Thu, Jun 27, 2013 at 1:10 PM, Jim <jim618@fastmail•co.uk> wrote: > Hello Everybody, > > Over the last few months we have been steadily adding > functionality to MultiBit including: > + encrypted wallets > + sign and verify message > + stability improvements and bug fixes. > > As a result of these efforts I think MultiBit is now > suitable for the entry level Bitcoin user. I propose > that we put MultiBit as the default desktop client > on the bitcoin.org "Choose your wallet" page. > > I think a typical new user comes to bitcoin.org from a > google search or a Bitcoin news article. We want them to > peruse the bitcoin.org site and try out a wallet. They > should be able to get MultiBit up and running in a tea break. > Then perhaps they get a colleague to send them some bitcoin > from an Android phone by zapping a QR code. This is definitely a great discussion to have. Here are some initial, unprioritized thoughts. As an engineer, there is never a clear answer, but a balance of costs and benefits. Arguments in favor of moving away from Bitcoin-Qt/bitcoind for wallet services: * Bitcoin-Qt is admittedly a very simple wallet. I see it's core strengths more as a "P2P router" for the public blockchain data. * Wallet feature innovation moves more slowly than Armory/bitcoinj/blockchain.info. * Requires the full blockchain, which is resource-intensive versus SPV. Arguments in favor of retaining Bitcoin-Qt/bitcoind default: * More field experience, code review and testing on desktop than others * Very real possibility of an overall net reduction of full nodes on P2P network Arguments in favor of multibit default: * Good user interface, perhaps more friendly for entry level users as you describe * Based on bitcoinj, which has field experience and a very large installed base thanks to Bitcoin Wallet/Schildbach Arguments against multibit default: * Less testing, field experience on desktop I'm sure others can come up with a few more. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-27 17:30 ` Jeff Garzik @ 2013-06-27 18:04 ` Luke-Jr 2013-06-27 18:41 ` Gregory Maxwell 2013-06-28 9:10 ` Mike Hearn 1 sibling, 1 reply; 47+ messages in thread From: Luke-Jr @ 2013-06-27 18:04 UTC (permalink / raw) To: bitcoin-development On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: > * Very real possibility of an overall net reduction of full nodes on P2P > network Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or MultiBit node. :/ Jim, will MultiBit be adding p2p listening support? > I'm sure others can come up with a few more. Possibly against: Does MultiBit still promote Bitcoin misunderstandings with misinformation like "from" addresses? (my apologies if I am remembering a different client) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-27 18:04 ` Luke-Jr @ 2013-06-27 18:41 ` Gregory Maxwell 2013-06-27 19:18 ` Jim 2013-06-28 10:59 ` John Dillon 0 siblings, 2 replies; 47+ messages in thread From: Gregory Maxwell @ 2013-06-27 18:41 UTC (permalink / raw) To: Luke-Jr; +Cc: bitcoin-development On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr <luke@dashjr•org> wrote: > On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: >> * Very real possibility of an overall net reduction of full nodes on P2P >> network > Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or > MultiBit node. :/ > Jim, will MultiBit be adding p2p listening support? Without validation listening isn't currently very useful. :( Maybe it could be somewhat more with some protocol additions. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-27 18:41 ` Gregory Maxwell @ 2013-06-27 19:18 ` Jim 2013-06-27 19:40 ` Jim 2013-06-27 21:12 ` Alex Kravets 2013-06-28 10:59 ` John Dillon 1 sibling, 2 replies; 47+ messages in thread From: Jim @ 2013-06-27 19:18 UTC (permalink / raw) To: bitcoin-development A few replies, in order of point raised: Jeff: Arguments against multibit default: * Less testing, field experience on desktop Yes this is true - downloads of multibit have typically been around 1/7th to 1/5th of bitcoin-QT downloads. It helps of course that the bitcoinj networking/ object model is also used by Andreas as you note. Greg: I think Mike has squashed the deadlocking problems with reentrant locks (primarily in the Wallet). I haven't seen one in at least a month. We discussed proxy support on the bitcoinj mailing list a while ago and at the time the stumbling block was the Java library used for the networking (Netty) did not support it. Mike or Miron would know better than I if this is still the case. Change address behaviour will improve significantly when HD wallet support goes into multibit/ bitcoinj (I am hoping to get my bit done over the summer). Matija Mazi has been working on a Java impl of HD wallets so it is coming down the pipe but there is a lot to do yet. Connections out from MultiBit are: + 4 bitcoind nodes on port 8333 + multibit.org (188.138.113.201) for help, current version info (and probably more in future) + the currency ticker will make HTTP gets to the source of whichever exchange(s) you have set up e.g MtGox, CampBX. This calls should disappear if you switch the currency conversion and ticker off. I think that is all the connections out I make. Mainly due to the exchanges abruptly changing their APIs and breaking things we are planning to put in intermediate "Exchange Data Provider" servers. Tim Molter is working on this in his XChange project. That will enable us to patch the server when things change and the multibits in the field won't be affected. There will probably be a couple of these initially for redundancy. Alex: Yes I think most users migrate to blockchain.info or, more recently coinbase.com. They are both good wallets but I'd like to keep Bitcoin as P2P as possible. Luke-Jr I think you are right here on the number of full nodes versus SPV nodes. I don't think we even know yet what are the working ratios of full nodes to SPV nodes. I haven't seen anybody do any analysis on this. I doubt multibit will ever participate in the Bitcoin network other than as an SPV client. All the optimisation is to reduce data traffic - it is effectively a mobile wallet that happens to live on a desktop. It is not really intended to be more than "a wallet for regular people to store and spend their bitcoin". In English the nomenclature for direction of the transactions is: "Sent to" and "Received with". To be honest I haven't transliterated the localisation files to check other language packs but the localisers are pretty good in my experience. On Thu, Jun 27, 2013, at 07:41 PM, Gregory Maxwell wrote: > On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr <luke@dashjr•org> wrote: > > On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: > >> * Very real possibility of an overall net reduction of full nodes on P2P > >> network > > Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or > > MultiBit node. :/ > > Jim, will MultiBit be adding p2p listening support? > > Without validation listening isn't currently very useful. :( Maybe it > could be somewhat more with some protocol additions. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- https://multibit.org Money, reinvented ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-27 19:18 ` Jim @ 2013-06-27 19:40 ` Jim 2013-06-27 19:50 ` Jim 2013-06-27 21:12 ` Alex Kravets 1 sibling, 1 reply; 47+ messages in thread From: Jim @ 2013-06-27 19:40 UTC (permalink / raw) To: bitcoin-development RE: 141.101.113.245 http://whois.domaintools.com/141.101.113.245 gives it as CloudFlare - I suspect it is protecting Mt Gox when we make our get for currency ticker info. On Thu, Jun 27, 2013, at 08:18 PM, Jim wrote: > A few replies, in order of point raised: > > Jeff: > Arguments against multibit default: > * Less testing, field experience on desktop > > Yes this is true - downloads of multibit have typically been around > 1/7th to 1/5th of bitcoin-QT downloads. It helps of course that > the bitcoinj networking/ object model is also used by Andreas > as you note. > > > Greg: > I think Mike has squashed the deadlocking problems with reentrant > locks (primarily in the Wallet). I haven't seen one in at least a month. > > We discussed proxy support on the bitcoinj mailing list a while ago > and at the time the stumbling block was the Java library used for > the networking (Netty) did not support it. Mike or Miron would > know better than I if this is still the case. > > Change address behaviour will improve significantly when HD > wallet support goes into multibit/ bitcoinj (I am hoping to get my > bit done over the summer). Matija Mazi has been working on a > Java impl of HD wallets so it is coming down the pipe but > there is a lot to do yet. > > Connections out from MultiBit are: > + 4 bitcoind nodes on port 8333 > + multibit.org (188.138.113.201) for help, current version info > (and probably more in future) > + the currency ticker will make HTTP gets to the source of > whichever exchange(s) you have set up e.g MtGox, CampBX. > This calls should disappear if you switch the currency conversion > and ticker off. > > I think that is all the connections out I make. > > Mainly due to the exchanges abruptly changing their APIs and > breaking things we are planning to put in intermediate > "Exchange Data Provider" servers. Tim Molter is working on this > in his XChange project. That will enable us to patch the server > when things change and the multibits in the field won't be > affected. There will probably be a couple of these initially > for redundancy. > > Alex: Yes I think most users migrate to blockchain.info or, > more recently coinbase.com. They are both good wallets > but I'd like to keep Bitcoin as P2P as possible. > > Luke-Jr > I think you are right here on the number of full nodes versus > SPV nodes. > I don't think we even know yet what are the working ratios of > full nodes to SPV nodes. I haven't seen anybody do any > analysis on this. > > I doubt multibit will ever participate in the Bitcoin network > other than as an SPV client. All the optimisation is to reduce > data traffic - it is effectively a mobile wallet that happens to > live on a desktop. It is not really intended to be more than > "a wallet for regular people to store and spend their bitcoin". > > In English the nomenclature for direction of the transactions > is: "Sent to" and "Received with". To be honest I > haven't transliterated the localisation files to check other > language packs but the localisers are pretty good in my > experience. > > > > > > On Thu, Jun 27, 2013, at 07:41 PM, Gregory Maxwell wrote: > > On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr <luke@dashjr•org> wrote: > > > On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: > > >> * Very real possibility of an overall net reduction of full nodes on P2P > > >> network > > > Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or > > > MultiBit node. :/ > > > Jim, will MultiBit be adding p2p listening support? > > > > Without validation listening isn't currently very useful. :( Maybe it > > could be somewhat more with some protocol additions. > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > -- > https://multibit.org Money, reinvented > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- https://multibit.org Money, reinvented ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-27 19:40 ` Jim @ 2013-06-27 19:50 ` Jim 0 siblings, 0 replies; 47+ messages in thread From: Jim @ 2013-06-27 19:50 UTC (permalink / raw) To: bitcoin-development I missed Greg's point on confirmations. It is definitely a challenge to explain/ visualize both: + has the transaction propagated the network ? and + it it confirmed/ buried in a block ? when those words probably don't mean much to the intended audience. The transaction status icons I *think* do it (explained here: https://multibit.org/en/help/v0.5/help_transactions.html). It basically boils down to: 1) triangle or square : bad. 2) filling circle : good 3) tick mark : great. On Thu, Jun 27, 2013, at 08:40 PM, Jim wrote: > RE: 141.101.113.245 > > http://whois.domaintools.com/141.101.113.245 > gives it as CloudFlare - I suspect it is protecting > Mt Gox when we make our get for currency ticker info. > > > On Thu, Jun 27, 2013, at 08:18 PM, Jim wrote: > > A few replies, in order of point raised: > > > > Jeff: > > Arguments against multibit default: > > * Less testing, field experience on desktop > > > > Yes this is true - downloads of multibit have typically been around > > 1/7th to 1/5th of bitcoin-QT downloads. It helps of course that > > the bitcoinj networking/ object model is also used by Andreas > > as you note. > > > > > > Greg: > > I think Mike has squashed the deadlocking problems with reentrant > > locks (primarily in the Wallet). I haven't seen one in at least a month. > > > > We discussed proxy support on the bitcoinj mailing list a while ago > > and at the time the stumbling block was the Java library used for > > the networking (Netty) did not support it. Mike or Miron would > > know better than I if this is still the case. > > > > Change address behaviour will improve significantly when HD > > wallet support goes into multibit/ bitcoinj (I am hoping to get my > > bit done over the summer). Matija Mazi has been working on a > > Java impl of HD wallets so it is coming down the pipe but > > there is a lot to do yet. > > > > Connections out from MultiBit are: > > + 4 bitcoind nodes on port 8333 > > + multibit.org (188.138.113.201) for help, current version info > > (and probably more in future) > > + the currency ticker will make HTTP gets to the source of > > whichever exchange(s) you have set up e.g MtGox, CampBX. > > This calls should disappear if you switch the currency conversion > > and ticker off. > > > > I think that is all the connections out I make. > > > > Mainly due to the exchanges abruptly changing their APIs and > > breaking things we are planning to put in intermediate > > "Exchange Data Provider" servers. Tim Molter is working on this > > in his XChange project. That will enable us to patch the server > > when things change and the multibits in the field won't be > > affected. There will probably be a couple of these initially > > for redundancy. > > > > Alex: Yes I think most users migrate to blockchain.info or, > > more recently coinbase.com. They are both good wallets > > but I'd like to keep Bitcoin as P2P as possible. > > > > Luke-Jr > > I think you are right here on the number of full nodes versus > > SPV nodes. > > I don't think we even know yet what are the working ratios of > > full nodes to SPV nodes. I haven't seen anybody do any > > analysis on this. > > > > I doubt multibit will ever participate in the Bitcoin network > > other than as an SPV client. All the optimisation is to reduce > > data traffic - it is effectively a mobile wallet that happens to > > live on a desktop. It is not really intended to be more than > > "a wallet for regular people to store and spend their bitcoin". > > > > In English the nomenclature for direction of the transactions > > is: "Sent to" and "Received with". To be honest I > > haven't transliterated the localisation files to check other > > language packs but the localisers are pretty good in my > > experience. > > > > > > > > > > > > On Thu, Jun 27, 2013, at 07:41 PM, Gregory Maxwell wrote: > > > On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr <luke@dashjr•org> wrote: > > > > On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: > > > >> * Very real possibility of an overall net reduction of full nodes on P2P > > > >> network > > > > Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or > > > > MultiBit node. :/ > > > > Jim, will MultiBit be adding p2p listening support? > > > > > > Without validation listening isn't currently very useful. :( Maybe it > > > could be somewhat more with some protocol additions. > > > > > > ------------------------------------------------------------------------------ > > > This SF.net email is sponsored by Windows: > > > > > > Build for Windows Store. > > > > > > http://p.sf.net/sfu/windows-dev2dev > > > _______________________________________________ > > > Bitcoin-development mailing list > > > Bitcoin-development@lists•sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > -- > > https://multibit.org Money, reinvented > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > -- > https://multibit.org Money, reinvented > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- https://multibit.org Money, reinvented ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-27 19:18 ` Jim 2013-06-27 19:40 ` Jim @ 2013-06-27 21:12 ` Alex Kravets 2013-06-27 21:56 ` Jeff Garzik 2013-06-27 22:03 ` Gary Rowe 1 sibling, 2 replies; 47+ messages in thread From: Alex Kravets @ 2013-06-27 21:12 UTC (permalink / raw) To: Jim; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 3845 bytes --] Hi Jim, On Thu, Jun 27, 2013 at 12:18 PM, Jim <jim618@fastmail•co.uk> wrote: > > Alex: Yes I think most users migrate to blockchain.info or, > more recently coinbase.com. They are both good wallets > but I'd like to keep Bitcoin as P2P as possible. > Guys, being a late comer/outsider (I got into bitcoin in early 2012), I can tell you that this particular asylum is definitely run by its inmates. What all the nerdy devs (and I am one so I know) seem unable to comprehend, is that regular people out there don't wanna learn all this new stuff and new terminology they simply have no attention span for it. Simply channelling them to a decent client that 1. Just works (no blockchain downloads and no re-sync) 2. Allows to retain control of the private keys Would be HUGE for mass adoption. Old tired argument about "Bitcoin needs your nodes", so we'll channel you to get bitcoin-qt client is both manipulative and unnecessary (there's plenty of nodes and NAT'ed home nodes which don't mine are mostly useless anyways) P.S. coinbase.com is just another trust-me setup takes your coins in exchange for IOUs, whereas blockchain.info does let you to retain control of your private keys. P.P.S. The reason why coinbase has gotten so big is precisely because they don't trouble regular lawyers and doctors with all the nonsense but simply give them a "buy" and a "sell" button. > Luke-Jr > I think you are right here on the number of full nodes versus > SPV nodes. > I don't think we even know yet what are the working ratios of > full nodes to SPV nodes. I haven't seen anybody do any > analysis on this. > > I doubt multibit will ever participate in the Bitcoin network > other than as an SPV client. All the optimisation is to reduce > data traffic - it is effectively a mobile wallet that happens to > live on a desktop. It is not really intended to be more than > "a wallet for regular people to store and spend their bitcoin". > > In English the nomenclature for direction of the transactions > is: "Sent to" and "Received with". To be honest I > haven't transliterated the localisation files to check other > language packs but the localisers are pretty good in my > experience. > > > > > > On Thu, Jun 27, 2013, at 07:41 PM, Gregory Maxwell wrote: > > On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr <luke@dashjr•org> wrote: > > > On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: > > >> * Very real possibility of an overall net reduction of full nodes on > P2P > > >> network > > > Even a reduction of *nodes at all*, as I've never seen a listening > bitcoinj or > > > MultiBit node. :/ > > > Jim, will MultiBit be adding p2p listening support? > > > > Without validation listening isn't currently very useful. :( Maybe it > > could be somewhat more with some protocol additions. > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > -- > https://multibit.org Money, reinvented > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Alex Kravets <http://www.linkedin.com/in/akravets> def redPill = ' Scala <http://www.scala-lang.org/> [[ brutal honesty <http://goo.gl/vwydt> is the best policy ]] [-- Attachment #2: Type: text/html, Size: 5923 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-27 21:12 ` Alex Kravets @ 2013-06-27 21:56 ` Jeff Garzik 2013-06-27 22:53 ` Alex Kravets 2013-06-27 22:03 ` Gary Rowe 1 sibling, 1 reply; 47+ messages in thread From: Jeff Garzik @ 2013-06-27 21:56 UTC (permalink / raw) To: Alex Kravets; +Cc: bitcoin-development On Thu, Jun 27, 2013 at 5:12 PM, Alex Kravets <kravets@gmail•com> wrote: > What all the nerdy devs (and I am one so I know) seem unable to comprehend, > is that regular people out there don't wanna learn all this new stuff and > new terminology they simply have no attention span for it. Bitcoin Wallet for Android is a decentralized client w/ network sync, and it works just fine. Fast, easy to use. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-27 21:56 ` Jeff Garzik @ 2013-06-27 22:53 ` Alex Kravets 0 siblings, 0 replies; 47+ messages in thread From: Alex Kravets @ 2013-06-27 22:53 UTC (permalink / raw) To: Jeff Garzik; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 930 bytes --] Perhaps there should be two different sections on the web page. Nerds / Non-Nerds With different recommendations for which clients to use. On Thu, Jun 27, 2013 at 2:56 PM, Jeff Garzik <jgarzik@bitpay•com> wrote: > On Thu, Jun 27, 2013 at 5:12 PM, Alex Kravets <kravets@gmail•com> wrote: > > What all the nerdy devs (and I am one so I know) seem unable to > comprehend, > > is that regular people out there don't wanna learn all this new stuff and > > new terminology they simply have no attention span for it. > > Bitcoin Wallet for Android is a decentralized client w/ network sync, > and it works just fine. Fast, easy to use. > > -- > Jeff Garzik > Senior Software Engineer and open source evangelist > BitPay, Inc. https://bitpay.com/ > -- Alex Kravets <http://www.linkedin.com/in/akravets> def redPill = ' Scala <http://www.scala-lang.org/> [[ brutal honesty <http://goo.gl/vwydt> is the best policy ]] [-- Attachment #2: Type: text/html, Size: 1698 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-27 21:12 ` Alex Kravets 2013-06-27 21:56 ` Jeff Garzik @ 2013-06-27 22:03 ` Gary Rowe 1 sibling, 0 replies; 47+ messages in thread From: Gary Rowe @ 2013-06-27 22:03 UTC (permalink / raw) To: Bitcoin Development List [-- Attachment #1: Type: text/plain, Size: 4964 bytes --] Many people that I have introduced Bitcoin to have balked at the massive blockchain download. When I showed them MultiBit (and Bitcoin Wallet) they breathed a sigh of relief and got on with it. A currency lives or dies by network effects. If we can provide the average low-tech user with a great client experience right from the word go then we can win them over quickly. Once that is accomplished then more techie users will likely go on to use a full node which will continue to strengthen the network overall. On 27 June 2013 22:12, Alex Kravets <kravets@gmail•com> wrote: > Hi Jim, > > On Thu, Jun 27, 2013 at 12:18 PM, Jim <jim618@fastmail•co.uk> wrote: > >> >> Alex: Yes I think most users migrate to blockchain.info or, >> more recently coinbase.com. They are both good wallets >> but I'd like to keep Bitcoin as P2P as possible. >> > > Guys, being a late comer/outsider (I got into bitcoin in early 2012), I > can tell you that this particular asylum is definitely run by its inmates. > > What all the nerdy devs (and I am one so I know) seem unable to > comprehend, is that regular people out there don't wanna learn all this new > stuff and new terminology they simply have no attention span for it. > > Simply channelling them to a decent client that > > 1. Just works (no blockchain downloads and no re-sync) > 2. Allows to retain control of the private keys > > Would be HUGE for mass adoption. > > Old tired argument about "Bitcoin needs your nodes", so we'll channel you > to get bitcoin-qt client is both manipulative and unnecessary (there's > plenty of nodes and NAT'ed home nodes which don't mine are mostly useless > anyways) > > P.S. coinbase.com is just another trust-me setup takes your coins in > exchange for IOUs, whereas blockchain.info does let you to retain control > of your private keys. > > P.P.S. The reason why coinbase has gotten so big is precisely because they > don't trouble regular lawyers and doctors with all the nonsense but simply > give them a > "buy" and a "sell" button. > > > > > >> Luke-Jr >> I think you are right here on the number of full nodes versus >> SPV nodes. >> I don't think we even know yet what are the working ratios of >> full nodes to SPV nodes. I haven't seen anybody do any >> analysis on this. >> >> I doubt multibit will ever participate in the Bitcoin network >> other than as an SPV client. All the optimisation is to reduce >> data traffic - it is effectively a mobile wallet that happens to >> live on a desktop. It is not really intended to be more than >> "a wallet for regular people to store and spend their bitcoin". >> >> In English the nomenclature for direction of the transactions >> is: "Sent to" and "Received with". To be honest I >> haven't transliterated the localisation files to check other >> language packs but the localisers are pretty good in my >> experience. >> >> >> >> >> >> On Thu, Jun 27, 2013, at 07:41 PM, Gregory Maxwell wrote: >> > On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr <luke@dashjr•org> wrote: >> > > On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: >> > >> * Very real possibility of an overall net reduction of full nodes on >> P2P >> > >> network >> > > Even a reduction of *nodes at all*, as I've never seen a listening >> bitcoinj or >> > > MultiBit node. :/ >> > > Jim, will MultiBit be adding p2p listening support? >> > >> > Without validation listening isn't currently very useful. :( Maybe it >> > could be somewhat more with some protocol additions. >> > >> > >> ------------------------------------------------------------------------------ >> > This SF.net email is sponsored by Windows: >> > >> > Build for Windows Store. >> > >> > http://p.sf.net/sfu/windows-dev2dev >> > _______________________________________________ >> > Bitcoin-development mailing list >> > Bitcoin-development@lists•sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> >> -- >> https://multibit.org Money, reinvented >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > > > -- > Alex Kravets <http://www.linkedin.com/in/akravets> def redPill = ' > Scala <http://www.scala-lang.org/> > [[ brutal honesty <http://goo.gl/vwydt> is the best policy ]] > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 7597 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-27 18:41 ` Gregory Maxwell 2013-06-27 19:18 ` Jim @ 2013-06-28 10:59 ` John Dillon 1 sibling, 0 replies; 47+ messages in thread From: John Dillon @ 2013-06-28 10:59 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Thu, Jun 27, 2013 at 6:41 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote: > On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr <luke@dashjr•org> wrote: >> On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: >>> * Very real possibility of an overall net reduction of full nodes on P2P >>> network >> Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or >> MultiBit node. :/ >> Jim, will MultiBit be adding p2p listening support? > > Without validation listening isn't currently very useful. :( Maybe it > could be somewhat more with some protocol additions. Possible non-validation data that can be usefully propagated: 1) Block headers. 2) *Confirmed* transactions linked to an aformentioned blockheader. 3) Proof-of-work/sacrifice limited P2P messages, for instance to co-ordinate trust-free-mixes or act as a communication channel for micropayment channels. 4) With UTXO existance proof support propagate transactions accompanied by proofs that all inputs exist. This would also allow for implementation of Peter's low-bandwidth decentralized P2Pool proposal. 5) UTXO fraud proofs. (one day) Strictly speaking #2 doesn't even need the protocol to be changed actually as it can be handled entirely within the existing INV/getdata mechanism. Sure someone could throw away a lot of hashing power and get an invalid block propagated, but really so what? SPV nodes should always take confirmations with a grain of salt anyway. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRzWx8AAoJEEWCsU4mNhiPlTkIAJKzFsT65o6LoU70hbaBsu3g aBdjYZSCnJ9+qWI2tqqUBedq2etbt71hAfWNnTXvFus+0iVB1HWJClW155319vuH Xi1m9G3O0NzX1d+cssMPxFBHsl4Rz6XYICrYyVEe2X554Zawdg6I53+1INHRfsBT 1vmq5Bxgopt0Tk9Vf8HNdRt/IXZJaPYm1PEzJHFppuOvl5+Fpypy3t/QXdsP8puP LnRdL7Bxfu3BSWrSRZo7l5Fpww3Y/vdNYCL4jDD/ME+36wi4CUM3psL8lsk81lB4 3t/ytF4y/adT/dEEtMj7BGWS0TIMMH0NyeCjqBdStiQsVfoowLCVfpuDzouZ6yY= =TI1m -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-27 17:30 ` Jeff Garzik 2013-06-27 18:04 ` Luke-Jr @ 2013-06-28 9:10 ` Mike Hearn 2013-06-28 14:24 ` Gavin Andresen 1 sibling, 1 reply; 47+ messages in thread From: Mike Hearn @ 2013-06-28 9:10 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev > Arguments in favor of retaining Bitcoin-Qt/bitcoind default: > * More field experience, code review and testing on desktop than others I'm hoping that if we start promoting alternative wallets their dev communities will get larger. Most bitcoinj code is peer reviewed, but not to the same extent that Bitcoin-Qt is. We're obviously not going to stop promoting Bitcoin-Qt as well. I think the distinction should be: * Want to get started fast? Grab MultiBit and you'll be under way in a couple of minutes. * Want to help out the Bitcoin network? Leave your computer switched on all the time and run Bitcoin-Qt instead. It will donate some of your computers resources to running the Bitcoin system. The MultiBit interface is OK but all desktop wallets could use some love from a friendly UI designer. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-28 9:10 ` Mike Hearn @ 2013-06-28 14:24 ` Gavin Andresen [not found] ` <CAFtwHRewE0wgvWsf-785hpCb8ns7wiGaKHAQ-1QmDD-W+diBJA@mail.gmail.com> 2013-06-30 11:42 ` Mike Hearn 0 siblings, 2 replies; 47+ messages in thread From: Gavin Andresen @ 2013-06-28 14:24 UTC (permalink / raw) To: Bitcoin Dev I vote "yes" to have MultiBit replace Bitcoin-Qt as the recommended desktop wallet app. I think most users will be happier with it. If I'm wrong, it is easy to change back. ^ permalink raw reply [flat|nested] 47+ messages in thread
[parent not found: <CAFtwHRewE0wgvWsf-785hpCb8ns7wiGaKHAQ-1QmDD-W+diBJA@mail.gmail.com>]
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org [not found] ` <CAFtwHRewE0wgvWsf-785hpCb8ns7wiGaKHAQ-1QmDD-W+diBJA@mail.gmail.com> @ 2013-06-28 20:37 ` Bill Hees 2013-06-28 20:42 ` Jim 0 siblings, 1 reply; 47+ messages in thread From: Bill Hees @ 2013-06-28 20:37 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1587 bytes --] There are good, valid arguments in support of promoting both the reference client, Bitcoin-QT, and for offering a lighter-weight alternative. Why not outline these arguments on bitcoin.org and provide links to each; or even links to a variety of alternative wallet solutions alongside descriptions of their respective benefits and drawbacks? Is there an advantage to having a singular "recommended" client? On Fri, Jun 28, 2013 at 1:35 PM, Bill Hees <billhees@gmail•com> wrote: > There are good, valid arguments in support of promoting both the reference > client, Bitcoin-QT, and for offering a lighter-weight alternative. Why not > outline these arguments on bitcoin.org and provide links to each; or even > links to a variety of alternative wallet solutions alongside descriptions > of their respective benefits and drawbacks? Is there an advantage to having > a singular "recommended" client? > > > On Fri, Jun 28, 2013 at 7:24 AM, Gavin Andresen <gavinandresen@gmail•com>wrote: > >> I vote "yes" to have MultiBit replace Bitcoin-Qt as the recommended >> desktop wallet app. I think most users will be happier with it. >> >> If I'm wrong, it is easy to change back. >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > [-- Attachment #2: Type: text/html, Size: 2638 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-28 20:37 ` Bill Hees @ 2013-06-28 20:42 ` Jim 0 siblings, 0 replies; 47+ messages in thread From: Jim @ 2013-06-28 20:42 UTC (permalink / raw) To: bitcoin-development There are already descriptions as you describe on: http://bitcoin.org/en/choose-your-wallet. If you hover over any of the wallet icons you get a description and a link. People being people, we find in practice that the very first wallet link on the page is what the majority of new users click. On Fri, Jun 28, 2013, at 09:37 PM, Bill Hees wrote: > There are good, valid arguments in support of promoting both the > reference > client, Bitcoin-QT, and for offering a lighter-weight alternative. Why > not > outline these arguments on bitcoin.org and provide links to each; or even > links to a variety of alternative wallet solutions alongside descriptions > of their respective benefits and drawbacks? Is there an advantage to > having > a singular "recommended" client? > > > On Fri, Jun 28, 2013 at 1:35 PM, Bill Hees <billhees@gmail•com> wrote: > > > There are good, valid arguments in support of promoting both the reference > > client, Bitcoin-QT, and for offering a lighter-weight alternative. Why not > > outline these arguments on bitcoin.org and provide links to each; or even > > links to a variety of alternative wallet solutions alongside descriptions > > of their respective benefits and drawbacks? Is there an advantage to having > > a singular "recommended" client? > > > > > > On Fri, Jun 28, 2013 at 7:24 AM, Gavin Andresen <gavinandresen@gmail•com>wrote: > > > >> I vote "yes" to have MultiBit replace Bitcoin-Qt as the recommended > >> desktop wallet app. I think most users will be happier with it. > >> > >> If I'm wrong, it is easy to change back. > >> > >> > >> ------------------------------------------------------------------------------ > >> This SF.net email is sponsored by Windows: > >> > >> Build for Windows Store. > >> > >> http://p.sf.net/sfu/windows-dev2dev > >> _______________________________________________ > >> Bitcoin-development mailing list > >> Bitcoin-development@lists•sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >> > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- https://multibit.org Money, reinvented ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-28 14:24 ` Gavin Andresen [not found] ` <CAFtwHRewE0wgvWsf-785hpCb8ns7wiGaKHAQ-1QmDD-W+diBJA@mail.gmail.com> @ 2013-06-30 11:42 ` Mike Hearn 2013-06-30 15:19 ` Jim 1 sibling, 1 reply; 47+ messages in thread From: Mike Hearn @ 2013-06-30 11:42 UTC (permalink / raw) To: Gavin Andresen, Saïvann Carignan; +Cc: Bitcoin Dev Sounds like we have consensus, Saivann, shall we do it? I'm also going to ask Theymos again to relax the newbie restrictions for the alt client forums. It's probably too hard to get support at the moment and "email jim" doesn't scale at all. On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen <gavinandresen@gmail•com> wrote: > I vote "yes" to have MultiBit replace Bitcoin-Qt as the recommended > desktop wallet app. I think most users will be happier with it. > > If I'm wrong, it is easy to change back. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-30 11:42 ` Mike Hearn @ 2013-06-30 15:19 ` Jim 2013-06-30 16:39 ` Gary Rowe 0 siblings, 1 reply; 47+ messages in thread From: Jim @ 2013-06-30 15:19 UTC (permalink / raw) To: bitcoin-development Yeah "email jim' was never going to work so I have bumped up MultiBit support (a bit) by: + having a dedicated Support page on the website https://multibit.org/support.html It has fixes and support notes for the most common gotchas. + the in-app help also now has a 'Support' section with "Troubleshooting' and the commonest gotchas. I've also written more help to cover as much as possible. + Failing that people are directed first to bitcoin.stackchange.com (I have a notification set up for the 'multibit' keyword. + Then finally users are directed to the github issues to search existing or raise a new issue. Gary and Tim often chip in on there to close issues down as well as me. On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote: > Sounds like we have consensus, Saivann, shall we do it? > > I'm also going to ask Theymos again to relax the newbie restrictions > for the alt client forums. It's probably too hard to get support at > the moment and "email jim" doesn't scale at all. > > On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen <gavinandresen@gmail•com> > wrote: > > I vote "yes" to have MultiBit replace Bitcoin-Qt as the recommended > > desktop wallet app. I think most users will be happier with it. > > > > If I'm wrong, it is easy to change back. > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- https://multibit.org Money, reinvented ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-30 15:19 ` Jim @ 2013-06-30 16:39 ` Gary Rowe 2013-07-09 0:22 ` Robert Backhaus 0 siblings, 1 reply; 47+ messages in thread From: Gary Rowe @ 2013-06-30 16:39 UTC (permalink / raw) To: Bitcoin Development List [-- Attachment #1: Type: text/plain, Size: 2953 bytes --] I've beefed up the supporting documentation for the website to make it more accessible for developers who wish to contribute. It's a Java application serving HTML. It can be found here: https://github.com/jim618/multibit-website On 30 June 2013 16:19, Jim <jim618@fastmail•co.uk> wrote: > Yeah "email jim' was never going to work so I have > bumped up MultiBit support (a bit) by: > > + having a dedicated Support page on the website > https://multibit.org/support.html > It has fixes and support notes for the most common gotchas. > + the in-app help also now has a 'Support' section with > "Troubleshooting' and the commonest gotchas. > I've also written more help to cover as much as possible. > + Failing that people are directed first to bitcoin.stackchange.com > (I have a notification set up for the 'multibit' keyword. > + Then finally users are directed to the github issues to search > existing or raise a new issue. Gary and Tim often chip in on there to > close > issues down as well as me. > > > > On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote: > > Sounds like we have consensus, Saivann, shall we do it? > > > > I'm also going to ask Theymos again to relax the newbie restrictions > > for the alt client forums. It's probably too hard to get support at > > the moment and "email jim" doesn't scale at all. > > > > On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen <gavinandresen@gmail•com > > > > wrote: > > > I vote "yes" to have MultiBit replace Bitcoin-Qt as the recommended > > > desktop wallet app. I think most users will be happier with it. > > > > > > If I'm wrong, it is easy to change back. > > > > > > > ------------------------------------------------------------------------------ > > > This SF.net email is sponsored by Windows: > > > > > > Build for Windows Store. > > > > > > http://p.sf.net/sfu/windows-dev2dev > > > _______________________________________________ > > > Bitcoin-development mailing list > > > Bitcoin-development@lists•sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > -- > https://multibit.org Money, reinvented > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 4811 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-30 16:39 ` Gary Rowe @ 2013-07-09 0:22 ` Robert Backhaus 2013-07-09 1:20 ` Caleb James DeLisle 0 siblings, 1 reply; 47+ messages in thread From: Robert Backhaus @ 2013-07-09 0:22 UTC (permalink / raw) To: Bitcoin Development List [-- Attachment #1: Type: text/plain, Size: 4034 bytes --] But... Multibit is Java. Java's security problems has made it an instant uninstall item on windows PCs for about a year now. Java exploits are a dime a dozen. Yes, you can reduce some of the problems by manually disabling the browser plugin, but how many users will do that? Recommending a fast SPV client as a first wallet - yes, of course. Recommending users open such a huge attack interface on their computers by installing Java - No go. Until Multibit is provided as a compiled binary without a Java dependency, it is DOA. On 1 July 2013 02:39, Gary Rowe <g.rowe@froot•co.uk> wrote: > I've beefed up the supporting documentation for the website to make it > more accessible for developers who wish to contribute. It's a Java > application serving HTML. > > It can be found here: https://github.com/jim618/multibit-website > > > On 30 June 2013 16:19, Jim <jim618@fastmail•co.uk> wrote: > >> Yeah "email jim' was never going to work so I have >> bumped up MultiBit support (a bit) by: >> >> + having a dedicated Support page on the website >> https://multibit.org/support.html >> It has fixes and support notes for the most common gotchas. >> + the in-app help also now has a 'Support' section with >> "Troubleshooting' and the commonest gotchas. >> I've also written more help to cover as much as possible. >> + Failing that people are directed first to bitcoin.stackchange.com >> (I have a notification set up for the 'multibit' keyword. >> + Then finally users are directed to the github issues to search >> existing or raise a new issue. Gary and Tim often chip in on there to >> close >> issues down as well as me. >> >> >> >> On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote: >> > Sounds like we have consensus, Saivann, shall we do it? >> > >> > I'm also going to ask Theymos again to relax the newbie restrictions >> > for the alt client forums. It's probably too hard to get support at >> > the moment and "email jim" doesn't scale at all. >> > >> > On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen < >> gavinandresen@gmail•com> >> > wrote: >> > > I vote "yes" to have MultiBit replace Bitcoin-Qt as the recommended >> > > desktop wallet app. I think most users will be happier with it. >> > > >> > > If I'm wrong, it is easy to change back. >> > > >> > > >> ------------------------------------------------------------------------------ >> > > This SF.net email is sponsored by Windows: >> > > >> > > Build for Windows Store. >> > > >> > > http://p.sf.net/sfu/windows-dev2dev >> > > _______________________________________________ >> > > Bitcoin-development mailing list >> > > Bitcoin-development@lists•sourceforge.net >> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > >> > >> ------------------------------------------------------------------------------ >> > This SF.net email is sponsored by Windows: >> > >> > Build for Windows Store. >> > >> > http://p.sf.net/sfu/windows-dev2dev >> > _______________________________________________ >> > Bitcoin-development mailing list >> > Bitcoin-development@lists•sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> >> -- >> https://multibit.org Money, reinvented >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 6464 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-07-09 0:22 ` Robert Backhaus @ 2013-07-09 1:20 ` Caleb James DeLisle 2013-07-09 10:36 ` Mike Hearn 0 siblings, 1 reply; 47+ messages in thread From: Caleb James DeLisle @ 2013-07-09 1:20 UTC (permalink / raw) To: bitcoin-development Java (Applet) security is indeed abysmal but lets compare apples to apples. With an applet some random guy with a website makes up some Java code and your browser automatically executes it. With Multibit you're only executing highly trusted code (so trusted that it handles your money). There has almost never been a Java exploit against secure trusted code. The idea of discouraging use of java apps just because people would be tricked into activating the browser plugin when installing the JVM is probably valid but Multibit is the only reasonably complete client outside of bitcoinqt and I think client diversity is more important than stamping out java. Thanks, Caleb On 07/08/2013 08:22 PM, Robert Backhaus wrote: > But... Multibit is Java. Java's security problems has made it an instant uninstall item on windows PCs for about a year now. Java exploits are a dime a dozen. > > Yes, you can reduce some of the problems by manually disabling the browser plugin, but how many users will do that? > > Recommending a fast SPV client as a first wallet - yes, of course. Recommending users open such a huge attack interface on their computers by installing Java - No go. Until Multibit is provided as a compiled binary without a Java dependency, it is DOA. > > > On 1 July 2013 02:39, Gary Rowe <g.rowe@froot•co.uk <mailto:g.rowe@froot•co.uk>> wrote: > > I've beefed up the supporting documentation for the website to make it more accessible for developers who wish to contribute. It's a Java application serving HTML. > > It can be found here: https://github.com/jim618/multibit-website > > > On 30 June 2013 16:19, Jim <jim618@fastmail•co.uk <mailto:jim618@fastmail•co.uk>> wrote: > > Yeah "email jim' was never going to work so I have > bumped up MultiBit support (a bit) by: > > + having a dedicated Support page on the website > https://multibit.org/support.html > It has fixes and support notes for the most common gotchas. > + the in-app help also now has a 'Support' section with > "Troubleshooting' and the commonest gotchas. > I've also written more help to cover as much as possible. > + Failing that people are directed first to bitcoin.stackchange.com <http://bitcoin.stackchange.com> > (I have a notification set up for the 'multibit' keyword. > + Then finally users are directed to the github issues to search > existing or raise a new issue. Gary and Tim often chip in on there to > close > issues down as well as me. > > > > On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote: > > Sounds like we have consensus, Saivann, shall we do it? > > > > I'm also going to ask Theymos again to relax the newbie restrictions > > for the alt client forums. It's probably too hard to get support at > > the moment and "email jim" doesn't scale at all. > > > > On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen <gavinandresen@gmail•com <mailto:gavinandresen@gmail•com>> > > wrote: > > > I vote "yes" to have MultiBit replace Bitcoin-Qt as the recommended > > > desktop wallet app. I think most users will be happier with it. > > > > > > If I'm wrong, it is easy to change back. > > > > > > ------------------------------------------------------------------------------ > > > This SF.net email is sponsored by Windows: > > > > > > Build for Windows Store. > > > > > > http://p.sf.net/sfu/windows-dev2dev > > > _______________________________________________ > > > Bitcoin-development mailing list > > > Bitcoin-development@lists•sourceforge.net <mailto:Bitcoin-development@lists•sourceforge.net> > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge.net <mailto:Bitcoin-development@lists•sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > -- > https://multibit.org Money, reinvented > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net <mailto:Bitcoin-development@lists•sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net <mailto:Bitcoin-development@lists•sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-07-09 1:20 ` Caleb James DeLisle @ 2013-07-09 10:36 ` Mike Hearn 2013-07-09 10:56 ` Jim 0 siblings, 1 reply; 47+ messages in thread From: Mike Hearn @ 2013-07-09 10:36 UTC (permalink / raw) To: Caleb James DeLisle; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 7539 bytes --] Modern Java versions let you bundle the app with a stripped down JVM. I don't know if Jim does that, but I think it's an obvious step towards making MultiBit friendlier and easier to use. BTW I believe most secure browsers (Chrome, Firefox) have banned the applet plugin or severely restrained it anyway. So even if you install the JVM and plugin together there is not an issue. On Tue, Jul 9, 2013 at 3:20 AM, Caleb James DeLisle < calebdelisle@lavabit•com> wrote: > Java (Applet) security is indeed abysmal but lets compare apples to apples. > With an applet some random guy with a website makes up some Java code and > your browser automatically executes it. > With Multibit you're only executing highly trusted code (so trusted that it > handles your money). > There has almost never been a Java exploit against secure trusted code. > > The idea of discouraging use of java apps just because people would be > tricked into activating the browser plugin when installing the JVM is > probably valid but Multibit is the only reasonably complete client outside > of bitcoinqt and I think client diversity is more important than stamping > out java. > > Thanks, > Caleb > > > On 07/08/2013 08:22 PM, Robert Backhaus wrote: > > But... Multibit is Java. Java's security problems has made it an instant > uninstall item on windows PCs for about a year now. Java exploits are a > dime a dozen. > > > > Yes, you can reduce some of the problems by manually disabling the > browser plugin, but how many users will do that? > > > > Recommending a fast SPV client as a first wallet - yes, of course. > Recommending users open such a huge attack interface on their computers by > installing Java - No go. Until Multibit is provided as a compiled binary > without a Java dependency, it is DOA. > > > > > > On 1 July 2013 02:39, Gary Rowe <g.rowe@froot•co.uk <mailto: > g.rowe@froot•co.uk>> wrote: > > > > I've beefed up the supporting documentation for the website to make > it more accessible for developers who wish to contribute. It's a Java > application serving HTML. > > > > It can be found here: https://github.com/jim618/multibit-website > > > > > > On 30 June 2013 16:19, Jim <jim618@fastmail•co.uk <mailto: > jim618@fastmail•co.uk>> wrote: > > > > Yeah "email jim' was never going to work so I have > > bumped up MultiBit support (a bit) by: > > > > + having a dedicated Support page on the website > > https://multibit.org/support.html > > It has fixes and support notes for the most common gotchas. > > + the in-app help also now has a 'Support' section with > > "Troubleshooting' and the commonest gotchas. > > I've also written more help to cover as much as possible. > > + Failing that people are directed first to > bitcoin.stackchange.com <http://bitcoin.stackchange.com> > > (I have a notification set up for the 'multibit' keyword. > > + Then finally users are directed to the github issues to search > > existing or raise a new issue. Gary and Tim often chip in on > there to > > close > > issues down as well as me. > > > > > > > > On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote: > > > Sounds like we have consensus, Saivann, shall we do it? > > > > > > I'm also going to ask Theymos again to relax the newbie > restrictions > > > for the alt client forums. It's probably too hard to get > support at > > > the moment and "email jim" doesn't scale at all. > > > > > > On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen < > gavinandresen@gmail•com <mailto:gavinandresen@gmail•com>> > > > wrote: > > > > I vote "yes" to have MultiBit replace Bitcoin-Qt as the > recommended > > > > desktop wallet app. I think most users will be happier with > it. > > > > > > > > If I'm wrong, it is easy to change back. > > > > > > > > > ------------------------------------------------------------------------------ > > > > This SF.net email is sponsored by Windows: > > > > > > > > Build for Windows Store. > > > > > > > > http://p.sf.net/sfu/windows-dev2dev > > > > _______________________________________________ > > > > Bitcoin-development mailing list > > > > Bitcoin-development@lists•sourceforge.net <mailto: > Bitcoin-development@lists•sourceforge.net> > > > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > ------------------------------------------------------------------------------ > > > This SF.net email is sponsored by Windows: > > > > > > Build for Windows Store. > > > > > > http://p.sf.net/sfu/windows-dev2dev > > > _______________________________________________ > > > Bitcoin-development mailing list > > > Bitcoin-development@lists•sourceforge.net <mailto: > Bitcoin-development@lists•sourceforge.net> > > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > -- > > https://multibit.org Money, reinvented > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge.net <mailto: > Bitcoin-development@lists•sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge.net <mailto: > Bitcoin-development@lists•sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > > > > > ------------------------------------------------------------------------------ > > See everything from the browser to the database with AppDynamics > > Get end-to-end visibility with application monitoring from AppDynamics > > Isolate bottlenecks and diagnose root cause in seconds. > > Start your free trial of AppDynamics Pro today! > > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > > > > > > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 11706 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-07-09 10:36 ` Mike Hearn @ 2013-07-09 10:56 ` Jim 2013-07-09 11:04 ` Mike Hearn 2013-07-09 14:00 ` Daniel F 0 siblings, 2 replies; 47+ messages in thread From: Jim @ 2013-07-09 10:56 UTC (permalink / raw) To: bitcoin-development Yes I would like to bundle a JVM as it would simplify the user experience. There are a few downsides though: + all the build packaging will need redoing and retesting. + it will bump up the MultiBit download from about 11MB to 30-40MB (I think). This drops the maximum copies of MultiBit the multibit.org server can deliver per day from around 90,000 to 30,000ish. The multibit.org server maxes out at 1 TB of bandwidth per day. Currently there is no provision to update anything automatically. I would like to start having Bitcoin signed files that MultiBit can check and update (initially the checkpoints file, I18N files - NOT code at first because of the security implications). I think this needs to be in place before bundling a JVM so that users don't have to keep redownloading it. Having lists of all the artifacts signed and them having SHA256 hashes then makes it practical/ safe to start mirroring the code. I can see each mirror crosschecking the others that the SHA256s are correct for instance. This would increase the maximum number of downloads we could cope with. On Tue, Jul 9, 2013, at 11:36 AM, Mike Hearn wrote: > Modern Java versions let you bundle the app with a stripped down JVM. I > don't know if Jim does that, but I think it's an obvious step towards > making MultiBit friendlier and easier to use. > > BTW I believe most secure browsers (Chrome, Firefox) have banned the > applet > plugin or severely restrained it anyway. So even if you install the JVM > and > plugin together there is not an issue. > > > On Tue, Jul 9, 2013 at 3:20 AM, Caleb James DeLisle < > calebdelisle@lavabit•com> wrote: > > > Java (Applet) security is indeed abysmal but lets compare apples to apples. > > With an applet some random guy with a website makes up some Java code and > > your browser automatically executes it. > > With Multibit you're only executing highly trusted code (so trusted that it > > handles your money). > > There has almost never been a Java exploit against secure trusted code. > > > > The idea of discouraging use of java apps just because people would be > > tricked into activating the browser plugin when installing the JVM is > > probably valid but Multibit is the only reasonably complete client outside > > of bitcoinqt and I think client diversity is more important than stamping > > out java. > > > > Thanks, > > Caleb > > > > > > On 07/08/2013 08:22 PM, Robert Backhaus wrote: > > > But... Multibit is Java. Java's security problems has made it an instant > > uninstall item on windows PCs for about a year now. Java exploits are a > > dime a dozen. > > > > > > Yes, you can reduce some of the problems by manually disabling the > > browser plugin, but how many users will do that? > > > > > > Recommending a fast SPV client as a first wallet - yes, of course. > > Recommending users open such a huge attack interface on their computers by > > installing Java - No go. Until Multibit is provided as a compiled binary > > without a Java dependency, it is DOA. > > > > > > > > > On 1 July 2013 02:39, Gary Rowe <g.rowe@froot•co.uk <mailto: > > g.rowe@froot•co.uk>> wrote: > > > > > > I've beefed up the supporting documentation for the website to make > > it more accessible for developers who wish to contribute. It's a Java > > application serving HTML. > > > > > > It can be found here: https://github.com/jim618/multibit-website > > > > > > > > > On 30 June 2013 16:19, Jim <jim618@fastmail•co.uk <mailto: > > jim618@fastmail•co.uk>> wrote: > > > > > > Yeah "email jim' was never going to work so I have > > > bumped up MultiBit support (a bit) by: > > > > > > + having a dedicated Support page on the website > > > https://multibit.org/support.html > > > It has fixes and support notes for the most common gotchas. > > > + the in-app help also now has a 'Support' section with > > > "Troubleshooting' and the commonest gotchas. > > > I've also written more help to cover as much as possible. > > > + Failing that people are directed first to > > bitcoin.stackchange.com <http://bitcoin.stackchange.com> > > > (I have a notification set up for the 'multibit' keyword. > > > + Then finally users are directed to the github issues to search > > > existing or raise a new issue. Gary and Tim often chip in on > > there to > > > close > > > issues down as well as me. > > > > > > > > > > > > On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote: > > > > Sounds like we have consensus, Saivann, shall we do it? > > > > > > > > I'm also going to ask Theymos again to relax the newbie > > restrictions > > > > for the alt client forums. It's probably too hard to get > > support at > > > > the moment and "email jim" doesn't scale at all. > > > > > > > > On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen < > > gavinandresen@gmail•com <mailto:gavinandresen@gmail•com>> > > > > wrote: > > > > > I vote "yes" to have MultiBit replace Bitcoin-Qt as the > > recommended > > > > > desktop wallet app. I think most users will be happier with > > it. > > > > > > > > > > If I'm wrong, it is easy to change back. > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > This SF.net email is sponsored by Windows: > > > > > > > > > > Build for Windows Store. > > > > > > > > > > http://p.sf.net/sfu/windows-dev2dev > > > > > _______________________________________________ > > > > > Bitcoin-development mailing list > > > > > Bitcoin-development@lists•sourceforge.net <mailto: > > Bitcoin-development@lists•sourceforge.net> > > > > > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > > > > ------------------------------------------------------------------------------ > > > > This SF.net email is sponsored by Windows: > > > > > > > > Build for Windows Store. > > > > > > > > http://p.sf.net/sfu/windows-dev2dev > > > > _______________________________________________ > > > > Bitcoin-development mailing list > > > > Bitcoin-development@lists•sourceforge.net <mailto: > > Bitcoin-development@lists•sourceforge.net> > > > > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > > > -- > > > https://multibit.org Money, reinvented > > > > > > > > ------------------------------------------------------------------------------ > > > This SF.net email is sponsored by Windows: > > > > > > Build for Windows Store. > > > > > > http://p.sf.net/sfu/windows-dev2dev > > > _______________________________________________ > > > Bitcoin-development mailing list > > > Bitcoin-development@lists•sourceforge.net <mailto: > > Bitcoin-development@lists•sourceforge.net> > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > This SF.net email is sponsored by Windows: > > > > > > Build for Windows Store. > > > > > > http://p.sf.net/sfu/windows-dev2dev > > > _______________________________________________ > > > Bitcoin-development mailing list > > > Bitcoin-development@lists•sourceforge.net <mailto: > > Bitcoin-development@lists•sourceforge.net> > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > See everything from the browser to the database with AppDynamics > > > Get end-to-end visibility with application monitoring from AppDynamics > > > Isolate bottlenecks and diagnose root cause in seconds. > > > Start your free trial of AppDynamics Pro today! > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > > > > > > > > > > > _______________________________________________ > > > Bitcoin-development mailing list > > > Bitcoin-development@lists•sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > > > > > ------------------------------------------------------------------------------ > > See everything from the browser to the database with AppDynamics > > Get end-to-end visibility with application monitoring from AppDynamics > > Isolate bottlenecks and diagnose root cause in seconds. > > Start your free trial of AppDynamics Pro today! > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- https://multibit.org Money, reinvented ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-07-09 10:56 ` Jim @ 2013-07-09 11:04 ` Mike Hearn 2013-07-09 11:13 ` Will ` (2 more replies) 2013-07-09 14:00 ` Daniel F 1 sibling, 3 replies; 47+ messages in thread From: Mike Hearn @ 2013-07-09 11:04 UTC (permalink / raw) To: Jim; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 11802 bytes --] How many downloads/day do we see currently? I think you said it's on the order of a few thousand, so nowhere near 30k I'd guess. Anyway I can mirror it if we need to. The JavaFX packager is supposed to delete parts of the JVM that aren't used. Is the 30-40mb figure based on using that tool or something else? Note that you don't need to use the JFX widget toolkit to use the bundler tool. We could also invest in a copy of JET, which does native compilation down to self contained Windows binaries. It might create smaller bundles. But, it's a proprietary tool and I don't know how reproducible its outputs are. For the auto update, is there an existing auto update framework that we can modify to support threshold signed updates? I'm sure such a thing must exist. The updates would download in the background and then the app can just ask the user to restart it once the update is locally available, as Chrome does. On Tue, Jul 9, 2013 at 12:56 PM, Jim <jim618@fastmail•co.uk> wrote: > Yes I would like to bundle a JVM as it would simplify the user > experience. > > There are a few downsides though: > + all the build packaging will need redoing and retesting. > + it will bump up the MultiBit download from about 11MB to 30-40MB > (I think). This drops the maximum copies of MultiBit the multibit.org > server can deliver per day from around 90,000 to 30,000ish. > The multibit.org server maxes out at 1 TB of bandwidth per day. > > Currently there is no provision to update anything automatically. > I would like to start having Bitcoin signed files that MultiBit can > check > and update (initially the checkpoints file, I18N files - NOT code > at first because of the security implications). I think this needs to be > in place before bundling a JVM so that users don't have to > keep redownloading it. > > Having lists of all the artifacts signed and them having SHA256 hashes > then makes it practical/ safe to start mirroring the code. I can see > each mirror crosschecking the others that the SHA256s are correct > for instance. This would increase the maximum number of > downloads we could cope with. > > > On Tue, Jul 9, 2013, at 11:36 AM, Mike Hearn wrote: > > Modern Java versions let you bundle the app with a stripped down JVM. I > > don't know if Jim does that, but I think it's an obvious step towards > > making MultiBit friendlier and easier to use. > > > > BTW I believe most secure browsers (Chrome, Firefox) have banned the > > applet > > plugin or severely restrained it anyway. So even if you install the JVM > > and > > plugin together there is not an issue. > > > > > > On Tue, Jul 9, 2013 at 3:20 AM, Caleb James DeLisle < > > calebdelisle@lavabit•com> wrote: > > > > > Java (Applet) security is indeed abysmal but lets compare apples to > apples. > > > With an applet some random guy with a website makes up some Java code > and > > > your browser automatically executes it. > > > With Multibit you're only executing highly trusted code (so trusted > that it > > > handles your money). > > > There has almost never been a Java exploit against secure trusted code. > > > > > > The idea of discouraging use of java apps just because people would be > > > tricked into activating the browser plugin when installing the JVM is > > > probably valid but Multibit is the only reasonably complete client > outside > > > of bitcoinqt and I think client diversity is more important than > stamping > > > out java. > > > > > > Thanks, > > > Caleb > > > > > > > > > On 07/08/2013 08:22 PM, Robert Backhaus wrote: > > > > But... Multibit is Java. Java's security problems has made it an > instant > > > uninstall item on windows PCs for about a year now. Java exploits are a > > > dime a dozen. > > > > > > > > Yes, you can reduce some of the problems by manually disabling the > > > browser plugin, but how many users will do that? > > > > > > > > Recommending a fast SPV client as a first wallet - yes, of course. > > > Recommending users open such a huge attack interface on their > computers by > > > installing Java - No go. Until Multibit is provided as a compiled > binary > > > without a Java dependency, it is DOA. > > > > > > > > > > > > On 1 July 2013 02:39, Gary Rowe <g.rowe@froot•co.uk <mailto: > > > g.rowe@froot•co.uk>> wrote: > > > > > > > > I've beefed up the supporting documentation for the website to > make > > > it more accessible for developers who wish to contribute. It's a Java > > > application serving HTML. > > > > > > > > It can be found here: https://github.com/jim618/multibit-website > > > > > > > > > > > > On 30 June 2013 16:19, Jim <jim618@fastmail•co.uk <mailto: > > > jim618@fastmail•co.uk>> wrote: > > > > > > > > Yeah "email jim' was never going to work so I have > > > > bumped up MultiBit support (a bit) by: > > > > > > > > + having a dedicated Support page on the website > > > > https://multibit.org/support.html > > > > It has fixes and support notes for the most common > gotchas. > > > > + the in-app help also now has a 'Support' section with > > > > "Troubleshooting' and the commonest gotchas. > > > > I've also written more help to cover as much as possible. > > > > + Failing that people are directed first to > > > bitcoin.stackchange.com <http://bitcoin.stackchange.com> > > > > (I have a notification set up for the 'multibit' keyword. > > > > + Then finally users are directed to the github issues to > search > > > > existing or raise a new issue. Gary and Tim often chip in > on > > > there to > > > > close > > > > issues down as well as me. > > > > > > > > > > > > > > > > On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote: > > > > > Sounds like we have consensus, Saivann, shall we do it? > > > > > > > > > > I'm also going to ask Theymos again to relax the newbie > > > restrictions > > > > > for the alt client forums. It's probably too hard to get > > > support at > > > > > the moment and "email jim" doesn't scale at all. > > > > > > > > > > On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen < > > > gavinandresen@gmail•com <mailto:gavinandresen@gmail•com>> > > > > > wrote: > > > > > > I vote "yes" to have MultiBit replace Bitcoin-Qt as the > > > recommended > > > > > > desktop wallet app. I think most users will be happier > with > > > it. > > > > > > > > > > > > If I'm wrong, it is easy to change back. > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > This SF.net email is sponsored by Windows: > > > > > > > > > > > > Build for Windows Store. > > > > > > > > > > > > http://p.sf.net/sfu/windows-dev2dev > > > > > > _______________________________________________ > > > > > > Bitcoin-development mailing list > > > > > > Bitcoin-development@lists•sourceforge.net <mailto: > > > Bitcoin-development@lists•sourceforge.net> > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > This SF.net email is sponsored by Windows: > > > > > > > > > > Build for Windows Store. > > > > > > > > > > http://p.sf.net/sfu/windows-dev2dev > > > > > _______________________________________________ > > > > > Bitcoin-development mailing list > > > > > Bitcoin-development@lists•sourceforge.net <mailto: > > > Bitcoin-development@lists•sourceforge.net> > > > > > > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > > > > > > -- > > > > https://multibit.org Money, reinvented > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > This SF.net email is sponsored by Windows: > > > > > > > > Build for Windows Store. > > > > > > > > http://p.sf.net/sfu/windows-dev2dev > > > > _______________________________________________ > > > > Bitcoin-development mailing list > > > > Bitcoin-development@lists•sourceforge.net <mailto: > > > Bitcoin-development@lists•sourceforge.net> > > > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > This SF.net email is sponsored by Windows: > > > > > > > > Build for Windows Store. > > > > > > > > http://p.sf.net/sfu/windows-dev2dev > > > > _______________________________________________ > > > > Bitcoin-development mailing list > > > > Bitcoin-development@lists•sourceforge.net <mailto: > > > Bitcoin-development@lists•sourceforge.net> > > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > See everything from the browser to the database with AppDynamics > > > > Get end-to-end visibility with application monitoring from > AppDynamics > > > > Isolate bottlenecks and diagnose root cause in seconds. > > > > Start your free trial of AppDynamics Pro today! > > > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > > > > > > > > > > > > > > > _______________________________________________ > > > > Bitcoin-development mailing list > > > > Bitcoin-development@lists•sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > See everything from the browser to the database with AppDynamics > > > Get end-to-end visibility with application monitoring from AppDynamics > > > Isolate bottlenecks and diagnose root cause in seconds. > > > Start your free trial of AppDynamics Pro today! > > > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > > _______________________________________________ > > > Bitcoin-development mailing list > > > Bitcoin-development@lists•sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > ------------------------------------------------------------------------------ > > See everything from the browser to the database with AppDynamics > > Get end-to-end visibility with application monitoring from AppDynamics > > Isolate bottlenecks and diagnose root cause in seconds. > > Start your free trial of AppDynamics Pro today! > > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > -- > https://multibit.org Money, reinvented > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 18021 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-07-09 11:04 ` Mike Hearn @ 2013-07-09 11:13 ` Will 2013-07-09 11:15 ` Jim 2013-07-09 11:18 ` Mike Hearn 2 siblings, 0 replies; 47+ messages in thread From: Will @ 2013-07-09 11:13 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 569 bytes --] Omaha - which is the automatic update framework that Google Chrome uses - is open sourced: https://code.google.com/p/omaha/ It might be a bit heavyweight for just one package though. Will On 9 July 2013 13:04, Mike Hearn <mike@plan99•net> wrote: > For the auto update, is there an existing auto update framework that we > can modify to support threshold signed updates? I'm sure such a thing must > exist. The updates would download in the background and then the app can > just ask the user to restart it once the update is locally available, as > Chrome does. > [-- Attachment #2: Type: text/html, Size: 1086 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-07-09 11:04 ` Mike Hearn 2013-07-09 11:13 ` Will @ 2013-07-09 11:15 ` Jim 2013-07-09 11:18 ` Mike Hearn 2 siblings, 0 replies; 47+ messages in thread From: Jim @ 2013-07-09 11:15 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev Currently there are about 2,500 downloads a day for MultiBit. There are download stats here: https://multibit.org/awstats/awstats.pl?config=multibit.org With a mirror from Mike and perhaps another instance at multibit.org that would get us to 100K per day so probably nothing to worry about. I think the highest daily download stats I have seen were in the April 2013 'boom' where Bitcoin-QT downloads hit 30K per day as I recall. The 30-40 MB including a JVM is based on the download sizes for CharlesProxy.com which does this for their Windows downloads. The sizes are here: http://www.charlesproxy.com/download/ This is a Java codebase too. Yes there must be an auto-update framework (but without ECDSA signing most likely). I haven't spent much time on this yet. On Tue, Jul 9, 2013, at 12:04 PM, Mike Hearn wrote: > How many downloads/day do we see currently? I think you said it's on the > order of a few thousand, so nowhere near 30k I'd guess. Anyway I can > mirror > it if we need to. > > The JavaFX packager is supposed to delete parts of the JVM that aren't > used. Is the 30-40mb figure based on using that tool or something else? > Note that you don't need to use the JFX widget toolkit to use the bundler > tool. > > We could also invest in a copy of JET, which does native compilation down > to self contained Windows binaries. It might create smaller bundles. But, > it's a proprietary tool and I don't know how reproducible its outputs > are. > > For the auto update, is there an existing auto update framework that we > can > modify to support threshold signed updates? I'm sure such a thing must > exist. The updates would download in the background and then the app can > just ask the user to restart it once the update is locally available, as > Chrome does. > > > > On Tue, Jul 9, 2013 at 12:56 PM, Jim <jim618@fastmail•co.uk> wrote: > > > Yes I would like to bundle a JVM as it would simplify the user > > experience. > > > > There are a few downsides though: > > + all the build packaging will need redoing and retesting. > > + it will bump up the MultiBit download from about 11MB to 30-40MB > > (I think). This drops the maximum copies of MultiBit the multibit.org > > server can deliver per day from around 90,000 to 30,000ish. > > The multibit.org server maxes out at 1 TB of bandwidth per day. > > > > Currently there is no provision to update anything automatically. > > I would like to start having Bitcoin signed files that MultiBit can > > check > > and update (initially the checkpoints file, I18N files - NOT code > > at first because of the security implications). I think this needs to be > > in place before bundling a JVM so that users don't have to > > keep redownloading it. > > > > Having lists of all the artifacts signed and them having SHA256 hashes > > then makes it practical/ safe to start mirroring the code. I can see > > each mirror crosschecking the others that the SHA256s are correct > > for instance. This would increase the maximum number of > > downloads we could cope with. > > > > > > On Tue, Jul 9, 2013, at 11:36 AM, Mike Hearn wrote: > > > Modern Java versions let you bundle the app with a stripped down JVM. I > > > don't know if Jim does that, but I think it's an obvious step towards > > > making MultiBit friendlier and easier to use. > > > > > > BTW I believe most secure browsers (Chrome, Firefox) have banned the > > > applet > > > plugin or severely restrained it anyway. So even if you install the JVM > > > and > > > plugin together there is not an issue. > > > > > > > > > On Tue, Jul 9, 2013 at 3:20 AM, Caleb James DeLisle < > > > calebdelisle@lavabit•com> wrote: > > > > > > > Java (Applet) security is indeed abysmal but lets compare apples to > > apples. > > > > With an applet some random guy with a website makes up some Java code > > and > > > > your browser automatically executes it. > > > > With Multibit you're only executing highly trusted code (so trusted > > that it > > > > handles your money). > > > > There has almost never been a Java exploit against secure trusted code. > > > > > > > > The idea of discouraging use of java apps just because people would be > > > > tricked into activating the browser plugin when installing the JVM is > > > > probably valid but Multibit is the only reasonably complete client > > outside > > > > of bitcoinqt and I think client diversity is more important than > > stamping > > > > out java. > > > > > > > > Thanks, > > > > Caleb > > > > > > > > > > > > On 07/08/2013 08:22 PM, Robert Backhaus wrote: > > > > > But... Multibit is Java. Java's security problems has made it an > > instant > > > > uninstall item on windows PCs for about a year now. Java exploits are a > > > > dime a dozen. > > > > > > > > > > Yes, you can reduce some of the problems by manually disabling the > > > > browser plugin, but how many users will do that? > > > > > > > > > > Recommending a fast SPV client as a first wallet - yes, of course. > > > > Recommending users open such a huge attack interface on their > > computers by > > > > installing Java - No go. Until Multibit is provided as a compiled > > binary > > > > without a Java dependency, it is DOA. > > > > > > > > > > > > > > > On 1 July 2013 02:39, Gary Rowe <g.rowe@froot•co.uk <mailto: > > > > g.rowe@froot•co.uk>> wrote: > > > > > > > > > > I've beefed up the supporting documentation for the website to > > make > > > > it more accessible for developers who wish to contribute. It's a Java > > > > application serving HTML. > > > > > > > > > > It can be found here: https://github.com/jim618/multibit-website > > > > > > > > > > > > > > > On 30 June 2013 16:19, Jim <jim618@fastmail•co.uk <mailto: > > > > jim618@fastmail•co.uk>> wrote: > > > > > > > > > > Yeah "email jim' was never going to work so I have > > > > > bumped up MultiBit support (a bit) by: > > > > > > > > > > + having a dedicated Support page on the website > > > > > https://multibit.org/support.html > > > > > It has fixes and support notes for the most common > > gotchas. > > > > > + the in-app help also now has a 'Support' section with > > > > > "Troubleshooting' and the commonest gotchas. > > > > > I've also written more help to cover as much as possible. > > > > > + Failing that people are directed first to > > > > bitcoin.stackchange.com <http://bitcoin.stackchange.com> > > > > > (I have a notification set up for the 'multibit' keyword. > > > > > + Then finally users are directed to the github issues to > > search > > > > > existing or raise a new issue. Gary and Tim often chip in > > on > > > > there to > > > > > close > > > > > issues down as well as me. > > > > > > > > > > > > > > > > > > > > On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote: > > > > > > Sounds like we have consensus, Saivann, shall we do it? > > > > > > > > > > > > I'm also going to ask Theymos again to relax the newbie > > > > restrictions > > > > > > for the alt client forums. It's probably too hard to get > > > > support at > > > > > > the moment and "email jim" doesn't scale at all. > > > > > > > > > > > > On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen < > > > > gavinandresen@gmail•com <mailto:gavinandresen@gmail•com>> > > > > > > wrote: > > > > > > > I vote "yes" to have MultiBit replace Bitcoin-Qt as the > > > > recommended > > > > > > > desktop wallet app. I think most users will be happier > > with > > > > it. > > > > > > > > > > > > > > If I'm wrong, it is easy to change back. > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > This SF.net email is sponsored by Windows: > > > > > > > > > > > > > > Build for Windows Store. > > > > > > > > > > > > > > http://p.sf.net/sfu/windows-dev2dev > > > > > > > _______________________________________________ > > > > > > > Bitcoin-development mailing list > > > > > > > Bitcoin-development@lists•sourceforge.net <mailto: > > > > Bitcoin-development@lists•sourceforge.net> > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > This SF.net email is sponsored by Windows: > > > > > > > > > > > > Build for Windows Store. > > > > > > > > > > > > http://p.sf.net/sfu/windows-dev2dev > > > > > > _______________________________________________ > > > > > > Bitcoin-development mailing list > > > > > > Bitcoin-development@lists•sourceforge.net <mailto: > > > > Bitcoin-development@lists•sourceforge.net> > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > > > > > > > > > -- > > > > > https://multibit.org Money, reinvented > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > This SF.net email is sponsored by Windows: > > > > > > > > > > Build for Windows Store. > > > > > > > > > > http://p.sf.net/sfu/windows-dev2dev > > > > > _______________________________________________ > > > > > Bitcoin-development mailing list > > > > > Bitcoin-development@lists•sourceforge.net <mailto: > > > > Bitcoin-development@lists•sourceforge.net> > > > > > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > This SF.net email is sponsored by Windows: > > > > > > > > > > Build for Windows Store. > > > > > > > > > > http://p.sf.net/sfu/windows-dev2dev > > > > > _______________________________________________ > > > > > Bitcoin-development mailing list > > > > > Bitcoin-development@lists•sourceforge.net <mailto: > > > > Bitcoin-development@lists•sourceforge.net> > > > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > See everything from the browser to the database with AppDynamics > > > > > Get end-to-end visibility with application monitoring from > > AppDynamics > > > > > Isolate bottlenecks and diagnose root cause in seconds. > > > > > Start your free trial of AppDynamics Pro today! > > > > > > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Bitcoin-development mailing list > > > > > Bitcoin-development@lists•sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > See everything from the browser to the database with AppDynamics > > > > Get end-to-end visibility with application monitoring from AppDynamics > > > > Isolate bottlenecks and diagnose root cause in seconds. > > > > Start your free trial of AppDynamics Pro today! > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > > > _______________________________________________ > > > > Bitcoin-development mailing list > > > > Bitcoin-development@lists•sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > > > ------------------------------------------------------------------------------ > > > See everything from the browser to the database with AppDynamics > > > Get end-to-end visibility with application monitoring from AppDynamics > > > Isolate bottlenecks and diagnose root cause in seconds. > > > Start your free trial of AppDynamics Pro today! > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > > _______________________________________________ > > > Bitcoin-development mailing list > > > Bitcoin-development@lists•sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > -- > > https://multibit.org Money, reinvented > > > > > > ------------------------------------------------------------------------------ > > See everything from the browser to the database with AppDynamics > > Get end-to-end visibility with application monitoring from AppDynamics > > Isolate bottlenecks and diagnose root cause in seconds. > > Start your free trial of AppDynamics Pro today! > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- https://multibit.org Money, reinvented ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-07-09 11:04 ` Mike Hearn 2013-07-09 11:13 ` Will 2013-07-09 11:15 ` Jim @ 2013-07-09 11:18 ` Mike Hearn 2 siblings, 0 replies; 47+ messages in thread From: Mike Hearn @ 2013-07-09 11:18 UTC (permalink / raw) To: Jim; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 13678 bytes --] By the way, the Java Web Start system has improved a lot in recent versions as well. I just tried running http://jfxtras.org/ and this was the experience: - It told me my Java was insecure and that I should download the latest version (hah). It had three buttons, one saying "Update", one saying "Block content in browser" and one saying "Later". So it seems Java learned how to disable its plugin by itself anyway. I think on non-Linux platforms it probably knows how to update itself as well these days. - As it happens I don't care right now because jfxtras is a source I trust, so I clicked later and it popped up a permission screen saying the author was unknown, could damage my computer, etc. Actually, Jim has a code signing cert so this would show his identity at that point. - Clicked run. The app downloaded in a few seconds and was running. - JavaWS keeps the app up to date for you at that point. It's triggered by downloading and opening a .jnlp file, so - same security boundaries as a regular app download, except you download metadata for the runtime instead of the whole app at once. It might be worth providing a JNLP option on the multibit webpage as well, as although I wouldn't let the applet plugin in my browser, once I made an explicit decision to go to multibit.org and trust James Burton with my money, the JWS experience at that point is pretty good. Until we have our own auto update engine it's better than nothing. On Tue, Jul 9, 2013 at 1:04 PM, Mike Hearn <mike@plan99•net> wrote: > How many downloads/day do we see currently? I think you said it's on the > order of a few thousand, so nowhere near 30k I'd guess. Anyway I can mirror > it if we need to. > > The JavaFX packager is supposed to delete parts of the JVM that aren't > used. Is the 30-40mb figure based on using that tool or something else? > Note that you don't need to use the JFX widget toolkit to use the bundler > tool. > > We could also invest in a copy of JET, which does native compilation down > to self contained Windows binaries. It might create smaller bundles. But, > it's a proprietary tool and I don't know how reproducible its outputs are. > > For the auto update, is there an existing auto update framework that we > can modify to support threshold signed updates? I'm sure such a thing must > exist. The updates would download in the background and then the app can > just ask the user to restart it once the update is locally available, as > Chrome does. > > > > On Tue, Jul 9, 2013 at 12:56 PM, Jim <jim618@fastmail•co.uk> wrote: > >> Yes I would like to bundle a JVM as it would simplify the user >> experience. >> >> There are a few downsides though: >> + all the build packaging will need redoing and retesting. >> + it will bump up the MultiBit download from about 11MB to 30-40MB >> (I think). This drops the maximum copies of MultiBit the multibit.org >> server can deliver per day from around 90,000 to 30,000ish. >> The multibit.org server maxes out at 1 TB of bandwidth per day. >> >> Currently there is no provision to update anything automatically. >> I would like to start having Bitcoin signed files that MultiBit can >> check >> and update (initially the checkpoints file, I18N files - NOT code >> at first because of the security implications). I think this needs to be >> in place before bundling a JVM so that users don't have to >> keep redownloading it. >> >> Having lists of all the artifacts signed and them having SHA256 hashes >> then makes it practical/ safe to start mirroring the code. I can see >> each mirror crosschecking the others that the SHA256s are correct >> for instance. This would increase the maximum number of >> downloads we could cope with. >> >> >> On Tue, Jul 9, 2013, at 11:36 AM, Mike Hearn wrote: >> > Modern Java versions let you bundle the app with a stripped down JVM. I >> > don't know if Jim does that, but I think it's an obvious step towards >> > making MultiBit friendlier and easier to use. >> > >> > BTW I believe most secure browsers (Chrome, Firefox) have banned the >> > applet >> > plugin or severely restrained it anyway. So even if you install the JVM >> > and >> > plugin together there is not an issue. >> > >> > >> > On Tue, Jul 9, 2013 at 3:20 AM, Caleb James DeLisle < >> > calebdelisle@lavabit•com> wrote: >> > >> > > Java (Applet) security is indeed abysmal but lets compare apples to >> apples. >> > > With an applet some random guy with a website makes up some Java code >> and >> > > your browser automatically executes it. >> > > With Multibit you're only executing highly trusted code (so trusted >> that it >> > > handles your money). >> > > There has almost never been a Java exploit against secure trusted >> code. >> > > >> > > The idea of discouraging use of java apps just because people would be >> > > tricked into activating the browser plugin when installing the JVM is >> > > probably valid but Multibit is the only reasonably complete client >> outside >> > > of bitcoinqt and I think client diversity is more important than >> stamping >> > > out java. >> > > >> > > Thanks, >> > > Caleb >> > > >> > > >> > > On 07/08/2013 08:22 PM, Robert Backhaus wrote: >> > > > But... Multibit is Java. Java's security problems has made it an >> instant >> > > uninstall item on windows PCs for about a year now. Java exploits are >> a >> > > dime a dozen. >> > > > >> > > > Yes, you can reduce some of the problems by manually disabling the >> > > browser plugin, but how many users will do that? >> > > > >> > > > Recommending a fast SPV client as a first wallet - yes, of course. >> > > Recommending users open such a huge attack interface on their >> computers by >> > > installing Java - No go. Until Multibit is provided as a compiled >> binary >> > > without a Java dependency, it is DOA. >> > > > >> > > > >> > > > On 1 July 2013 02:39, Gary Rowe <g.rowe@froot•co.uk <mailto: >> > > g.rowe@froot•co.uk>> wrote: >> > > > >> > > > I've beefed up the supporting documentation for the website to >> make >> > > it more accessible for developers who wish to contribute. It's a Java >> > > application serving HTML. >> > > > >> > > > It can be found here: >> https://github.com/jim618/multibit-website >> > > > >> > > > >> > > > On 30 June 2013 16:19, Jim <jim618@fastmail•co.uk <mailto: >> > > jim618@fastmail•co.uk>> wrote: >> > > > >> > > > Yeah "email jim' was never going to work so I have >> > > > bumped up MultiBit support (a bit) by: >> > > > >> > > > + having a dedicated Support page on the website >> > > > https://multibit.org/support.html >> > > > It has fixes and support notes for the most common >> gotchas. >> > > > + the in-app help also now has a 'Support' section with >> > > > "Troubleshooting' and the commonest gotchas. >> > > > I've also written more help to cover as much as possible. >> > > > + Failing that people are directed first to >> > > bitcoin.stackchange.com <http://bitcoin.stackchange.com> >> > > > (I have a notification set up for the 'multibit' keyword. >> > > > + Then finally users are directed to the github issues to >> search >> > > > existing or raise a new issue. Gary and Tim often chip >> in on >> > > there to >> > > > close >> > > > issues down as well as me. >> > > > >> > > > >> > > > >> > > > On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote: >> > > > > Sounds like we have consensus, Saivann, shall we do it? >> > > > > >> > > > > I'm also going to ask Theymos again to relax the newbie >> > > restrictions >> > > > > for the alt client forums. It's probably too hard to get >> > > support at >> > > > > the moment and "email jim" doesn't scale at all. >> > > > > >> > > > > On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen < >> > > gavinandresen@gmail•com <mailto:gavinandresen@gmail•com>> >> > > > > wrote: >> > > > > > I vote "yes" to have MultiBit replace Bitcoin-Qt as the >> > > recommended >> > > > > > desktop wallet app. I think most users will be happier >> with >> > > it. >> > > > > > >> > > > > > If I'm wrong, it is easy to change back. >> > > > > > >> > > > > > >> > > >> ------------------------------------------------------------------------------ >> > > > > > This SF.net email is sponsored by Windows: >> > > > > > >> > > > > > Build for Windows Store. >> > > > > > >> > > > > > http://p.sf.net/sfu/windows-dev2dev >> > > > > > _______________________________________________ >> > > > > > Bitcoin-development mailing list >> > > > > > Bitcoin-development@lists•sourceforge.net <mailto: >> > > Bitcoin-development@lists•sourceforge.net> >> > > > > > >> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > > > >> > > > > >> > > >> ------------------------------------------------------------------------------ >> > > > > This SF.net email is sponsored by Windows: >> > > > > >> > > > > Build for Windows Store. >> > > > > >> > > > > http://p.sf.net/sfu/windows-dev2dev >> > > > > _______________________________________________ >> > > > > Bitcoin-development mailing list >> > > > > Bitcoin-development@lists•sourceforge.net <mailto: >> > > Bitcoin-development@lists•sourceforge.net> >> > > > > >> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > > >> > > > >> > > > -- >> > > > https://multibit.org Money, reinvented >> > > > >> > > > >> > > >> ------------------------------------------------------------------------------ >> > > > This SF.net email is sponsored by Windows: >> > > > >> > > > Build for Windows Store. >> > > > >> > > > http://p.sf.net/sfu/windows-dev2dev >> > > > _______________________________________________ >> > > > Bitcoin-development mailing list >> > > > Bitcoin-development@lists•sourceforge.net <mailto: >> > > Bitcoin-development@lists•sourceforge.net> >> > > > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > > >> > > > >> > > > >> > > > >> > > >> ------------------------------------------------------------------------------ >> > > > This SF.net email is sponsored by Windows: >> > > > >> > > > Build for Windows Store. >> > > > >> > > > http://p.sf.net/sfu/windows-dev2dev >> > > > _______________________________________________ >> > > > Bitcoin-development mailing list >> > > > Bitcoin-development@lists•sourceforge.net <mailto: >> > > Bitcoin-development@lists•sourceforge.net> >> > > > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > > >> > > > >> > > > >> > > > >> > > > >> > > >> ------------------------------------------------------------------------------ >> > > > See everything from the browser to the database with AppDynamics >> > > > Get end-to-end visibility with application monitoring from >> AppDynamics >> > > > Isolate bottlenecks and diagnose root cause in seconds. >> > > > Start your free trial of AppDynamics Pro today! >> > > > >> > > >> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >> > > > >> > > > >> > > > >> > > > _______________________________________________ >> > > > Bitcoin-development mailing list >> > > > Bitcoin-development@lists•sourceforge.net >> > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > > >> > > >> > > >> > > >> > > >> ------------------------------------------------------------------------------ >> > > See everything from the browser to the database with AppDynamics >> > > Get end-to-end visibility with application monitoring from AppDynamics >> > > Isolate bottlenecks and diagnose root cause in seconds. >> > > Start your free trial of AppDynamics Pro today! >> > > >> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >> > > _______________________________________________ >> > > Bitcoin-development mailing list >> > > Bitcoin-development@lists•sourceforge.net >> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > >> > >> ------------------------------------------------------------------------------ >> > See everything from the browser to the database with AppDynamics >> > Get end-to-end visibility with application monitoring from AppDynamics >> > Isolate bottlenecks and diagnose root cause in seconds. >> > Start your free trial of AppDynamics Pro today! >> > >> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >> > _______________________________________________ >> > Bitcoin-development mailing list >> > Bitcoin-development@lists•sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> >> -- >> https://multibit.org Money, reinvented >> >> >> ------------------------------------------------------------------------------ >> See everything from the browser to the database with AppDynamics >> Get end-to-end visibility with application monitoring from AppDynamics >> Isolate bottlenecks and diagnose root cause in seconds. >> Start your free trial of AppDynamics Pro today! >> >> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > [-- Attachment #2: Type: text/html, Size: 20387 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-07-09 10:56 ` Jim 2013-07-09 11:04 ` Mike Hearn @ 2013-07-09 14:00 ` Daniel F 2013-07-09 14:06 ` Jeff Garzik 1 sibling, 1 reply; 47+ messages in thread From: Daniel F @ 2013-07-09 14:00 UTC (permalink / raw) To: bitcoin-development on 07/09/2013 06:56 AM Jim said the following: > + it will bump up the MultiBit download from about 11MB to 30-40MB > (I think). This drops the maximum copies of MultiBit the multibit.org > server can deliver per day from around 90,000 to 30,000ish. > The multibit.org server maxes out at 1 TB of bandwidth per day. You could host your downloads on sourceforge and achieve virtually unlimited capacity. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-07-09 14:00 ` Daniel F @ 2013-07-09 14:06 ` Jeff Garzik 2013-07-09 14:28 ` Mike Hearn 0 siblings, 1 reply; 47+ messages in thread From: Jeff Garzik @ 2013-07-09 14:06 UTC (permalink / raw) To: Daniel F; +Cc: bitcoin-development On Tue, Jul 9, 2013 at 10:00 AM, Daniel F <nanotube@gmail•com> wrote: > on 07/09/2013 06:56 AM Jim said the following: >> + it will bump up the MultiBit download from about 11MB to 30-40MB >> (I think). This drops the maximum copies of MultiBit the multibit.org >> server can deliver per day from around 90,000 to 30,000ish. >> The multibit.org server maxes out at 1 TB of bandwidth per day. > > You could host your downloads on sourceforge and achieve virtually > unlimited capacity. Indeed. There is no reason to worry about download bandwidth these days, for open source software downloads. Move the downloads to a site where such worries do not exist. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-07-09 14:06 ` Jeff Garzik @ 2013-07-09 14:28 ` Mike Hearn 2013-07-09 14:46 ` Jim 2013-07-09 14:57 ` Daniel F 0 siblings, 2 replies; 47+ messages in thread From: Mike Hearn @ 2013-07-09 14:28 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1702 bytes --] SourceForge has a horrible UI and blocks some countries. It also exposes us to a large and potentially hackable mirror network. Whilst we're not bandwidth constrained on our own servers, let's try and keep using them. On Tue, Jul 9, 2013 at 4:06 PM, Jeff Garzik <jgarzik@bitpay•com> wrote: > On Tue, Jul 9, 2013 at 10:00 AM, Daniel F <nanotube@gmail•com> wrote: > > on 07/09/2013 06:56 AM Jim said the following: > >> + it will bump up the MultiBit download from about 11MB to 30-40MB > >> (I think). This drops the maximum copies of MultiBit the multibit.org > >> server can deliver per day from around 90,000 to 30,000ish. > >> The multibit.org server maxes out at 1 TB of bandwidth per day. > > > > You could host your downloads on sourceforge and achieve virtually > > unlimited capacity. > > Indeed. There is no reason to worry about download bandwidth these > days, for open source software downloads. > > Move the downloads to a site where such worries do not exist. > > -- > Jeff Garzik > Senior Software Engineer and open source evangelist > BitPay, Inc. https://bitpay.com/ > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 2707 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-07-09 14:28 ` Mike Hearn @ 2013-07-09 14:46 ` Jim 2013-07-09 14:57 ` Daniel F 1 sibling, 0 replies; 47+ messages in thread From: Jim @ 2013-07-09 14:46 UTC (permalink / raw) To: bitcoin-development For those interested in these things the multibit.org server is a dedicated server hosted by the German company http://www.server4you.net. It is physically located in the delightful city of Strasbourg, just on the French side of the French German border. On Tue, Jul 9, 2013, at 03:28 PM, Mike Hearn wrote: > SourceForge has a horrible UI and blocks some countries. It also exposes > us > to a large and potentially hackable mirror network. Whilst we're not > bandwidth constrained on our own servers, let's try and keep using them. > > > On Tue, Jul 9, 2013 at 4:06 PM, Jeff Garzik <jgarzik@bitpay•com> wrote: > > > On Tue, Jul 9, 2013 at 10:00 AM, Daniel F <nanotube@gmail•com> wrote: > > > on 07/09/2013 06:56 AM Jim said the following: > > >> + it will bump up the MultiBit download from about 11MB to 30-40MB > > >> (I think). This drops the maximum copies of MultiBit the multibit.org > > >> server can deliver per day from around 90,000 to 30,000ish. > > >> The multibit.org server maxes out at 1 TB of bandwidth per day. > > > > > > You could host your downloads on sourceforge and achieve virtually > > > unlimited capacity. > > > > Indeed. There is no reason to worry about download bandwidth these > > days, for open source software downloads. > > > > Move the downloads to a site where such worries do not exist. > > > > -- > > Jeff Garzik > > Senior Software Engineer and open source evangelist > > BitPay, Inc. https://bitpay.com/ > > > > > > ------------------------------------------------------------------------------ > > See everything from the browser to the database with AppDynamics > > Get end-to-end visibility with application monitoring from AppDynamics > > Isolate bottlenecks and diagnose root cause in seconds. > > Start your free trial of AppDynamics Pro today! > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- https://multibit.org Money, reinvented ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-07-09 14:28 ` Mike Hearn 2013-07-09 14:46 ` Jim @ 2013-07-09 14:57 ` Daniel F 2013-07-09 15:27 ` Mike Hearn 1 sibling, 1 reply; 47+ messages in thread From: Daniel F @ 2013-07-09 14:57 UTC (permalink / raw) Cc: Bitcoin Dev on 07/09/2013 10:28 AM Mike Hearn said the following: > SourceForge has a horrible UI and blocks some countries. It also exposes > us to a large and potentially hackable mirror network. Whilst we're not > bandwidth constrained on our own servers, let's try and keep using them. the point was just that "if need be" free capacity is available without having to throw money at it. until there's no need, doesn't matter. also hackability (and ui) should be irrelevant for the autoupdate process (which i presume will do all kinds of checksum and sig verification). and it's likely the autoupdates that will create very lumpy download demand. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-07-09 14:57 ` Daniel F @ 2013-07-09 15:27 ` Mike Hearn 2013-07-09 15:32 ` Nick Simpson 0 siblings, 1 reply; 47+ messages in thread From: Mike Hearn @ 2013-07-09 15:27 UTC (permalink / raw) To: Daniel F; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1455 bytes --] That's true - we could serve new users off our own servers and auto updates off SF.net mirrors, potentially. On Tue, Jul 9, 2013 at 4:57 PM, Daniel F <nanotube@gmail•com> wrote: > on 07/09/2013 10:28 AM Mike Hearn said the following: > > SourceForge has a horrible UI and blocks some countries. It also exposes > > us to a large and potentially hackable mirror network. Whilst we're not > > bandwidth constrained on our own servers, let's try and keep using them. > > the point was just that "if need be" free capacity is available without > having to throw money at it. until there's no need, doesn't matter. > > also hackability (and ui) should be irrelevant for the autoupdate > process (which i presume will do all kinds of checksum and sig > verification). and it's likely the autoupdates that will create very > lumpy download demand. > > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 2212 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-07-09 15:27 ` Mike Hearn @ 2013-07-09 15:32 ` Nick Simpson 2013-07-09 15:51 ` Johnathan Corgan 2013-07-09 15:59 ` Jeff Garzik 0 siblings, 2 replies; 47+ messages in thread From: Nick Simpson @ 2013-07-09 15:32 UTC (permalink / raw) Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2384 bytes --] What about something like Cloudflare? Transparent to most and it'd help with your bandwidth issues. Mike Hearn <mike@plan99•net> wrote: >That's true - we could serve new users off our own servers and auto >updates >off SF.net mirrors, potentially. > > >On Tue, Jul 9, 2013 at 4:57 PM, Daniel F <nanotube@gmail•com> wrote: > >> on 07/09/2013 10:28 AM Mike Hearn said the following: >> > SourceForge has a horrible UI and blocks some countries. It also >exposes >> > us to a large and potentially hackable mirror network. Whilst we're >not >> > bandwidth constrained on our own servers, let's try and keep using >them. >> >> the point was just that "if need be" free capacity is available >without >> having to throw money at it. until there's no need, doesn't matter. >> >> also hackability (and ui) should be irrelevant for the autoupdate >> process (which i presume will do all kinds of checksum and sig >> verification). and it's likely the autoupdates that will create very >> lumpy download demand. >> >> >> >> >------------------------------------------------------------------------------ >> See everything from the browser to the database with AppDynamics >> Get end-to-end visibility with application monitoring from >AppDynamics >> Isolate bottlenecks and diagnose root cause in seconds. >> Start your free trial of AppDynamics Pro today! >> >http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > >------------------------------------------------------------------------ > >------------------------------------------------------------------------------ >See everything from the browser to the database with AppDynamics >Get end-to-end visibility with application monitoring from AppDynamics >Isolate bottlenecks and diagnose root cause in seconds. >Start your free trial of AppDynamics Pro today! >http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > >------------------------------------------------------------------------ > >_______________________________________________ >Bitcoin-development mailing list >Bitcoin-development@lists•sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development [-- Attachment #2: Type: text/html, Size: 3572 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-07-09 15:32 ` Nick Simpson @ 2013-07-09 15:51 ` Johnathan Corgan 2013-07-09 16:44 ` Mike Hearn 2013-07-09 15:59 ` Jeff Garzik 1 sibling, 1 reply; 47+ messages in thread From: Johnathan Corgan @ 2013-07-09 15:51 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 528 bytes --] On 07/09/2013 08:32 AM, Nick Simpson wrote: > What about something like Cloudflare? Transparent to most and it'd help > with your bandwidth issues. By way of endorsement, at the GNU Radio Project we switched to CloudFlare's free service tier a few months ago. We host on AWS EC2 our own web servers, downloads, and git repositories. CloudFlare has reduced our bandwidth bill by about 50%, with very little pain. -- Johnathan Corgan Corgan Labs - SDR Training and Development Services http://corganlabs.com [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 230 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-07-09 15:51 ` Johnathan Corgan @ 2013-07-09 16:44 ` Mike Hearn 0 siblings, 0 replies; 47+ messages in thread From: Mike Hearn @ 2013-07-09 16:44 UTC (permalink / raw) To: Johnathan Corgan; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1414 bytes --] That's good to know. Still, at the moment we'd need to dramatically increase the download size and increase Bitcoin usage by 10x to hit our limits. It'd be a good problem to have. On Tue, Jul 9, 2013 at 5:51 PM, Johnathan Corgan <johnathan@corganlabs•com>wrote: > On 07/09/2013 08:32 AM, Nick Simpson wrote: > > > What about something like Cloudflare? Transparent to most and it'd help > > with your bandwidth issues. > > By way of endorsement, at the GNU Radio Project we switched to > CloudFlare's free service tier a few months ago. We host on AWS EC2 our > own web servers, downloads, and git repositories. CloudFlare has > reduced our bandwidth bill by about 50%, with very little pain. > > -- > Johnathan Corgan > Corgan Labs - SDR Training and Development Services > http://corganlabs.com > > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 2231 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-07-09 15:32 ` Nick Simpson 2013-07-09 15:51 ` Johnathan Corgan @ 2013-07-09 15:59 ` Jeff Garzik 2013-07-09 16:03 ` Nick Simpson 2013-07-09 22:15 ` Andreas Petersson 1 sibling, 2 replies; 47+ messages in thread From: Jeff Garzik @ 2013-07-09 15:59 UTC (permalink / raw) To: Nick Simpson; +Cc: Bitcoin Dev On Tue, Jul 9, 2013 at 11:32 AM, Nick Simpson <nick@mynicknet•com> wrote: > What about something like Cloudflare? Transparent to most and it'd help with > your bandwidth issues. Cloudflare is rapidly becoming a bitcoin community SPOF. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-07-09 15:59 ` Jeff Garzik @ 2013-07-09 16:03 ` Nick Simpson 2013-07-09 22:15 ` Andreas Petersson 1 sibling, 0 replies; 47+ messages in thread From: Nick Simpson @ 2013-07-09 16:03 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 528 bytes --] Not any more than sourceforge or github.. None of these solutions are replacements, but rather only supplements to self hosted files. Jeff Garzik <jgarzik@bitpay•com> wrote: >On Tue, Jul 9, 2013 at 11:32 AM, Nick Simpson <nick@mynicknet•com> >wrote: >> What about something like Cloudflare? Transparent to most and it'd >help with >> your bandwidth issues. > >Cloudflare is rapidly becoming a bitcoin community SPOF. >-- >Jeff Garzik >Senior Software Engineer and open source evangelist >BitPay, Inc. https://bitpay.com/ [-- Attachment #2: Type: text/html, Size: 807 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-07-09 15:59 ` Jeff Garzik 2013-07-09 16:03 ` Nick Simpson @ 2013-07-09 22:15 ` Andreas Petersson 1 sibling, 0 replies; 47+ messages in thread From: Andreas Petersson @ 2013-07-09 22:15 UTC (permalink / raw) To: bitcoin-development It particulary worries me that a lot of sites hand over their SSL private keys to Cloudflare, and they are located in prism land. > Cloudflare is rapidly becoming a bitcoin community SPOF. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-27 17:10 [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org Jim 2013-06-27 17:30 ` Jeff Garzik @ 2013-06-27 17:56 ` Gregory Maxwell 2013-06-27 18:05 ` Alex Kravets ` (2 more replies) 1 sibling, 3 replies; 47+ messages in thread From: Gregory Maxwell @ 2013-06-27 17:56 UTC (permalink / raw) To: Jim; +Cc: bitcoin-development On Thu, Jun 27, 2013 at 10:10 AM, Jim <jim618@fastmail•co.uk> wrote: > Let me know if you think this is a good idea (or not!) > and if you have any questions. Being able to promote a fast SPV desktop wallet would be great! I went through an cycle of testing on multibit after I saw some complaints when it went up on the page before without at lot of discussion. There were a number of issues with it at the time, in particular the frequent deadlocks— though Mike was saying that those should be fixed. I see some of the the other things that were concerning for me at the time are still uncorrected though, e.g. no proxy support (so users can't follow our recommended best practices of using it with Tor), that it reuses addresses (esp for change), that it doesn't clearly distinguish confirmation level. It also make repeated https connections to 141.101.113.245? (I'm not seeing the IP in the source, and it doesn't have a useful reverse dns entry, so I can't tell what its for). Is there any timeframe for changing any of this stuff? ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-27 17:56 ` Gregory Maxwell @ 2013-06-27 18:05 ` Alex Kravets 2013-06-27 23:45 ` Caleb James DeLisle 2013-06-28 9:05 ` Mike Hearn 2 siblings, 0 replies; 47+ messages in thread From: Alex Kravets @ 2013-06-27 18:05 UTC (permalink / raw) To: Gregory Maxwell; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 2192 bytes --] Hi guys, This would be a big step forward. Anecdotally I can report that <5% of * non-nerds* who don't abandon Bitcoin after waiting for the initial blockchain download and *ongoing* sync on every restart, end up using blockchain.info simply because it just works and works on their iPads & iPhones. Conversely, all the serious nerds end up using Armory and/or Brainwallets for ultimate control. On Thu, Jun 27, 2013 at 10:56 AM, Gregory Maxwell <gmaxwell@gmail•com>wrote: > On Thu, Jun 27, 2013 at 10:10 AM, Jim <jim618@fastmail•co.uk> wrote: > > Let me know if you think this is a good idea (or not!) > > and if you have any questions. > > Being able to promote a fast SPV desktop wallet would be great! > > I went through an cycle of testing on multibit after I saw some > complaints when it went up on the page before without at lot of > discussion. There were a number of issues with it at the time, in > particular the frequent deadlocks— though Mike was saying that those > should be fixed. > > I see some of the the other things that were concerning for me at the > time are still uncorrected though, e.g. no proxy support (so users > can't follow our recommended best practices of using it with Tor), > that it reuses addresses (esp for change), that it doesn't clearly > distinguish confirmation level. It also make repeated https > connections to 141.101.113.245? (I'm not seeing the IP in the source, > and it doesn't have a useful reverse dns entry, so I can't tell what > its for). Is there any timeframe for changing any of this stuff? > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Alex Kravets <http://www.linkedin.com/in/akravets> def redPill = ' Scala <http://www.scala-lang.org/> [[ brutal honesty <http://goo.gl/vwydt> is the best policy ]] [-- Attachment #2: Type: text/html, Size: 3228 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-27 17:56 ` Gregory Maxwell 2013-06-27 18:05 ` Alex Kravets @ 2013-06-27 23:45 ` Caleb James DeLisle 2013-06-28 9:05 ` Mike Hearn 2 siblings, 0 replies; 47+ messages in thread From: Caleb James DeLisle @ 2013-06-27 23:45 UTC (permalink / raw) To: bitcoin-development On 06/27/2013 01:56 PM, Gregory Maxwell wrote: > On Thu, Jun 27, 2013 at 10:10 AM, Jim <jim618@fastmail•co.uk> wrote: >> Let me know if you think this is a good idea (or not!) >> and if you have any questions. > > Being able to promote a fast SPV desktop wallet would be great! > > I went through an cycle of testing on multibit after I saw some > complaints when it went up on the page before without at lot of > discussion. There were a number of issues with it at the time, in > particular the frequent deadlocks— though Mike was saying that those > should be fixed. > > I see some of the the other things that were concerning for me at the > time are still uncorrected though, e.g. no proxy support (so users > can't follow our recommended best practices of using it with Tor), If I were a Bitcoin dev, I would not want to talk about anonymity or TOR because that's likely to attract people with paranoid dilutions and they're really terrible users to support :) Also yay for promoting fast, easy to use clients for casual users! Thanks, Caleb > that it reuses addresses (esp for change), that it doesn't clearly > distinguish confirmation level. It also make repeated https > connections to 141.101.113.245? (I'm not seeing the IP in the source, > and it doesn't have a useful reverse dns entry, so I can't tell what > its for). Is there any timeframe for changing any of this stuff? > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-27 17:56 ` Gregory Maxwell 2013-06-27 18:05 ` Alex Kravets 2013-06-27 23:45 ` Caleb James DeLisle @ 2013-06-28 9:05 ` Mike Hearn 2013-06-28 10:09 ` John Dillon 2 siblings, 1 reply; 47+ messages in thread From: Mike Hearn @ 2013-06-28 9:05 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Dev > There were a number of issues with it at the time, in > particular the frequent deadlocks— though Mike was saying that those > should be fixed. Yes. There were a number of lock cycles that didn't cause issues so much when traffic was lower and as Bitcoin got more popular it became a critical problem. I redid a lot of the concurrency to fix that, and now all the core locks are cycle detecting so regressions should be detected fairly fast. I'm still making changes to the concurrency design but mostly to improve the API at this point, not fix bugs. There is one deadlock I'm still aware of, thanks to Netty. However it's very rare and was only reported by someone who kept a server running for many days in a row. We want to junk Netty soon anyway. It's a network library but it doesn't really add much value for our use case and it turned out to have some serious design issues internally. > I see some of the the other things that were concerning for me at the > time are still uncorrected though, e.g. no proxy support (so users > can't follow our recommended best practices of using it with Tor), Yeah. That's not the primary privacy issue with bitcoinj though. I'm much, much more concerned about leaks via the block chain than the network layer. Especially as Tor is basically a giant man in the middle, without any kind of authentication you can easily end up connected to a sybil network without any idea. I'd be surprised if Tor usage was very high amongst Bitcoin users. > that it reuses addresses (esp for change), that it doesn't clearly > distinguish confirmation level. It does actually, but the iconography is not very clear. I'm not convinced any users really care about the difference between two and three blocks these days. Maybe exchanges and other security-critical applications do, but I doubt desktop users do. It's not a library limitation anyway, it's a case of how best to present information to a user who is not familiar with how Bitcoin works. "Safe" and "Not safe" is still a rather misleading distinction given the general absence of double spends against mempool transactions, but it's still a lot more meaningful than "2 confirms" vs "3 confirms", something that would just make a new user ask what the heck a confirm is. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-28 9:05 ` Mike Hearn @ 2013-06-28 10:09 ` John Dillon 2013-06-28 10:20 ` Mike Hearn 2013-06-30 10:12 ` Peter Todd 0 siblings, 2 replies; 47+ messages in thread From: John Dillon @ 2013-06-28 10:09 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, Jun 28, 2013 at 9:05 AM, Mike Hearn <mike@plan99•net> wrote: >> I see some of the the other things that were concerning for me at the >> time are still uncorrected though, e.g. no proxy support (so users >> can't follow our recommended best practices of using it with Tor), > > Yeah. That's not the primary privacy issue with bitcoinj though. I'm > much, much more concerned about leaks via the block chain than the > network layer. Especially as Tor is basically a giant man in the > middle, without any kind of authentication you can easily end up > connected to a sybil network without any idea. I'd be surprised if Tor > usage was very high amongst Bitcoin users. Tor does not act as a particularly effective man in the middle for nodes that support connections to hidden services because while your connections to standard Bitcoin nodes go through your exit node, the routing path for each hidden service peer is independent. Having said that we should offer modes that send your self-generated transactions out via Tor, while still maintaining non-Tor connections. Anyway Sybil attacks aren't all that interesting if you are the one sending the funds, and receivers are reasonably well protected simply because generating false confirmations is extremely expensive and very difficult to do quickly. After all, you always make the assumption that nearly all hashing power in existence is honest when you talk about replace-by-fee among other things, and that assumption naturally leads to the conclusion that generating false confirmations with a sybil attack would take more than long enough that the user would be suspicious that something was wrong long before being defrauded. I'd be surprised if anyone has ever bothered with a false confirmation sybil attack. I wouldn't be the slightest bit surprised if the NSA is recording all the Bitcoin traffic they can for future analysis to find true transaction origins. Which reminds me, again, we need node-to-node connections to be encrypted to at least protect against network-wide passive sniffiing. Regarding usage I would be interested to hear from those running Bitcoin nodes advertising themselves as hidden services. > It's not a library limitation anyway, it's a case of how best to > present information to a user who is not familiar with how Bitcoin > works. "Safe" and "Not safe" is still a rather misleading distinction > given the general absence of double spends against mempool > transactions, but it's still a lot more meaningful than "2 confirms" For what it is worth I ran a double-spend generator a month or so ago against the replace-by-fee node that Peter setup and I found that a small number of the double-spends did in fact appear to be mined under replace-by-fee rules. Specifically the generator would create a transaction from confirmed inputs, wait 60-180 seconds (randomized) to allow for full propagation, and then create a double-spend if the transaction hadn't already been mined. The transactions were randomized to look like normal traffic, including occasional bets to Satoshidice and similar for fun. (for the record the script had no way of knowing if a bet won and would happily attempt to double-spend wins) Fees for the replacement were power-law distributed IIRC, with some occasionally set to be quite hefty. Though possibly just an artifact of unusually slow transaction propagation it appeared that about 0.25% of hashing power was following replace-by-fee rules. (not including transactions involving gambling, I know Eligius and perhaps others block such transactions from their mempools making double-spends easy to accomplish by including Satoshidice outputs) I'm actually surprised by that figure myself given Peter Todd and I haven't made a serious attempt yet to get miners to use replace-by-fee rules. An interesting experiment would be to advertise that money is being given away by such a tx generator in the mining forum, although I would prefer to see solid mempool support for the "scorched-earth" double-spend countermeasure first; Peter sounds like he has some great ideas there, although as usual I am seeing very little in the way of code. :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRzWCOAAoJEEWCsU4mNhiPwhgH/ic/OJMCYwdIuEM2ArSAEQRY l5bqafMYMcC/KE9xqZ1HVkLJ9Zg57MQ8VZw95WOsmRgNA0v1xIoCyREjI84QkCIq R/hOgS97eJc+XXnPBVoB4Jadq5LQ6jNpJo7cmiLJjCEmE6rTxLZBBT4P3eQw8oIn WAd7X7utP7/QAkjhaWB9FsfWT8QZseqpSPv8WucRftsRCABurzuD+eSfpRqYwk2z XBD0zO+EyAtu6hB3dRAFhqnhVfEcOLJCtXpm76WO574H4AZ/8EN+HozLJSUtylCq j1NZnpj/6pdFh2v5Pid4HEMEvuNNX60u6iXGJ560PUsdKmOh+LEhUBLKd9acJTw= =QtjI -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-28 10:09 ` John Dillon @ 2013-06-28 10:20 ` Mike Hearn 2013-06-28 10:32 ` John Dillon 2013-06-30 10:12 ` Peter Todd 1 sibling, 1 reply; 47+ messages in thread From: Mike Hearn @ 2013-06-28 10:20 UTC (permalink / raw) To: John Dillon; +Cc: Bitcoin Dev I suspect what you saw is mining nodes restarting and clearing their mempools out rather than an explicit policy of replace by fee. On Fri, Jun 28, 2013 at 12:09 PM, John Dillon <john.dillon892@googlemail•com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On Fri, Jun 28, 2013 at 9:05 AM, Mike Hearn <mike@plan99•net> wrote: >>> I see some of the the other things that were concerning for me at the >>> time are still uncorrected though, e.g. no proxy support (so users >>> can't follow our recommended best practices of using it with Tor), >> >> Yeah. That's not the primary privacy issue with bitcoinj though. I'm >> much, much more concerned about leaks via the block chain than the >> network layer. Especially as Tor is basically a giant man in the >> middle, without any kind of authentication you can easily end up >> connected to a sybil network without any idea. I'd be surprised if Tor >> usage was very high amongst Bitcoin users. > > Tor does not act as a particularly effective man in the middle for nodes > that support connections to hidden services because while your > connections to standard Bitcoin nodes go through your exit node, the > routing path for each hidden service peer is independent. Having said > that we should offer modes that send your self-generated transactions > out via Tor, while still maintaining non-Tor connections. > > Anyway Sybil attacks aren't all that interesting if you are the one > sending the funds, and receivers are reasonably well protected simply > because generating false confirmations is extremely expensive and very > difficult to do quickly. After all, you always make the assumption that > nearly all hashing power in existence is honest when you talk about > replace-by-fee among other things, and that assumption naturally leads > to the conclusion that generating false confirmations with a sybil > attack would take more than long enough that the user would be > suspicious that something was wrong long before being defrauded. > > I'd be surprised if anyone has ever bothered with a false confirmation > sybil attack. I wouldn't be the slightest bit surprised if the NSA is > recording all the Bitcoin traffic they can for future analysis to find > true transaction origins. Which reminds me, again, we need node-to-node > connections to be encrypted to at least protect against network-wide > passive sniffiing. > > Regarding usage I would be interested to hear from those running Bitcoin > nodes advertising themselves as hidden services. > >> It's not a library limitation anyway, it's a case of how best to >> present information to a user who is not familiar with how Bitcoin >> works. "Safe" and "Not safe" is still a rather misleading distinction >> given the general absence of double spends against mempool >> transactions, but it's still a lot more meaningful than "2 confirms" > > For what it is worth I ran a double-spend generator a month or so ago > against the replace-by-fee node that Peter setup and I found that a > small number of the double-spends did in fact appear to be mined under > replace-by-fee rules. > > Specifically the generator would create a transaction from confirmed > inputs, wait 60-180 seconds (randomized) to allow for full propagation, > and then create a double-spend if the transaction hadn't already been > mined. The transactions were randomized to look like normal traffic, > including occasional bets to Satoshidice and similar for fun. (for the > record the script had no way of knowing if a bet won and would happily > attempt to double-spend wins) Fees for the replacement were power-law > distributed IIRC, with some occasionally set to be quite hefty. > > Though possibly just an artifact of unusually slow transaction > propagation it appeared that about 0.25% of hashing power was following > replace-by-fee rules. (not including transactions involving gambling, I > know Eligius and perhaps others block such transactions from their > mempools making double-spends easy to accomplish by including > Satoshidice outputs) > > I'm actually surprised by that figure myself given Peter Todd and I > haven't made a serious attempt yet to get miners to use replace-by-fee > rules. An interesting experiment would be to advertise that money is > being given away by such a tx generator in the mining forum, although I > would prefer to see solid mempool support for the "scorched-earth" > double-spend countermeasure first; Peter sounds like he has some great > ideas there, although as usual I am seeing very little in the way of > code. :) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iQEcBAEBCAAGBQJRzWCOAAoJEEWCsU4mNhiPwhgH/ic/OJMCYwdIuEM2ArSAEQRY > l5bqafMYMcC/KE9xqZ1HVkLJ9Zg57MQ8VZw95WOsmRgNA0v1xIoCyREjI84QkCIq > R/hOgS97eJc+XXnPBVoB4Jadq5LQ6jNpJo7cmiLJjCEmE6rTxLZBBT4P3eQw8oIn > WAd7X7utP7/QAkjhaWB9FsfWT8QZseqpSPv8WucRftsRCABurzuD+eSfpRqYwk2z > XBD0zO+EyAtu6hB3dRAFhqnhVfEcOLJCtXpm76WO574H4AZ/8EN+HozLJSUtylCq > j1NZnpj/6pdFh2v5Pid4HEMEvuNNX60u6iXGJ560PUsdKmOh+LEhUBLKd9acJTw= > =QtjI > -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-28 10:20 ` Mike Hearn @ 2013-06-28 10:32 ` John Dillon 0 siblings, 0 replies; 47+ messages in thread From: John Dillon @ 2013-06-28 10:32 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, Jun 28, 2013 at 10:20 AM, Mike Hearn <mike@plan99•net> wrote: > I suspect what you saw is mining nodes restarting and clearing their > mempools out rather than an explicit policy of replace by fee. Possibly, but it is a rather short window of opportunity and the mining node would have to be connected directly, to Peter's replace-by-fee node. I also took care to ensure transactions were only ever broadcast once. (I disabled the wallet rebroadcast mechanism) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRzWYWAAoJEEWCsU4mNhiP3fIIAJLFxMnjI4BGRrNLsxs0hXp0 zDCgiZ6UnZa5JRcd/6KjV3hnPHwweGEjChGfrzY/Fxo4Pga1lQFlp8E8PaFUJq50 r6LTNJQLW50r5mFkZ6Mkh877WwX/OHBzkp8SqbbD7+dDBV7R9LqLYqLTHgObKxg1 V9UjGRJiMohW8HLdOzEXOz1ugoBCjR+vyQW5ZD2nZVcQlIhxSIgeC/M46oxMN7pE Y5EepCQehNPuc1On7TtJ9LlmFJ6Dvsl6dqwKNWMi1lgBTiw7abdTJne2B/KeDyom vhGuhmpMLGKKgJns3hne3yQM+Ivi3jLIHKejcoCm1JkSCdjw48XkyGd0V359M3w= =qyyq -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 2013-06-28 10:09 ` John Dillon 2013-06-28 10:20 ` Mike Hearn @ 2013-06-30 10:12 ` Peter Todd 1 sibling, 0 replies; 47+ messages in thread From: Peter Todd @ 2013-06-30 10:12 UTC (permalink / raw) To: John Dillon; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3533 bytes --] On Fri, Jun 28, 2013 at 10:09:16AM +0000, John Dillon wrote: > true transaction origins. Which reminds me, again, we need node-to-node > connections to be encrypted to at least protect against network-wide > passive sniffiing. Agreed. Speaking of, I may have missed it but as far as I can tell Bitmessage doesn't encrypt node-to-node communications, a serious oversight. Any attacker that can sniff a large fraction of the network, like the NSA, can easily use this to track down the originating node of any message, just like they can do with Bitcoin. > For what it is worth I ran a double-spend generator a month or so ago > against the replace-by-fee node that Peter setup and I found that a > small number of the double-spends did in fact appear to be mined under > replace-by-fee rules. Ah! I had a feeling that might be you. Were you the person who was creating the 1BTC fee transactions as well? > Though possibly just an artifact of unusually slow transaction > propagation it appeared that about 0.25% of hashing power was following > replace-by-fee rules. (not including transactions involving gambling, I > know Eligius and perhaps others block such transactions from their > mempools making double-spends easy to accomplish by including > Satoshidice outputs) I just got an email from someone saying they had a few Avalons with that patch installed actually; that was probably them. > I'm actually surprised by that figure myself given Peter Todd and I > haven't made a serious attempt yet to get miners to use replace-by-fee > rules. An interesting experiment would be to advertise that money is > being given away by such a tx generator in the mining forum, although I > would prefer to see solid mempool support for the "scorched-earth" > double-spend countermeasure first; Peter sounds like he has some great > ideas there, although as usual I am seeing very little in the way of > code. :) Keep in mind it's not just the mempool that needs changing - the network protocol semantics need to change too. For the "scorched-earth" strategy to work you need nodes tell their peers about the total fees a transaction has attached in addition tot he tx hash. Essentially you are advertising to your peers what would right now be an orphan, and your peers need to recursively get dependencies; I'm sure there's a bunch of edge cases there that would be need to thought out carefully. It's useful for a lot of things though, for instance when a zero-fee, zero-priority tx is given to a merchant who now wants to tell miners to mine it anyway due to a child tx. What I'd recommend actually for the nearer term is just adding recursive fee evaluation with a depth*breadth anti-DoS limit, adding the rpc and GUI adjfee and canceltx commands, adding better wallet support for conflicts, (someone is already workng on this) and adding a service bit with preferential peering. By preferential peering I mean you set aside a portion of your outgoing peer slots for peers with certain bits set and only fill those slots with those peers. In addition you can have DNS seeds return peers with specified service bits set: x0000000000000003.v1.seed.petertodd.org could be nodes with the first and second bits set. (we might want to define the upper 8 service bits as a service bit version field so we can redefine the other 56 in the far off future if required) -- 'peter'[:-1]@petertodd.org 00000000000000b2b1f2ca2a2f937c2d93c41a5d089e1d3d4fe6bb663dd25db5 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2013-07-09 22:15 UTC | newest]
Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-27 17:10 [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org Jim
2013-06-27 17:30 ` Jeff Garzik
2013-06-27 18:04 ` Luke-Jr
2013-06-27 18:41 ` Gregory Maxwell
2013-06-27 19:18 ` Jim
2013-06-27 19:40 ` Jim
2013-06-27 19:50 ` Jim
2013-06-27 21:12 ` Alex Kravets
2013-06-27 21:56 ` Jeff Garzik
2013-06-27 22:53 ` Alex Kravets
2013-06-27 22:03 ` Gary Rowe
2013-06-28 10:59 ` John Dillon
2013-06-28 9:10 ` Mike Hearn
2013-06-28 14:24 ` Gavin Andresen
[not found] ` <CAFtwHRewE0wgvWsf-785hpCb8ns7wiGaKHAQ-1QmDD-W+diBJA@mail.gmail.com>
2013-06-28 20:37 ` Bill Hees
2013-06-28 20:42 ` Jim
2013-06-30 11:42 ` Mike Hearn
2013-06-30 15:19 ` Jim
2013-06-30 16:39 ` Gary Rowe
2013-07-09 0:22 ` Robert Backhaus
2013-07-09 1:20 ` Caleb James DeLisle
2013-07-09 10:36 ` Mike Hearn
2013-07-09 10:56 ` Jim
2013-07-09 11:04 ` Mike Hearn
2013-07-09 11:13 ` Will
2013-07-09 11:15 ` Jim
2013-07-09 11:18 ` Mike Hearn
2013-07-09 14:00 ` Daniel F
2013-07-09 14:06 ` Jeff Garzik
2013-07-09 14:28 ` Mike Hearn
2013-07-09 14:46 ` Jim
2013-07-09 14:57 ` Daniel F
2013-07-09 15:27 ` Mike Hearn
2013-07-09 15:32 ` Nick Simpson
2013-07-09 15:51 ` Johnathan Corgan
2013-07-09 16:44 ` Mike Hearn
2013-07-09 15:59 ` Jeff Garzik
2013-07-09 16:03 ` Nick Simpson
2013-07-09 22:15 ` Andreas Petersson
2013-06-27 17:56 ` Gregory Maxwell
2013-06-27 18:05 ` Alex Kravets
2013-06-27 23:45 ` Caleb James DeLisle
2013-06-28 9:05 ` Mike Hearn
2013-06-28 10:09 ` John Dillon
2013-06-28 10:20 ` Mike Hearn
2013-06-28 10:32 ` John Dillon
2013-06-30 10:12 ` Peter Todd
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox