<unnamed>

Public Key

npub108dfgewsuqzm6cvllzmxsv0xnn69rrjnyg5pa32a727k89ndh3xqmsr4hp

Profile Code

nprofile1qqs8nk55vhgwqpdavx0l3dngx8nfeaz33efjy2q7c4wl90trjekmcnqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsngyfnc

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 19:56:43 CEST

- 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:16:38 CEST

- 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 05:11:17 CEST

- 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