{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-19\n📝 Original message:On Fri, Jun 19, 2015 at 09:18:54AM -0700, Adrian Macneil wrote:\n\u003e \u003e\n\u003e \u003e \u003e So connecting to many nodes just because we can and it's not technically\n\u003e \u003e \u003e prevented is bad for the network and creating systemic risks of failure,\n\u003e \u003e\n\u003e \u003e Well it is actually; that's why myself, Wladimir van der Laan, and\n\u003e \u003e Gregory Maxwell all specifically¹ called Chainalysis's actions a sybil\n\u003e \u003e attack.\n\u003e \u003e\n\u003e \u003e The Bitcoin P2P network is resilliant to failure when the chance of any\n\u003e \u003e one node going down is uncorrelated with others. For instance if you\n\u003e \u003e accidentally introduced a bug in your nodes that failed to relay\n\u003e \u003e transactions/blocks properly, you'd simultaneously be disrupting a large\n\u003e \u003e portion of the network all at once.\n\u003e \u003e\n\u003e \n\u003e This is exactly what your RBF patch is doing. By your own logic, nodes on\n\u003e the network should be allowed to relay (or not relay) whatever they wish.\n\nAh, seems you misunderstand the problem.\n\nBy properly we're concerned that things do get relayed, not that they do\nnot. In particularl with blocks a fairly to relay valid blocks will\nquickly lead to a loss of consensus.\n\n\u003e \u003e How many nodes is Coinbase connecting too? What software are they\n\u003e \u003e running? What subnets are they using? In particular, are they all on one\n\u003e \u003e subnet or multiple?\n\u003e \u003e\n\u003e \n\u003e We're running about a dozen nodes running regular Bitcoin Core in various\n\u003e subnets. We aren't doing anything particularly out of the ordinary here.\n\u003e Nothing that would fall under your definition of a sybil attack or harmful\n\u003e to the network.\n\nRight, so those dozen nodes, how many outgoing connections are they\nmaking?\n\n\u003e \u003e But of course, you'd never 51% the network right? After all it's not\n\u003e \u003e possible to guarantee that your miner won't mine double-spends, as there\n\u003e \u003e is no single consensus definition of which transaction came first, nor\n\u003e \u003e can there be.\n\u003e \u003e\n\u003e \u003e Or do you see things differently? If I'm a small miner should I be\n\u003e \u003e worried my blocks might be rejected by the majority with hashing power\n\u003e \u003e contracts because I'm unable to predict which transactions Coinbase\n\u003e \u003e believes should go in the blockchain?\n\u003e \u003e\n\u003e \n\u003e You seem so concerned that we are actively trying to harm or control the\n\u003e network. We're simply trying to drive bitcoin adoption by making it easy\n\u003e for people to spend their bitcoin with merchants online. The problems we\n\u003e face are no different from other merchant processors, or small independent\n\u003e merchants accepting online or point-of-sale payments.\n\u003e\n\u003e We've historically had relatively little interest in what miners were doing\n\u003e (until RBF came out) - for the most part it didn't affect our business.\n\u003e However, most large merchants would be simply uninterested in accepting\n\u003e bitcoin if we forced their customers to wait 10-60 minutes for their\n\u003e payments to confirm. Many have inventory management systems which can not\n\u003e even place items on hold that long.\n\nWhile your goals may be reasonable, again, the question is how are you\ngoing to achieve them? Do you accept that you may be in a position where\nyou can't guarantee confirmations? Again, what's your plan to deal with\nthis? For instance, I know Coinbase is contractually obliged to accept\nzeroconf payments with at least some of your customers - how strong are\nthose agreements?\n\nWhat we're worried about is your plan appears to include nothing\nconcrete beyond the possibility of getting contracts with hashing power,\nmaybe even just a majority of hashing power. This is something that\nshould concern everyone in the Bitcoin ecosystem, and it'd help if you\nclearly stated what your intentions are.\n\n-- \n'peter'[:-1]@petertodd.org\n00000000000000001128683847671e0ca022f9c74df90a3dc718545379101b72\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/654f5968/attachment.sig\u003e"}