<unnamed>

Public Key

npub108dfgewsuqzm6cvllzmxsv0xnn69rrjnyg5pa32a727k89ndh3xqmsr4hp

Profile Code

nprofile1qqs8nk55vhgwqpdavx0l3dngx8nfeaz33efjy2q7c4wl90trjekmcnqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsngyfnc

Publishing to

relay.primal.net

nos.lol

relay.damus.io

Last Notes

2023-06-07 17:56:43 UTC

- reply

📅 Original date posted:2017-02-25
📝 Original message:On Sat, Feb 25, 2017 at 11:12 AM, Peter Todd via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via bitcoin-dev wrote:
>> >SHA1 is insecure because the SHA1 algorithm is insecure, not because
>> 160bits isn't enough.
>>
>> I would argue that 160-bits isn't enough for collision resistance. Assuming
>> RIPEMD-160(SHA-256(msg)) has no flaws (i.e. is a random oracle), collisions
>
> That's something that we're well aware of; there have been a few discussions on
> this list about how P2SH's 160-bits is insufficient in certain use-cases such
> as multisig.
>
> However, remember that a 160-bit *security level* is sufficient, and RIPEMD160
> has 160-bit security against preimage attacks. Thus things like
> pay-to-pubkey-hash are perfectly secure: sure you could generate two pubkeys
> that have the same RIPEMD160(SHA256()) digest, but if someone does that it
> doesn't cause the Bitcoin network itself any harm, and doing so is something
> you choose to do to yourself.
P2SH is not secure against collision. I could write two scripts with
the same hash, one of which is an escrow script and the other which
pays it to me, have someone pay to the escrow script, and then get the
payment. Some formal analysis tools would ignore the unused
instructions even if human analysis would not.
>
> In any case, segwit will provide a 256-bit pay-to-witness-script-hash(1), which
> provides a 128-bit security level against collision attacks.
>
> 1) https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Native_P2WSH
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
"Man is born free, but everywhere he is in chains".
--Rousseau.

2023-06-07 17:47:44 UTC

- reply

