Lloyd Fournier

> I claim that the ability to find identical-prefix collisions in SHA1 outright breaks the rpsp property of SHA1 (not to mention the chosen-prefix collisions which are only 4x more...

> @LLFourn Pieter informed me that I misunderstood the rpsp and, that one message must be chosen prior to the prefix. So my claims about SHA1's identical-prefix attack implying the...

@sipa wrote: > @roconnor-blockstream That's a fair point, but at the same time, signing hardware shouldn't be signing things it doesn't understand, so even if BIP340 supports variable length messages,...

@gmaxwell @real-or-random thanks that gives me some better perspective. Reserving the 23(?) bytes in front of the message for domain separation of signatures (rather than hashes) sounds like a much...

I think even the existing specification has a problem with domain separation without even considering variable length messages. Let's say I am a crypto engineer working for a Bitcoin exchange...

> Is it accurate to say that if we only support 32-byte "messages" we should strongly recommend or require that those messages be SHA256 tagged hash values, and that if...

Hi @allisonmoyer I can give some commentary about where we're going with this. BDK is moving towards a v1.0 release. I made the first PR for this yesterday #793. The...

see also #974, #776, #1333. I have rough plan in #1333 for how to sort transaction in the way I think applications should display them which is by the first...

Hey @garydevenay. There's a lot of simplifications coming up for `v1.0` in how this is done. There are two things you need to be able to store: 1. Raw transaction...

The example above doesn't apply here since we don't insert script pubkeys in the database anyway as part of BDK's architecture atm. In general I think you can't get the...