On Fri, Jan 08, 2016 at 02:00:11PM +1030, Rusty Russell via bitcoin-dev wrote:
> Pieter Wuille via bitcoin-dev
> writes:
> > Yes, this is what I worry about. We're constructing a 2-of-2 multisig
> > escrow in a contract. I reveal my public key A, you do a 80-bit search for
> > B and C such that H(
On Thu, Jan 07, 2016 at 08:54:00PM -0500, Gavin Andresen via bitcoin-dev wrote:
> ---
>
> I'm really disappointed with the "Here's the spec, take it or leave it"
> attitude. What's the point of having a BIP process if the discussion just
> comes down to "We think more is better. We don't care what
BitGo also intends to support SegWit transactions as soon as possible.
- Jameson
On Thu, Jan 7, 2016 at 9:17 PM, Matthieu Riou via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Not strictly speaking a wallet but we (BlockCypher) will also go down the
> segwit path as soon as the
And to fend off the messag that I bet somebody is composing right now:
Yes, I know about a "security first" mindset. But as I said earlier in the
thread, there is a tradeoff here between crypto strength and code
complexity, and "the strength of the crypto is all that matters" is NOT
security firs
On Fri, Jan 8, 2016 at 10:46 AM, Gavin Andresen
wrote:
> And Ethan or Anthony: can you think of a similar attack scheme if you
> assume we had switched to Schnorr 2-of-2 signatures by then?
Don't answer that, I was being dense again, Anthony's scheme works with
Schnorr...
--
--
Gavin Andres
On Fri, Jan 8, 2016 at 10:50 AM, Gavin Andresen
wrote:
> But as I said earlier in the thread, there is a tradeoff here between
> crypto strength and code complexity, and "the strength of the crypto is all
> that matters" is NOT security first.
I should be more explicit about code complexity:
T
Thanks, Anthony, that works!
So...
How many years until we think a 2^84 attack where the work is an ECDSA
private->public key derivation will take a reasonable amount of time?
And Ethan or Anthony: can you think of a similar attack scheme if you
assume we had switched to Schnorr 2-of-2 signatur
On Fri, Jan 8, 2016 at 2:54 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I'm saying we can eliminate one somewhat unlikely attack (that there is a
> bug in the code or test cases, today or some future version, that has to
> decide what to do with "version 0"
On Fri, Jan 08, 2016 at 07:38:50AM -0500, Gavin Andresen via bitcoin-dev wrote:
> Lets see if I've followed the specifics of the collision attack correctly,
> Ethan (or somebody) please let me know if I'm missing something:
>
> So attacker is in the middle of establishing a payment channel with
>
Tricky choice. On the one hand I had spotted this too before and maybe
one or two more exceptions to bitcoin's 128-bit security target and
been vaguely tut-tutting about them in the background. It's kind of a
violation of crypto rule of thumb that you want to balance things and
not have odd weak p
On Fri, Jan 8, 2016 at 4:38 AM, Gavin Andresen via bitcoin-dev
wrote:
> On Fri, Jan 8, 2016 at 7:02 AM, Rusty Russell wrote:
>>
>> Matt Corallo writes:
>> > Indeed, anything which uses P2SH is obviously vulnerable if there is
>> > an attack on RIPEMD160 which reduces it's security only marginall
On Fri, Jan 8, 2016 at 7:02 AM, Rusty Russell wrote:
> Matt Corallo writes:
> > Indeed, anything which uses P2SH is obviously vulnerable if there is
> > an attack on RIPEMD160 which reduces it's security only marginally.
>
> I don't think this is true? Even if you can generate a collision in
>
Matt Corallo writes:
> Indeed, anything which uses P2SH is obviously vulnerable if there is
> an attack on RIPEMD160 which reduces it's security only marginally.
I don't think this is true? Even if you can generate a collision in
RIPEMD160, that doesn't help you since you need to create a specif
13 matches
Mail list logo
