Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
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 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 > > 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.orgMoney, 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
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
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 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 > 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
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
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
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Jun 27, 2013 at 6:41 PM, Gregory Maxwell wrote: > On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr 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- -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Jun 28, 2013 at 10:20 AM, Mike Hearn 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- -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > Thinking about this a little more, I guess it does not hurt to build some > kind of voting system into the clients. But I think it's more useful for > straw polls. For example a bug fix 100% of people should agree on. A > protocol optimization perhaps 80% would agree on. A protocol change that > redistributes wealth or incentives perhaps only 60% will agree on. > > At this point in time it's far too easy to deliver contentious changes into > the hands of the general population. I think that fortunately we're blessed > with a very strong dev team, but the fundamental philosophy of bitcoin is to > not put too much trust in single point, but rather, to distribute and > diversify trust to the edges. I disagree entirely. Your example of "straw polls" for bug fixes and features is precisely what the current method of rough consensus and running code, an IETF expression, handles just fine. What the method does not handle effectively are issues that are fundementally political rather than technical in nature. Blocksize is precisely the latter because while the tradeoffs are technical in nature the fundemental issue at hand is what do we want Bitcoin to be? Who are we going to allow to participate? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRzWR7AAoJEEWCsU4mNhiPEYsIAME+VvS4vfE0PdOMv3vHWGSH HwUJdtKPold4+p0jhPBKSMbgnpMvXsZezMIIxj8xehnblnVuUdyakibXAdgVNLvp a6SCw+W/VnopYCw151zZ4FQS92KQuSbX+XmYTQy32oqZIXtBmTE1fydw5q6YhoXb gCCygPRyLTIQxLZAxqqRrQ0nsSE5ID5kDcr+xRsmCvfIKrzoOCbYL+nXPCB4Zzgu Gs7Lfa0yfTrUlQmoDseyoWrVuhfYuFNesTAs3z6imMTdHqZh8Z+a+gmC+G9qFO1h y7hOmzW4oz7hH4R2F6M+UpV6rKdwMaNYwrDw5eHClDgGYNfjjVduQ/YMQnbjyAc= =5mhd -END PGP SIGNATURE- -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
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 wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Fri, Jun 28, 2013 at 9:05 AM, Mike Hearn 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= >
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Jun 28, 2013 at 9:05 AM, Mike Hearn 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- -- 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.sourcef
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
> 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. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
> 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. -- 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
