public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Aaron Voisine <voisine@gmail.com>
To: Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	 Jonas Schnelli <dev@jonasschnelli.ch>,
	bfd@cock.lu
Subject: Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security
Date: Tue, 03 Jan 2017 22:18:21 +0000	[thread overview]
Message-ID: <CACq0ZD7XT_h8ADptKA0uBT7617fvvgh3uGndkc08RZUSQM2yQg@mail.gmail.com> (raw)
In-Reply-To: <74aeb4760316b59a3db56c0d16d11f28@cock.lu>

[-- Attachment #1: Type: text/plain, Size: 2769 bytes --]

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 <
bitcoin-dev@lists.linuxfoundation.org> 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.
>
> >
>
> > </jonas>
>
> >
>
> >
>
> > _______________________________________________
>
> > 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
>
>

[-- Attachment #2: Type: text/html, Size: 4405 bytes --]

  reply	other threads:[~2017-01-03 22:18 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-09  8:26 [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security bfd
2016-05-09  8:57 ` Gregory Maxwell
2016-05-11 20:06 ` Bob McElrath
2016-05-11 20:29   ` Bob McElrath
2016-07-28 21:07     ` Leo Wandersleb
2017-01-06 22:07       ` Erik Aronesty
2017-01-03 20:24     ` bfd
     [not found] ` <77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch>
2017-01-03 20:18   ` bfd
2017-01-03 22:18     ` Aaron Voisine [this message]
2017-01-03 22:28       ` bfd
2017-01-03 23:06       ` adiabat
2017-01-03 23:46         ` Aaron Voisine
2017-01-04  0:10           ` bfd
2017-01-04  0:36             ` Aaron Voisine
2017-01-04  6:06               ` Eric Voskuil
2017-01-04 16:13         ` Leo Wandersleb
2017-01-04  7:47       ` Jonas Schnelli
2017-01-04  8:56         ` Aaron Voisine
2017-01-04 10:13           ` Jorge Timón
2017-01-04 11:00             ` Adam Back
2017-01-06  2:15           ` bfd
2017-01-06  7:07             ` Aaron Voisine
2017-01-05  7:06         ` Chris Priest
2017-01-05  7:45           ` Eric Voskuil
2017-01-05 14:48             ` Christian Decker
2017-01-06 20:15             ` Chris Priest
2017-01-06 21:35               ` James MacWhyte
2017-01-06 21:50                 ` Eric Voskuil
2017-01-06  2:04           ` bfd
2017-03-15 22:36             ` Tom Harding
2017-03-16  0:25               ` bfd
2017-03-16 15:05                 ` Tom Harding
2017-02-17  0:28 ` Chris Belcher
2017-04-01 23:49   ` bfd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACq0ZD7XT_h8ADptKA0uBT7617fvvgh3uGndkc08RZUSQM2yQg@mail.gmail.com \
    --to=voisine@gmail.com \
    --cc=bfd@cock.lu \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=dev@jonasschnelli.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox