Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
On Wed, Jul 15, 2015 at 05:08:05PM -0700, Matthieu Riou via bitcoin-dev wrote: On Wed, Jul 15, 2015 at 12:32 PM, Peter Todd p...@petertodd.org wrote: In a Sybil attack the attacker subverts the reputation system of a peer-to-peer network by creating a large number of pseudonymous identities, using them to gain a disproportionately large influence. Our identities aren't pseudonymous. Then are you willing to tell us what IP addresses your nodes connect from? This is important network stability information due to how nodes prevent a lack of diversity in their outgoing connections. In the case of Bitcoin, there's something like 6,000 nodes, so if that 20% is achived via outgoing connections you'd have 600 to 1200 active outgoing connections using up network resources. Meanwhile, the default is 8 outgoing connections - you're using about two orders of magnitude more resources. You're not talking about a Sybil attack anymore, just resource use. We do know how to change default configurations to offer more connections. The Bitcoin P2P network's primary concern is reliability through diversity; you are harming that resource. So to be clear, you have both a high level of outgoing and incoming connections? Given that Bitcoin nodes only connect to eight outgoing peers, how do you manage to connect to your claimed 10%-20% of all reachable nodes? Obviously you can't be doing that with just incoming connections, unless you're running hundreds of nodes, or doing an addr spamming attack. If you are achieving that via incoming connections, you're placing a big part of the relay network under central control. As we've seen in the case of Chainalysis's sybil attack, even unintentional confirguation screwups can cause serious and widespread issues due to the large number of nodes that can fail in one go. (note how Chainalysis's actions were described(1) as a sybil attack by multiple Bitcoin devs, including Gregory Maxwell, Wladimir van der Laan, and myself) We're not Chainanalysis and we do not run hundreds of distinct nodes. Just a few well-tuned ones. It's actually marginally better for the network if you're using hundreds of distinct nodes rather than just a few to do this sybil attack - the chance of your small number of nodes suddenly going off-line and causing propagation issues is more than hundreds of nodes all going off-line suddenly. Additionally it's easier for bad actors to survail your few internet connections to easily get tx propagation information from the network than it is to survail Chainalysis's setup. (ironic I know) What you are doing is inherently incompatible with decentralization. That's a matter of opinion. One could argue your actions and control attempts hurt decentralization. Either way, no one should play the decentralization police or act as a gatekeeper. Control attempts? Care to explain? Re: gatekeeping - fact is your business model and technology can only be succesfully run by a small number of entities at once, resulting in a situation where those few companies act as gatekeepers for access to zeroconf confirmation probability information. Question: Do you have relationships with mining pools? For instance, are you looking at contracts to have transactions mined to guarantee confirmations? No, we do not. We do not know anyone else having such contracts. As you know, Coinbase also denied having such contracts in place [1]. But you seem to have more relationships with mining pools than we do. Nice cheap shot there. My relationships are nothing more than people being willing to talk to me, ask me for advice, and warn me about possible threats. They're not legal contracts. -- 'peter'[:-1]@petertodd.org 138147be90db48b8338de6d58cc6b60e6ad360f6ef486d8c signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP0074 Draft (Dynamic Rate Lookup)
You should rename your file to something like bip-draft-dynamic-rate-lookup. Using an arbitrary BIP number will cause confusion when that BIP number is actually assigned later. On Friday, 17 July 2015, at 3:50 pm, David Barnes | Bitcoin Co. Ltd. via bitcoin-dev wrote: I picked up the next available number myself, but can be changed to anything, the 74 is unimportant to the proposal. David Barnes On 7/17/2015 2:54 PM, Micha Bailey wrote: Did Greg assign this number? He didn't do it here on the ML. You're not supposed to use arbitrary numbers, certainly not numbers that are close/similar to ones already assigned. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP0074 Draft (Dynamic Rate Lookup)
I picked up the next available number myself, but can be changed to anything, the 74 is unimportant to the proposal. David Barnes On 7/17/2015 2:54 PM, Micha Bailey wrote: Did Greg assign this number? He didn't do it here on the ML. You're not supposed to use arbitrary numbers, certainly not numbers that are close/similar to ones already assigned. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
I appreciate the thought :) I think where we differ is on where we believe the trade offs should be on perceived privacy versus censorship resistance and centralization. By having a limited number of proxies people need to go through to easily implement, be it the 4 you recommend, or 53, you actually have a very limited number of actors for an authority or hacker to go to in order to be able to install/force logging, or censorship. This very centralization forces us back to a model where we need to trust a very small number of actors in order for the system to operate as designed. This, to me, appears to be the opposite of the goals of the bitcoin ecosystem. To ensure this point is clear, I strongly believe recommending people focus all lookups through 4 centralized proxies is a bad idea and counter to bitcoin's ideals. The fact that hackers or state actors need to corrupt only a small number of servers/services in order to gain global visibility into all queries, I believe, breaks any perceived privacy gains from using DNSCrypt. A very small number of hacks or subpoenas and everyone's records are fair game in one place. You're misstating (or not understanding) the attack surface. State-level attackers won't compromise 50+ DNSCrypt servers, they can get the information on lookups a lot more trivially. Censorship resistance and protection from state-level attackers comes from the decentralised side of OpenAlias (ie. Namecoin resolution, preferably done using a local copy of the NMC blockchain). Since Netki supports Namecoin resolution too there is no need to worry about protecting end users from that. There is, however, a need to protect users from man-in-the-middle attacks where the data is not modified en-route, but it is sniffed. Who you pay in a financial transaction is, and should be, privileged information between yourself and that person. By encouraging open DNS lookups you're effectively hanging that information out for all to see. It is true that there are only 4 DNSCrypt servers we are comfortable recommending. It is also true that there were, at one stage, only 4 Electrum servers. There were also only 4 Bitcoin nodes. As something grows and becomes more useful and usable the number of voluntary participants becomes much greater, and we will provide the necessary tools to enable these volunteers. So in a world where tens of thousands of Bitcoiners are using an aliasing standard (which, in and of itself, is a convenience service anyway), and hundreds of individuals and companies are hosting DNSCrypt resolvers, is it even a valid argument to harp on the number of proxies? Thus it is not worth talking about today. It is definitely worth discussing in future if the number of DNSCrypt resolvers doesn't increase, but that is a different discussion for a different time. For the highly privacy conscious they can, today do their DNS lookups over a non logging VPN connection without forcing everyone else through a handful of centralized servers. Or they can use DNSCrypt optionally themselves. All of our tools have always been open source and folks can modify them for their own desired uses, or submit pull requests with their own ideas. Everyone should be highly privacy conscious when it comes to financial transactions, and it would be unconscionable of both you and I not to defend end-user privacy. We'd love to hear others thoughts on this. While I believe that for now the centralization trade offs required to use DNSCrypt today (via a limited number of proxies) outweigh any perceived privacy benefits it provides, we are always open to what others in the community believe and have made modifications to how things work before as a result of feedback from industry participants. It's important to remember that the paranoid won't use an aliasing service, or at best will use a local Namecoin blockchain for that purpose. This is a convenience service to provide general and broad appeal for the non-technical, and those are the very people that need to be protected from nosey neighbours / workmates / ISPs. Privacy is not only (or even at all) about protecting people buying drugs on a darknet market, it is about defending personal liberties. I think DANE is a great idea. We were just discussing that with Andreas S., and are currently looking at whether we want to add this as optional versus mandatory, based on how widely available DANE is for folks using services like Cloudflare, Akamai, etc for their DNS, which many providers in the space today are. Of course, the security conscious could setup DANE on the URL we use AS IS. There is no need to create a special kv pair for this as is done in OpenAlias. As you know, DNSSEC and HTTPS support this today out of the box. Embedding the TLSA record in a KV pair just means that pinning takes one less step. The CA validation, in our case, is an ADDITIONAL signature based validation to the DNSSEC chain, not a
Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
I would prefer a dynamic solution that did not necessitate a second hard fork down the road. I propose doubling the block size every 100k blocks (~2 years) block 400,000 = 2MB (2016) block 500,000 = 4MB (2017) block 600,000 = 8MB (2018) Chris On Fri, Jul 17, 2015 at 1:57 PM, Ross Nicoll via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I'd back this if we can't find a permanent solution - 2MB gives us a lot more wiggle room in the interim at least; one of my concerns with block size is 3 transactions per second is absolutely tiny, and we need space for the network to search for an equilibrium between volume and pricing without risk of an adoption spike rendering it essentially unusable. I'd favour switching over by block height rather than time, and I'd suggest that given virtually every wallet/node out there will require testing (even if many do not currently enforce a limit and therefore do not need changing), 6 months should be considered a minimum target. I'd open with a suggestion of block 390k as a target. Ross On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote: Opening a mailing list thread on this BIP: BIP PR: https://github.com/bitcoin/bips/pull/173 Code PR: https://github.com/bitcoin/bitcoin/pull/6451 The general intent of this BIP is as a minimum viable alternative plan to my preferred proposal (BIP 100). If agreement is not reached on a more comprehensive solution, then this solution is at least available and a known quantity. A good backup plan. Benefits: conservative increase. proves network can upgrade. permits some added growth, while the community market gathers data on how an increased block size impacts privacy, security, centralization, transaction throughput and other metrics. 2MB seems to be a Least Common Denominator on an increase. Costs: requires a hard fork. requires another hard fork down the road. ___ bitcoin-dev mailing listbitcoin-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
I'd back this if we can't find a permanent solution - 2MB gives us a lot more wiggle room in the interim at least; one of my concerns with block size is 3 transactions per second is absolutely tiny, and we need space for the network to search for an equilibrium between volume and pricing without risk of an adoption spike rendering it essentially unusable. I'd favour switching over by block height rather than time, and I'd suggest that given virtually every wallet/node out there will require testing (even if many do not currently enforce a limit and therefore do not need changing), 6 months should be considered a minimum target. I'd open with a suggestion of block 390k as a target. Ross On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote: Opening a mailing list thread on this BIP: BIP PR: https://github.com/bitcoin/bips/pull/173 Code PR: https://github.com/bitcoin/bitcoin/pull/6451 The general intent of this BIP is as a minimum viable alternative plan to my preferred proposal (BIP 100). If agreement is not reached on a more comprehensive solution, then this solution is at least available and a known quantity. A good backup plan. Benefits: conservative increase. proves network can upgrade. permits some added growth, while the community market gathers data on how an increased block size impacts privacy, security, centralization, transaction throughput and other metrics. 2MB seems to be a Least Common Denominator on an increase. Costs: requires a hard fork. requires another hard fork down the road. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
