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 38D9F9E2 for ; Wed, 6 Jun 2018 21:01:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 83E45761 for ; Wed, 6 Jun 2018 21:01:43 +0000 (UTC) Received: by mail-oi0-f44.google.com with SMTP id e8-v6so6592166oii.2 for ; Wed, 06 Jun 2018 14:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UO9ZagBo/U2Ek5jbYNf+E9OULBH16S1wsKcQ/oEEX/g=; b=ZGfBAajdH2QSTNI7UNnjrEAP/Uj8hBZ6oW2M+Yg+uPbF6yROJ7ceQtp+SYnOCGADu3 Gkylja4p4HAaTjiuqdBILcY5T1qDOpBkYEJXy1E4QY7nV5OtBwvPKMJYvNicUEMtkyFh ddGi9D34bBjLGR0EEwUFANY2cOfoZEszJxHuaN3aubn15BIFGfQDeaQgLV8W3ont2wx2 bkeK6OD+ecjkQwt3Ck0SiniHJ3adHegZkCZ5hS7+dwPpYYnBuQG7NAUntBvXKgKFl30P OiRZGhcScdtKrFTrCndJtF5LYlWeoWIfF5DaAtjI1DrejCL9ruDNBlbt+rpfQfpHzjvu yoeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UO9ZagBo/U2Ek5jbYNf+E9OULBH16S1wsKcQ/oEEX/g=; b=G+ljKbQJHtpU15cD+/c5xW/+XSPFAiODBREwgWWbhT3Q1hJbeExwWkAzGzlxuRt482 voD1Tmylo3CaLsWVJYMCGf4HBSgSPNg9jRxkmWqJV11ZEqmupiEHL3/LTeCvj3qiLhxJ tn0FXZK5ysVc3MnZtFbSUwkGxOmFep5mi1ntAu8wfO2s1HDYz+nF/3L8VQ5uma4vj69X m8fjrJFrqHqO6o3DLqV1wwRrkW8jW5xy0oD30Pe7mk4J45PiGlcDl0SuqCygdLwHT65x OKO2CSao5BmOJTdMTatnzgPQ7qjQ3podYBfCXzCDKNnJW2W2TqziXaOSh6MYPNZDP/dk tV5w== X-Gm-Message-State: APt69E2eeAAk2bwefkfd7bpliamq0VjMk+qGit0/WIZLUvVodIrLKFKQ DP/VkSmb/jYPM12DtpK3xjV401GUkPh4YtD6qko= X-Google-Smtp-Source: ADUXVKIcGitFxqG8DRcZIp8FxuXLJrA1VXALsuF0dOLpqxm476Y8DSi9eB+1h6rT258kLMmFttoP2iA1zHFbkoE2QY0= X-Received: by 2002:aca:3ad6:: with SMTP id h205-v6mr2385144oia.185.1528318902825; Wed, 06 Jun 2018 14:01:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:4a85:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 14:01:22 -0700 (PDT) In-Reply-To: <3bf1d66e-8ebb-d475-04c4-a6b2c0a06794@aei.ca> References: <3bf1d66e-8ebb-d475-04c4-a6b2c0a06794@aei.ca> From: Darren Weber Date: Wed, 6 Jun 2018 14:01:22 -0700 Message-ID: To: Thomas Guyot-Sionnest Content-Type: multipart/alternative; boundary="0000000000004e7734056dff7988" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 07 Jun 2018 14:01:47 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP suggestion: PoW proportional to block transaction sum 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, 06 Jun 2018 21:01:44 -0000 --0000000000004e7734056dff7988 Content-Type: text/plain; charset="UTF-8" Hi Thomas, Thanks for considering this suggestion. You've raised some interesting points (and concluded that it could be very difficult to implement). I'm not yet at a point where I could answer any questions about implementation details with any authority. With that caveat, your points are worth considering further and I will dwell on it for a bit. Best regards, Darren On Tue, Jun 5, 2018 at 3:50 AM, Thomas Guyot-Sionnest wrote: > On 30/05/18 12:17 PM, Darren Weber via bitcoin-dev wrote: > > > > Apologies for brevity, noob here and just throwing out an idea in case > > it's useful (probably already covered somewhere, but I haven't got > > time to do all the necessary background research). > > > > From https://github.com/bitcoin/bitcoin/issues/13342 > > > > Suggestion: To make it more difficult for a malicious attacker to > > reap quick rewards by double-spending large amounts with a relatively > > brief majority of the network hashing power, introduce a hash workload > > that is proportional to the sum of transactions in a block (probably > > the sum of the absolute values, and a "proportionality function" could > > be linear or exponential). The motivation is to make it more > > difficult for malicious attacks to hash-power their way through a few > > large transactions. Obviously, there are costs in greater transaction > > delays (and fees?) for larger amounts (absolute value). > > > > If there is original value in the idea, I can try to make time to > > follow-up with a better BIP proposal. > > > Hi Darren, > > I'm wondering how do you think this can be implemented... The problem > being that you cannot just decide to exclude transactions because you > found a lesser difficulty hash since that hash includes all transactions > already... Miners will either include or not these transactions based on > economical value, and since most of the rewards still comes from block > rewards there would be very little right now except with very high fees. > > Even worse, it may have detrimental side-effects: since there is no > distinctions between destination and change addresses, one can only > assume the transaction amount is the full input amount. Therefore users > would be inclined to keep large amount in lots of smaller addresses to > avoid being penalized on small transactions, increasing the UTXO size > for everybody. > > And besides, this is a huge change to swallow, requiring very good > consensus and a hard fork. IMHO I wouldn't even waste time on this. > > Regards, > > -- > Thomas > > > -- Darren L. Weber, Ph.D. http://psdlw.users.sourceforge.net/ http://psdlw.users.sourceforge.net/wordpress/ --0000000000004e7734056dff7988 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi=C2=A0Thomas,

