Re: [bitcoin-dev] User Activated Soft Fork Split Protection

On Wed, Jun 7, 2017 at 8:01 PM, Jared Lee Richardson wrote: >> If you're looking for hard numbers at this point you aren't likely to >> find them because not everything is easy to measure directly. > > There's quite a few hard numbers that are available that are of varying

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

Hi y'all, Thanks for all the comments so far! I've pushed a series of updates to the text of the BIP repo linked in the OP. The fixes include: typos, components of the specification which were incorrect (N is the total number of items, NOT the number of txns in the block), and a few sections

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

Gregory wrote: > I see the inner loop of construction and lookup are free of > non-constant divmod. This will result in implementations being > needlessly slow Ahh, sipa brought this up other day, but I thought he was referring to the coding loop (which uses a power of 2 divisor/modulus), not the

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

Tomas wrote: > A rough estimate would indicate this to be about 2-2.5x as big per block > as your proposal, but comes with rather different security > characteristics, and would not require download since genesis. Our proposal _doesnt_ require downloading from genesis, if by "downloading" you

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

> Correct me if I'm wrong, but from my interpretation we can't use that > method as described as we need to output 64-bit integers rather than > 32-bit integers. Had a chat with gmax off-list and came to the realization that the method _should_ indeed generalize to our case of outputting 64-bit

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

Karl wrote: > I am also curious if you have considered digests containing multiple > blocks. Retaining a permanent binsearchable record of the entire chain is > obviously too space costly, but keeping the last X blocks as binsearchable > could speed up syncing for clients tremendously, I feel.

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

On Thu, Jun 8, 2017 at 6:44 AM Conner Fromknecht wrote: > I don't normally post here, but I'm sorry, if you don't see those two as > equal, then I think you have misunderstood the *entire* value proposition > of cryptocurrencies. > > The state of any cryptocurrency should

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

On Thu, Jun 1, 2017, at 21:01, Olaoluwa Osuntokun via bitcoin-dev wrote:> 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> > Very interesting. I would like to

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

I don't normally post here, but I'm sorry, if you don't see those two as equal, then I think you have misunderstood the *entire* value proposition of cryptocurrencies. The state of any cryptocurrency should entirely (and only) be defined by its ledger. If the state of the system can be altered