[Bitcoin-development] Double-Spending Fast Payments in Bitcoin due to Client versions 0.8.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Bitcoin developers, We would like to report a vulnerability which might lead, under some assumptions, to a double-spending attack in a fast payment scenario. The vulnerability has been introduced due to signature encoding incompatibilities between versions 0.8.2 (or 0.8.3) and earlier Bitcoin versions. Please find at the following link a detailed description of this vulnerability: ftp://ftp.inf.ethz.ch/pub/publications/tech-reports/7xx/789.pdf We contacted and informed Gavin earlier about this problem. With best regards, Arthur Gervais -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJRzBKLAAoJEI2AYXeasI8/eNYH/2b45o8JPjuiOXeE0MgiYO4g HgGorNBvH3hLlSZkGh/7GxeGWi3tiEq8DKAgqFd8p+1Ay4YVHK86jJMBxAc8lzpx TqS6Szrhlx7slamMGhjeem4BJ2RmfVqSRQjidYxwdee8bMQRVH5DiBzndpZwCeHa AvlP8ojTUFozOJs5PvjEqE+sDKDe5nDC96uiZyMROK8neoiLZpJzV3+ScTUjLCeB zg34wttX80WKpkXJFvq88FTIvO5E42NGP3APnt2J/HZcey4Mi9UIhLt+/TJ7Z07l HuxFlzyXdCgRkJWvU13yn8bUP0cbeoox6Cwn7rDAIisVLn4KB9XPThPjfJbKEkg= =Y6bs -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] Double-Spending Fast Payments in Bitcoin due to Client versions 0.8.1
On Thu, Jun 27, 2013 at 3:23 AM, Arthur Gervais arthur.gerv...@inf.ethz.ch wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Bitcoin developers, We would like to report a vulnerability which might lead, under some assumptions, to a double-spending attack in a fast payment scenario. The vulnerability has been introduced due to signature encoding incompatibilities between versions 0.8.2 (or 0.8.3) and earlier Bitcoin versions. Please find at the following link a detailed description of this vulnerability: ftp://ftp.inf.ethz.ch/pub/publications/tech-reports/7xx/789.pdf It would be kind if your paper cited the one of the prior discussions of this transaction pattern: E.g. https://bitcointalk.org/index.php?topic=196990.msg2048297#msg2048297 (I think there are a couple others) The family of transaction patterns you describe is one of the ones I specifically cite as an example of why taking non-reversible actions on unconfirmed transactions is unsafe (and why most of the Bitcoin community resources) council the same. You can get similar patterns absent changes in the IsStandard rule through a number of other means. One obvious one is through concurrent announcement: You announce conflicting transactions at the same time to many nodes and one excludes another. By performing this many times and using chains of unconfirmed transactions and seeing which family your victim observes you can create input mixes that are only accepted by very specific subsets of the network. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] [ANN] Micropayment Channel Implementation
As of today, a full implementation of micropayment channels has been merged onto bitcoinj's master branch (to be released in the next version). It is designed to make it easy for users to create payment channel servers and clients based on the design at https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party, by creating a simple TCP socket and exchanging protobufs to initialize and make payments. It supports various levels of abstractions, allowing users to drive the state machines which do basic channel init/verification themselves, allow bitcoinj to handle all the complexity of channel management/expiry/etc and simply exchange protobufs over whatever whatever connection they wish to make with the server, or let bitcoinj handle opening a TCP socket and do all the work. See https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments for details on how to use the implementation in bitcoinj. A more full protocol description will be written up in the form of a BIP as the code matures a bit more (with the hope that other implementations can appear), but, generally: 1. Client and server exchange version handshake, and client may optionally request that an existing channel be reopened (the channels last for 24 hours by default, so if the connection gets killed, reopening an existing channel is useful). 2. The protocol described on the wiki is followed, exchanging (canonical!) signatures and transactions until a multisignature contract is established and broadcast which locks money into the channel, and a refund transaction is created and signed which allows the client to spend the entire multisignature transaction to wherever they want (SIGHASH_NONE|SIGHASH_ANYONECANPAY) after some lock time (by default, 24 hours). Both client and server store a copy of the channel in their wallet so that if the app itself crashes the refund transaction can still be broadcast/the channel can still be resumed. At this point either the whole wallet should be backed up or the total value in payment channels at any given time should be kept reasonably low (because payment channels are designed to combine micropayments into confirmable payments, this shouldn't be an issue) 3. The client increments payments by sending the server new signatures spending the multisig contract partially back to themselves and allowing the server to do what they want with the rest (SIGHASH_SINGLE|SIGHASH_ANYONECANPAY). 4. When the client sends a CLOSE message or the channel approaches the refund transaction unlock time, the server adds any necessary fees to the latest payment transaction and broadcasts it, closing the channel, disconnecting the client if the connection is still open and removing the stored channel state from its wallet. See https://code.google.com/p/bitcoinj/source/browse/core/src/paymentchannel.proto for the protobuf/protocol description. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
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 -- 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
On Thu, Jun 27, 2013 at 1:10 PM, Jim jim...@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/ -- 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
On Thu, Jun 27, 2013 at 10:10 AM, Jim jim...@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
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
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 gmaxw...@gmail.comwrote: On Thu, Jun 27, 2013 at 10:10 AM, Jim jim...@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 ]] -- 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
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) -- 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
On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr l...@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
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
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 l...@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.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
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 l...@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.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 -- 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
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 l...@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.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
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
On 06/27/2013 01:56 PM, Gregory Maxwell wrote: On Thu, Jun 27, 2013 at 10:10 AM, Jim jim...@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 -- 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