Thanks fo= r considering this suggestion.=C2=A0 You've raised some interesting poi= nts (and concluded that it could be very difficult to implement).=C2=A0 I&#= 39;m not yet at a point where I could answer any questions about implementa= tion details with any authority.=C2=A0 With that caveat, your points are wo= rth considering further and I will dwell on it for a bit.

Best regards,
Darren


On Tue, Jun 5, 2018 at 3:50= AM, Thomas Guyot-Sionnest <dermoth@aei.ca> wrote:
On 30/05/18 12:17 PM, Darren Weber v= ia bitcoin-dev wrote:
>
> Apologies for brevity, noob here and just throwing out an idea in case=
> it's useful (probably already covered somewhere, but I haven't= got
> time to do all the necessary background research).
>
> From https://github.com/bitcoi= n/bitcoin/issues/13342
>
> Suggestion:=C2=A0 To make it more difficult for a malicious attacker t= o
> reap quick rewards by double-spending large amounts with a relatively<= br> > brief majority of the network hashing power, introduce a hash workload=
> that is proportional to the sum of transactions in a block (probably > the sum of the absolute values, and a "proportionality function&q= uot; could
> be linear or exponential).=C2=A0 The motivation is to make it more
> difficult for malicious attacks to hash-power their way through a few<= br> > large transactions.=C2=A0 Obviously, there are costs in greater transa= ction
> delays (and fees?) for larger amounts (absolute value).
>
> If there is original value in the idea, I can try to make time to
> follow-up with a better BIP proposal.
>
Hi Darren,

I'm wondering how do you think this can be implemented... The problem being that you cannot just decide to exclude transactions because you
found a lesser difficulty hash since that hash includes all transactions already... Miners will either include or not these transactions based on economical value, and since most of the rewards still comes from block
rewards there would be very little right now except with very high fees.
Even worse, it may have detrimental side-effects: since there is no
distinctions between destination and change addresses, one can only
assume the transaction amount is the full input amount. Therefore users
would be inclined to keep large amount in lots of smaller addresses to
avoid being penalized on small transactions, increasing the UTXO size
for everybody.

And besides, this is a huge change to swallow, requiring very good
consensus and a hard fork. IMHO I wouldn't even waste time on this.

Regards,

--
Thomas





--
--0000000000004e7734056dff7988--