From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0D5DCBB3 for ; Tue, 30 Jun 2015 00:52:02 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CAAB9F1 for ; Tue, 30 Jun 2015 00:52:00 +0000 (UTC) Received: by lagc2 with SMTP id c2so29466682lag.3 for ; Mon, 29 Jun 2015 17:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TzaE61dp2NJtQdO5J+bGZw68wKFiOeWCxe3/ZZ3P3VE=; b=cJDsIy9OY6c49d301tAJVMzGwecyBoMOxAOAKUKikbOsJNlh2ycl4nGT0OyePAlnyt NSjuNm4uikxz1UQzGadryDscGaWsLXCDVwP8h+nkja3PapJRJ+j5o/3kyA5oFCv+QUxI +XkxQE9Np4urgAdr63FlVq++2YIVIgI1qB0/4dy8cugvE5IH1opizXiaMTsTPajbdPUY e+O5WlHDVa8gKgbcuGtNq6QpuLWKcPEOHFRqOD/qg3aU3HUBRBF54blDNyCsIspyrb1O FayNXPf/VQltU9D/A6ieQBRf11Z4924i7rG7QbwUHYmOSmfoeu9tJrskfC9Bl6JQ8nbZ kXLA== MIME-Version: 1.0 X-Received: by 10.152.43.134 with SMTP id w6mr15261770lal.120.1435625518881; Mon, 29 Jun 2015 17:51:58 -0700 (PDT) Received: by 10.114.184.175 with HTTP; Mon, 29 Jun 2015 17:51:58 -0700 (PDT) Received: by 10.114.184.175 with HTTP; Mon, 29 Jun 2015 17:51:58 -0700 (PDT) In-Reply-To: <5591E10F.9000008@thinlink.com> References: <20150629050726.GA502@savin.petertodd.org> <5591E10F.9000008@thinlink.com> Date: Tue, 30 Jun 2015 02:51:58 +0200 Message-ID: From: Natanael To: Tom Harding Content-Type: multipart/alternative; boundary=001a11c1a8081564cc0519b19d3b X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 00:52:02 -0000 --001a11c1a8081564cc0519b19d3b Content-Type: text/plain; charset=UTF-8 Den 30 jun 2015 02:21 skrev "Tom Harding" : > > On 6/28/2015 10:07 PM, Peter Todd wrote: >> >> Worryingly large payment providers have shown >> willingness(4) to consider extreme measures such as entering into legal >> contracts directly with large miners to ensure their transactions get mined. >> This is a significant centralization risk and it is not practical or even >> possible for small miners to enter into these contracts, leading to a situation >> where moving your hashing power to a larger pool will result in higher profits >> from hashing power contracts; if these payment providers secure a majority of >> hashing power with these contracts inevitably there will be a temptation to >> kick non-compliant miners off the network entirely with a 51% attack. >> > > Your incomprehensible meddling with successful usage patterns threatens to have unintended consequences directly in opposition to your own stated goal of decentralization. And yet you persist. > > As we deliberately break things and turn the P2P network into a completely unpredictable hodge-podge of relay policies, we should expect many more participants to bypass the P2P network entirely. What you are asking for is TSA style reactive security and unverifiable and fundamentally untrustable security mechanisms, rejecting proactive security on the grounds that it is inconvenient. What you ask to see implemented will trivially fall to a sybil attack. It isn't securable. It is running on the honor system exclusively. It will be attacked, it will fail, losses will be had, the attackers will walk away with embarrassingly large sums. You want verifiable behavior? Incentives to tell the truth? Incentives to be consistent? Multisignature notaries (Greenaddress.it), payment channel based hub-and-spokes (LN, Stroem), etc... Trusting the P2P network is futile. You need one accountable party that is actually capable of enforcing the behavior you ask for, one that can build a reputation over time - the P2P nodes you wish to hold accountable are on the other hand powerless to stop an actual attack, their reputations are therefore meaningless and irrelevant. Multisignature notaries aren't, as they can stop an attack, and they can be sued for breach of contract if they don't - neither of those applies to P2P nodes. --001a11c1a8081564cc0519b19d3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Den 30 jun 2015 02:21 skrev "Tom Harding" <tomh@thinlink.com>:
>
> On 6/28/2015 10:07 PM, Peter Todd wrote:
>>
>> Worryingly large payment providers have shown
>> willingness(4) to consider extreme measures such as entering into = legal
>> contracts directly with large miners to ensure their transactions = get mined.
>> This is a significant centralization risk and it is not practical = or even
>> possible for small miners to enter into these contracts, leading t= o a situation
>> where moving your hashing power to a larger pool will result in hi= gher profits
>> from hashing power contracts; if these payment providers secure a = majority of
>> hashing power with these contracts inevitably there will be a temp= tation to
>> kick non-compliant miners off the network entirely with a 51% atta= ck.
>>
>
> Your incomprehensible meddling with successful usage patterns threaten= s to have unintended consequences directly in opposition to your own stated= goal of decentralization.=C2=A0 And yet you persist.
>
> As we deliberately break things and turn the P2P network into a comple= tely unpredictable hodge-podge of relay policies, we should expect many mor= e participants to bypass the P2P network entirely.

What you are asking for is TSA style reactive security and u= nverifiable and fundamentally untrustable security mechanisms, rejecting pr= oactive security on the grounds that it is inconvenient.

What you ask to see implemented will trivially fall to a syb= il attack. It isn't securable. It is running on the honor system exclus= ively. It will be attacked, it will fail, losses will be had, the attackers= will walk away with embarrassingly large sums.

You want verifiable behavior? Incentives to tell the truth? = Incentives to be consistent? Multisignature notaries (Greenaddress.it), pay= ment channel based hub-and-spokes (LN,=C2=A0 Stroem), etc... Trusting the P= 2P network is futile. You need one accountable party that is actually capab= le of enforcing the behavior you ask for, one that can build a reputation o= ver time - the P2P nodes you wish to hold accountable are on the other hand= powerless to stop an actual attack, their reputations are therefore meanin= gless and irrelevant. Multisignature notaries aren't, as they can stop = an attack, and they can be sued for breach of contract if they don't - = neither of those applies to P2P nodes.

--001a11c1a8081564cc0519b19d3b--