Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C3776A7C for ; Wed, 12 Jul 2017 00:21:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com [209.85.220.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 27EC986 for ; Wed, 12 Jul 2017 00:21:08 +0000 (UTC) Received: by mail-qk0-f181.google.com with SMTP id v143so6928040qkb.0 for ; Tue, 11 Jul 2017 17:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=7sIS8Ez9umhdbV7zUzvoSPvoXU0Q3RoIuErDfEEnXbA=; b=nvT6cn39WA8W4yWtnhFibMvQtHWqYM1VbiZ7sKYIXyOzsBtpyeBL4K1kASiyGyMli1 /Uw+LaGZCeOHHSc5CUu2AFI3t14OyZeTPOZHUR1nwRVKQvvP4GQkX/cg9jIMOb29cDoR d3RoHacqLyJHj15Q34Skcm33E1FOcvQaOc+ebRs5G4hXhhOlmbU587xOhiHm0y96DaBh R9NELRx1SrIFh2sQaDsgMSTOjMcqFnV4IPgSbcjKBcfDZTedW1ZFriojI/4PMeWdpIuz dgiwG0/EYBeCm2Y4Riovdvrq3LhiwGYw2qUwoT8RRkRbfLAD46lWFRRowRrKOgQoHZ6n mBsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=7sIS8Ez9umhdbV7zUzvoSPvoXU0Q3RoIuErDfEEnXbA=; b=n9Wn82Q1SSYDH7LbYKem/NYXGk7Xfrxmt944v+EJ4ROb8rmy8y1mFHY7ogXpCeu0+S jYPn757JtGHMJYxCcb5aMPftFJCWfa4jeJSi7jctZeD+T6F+vmMKA1UjK4NI9B0EcyLv 65rfQk59siXQUuJSV8HGSFndnw1ooMS8zMWjHoWSOie3klvHKJdyWVpfR/jVF7DuihsU PD0Y0fGEFm0cb1EG/8tkm96/cuJSB+gDI/3PZh8vjKGMVKrnN0ESHWtbLEXam5uJYUaG Qqc36+JcSw25l3gJbVo8GE0O2BHKpEvlqHYDnKHFHHb+t9ZUvLfsx469y3XnRknQYiRz GTUA== X-Gm-Message-State: AIVw113WqfVqr63bvNPy9KF55SrzVdKRp2KS15hk9j5VcY6YfAI4JBpj oMB7DIO0DEW1PA== X-Received: by 10.55.142.67 with SMTP id q64mr3010056qkd.99.1499818867366; Tue, 11 Jul 2017 17:21:07 -0700 (PDT) Received: from [192.168.1.104] (ool-45726efb.dyn.optonline.net. [69.114.110.251]) by smtp.googlemail.com with ESMTPSA id l15sm661098qtb.51.2017.07.11.17.21.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 17:21:06 -0700 (PDT) To: Tao Effect References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com> <1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com> <08078429-089f-9315-2f76-a08121c5378c@gmail.com> From: Paul Sztorc Message-ID: Date: Tue, 11 Jul 2017 20:21:09 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------70E6B8F1939101E9A2607FCD" Content-Language: en-US X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 12 Jul 2017 00:37:38 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Updating the Scaling Roadmap X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 00:21:08 -0000 This is a multi-part message in MIME format. --------------70E6B8F1939101E9A2607FCD Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 7/11/2017 7:12 PM, Tao Effect wrote: > Paul, > > There is a difference between replying to an email, and addressing the > issues that were brought up in it. > > I did read your reply, and I chose not to respond to it because it did > not address anything I said. In that case you should clarify, which is exactly what you are doing now. > > Here's an example: > >> It would not be accurate to say that miners have "total" control. Miners >> do control the destination of withdrawals, but they do not control the >> withdrawal-duration nor the withdrawal-frequency. >> >> So, if miners wish to 'steal' from a sidechain, they _can_ initiate a >> theft, but they can not change the fact that their malfeasance will be >> [a] obvious, and [b] on display for a long period of time. > > Here, you admit that the security of the sidechains allows miners to > steal bitcoins, something they cannot do currently. If that were the case, then DC would need to be a hard fork. It so happens that it is *not* the case -- if users choose to deposit to an anyone-can-spend output, then miners can take the Bitcoins, which *is* something that miners can do currently. > > You next tried to equate three different types of theft, what you > called "Classic Theft", "Channel Theft", and "Drivechain Theft", saying: > >> I do not think that any of the three stands out as being categorically >> worse than the others > > To anyone who understands bitcoin, there is a very clear, > unmistakeable difference between double-spending ("Classic Theft"), > and *ownership* of the private key controlling the bitcoins. > > Similarly, to anyone who understands bitcoin, there is also a very > clear, unmistakeable difference between censorship ("Channel Theft"), > and *ownership* of the private key controlling the bitcoins. I am not sure what you are disagreeing with. The three thefts involve different attacker resources and behaviors, and in that way they are different. But in all three cases the user has lost the BTC they would have otherwise owned, and in that way they are not different. And users are under no obligation to use DC, just as they are under no obligation to open a LN channel (or use P2SH, etc). > > I am not sure how else to respond to that email, given that none of > the issues were really addressed. Other than your complaint about being freely given the option to upgrade to software which will give you the option to freely opt-in to a different security model that you can otherwise ignore, feel free to bring up any other issues you feel need to be addressed. > Drivechain is an unmistakeable weakening of Bitcoin's security > guarantees. This you have not denied. That is false. I do deny it. Per the logic of the soft fork, the security properties are at best unchanged (as I think almost everyone else on this list would acknowledge). And even for those users who opt-in, I feel the risk of theft is low, as I explain in the very passage you've quoted above. And please try to avoid going off-topic -- this is supposed to be about the idea of a new roadmap. Paul --------------70E6B8F1939101E9A2607FCD Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 7/11/2017 7:12 PM, Tao Effect wrote:
Paul,

There is a difference between replying to an email, and addressing the issues that were brought up in it.

I did read your reply, and I chose not to respond to it because it did not address anything I said.

In that case you should clarify, which is exactly what you are doing now.


Here's an example:

It would not be accurate to say that miners have "total" control. Miners
do control the destination of withdrawals, but they do not control the
withdrawal-duration nor the withdrawal-frequency.

So, if miners wish to 'steal' from a sidechain, they _can_ initiate a
theft, but they can not change the fact that their malfeasance will be
[a] obvious, and [b] on display for a long period of time.

Here, you admit that the security of the sidechains allows miners to steal bitcoins, something they cannot do currently.

If that were the case, then DC would need to be a hard fork. It so happens that it is *not* the case -- if users choose to deposit to an anyone-can-spend output, then miners can take the Bitcoins, which *is* something that miners can do currently.


You next tried to equate three different types of theft, what you called "Classic Theft", "Channel Theft", and "Drivechain Theft", saying:

I do not think that any of the three stands out as being categorically
worse than the others

To anyone who understands bitcoin, there is a very clear, unmistakeable difference between double-spending ("Classic Theft"), and *ownership* of the private key controlling the bitcoins.

Similarly, to anyone who understands bitcoin, there is also a very clear, unmistakeable difference between censorship ("Channel Theft"), and *ownership* of the private key controlling the bitcoins.

I am not sure what you are disagreeing with. The three thefts involve different attacker resources and behaviors, and in that way they are different. But in all three cases the user has lost the BTC they would have otherwise owned, and in that way they are not different.

And users are under no obligation to use DC, just as they are under no obligation to open a LN channel (or use P2SH, etc).


I am not sure how else to respond to that email, given that none of the issues were really addressed.
Other than your complaint about being freely given the option to upgrade to software which will give you the option to freely opt-in to a different security model that you can otherwise ignore, feel free to bring up any other issues you feel need to be addressed.

Drivechain is an unmistakeable weakening of Bitcoin's security guarantees. This you have not denied.
That is false. I do deny it. Per the logic of the soft fork, the security properties are at best unchanged (as I think almost everyone else on this list would acknowledge). And even for those users who opt-in, I feel the risk of theft is low, as I explain in the very passage you've quoted above.

And please try to avoid going off-topic -- this is supposed to be about the idea of a new roadmap.

Paul --------------70E6B8F1939101E9A2607FCD--