From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id B5DA7C000D; Fri, 1 Oct 2021 13:40:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id A0F6B4023B; Fri, 1 Oct 2021 13:40:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-GiURVgTZhr; Fri, 1 Oct 2021 13:40:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by smtp2.osuosl.org (Postfix) with ESMTPS id 60FC2400D0; Fri, 1 Oct 2021 13:40:19 +0000 (UTC) Received: by mail-pj1-x102d.google.com with SMTP id oj15-20020a17090b4d8f00b0019f8860d6e2so290263pjb.5; Fri, 01 Oct 2021 06:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7JiZ1Ht8KdWvwN40N8LBSywCONVo6XuxA+02RHRvB0w=; b=lGrGR5BUKJNRmiHF93B8lZnkssdlNtCQXNjUyTbvy5rxSCV8ob/dHw/dSF9ZJUh5vI DaGYN7U//dQaCp9RS7q1W3U+XL6xJ7VhwNjZxmLlCcAT4hz5j++XdDdrzPA0ZINsNm1g kMBN7F4nBtWK7D7FCTlSLfDlLIMyz2a3sA3/FXNbyTYK0A7VZDsbzRbaVFlMH2nwxpZZ KiPWKwk9e1HDaPcv7vlyAXDlV1ahZg8g1kwN16FmyoP1leBvXdBKXp1Vv6IJ/kpUs1Ey yC9Bh4Nn3EBzYc/1jTAvtNiF2g74YJ2vb9A7zbb6vPC80y8/QZpiLDc9PEnbtjq828f3 Qvwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7JiZ1Ht8KdWvwN40N8LBSywCONVo6XuxA+02RHRvB0w=; b=07vSW+ugVisZ/6ncaWWfnVW6240ptm7pnttiTmYMPpf4kNkKUQ/jyu7QEO23zrkGEM U0prBhLS6pbP9UDZVtSdjASM0AWvhkOiNJ4JU3KHMM+cOt1GDgs+9ngDPFavH0G8A9tS Wbv3T+u6jpGCgH5xKx1DoQsQ1jfATo+QLkXnBw5VBChOloqhHihmDGul5Sz2UpVC6xxw c8C8AIwmIkCxMmVmzC8+CAA6mtwng5a03WjY/pIv6lJRUgSqgIw62Vr98o8pRWOyJPtb nBC/uDOGUlnpUENHnHT0hhAMH//h/lvAHPB8DDjhsmUIrz/O5Gr+FT0uvXrhVQ7RfjpI 8ghA== X-Gm-Message-State: AOAM533oBtj4LMOxh9Iy/EtlvMIWyS+4NK0TZBfbskHEZ796C8+nCmjj 63lchCwq4XvUVoAvPpZkJLxVEZff6k5VMSf6NZ1nycXZY5Xdqow= X-Google-Smtp-Source: ABdhPJzx3RoKoVJmuPB2vnVclTLjZ0UJRfDOLnF692WhZ3IBW8ZczGsT3Ep7fEwUWO+z5pKEvcjYG2jPdHQYbPNVXz0= X-Received: by 2002:a17:90a:8b8d:: with SMTP id z13mr490273pjn.0.1633095618467; Fri, 01 Oct 2021 06:40:18 -0700 (PDT) MIME-Version: 1.0 References: <20210808215101.wuaidu5ww63ajx6h@ganymede> In-Reply-To: From: Erik Aronesty Date: Fri, 1 Oct 2021 09:40:06 -0400 Message-ID: To: Pieter Wuille , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 01 Oct 2021 13:45:28 +0000 Cc: lightning-dev Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2021 13:40:20 -0000 mostly thinking out loud suppose there is a "lightweight" node: 1. ignores utxo's below the dust limit 2. doesn't validate dust tx 3. still validates POW, other tx, etc. these nodes could possibly get forked - accepting a series of valid, mined blocks where there is an invalid but ignored dust tx, however this attack seems every bit as expensive as a 51% attack On Fri, Oct 1, 2021 at 3:45 AM Pieter Wuille via bitcoin-dev wrote: > > Jumping in late to this thread. > > I very much agree with how David Harding presents things, with a few comm= ents inline. > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original = Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 > On Sunday, August 8th, 2021 at 5:51 PM, David A. Harding via bitcoin-dev = wrote: > > > > 1. it's not our business what outputs people want to create > > > > Every additional output added to the UTXO set increases the amount of > > work full nodes need to do to validate new transactions. For miners > > for whom fast validation of new blocks can significantly affect their > > revenue, larger UTXO sets increase their costs and so contributes > > towards centralization of mining. > > Allowing 0-value or 1-sat outputs minimizes the cost for polluting the > > UTXO set during periods of low feerates. > > If your stuff is going to slow down my node and possibly reduce my > > censorship resistance, how is that not my business? > > Indeed - UTXO set size is an externality that unfortunately Bitcoin's con= sensus rules fail to account > for. Having a relay policy that avoids at the very least economically irr= ational behavior makes > perfect sense to me. > > It's also not obvious how consensus rules could deal with this, as you do= n't want consensus rules > with hardcoded prices/feerates. There are possibilities with designs like= transactions getting > a size/weight bonus/penalty, but that's both very hardforky, and hard to = get right without > introducing bad incentives. > > > > 2. dust outputs can be used in various authentication/delegation sma= rt > > > contracts > > > > > 3. dust sized htlcs in lightning ( > > > https://bitcoin.stackexchange.com/questions/46730/can-you-send-am= ounts-that-would-typically-be-considered-dust-through-the-light) > > > force channels to operate in a semi-trusted mode > > > > > 4. thinly divisible colored coin protocols might make use of sats as= value > > > markers for transactions. > > My personal, and possibly controversial, opinion is that colored coin pro= tocols have no business being on the Bitcoin chain, possibly > beyond committing to an occasional batched state update or so. Both becau= se there is little benefit for tokens with a trusted > issuer already, and because it competes with using Bitcoin for BTC - the = token that pays for its security (at least as long as > the subsidy doesn't run out). > > Of course, personal opinions are no reason to dictate what people should = or can use the chain for, but I do think it's reason to > voice hesitancy to worsening the system's scalability properties only to = benefit what I consider misguided use. > > > > 5. should we ever do confidential transactions we can't prevent it w= ithout > > > compromising privacy / allowed transfers > > > > I'm not an expert, but it seems to me that you can do that with range > > proofs. The range proof for >dust doesn't need to become part of the > > block chain, it can be relay only. > > Yeah, range proofs have a non-hidden range; the lower bound can be nonzer= o, which could be required as part of a relay policy. > > Cheers, > > -- > Pieter > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev