On Mon, May 29, 2017 at 12:10 PM, Peter Todd wrote:
> On Mon, May 29, 2017 at 10:55:37AM -0400, Russell O'Connor wrote:
> > Some of this proposal can be salvaged, I think, by putting the hash of
> the
> > tags into Sha256Compress's first argument:
> >
> > merkleRoot : Tree BitString -> Word25
Hi y'all,
Alex Akselrod and I would like to propose a new light client BIP for
consideration:
* https://github.com/Roasbeef/bips/blob/master/gcs_light_client.mediawiki
This BIP proposal describes a concrete specification (along with a
reference implementations[1][2][3]) for the much discussed
Thanks for sending this proposal! I look forward to having a great
discussion around this.
- Eric
On Thursday, June 1, 2017, Olaoluwa Osuntokun via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi y'all,
>
> Alex Akselrod and I would like to propose a new light client BIP for
> c
Quick comment before I finish reading it completely, looks like you have no way
to match the input prevouts being spent, which is rather nice from a "watch for
this output being spent" pov.
On June 1, 2017 3:01:14 PM EDT, Olaoluwa Osuntokun via bitcoin-dev
wrote:
>Hi y'all,
>
>Alex Akselrod an
Eric wrote:
> Thanks for sending this proposal! I look forward to having a great
> discussion around this.
Thanks Eric! We really appreciated the early feedback you gave on the
initial design.
One aspect which isn't in this BIP draft is direct support for unconfirmed
transactions. I consider such
On 06/01/2017 06:10 PM, Olaoluwa Osuntokun via bitcoin-dev wrote:
> One aspect which isn't in this BIP draft is direct support for unconfirmed
> transactions. I consider such a feature an important UX feature for mobile
> phones, and something which I've personally seen as an important
> UX-experi
On Fri, Jun 2, 2017 at 2:15 AM, Chris via bitcoin-dev
wrote:
> On 06/01/2017 06:10 PM, Olaoluwa Osuntokun via bitcoin-dev wrote:
>
>> One aspect which isn't in this BIP draft is direct support for unconfirmed
>> transactions. I consider such a feature an important UX feature for mobile
>> phones,
I agree with Greg and Laolu; BIP-37 filtering for transactions is no better
than for blocks and completely destroys privacy.
A constant stream of transactions is OK, but even cheaper for light clients
would be Laolu's proposal of streaming more tx data than existing inv
messages but less than exis
> In order to consider the average+median filter sizes in a world worth
larger
> blocks, I also ran the index for testnet:
>
> * total size: 2753238530
> * total avg: 5918.95736054141
> * total median: 60202
> * total max: 74983
> * regular size: 1165148878
> * regular