📅 Original date posted:2016-01-08
📝 Original message:On Fri, Jan 8, 2016 at 4:38 AM, Gavin Andresen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Jan 8, 2016 at 7:02 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>
>> Matt Corallo <lf-lists at mattcorallo.com> 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 specific
>> SHA256 hash for the RIPEMD160 preimage.
>>
>> Even a preimage attack only helps if it leads to more than one preimage
>> fairly cheaply; that would make grinding out the SHA256 preimage easier.
>> AFAICT even MD4 isn't this broken.
>
>
> It feels like we've gone over that before, but I can never remember where or
> when. I believe consensus was that if we were using the broken MD5 in all
> the places we use RIPEMD160 we'd still be secure today because of Satoshi's
> use of nested hash functions everywhere.
>
>>
>> But just with Moore's law (doubling every 18 months), we'll worry about
>> economically viable attacks in 20 years.[1]
>>
>>
>> That's far enough away that I would choose simplicity, and have all SW
>> scriptPubKeys simply be "<0> RIPEMD(SHA256(WP))" for now, but it's
>> not a no-brainer.
>
>
> 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
> somebody. Victim gives their public key, attacker creates the innocent
> fund-locking script '2 V A 2 CHECKMULTISIG' (V is victim's public key, A is
> attacker's) but doesn't give it to the victim yet.
>
> Instead they then generate about 2^81scripts that are some form of
> pay-to-attacker ....
> ... wait, no that doesn't work, because SHA256 is used as the inner hash
> function. They'd have to generate 2^129 to find a cycle in SHA256.
For 2^80 they simply generate 2^80 scripts that look innocent, and
2^80 that are not. With high probability there is a collision. I agree
that most cryptanalysis won't work because of the nesting, but 2^80 is
not good.
>
> Instead, they .. what? I don't see a viable attack unless RIPEMD160 and
> SHA256 (or the combination) suffers a cryptographic break.
>
>
> --
> --
> Gavin Andresen
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
"Man is born free, but everywhere he is in chains".
--Rousseau.

2023-06-07 17:47:43 UTC

- reply

📅 Original date posted:2016-01-07
📝 Original message:On Jan 7, 2016 5:22 PM, "Gavin Andresen via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Thu, Jan 7, 2016 at 6:52 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
>>
>> Bitcoin does have parts that rely on economic arguments for security or
privacy, but can we please stick to using cryptography that is up to par
for parts where we can? It's a small constant factor of data, and it
categorically removes the worry about security levels.
>
> Our message may have crossed in the mod queue:
>
> "So can we quantify the incremental increase in security of
SHA256(SHA256) over RIPEMD160(SHA256) versus the incremental increase in
security of having a simpler implementation of segwitness?"
There are several clever ways to exploit even chosen prefix collisions
using the scripting language. One could search for collisions where one
message is some data and the other is a jump over a critical check.
>
> I believe the history of computer security is that implementation errors
and sidechannel attacks are much, much more common than brute-force breaks.
KEEP IT SIMPLE.
Ask the Iranian nuclear program. Or those brainwallet users.
>
> (and a quibble: "do a 80-bit search for B and C such that H(A and B) =
H(B and C)" isn't enough, you have to end up with a C public key for which
you know the corresponding private key or the attacker just succeeds in
burning the funds)
>
>
> --
> --
> Gavin Andresen
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160107/9bdcb94f/attachment-0001.html>

2023-06-07 17:31:34 UTC

- reply

2023-06-07 15:16:38 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:On Sat, Mar 29, 2014 at 10:10 AM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> On Saturday, 29 March 2014, at 2:36 pm, Mike Hearn wrote:
>> Right - the explanation in the BIP about the board of directors is IMO a
>> little misleading. The problem is with splitting a private key is that at
>> some point, *someone* has to get the full private key back and they can
>> then just remember the private key to undo the system. CHECKMULTISIG avoids
>> this.
>
> The implication is that every director would want to retain the board's private key for himself but also would want to prevent every other director from successfully retaining the private key for himself, leading to a perpetual stalemate in which no director ever gets to retain the private key.
This is not the case: one can use MPC techniques to compute a
signature from shares without reconstructing the private key. There is
a paper on this for bitcoin, but I don't know where it is.
>
>> I can imagine that there may be occasional uses for splitting a wallet seed
>> like this, like for higher security cold wallets, but I suspect an ongoing
>> shared account like a corporate account is still best off using
>> CHECKMULTISIG or the n-of-m ECDSA threshold scheme proposed by Ali et al.
>
> Multisig does not allow for the topology I described. Say the board has seven directors, meaning the majority threshold is four. This means the organization needs the consent of six individuals in order to sign a transaction: the president, the CFO, and any four of the board members. A 6-of-9 multisig would not accomplish the same policy, as then any six board members could successfully sign a transaction without the consent of the president or CFO. Of course the multi-signature scheme could be expanded to allow for hierarchical threshold topologies, or Shamir's Secret Sharing can be used to distribute keys at the second level (and further, if desired).
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither Liberty nor Safety."
-- Benjamin Franklin

2023-06-07 10:41:51 UTC

- reply

📅 Original date posted:2012-11-28
📝 Original message:After doing more thinking, what about letting a spend sign more information
associated with the transaction, such as a transaction ID provided by the
merchant? This seems to solve a lot of the problems being put forward, with
much less complexity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121128/588982d1/attachment.html>

2023-06-07 03:11:17 UTC

- reply

📅 Original date posted:2012-03-02
📝 Original message:Dear all,
I am proposing a new opcode for the purposes of anonymous
transactions. This new opcode enables scripts to be given proof that
the receiver can carry out or has carried out a previous transaction.
I'm currently working on a paper that discusses using this opcode for
anonymous transactions.
Name: OP_CHECKEXPSIG
Stack before: <sig><pk><hash>
Stack after: T/F, where is true if sig is a ECDSA signature under pk
for the hash hash. (Hash is the hash of a message).
Uses: Preexisting digital cash techniques relied on keeping track of a
list of turned in notes to forbid double spending. Using
OP_CHECKEXPSIG we can instead pass the script that gives the nth note
value proof that the notes {1,...n-1} were turned in and are distinct.
This enables a coupling of the strong double spend protection of
Bitcoin with traditional digital cash's strong anonymity.
Sincerely,
Watson Ladd