path: root/24/c8534a5ec2edc3caf8ef08906e9f02a76ed1d7

Return-Path: <damian@willtech.com.au>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5363BC0012;
 Thu,  9 Dec 2021 06:27:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 41E4982C9C;
 Thu,  9 Dec 2021 06:27:11 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.035
X-Spam-Level: 
X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1,
 RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001,
 SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665]
 autolearn=no autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=neutral
 reason="invalid (public key: not available)" header.d=willtech.com.au
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Hx_HEJ0yh29b; Thu,  9 Dec 2021 06:27:09 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from bat.birch.relay.mailchannels.net
 (bat.birch.relay.mailchannels.net [23.83.209.13])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 08C2C82C2E;
 Thu,  9 Dec 2021 06:27:08 +0000 (UTC)
X-Sender-Id: hostpapa|x-authuser|damian@willtech.com.au
Received: from relay.mailchannels.net (localhost [127.0.0.1])
 by relay.mailchannels.net (Postfix) with ESMTP id EBABD521009;
 Thu,  9 Dec 2021 06:27:07 +0000 (UTC)
Received: from s110.servername.online (unknown [127.0.0.6])
 (Authenticated sender: hostpapa)
 by relay.mailchannels.net (Postfix) with ESMTPA id 4CFD352163C;
 Thu,  9 Dec 2021 06:27:07 +0000 (UTC)
X-Sender-Id: hostpapa|x-authuser|damian@willtech.com.au
Received: from s110.servername.online (s110.servername.online [204.44.192.22])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384)
 by 100.127.242.165 (trex/6.4.3); Thu, 09 Dec 2021 06:27:07 +0000
X-MC-Relay: Junk
X-MailChannels-SenderId: hostpapa|x-authuser|damian@willtech.com.au
X-MailChannels-Auth-Id: hostpapa
X-Keen-Thoughtful: 5bde93c50782d8ca_1639031227792_637586518
X-MC-Loop-Signature: 1639031227791:2147802329
X-MC-Ingress-Time: 1639031227791
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=willtech.com.au; s=default; h=Content-Transfer-Encoding:Content-Type:
 Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender
 :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:
 Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:
 List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=qq5rqQ73qG4zh458tbeQzaTkE58HFkXc+K4Vnq7Izbk=; b=8nrKeEYd5LLDJGoOf6NT2LR+Dl
 B7tCoXBTy4q6xwE5TrMp1jGFWinkrNCxQTOKrX76D7vyG8xo2SENHvo2ByJIL5ms/v3HKi3LJxT/I
 To9AcsK+qrqGz6t5Kg3xej9UJvNm9cO7BLf3F07K0i2E/o2zCW20qif1RGT5YazIst0LtqGU6PD9p
 s/1xI3ZL57Dk2lg0923F3IsMH802/EG6riP8Ysrrp1kLwYCbGdOYCXRFwIB3IJclzVzUtnJadDH8T
 aLYWYeLqDNemdayE3x/6l5kypm4yzFKegRNYT+U70F4uFCEnudtgRejsFjq8MXRif02TmBx2HDuMM
 YZ5I9xCA==;
Received: from localhost ([127.0.0.1]:38724 helo=s110.servername.online)
 by s110.servername.online with esmtpa (Exim 4.94.2)
 (envelope-from <damian@willtech.com.au>)
 id 1mvCtV-00Ajd5-Q9; Wed, 08 Dec 2021 22:27:06 -0800
MIME-Version: 1.0
Date: Wed, 08 Dec 2021 22:27:04 -0800
From: damian@willtech.com.au
To: Ruben Somsen <rsomsen@gmail.com>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAPv7TjYTK=xrOxMbpD1JKQ1vTpiWWoOeGt86erFGBOP5grFYNA@mail.gmail.com>
References: <CAD5xwhid2OH0GzXPvqWgsMag4J9zidsewEquT-JoOweVD5pxZg@mail.gmail.com>
 <CACdvm3Oynv4gWdaGXATxc3SoYDD8kuiPq-d9F2itsmayP0qeZQ@mail.gmail.com>
 <CAPv7TjZBU2v2Nfw2_8Qz33rUWKJ=uJ7u+_5tFxjM94mk=RnmOA@mail.gmail.com>
 <CAD5xwhiSEoBxw=NVUHnZ+s22nTZhMoWYoDrC=aQfPyvwgtLrTQ@mail.gmail.com>
 <CAPv7TjYTK=xrOxMbpD1JKQ1vTpiWWoOeGt86erFGBOP5grFYNA@mail.gmail.com>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <32e6a20882fa13da03aa6238f5dfff69@willtech.com.au>
