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 D3608258 for ; Tue, 3 Jan 2017 22:29:00 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from cock.li (cock.li [185.100.85.212]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D06F5196 for ; Tue, 3 Jan 2017 22:28:59 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.1 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.lu; s=mail; t=1483482537; bh=cpzXVyEKuggClj0P5u8qxvnVr3/0TwMIHA247OnYeV0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=xW1M5h6IKebYZASoY+KCgeYKI5gqzFYowY+D+GPCci8fL4mW8PLW180qZyEEcSlTI J20mlxgK3/jJJ9bEpQYF8tDXtsz5qFua7vdCy0MtJA5hU7Nfp/8g0MjSF0YhefjltS Vi8L7lTG9l9HooLlGTdgCC6PcuRRqmzpSBJQR4PTcvZNd7Jo3H6L7YVZzeDmQdj1IQ 4MG7nAT21R+jZ2p2gi9ukDg604VsmFzhZvKxeahJOHScaPCEA9z14DUQbDT1AWjUov pgG+d/3YAsPaEUt4MJA5OIpa3EO6+AGusEBRJu3YjgcahAgUaAYOEEJTWgpZY2Qv4u 2GSjd+KxMjByw== Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 03 Jan 2017 14:28:56 -0800 From: bfd@cock.lu To: Aaron Voisine In-Reply-To: References: <71d822e413ac457a530e1c367811cc24@cock.lu> <77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch> <74aeb4760316b59a3db56c0d16d11f28@cock.lu> Message-ID: X-Sender: bfd@cock.lu User-Agent: Roundcube Webmail/1.2.3 X-Mailman-Approved-At: Tue, 03 Jan 2017 23:25:59 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security 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: Tue, 03 Jan 2017 22:29:01 -0000 The concept was not particularly targeted towards businesses, but allowing for significantly improved wallet performance and reducing privacy for lite clients. You would expect that a business has the capacity to run a fully validating, fully storing node of their own. If they’re not something is fundamentally broken with Bitcoin, or their rationale of continuing to use it. On 2017-01-03 14:18, Aaron Voisine wrote: > Unconfirmed transactions are incredibly important for real world use. > Merchants for instance are willing to accept credit card payments of > thousands of dollars and ship the goods despite the fact that the > transaction can be reversed up to 60 days later. There is a very large > cost to losing the ability to have instant transactions in many or > even most situations. This cost is typically well above the fraud > risk. > > It's important to recognize that bitcoin serves a wide variety of use > cases with different profiles for time sensitivity and fraud risk. > > Aaron > > On Tue, Jan 3, 2017 at 12:41 PM bfd--- via bitcoin-dev > wrote: > >> The concept combined with the weak blocks system where miners commit >> >> to potential transaction inclusion with fractional difficulty blocks >> >> is possible. I'm not personally convinced that unconfirmed >> transaction >> >> display in a wallet is worth the privacy trade-off. The user has >> very >> >> little to gain from this knowledge until the txn is in a block. >> >> On 2017-01-01 13:01, Jonas Schnelli via bitcoin-dev wrote: >> >>> Hi >> >>>> We introduce several concepts that rework the lightweight Bitcoin >> >>>> client model in a manner which is secure, efficient and privacy >> >>>> compatible. >> >>>> >> >>>> The BFD can be used verbatim in replacement of BIP37, where the >> filter >> >>>> can be cached between clients without needing to be recomputed. >> It can >> >>>> also be used by normal pruned nodes to do re-scans locally of >> their >> >>>> wallet without needing to have the block data available to scan, >> or >> >>>> without reading the entire block chain from disk. >> >>> I started exploring the potential of BFD after this specification. >> >>> >> >>> What would be the preferred/recommended way to handle >> 0-conf/mempool >> >>> filtering – if & once BDF would have been deployed (any type, >> >>> semi-trusted oracles or protocol-level/softfork)? >> >>> >> >>> From the user-experience perspective, this is probably pretty >> important >> >>> (otherwise the experience will be that incoming funds can take >> serval >> >>> minutes to hours until they appear). >> >>> Using BIP37 bloom filters just for mempool filtering would >> obviously >> >>> result in the same unwanted privacy-setup. >> >>> >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> bitcoin-dev mailing list >> >>> bitcoin-dev@lists.linuxfoundation.org >> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> _______________________________________________ >> >> bitcoin-dev mailing list >> >> bitcoin-dev@lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev