On Jun 29, 2016, at 3:01 AM, Gregory Maxwell wrote:
>
>> On Tue, Jun 28, 2016 at 11:33 PM, Eric Voskuil wrote:
>> I don't follow this comment. The BIP aims quite clearly at "SPV" wallets as
>> its justifying scenario.
>
> It cites SPV as an example, doesn't mention bloom filters.. and sure--
Hi Alfie,
Yes, this is exactly what I meant. The complexity of the proposed construction
is comparable to that of Bitcoin itself. This is not itself prohibitive, but it
is clearly worthy of consideration.
A question we should ask is whether decentralized anonymous credentials is
applicable to
> Yes, this is exactly what I meant. The complexity of the proposed
> construction is comparable to that of Bitcoin itself. This is not itself
> prohibitive, but it is clearly worthy of consideration.
>
> A question we should ask is whether decentralized anonymous credentials is
> applicable t
> On Jun 30, 2016, at 2:20 PM, Jonas Schnelli wrote:
>
>
>> Yes, this is exactly what I meant. The complexity of the proposed
>> construction is comparable to that of Bitcoin itself. This is not itself
>> prohibitive, but it is clearly worthy of consideration.
>>
>> A question we should ask
>>> The core problem posed by BIP151 is a MITM attack. The implied solution
>>> (BIP151 + authentication) requires that a peer trusts that another is not
>>> an attacker.
>>
>> BIP151 would increase the risks for MITM attackers.
>> What are the benefits for Mallory of he can't be sure Alice and
On Thu, Jun 30, 2016 at 11:57 AM, Eric Voskuil via bitcoin-dev
wrote:
> The proliferation of node identity is my primary concern - this relates to
> privacy and the security of the network.
I think this is a reasonable concern.
However, node identity is already being used widely, and in a very
I agree.
Encrypting links in a network without identity doesn't really seem to help
enough for the costs to be justified.
I would like to see a PGP-like "web of trust" proposal for both the
security of the bitcoin network itself /and/ (eventually) of things like
transmission of bitcoin addresses.
On Thu, Jun 30, 2016 at 09:36:57AM -0400, Erik Aronesty via bitcoin-dev wrote:
> Encrypting links in a network without identity doesn't really seem to help
> enough for the costs to be justified.
Passive is still better than none.
> I would like to see a PGP-like "web of trust" proposal for both
Pieter, these are in my opinion very reasonable positions. I've made some
observations inline.
> On Jun 30, 2016, at 3:03 PM, Pieter Wuille wrote:
>
> On Thu, Jun 30, 2016 at 11:57 AM, Eric Voskuil via bitcoin-dev
> wrote:
>> The proliferation of node identity is my primary concern - this rela
> On Jun 30, 2016, at 2:43 PM, Jonas Schnelli wrote:
>
The core problem posed by BIP151 is a MITM attack. The implied solution
(BIP151 + authentication) requires that a peer trusts that another is not
an attacker.
>>>
>>> BIP151 would increase the risks for MITM attackers.
>>>
On Thu, Jun 30, 2016 at 05:22:08PM +0200, Eric Voskuil via bitcoin-dev wrote:
>
> > On Jun 30, 2016, at 2:43 PM, Jonas Schnelli wrote:
> >
> The core problem posed by BIP151 is a MITM attack. The implied solution
> (BIP151 + authentication) requires that a peer trusts that another is
> On Jun 30, 2016, at 6:52 PM, Peter Todd wrote:
>
>> On Thu, Jun 30, 2016 at 05:22:08PM +0200, Eric Voskuil via bitcoin-dev wrote:
>>
>>> On Jun 30, 2016, at 2:43 PM, Jonas Schnelli wrote:
>>>
>> The core problem posed by BIP151 is a MITM attack. The implied solution
>> (BIP151 + a
On Thu, Jun 30, 2016 at 08:25:45PM +0200, Eric Voskuil wrote:
> > To be clear, are you against Bitcoin Core's tor support?
> >
> > Because node-to-node connections over tor are encrypted, and make use of
> > onion
> > addresses, which are self-authenticated in the exact same way as BIP151
> > pr
> On Jun 30, 2016, at 9:06 PM, Peter Todd wrote:
>
> On Thu, Jun 30, 2016 at 08:25:45PM +0200, Eric Voskuil wrote:
>>> To be clear, are you against Bitcoin Core's tor support?
>>>
>>> Because node-to-node connections over tor are encrypted, and make use of
>>> onion
>>> addresses, which are s
Ethan Heilman writes:
>>It's also not clear to me why the HMAC, vs just SHA256(key|cipher-type|mesg).
>> But that's probably just my crypto ignorance...
>
> SHA256(key|cipher-type|mesg) is an extremely insecure MAC because of
> the length extension property of SHA256.
>
> If I have a tag y = SHA2
15 matches
Mail list logo