X-Sender: damian@willtech.com.au
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-AuthUser: damian@willtech.com.au
X-Mailman-Approved-At: Thu, 09 Dec 2021 09:17:05 +0000
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev]  Take 2: Removing the Dust Limit
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Dec 2021 06:27:11 -0000

Good Afternoon,

'Avoiding a soft-fork' is a political concession. Consensus is none of 
that.

KING JAMES HRMH
Great British Empire

Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills

et al.


Willtech
www.willtech.com.au
www.go-overt.com
and other projects

earn.com/willtech
linkedin.com/in/damianwilliamson


m. 0487135719
f. +61261470192


This email does not constitute a general advice. Please disregard this 
email if misdelivered.
On 2021-12-08 14:51, Ruben Somsen via bitcoin-dev wrote:
> Hi Jeremy,
> 
> Thanks for sharing your thoughts.
> 
> To summarize your arguments: the intentionally malicious path to
> getting the 0 sat output confirmed without being spent is uneconomical
> compared to simply creating dust outputs. And even if it does happen,
> the tx spending from the 0 sat output may still be valid (as long as
> none of its inputs get spent elsewhere) and could eventually get
> confirmed.
> 
> I think those are good points. I do still see a possibility where a
> user non-maliciously happens to behave in a way that causes all of the
> above to happen, but it does seem somewhat unlikely.
> 
> It could happen if all of the following occurs:
> 1. Another output happens to get spent at a higher feerate (e.g.
> because an absolute timelock expires and the output gets used)
> 2. The tx spending the 0 sat output then happens to not make it into
> the block due to the lower fees
> 3. The user then happens to invalidate the tx that was spending from
> the 0 sat output (seems rational at that point)
> 
> Assuming this is the only scenario (I am at least not currently aware
> of others), the question then becomes whether the above is acceptable
> in order to avoid a soft fork.
> 
> Cheers,
> Ruben
> 
> On Wed, Dec 8, 2021 at 6:41 PM Jeremy <jlrubin@mit.edu> wrote:
> 
>> IMO this is not a big problem. The problem is not if a 0 value ever
>> enters the mempool, it's if it is never spent. And even if C2/P1
>> goes in, C1 still can be spent. In fact, it increases it's feerate
>> with P1's confirmation so it's somewhat likely it would go in. C2
>> further has to be pretty expensive compared to C1 in order to be
>> mined when C2 would not be, so the user trying to do this has to pay
>> for it.
>> 
>> If we're worried it might never be spent again since no incentive,
>> it's rational for miners *and users who care about bloat* to save to
>> disk the transaction spending it to resurrect it. The way this can
>> be broken is if the txn has two inputs and that input gets spent
>> separately.
>> 
>> That said, I think if we can say that taking advantage of keeping
>> the 0 value output will cost you more than if you just made it above
>> dust threshold, it shouldn't be economically rational to not just do
>> a dust threshold value output instead.
>> 
>> So I'm not sure the extent to which we should bend backwards to make
>> 0 value outputs impossible v.s. making them inconvenient enough to
>> not be popular.
>> 
>> -------------------------------------
>> Consensus changes below:
>> -------------------------------------
>> 
>> Another possibility is to have a utxo with drop semantics; if UTXO X
>> with some flag on it is not spent in the block it is created, it
>> expires and can never be spent. This is essentially an inverse
>> timelock, but severely limited to one block and mempool evictions
>> can be handled as if a conflict were mined.
>> 
>> These types of 0 value outputs could be present just for attaching
>> fee in the mempool but be treated like an op_return otherwise. We
>> could add two cases for this: one bare segwit version (just the
>> number, no data) and one that's equivalent to taproot. This covers
>> OP_TRUE anchors very efficiently and ones that require a signature
>> as well.
>> 
>> This is relatively similar to how Transaction Sponsors works, but
>> without full tx graph de-linkage... obviously I think if we'll
>> entertain a consensus change, sponsors makes more sense, but
>> expiring utxos doesn't change as many properties of the tx-graph
>> validation so might be simpler.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev