Pieter Wuille via bitcoin-dev writes:
> On 05/03/2016 12:13 AM, lf-lists at mattcorallo.com (Matt Corallo) wrote:
>> Hi all,
>>
>> The following is a BIP-formatted design spec for compact block relay
>> designed to limit on wire bytes during block relay. You can find the
>> latest version of this
[9 May 16 @ 6:40 PDT]
For those interested in the hash collision attack discussion, it turns out
there is a faster way to scan your set to find the collision: you’d keep a
sorted list of the hashes for each TX you generate and then use binary search
to check that list for a collision for each
On Mon, May 9, 2016 at 11:37 PM, Peter R wrote:
> It is a standard result that there are
> m! / [n! (m-n)!]
> ways of picking n numbers from a set of m numbers, so there are
>
> (2^32)! / [2! (2^32 - 2)!] ~ 2^63
> possible pairs in a set of 2^32 transactions. So wouldn’t you have to
> pe
Greg Maxwell wrote:
> What are you talking about? You seem profoundly confused here...
>
> I obtain some txouts. I write a transaction spending them in malleable
> form (e.g. sighash single and an op_return output).. then grind the
> extra output to produce different hashes. After doing this 2^3
Hi Pieter,
> I tried to derive what length of short ids is actually necessary (some
> write-up is on
> https://gist.github.com/sipa/b2eb2e486156b5509ac711edd16153ed but it's
> incomplete).
>
> For any reasonable numbers I can come up with (in a very wide range),
> the number of bits needed is ver
On 05/03/2016 12:13 AM, lf-lists at mattcorallo.com (Matt Corallo) wrote:
> Hi all,
>
> The following is a BIP-formatted design spec for compact block relay
> designed to limit on wire bytes during block relay. You can find the
> latest version of this document at
> https://github.com/TheBlueMatt/
On Mon, May 9, 2016 at 8:57 AM, Tom via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> The moderators failed to catch his aggressive tone while moderating my post
> (see archives) for being too aggressive.
>
IIRC you were previously informed by moderators (on the same reddit thread
On Monday 09 May 2016 13:40:55 Peter Todd wrote:
> >> [It's a little disconcerting that you appear to be maintaining a fork
> >> and are unaware of this.]
> >
> >ehm...
>
> Can you please explain why you moved the above part of gmaxwell's reply to
> here,
A personal attack had no place in the tec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 9 May 2016 07:32:59 GMT-04:00, Tom via bitcoin-dev
wrote:
>On Monday 09 May 2016 10:43:02 Gregory Maxwell wrote:
>> Service bits are not generally a good mechanism for negating optional
>> peer-local parameters.
>
>Service bits are exactly the
On Monday 09 May 2016 10:43:02 Gregory Maxwell wrote:
> On Mon, May 9, 2016 at 9:35 AM, Tom Zander via bitcoin-dev
>
> wrote:
> > You misunderstand the networking effects.
> > The fact that your node is required to choose which one to set the
> > announce
> > bit on implies that it needs to predi
On Mon, May 9, 2016 at 11:32 AM, Tom wrote:
> On Monday 09 May 2016 10:43:02 Gregory Maxwell wrote:
>> On Mon, May 9, 2016 at 9:35 AM, Tom Zander via bitcoin-dev
>> wrote:
>> > You misunderstand the networking effects.
>> > The fact that your node is required to choose which one to set the
>> > a
On Mon, May 9, 2016 at 9:35 AM, Tom Zander via bitcoin-dev
wrote:
> You misunderstand the networking effects.
> The fact that your node is required to choose which one to set the announce
> bit on implies that it needs to predict which node will have the best data in
> the future.
Not required. I
On Sunday, May 08, 2016 03:24:22 AM Matt Corallo wrote:
> >> ===Intended Protocol Flow===
> >
> > I'm not a fan of the solution that a CNode should keep state and talk to
> > its remote nodes differently while announcing new blocks.
> > Its too complicated and ultimately counter-productive.
> >
>
On Mon, May 9, 2016 at 8:26 AM, bfd--- via bitcoin-dev
wrote:
> We introduce several concepts that rework the lightweight Bitcoin
> client model in a manner which is secure, efficient and privacy
> compatible.
[...]
> A Bloom Filter Digest is deterministically created of every block
I think this
We introduce several concepts that rework the lightweight Bitcoin
client model in a manner which is secure, efficient and privacy
compatible.
Thea properties of BIP37 SPV [0] are unfortunately not as strong as
originally thought:
* The expected privacy of the probabilistic nature of bloom
15 matches
Mail list logo
