Watson Ladd [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2012-03-02 to 2017-02-25
💬 Posted a total of 11 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:56:43

- 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

- 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

- 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:36

- reply

2023-06-07 17:31:34

- reply

2023-06-07 15:16:38

- 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:46:55

- reply

📅 Original date posted:2012-12-05
📝 Original message:On Tue, Dec 4, 2012 at 9:23 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Tue, Dec 4, 2012 at 10:06 PM, Mike Koss <mike at coinlab.com> wrote:
>> I've implemented an alternative to the BIP 32 proposal. I wanted a system
>> based on a hierarchical string representation (rather than hierarchy of
>> integers as BIP 32 proposes). For example I name keys like this:
>>
>> [hd1.75491111].store.1. 1D7GM5dkUtxvGeWgn7SYtanBuyj1MD1EZy
>> [hd1.75491111].store.2. 1QAqDbzpNKViGSjVe1XmnGbmZtvz5hM7t1
>> [hd1.75491111].store.3. 14XkSN92QLGeorYPpoVbG87DQhowEx3mFn
>> [hd1.75491111].store.4. 1JLcGdod6Wm33rMZuZZUmAEE6osLhM4QMn
>>
>> First draft of proposal:
>>
>> https://gist.github.com/4211704
>
> As Pieter pointed out recently— it's not (realistically) possible to
> blindly iterate through strings. This means your proposal loses the
> backup recoverablity property which is part the point of a
> deterministic wallet: If you have a backup prior to a new string name
> being established you must also have a reliable backup of the string
> as well.
I would like to note that BIP32 and this new proposal have a missing
feature: being able to spend
a coin sent to an address generated by this scheme implies being able
to spend any coin generated
by this scheme.
The easiest deterministic wallet construction is simply to use a
stream cipher to generate random
bytes used as the private keys in a wallet. Hierarchical constructions
do not seem to me to add more,
other then distinguishing transactions by sending to unique addresses,
which could be done by other means.
>
> Of course, if you're backing up the strings then you can also backup a
> map equating the hdwallet indexes to your strings, and in the event of
> a catastrophic loss where you are only left with the original ultimate
> root you lose no coins (only metadata) with the BIP32 scheme. If,
> instead, we have your scheme and the backup of strings is incomplete
> then some or all assigned coin may be lost forever.
>
> Your extended hierarchy of multiplers also makes me uncomfortable.
> BIP32 uses a HMAC in its construction to obtain strongly unstructured
> points.
I read BIP32. And while the multipliers at each level are
unstructured, the ones in the next level are products
of the ones before i.e. we have a multiplication tree with random
looking branches.
Note that the order of the basepoint is prime or a small cofactor
times a prime, so this isn't an issue (usually:
the cofactor could be annoying).
--
"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

- 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 10:11:53

- reply

📅 Original date posted:2012-06-03
📝 Original message:On Sat, Jun 2, 2012 at 7:52 PM, Luke-Jr <luke at dashjr.org> wrote:
> Analysis, comments, constructive criticism, etc welcome for the following:
>
> ==Background==
> At present, an attacker can harm a pool by intentionally NOT submitting shares
> that are also valid blocks. All pools are vulnerable to this attack, whether
> centralized or decentralized and regardless of reward system used. The
> attack's effectiveness is proportional to ratio of the attacker's hashrate to
> the rest of the pool.
This attack has an obvious signature: getting outworked on the same
block as the pool was trying to verify, and always by the same person.
>
> There are obvious solutions that can be used to defeat this attack on
> centralized pools. For example, including a secret in the coinbase transaction
> that is accepted by the network as a partial preimage proof-of-work. All these
> solutions require changes to Bitcoin's proof-of-work acceptance terms, and
> since centralized pools can be harmful to the network's security, these rule
> changes are not likely to gain enough acceptance among the greater Bitcoin
> community.
>
> ==Proposed Solution==
> Please comment on the viability of this new proof-of-work algorithm, which I
> think should be viable for even decentralized pools:
>
> Blocks are accepted at a lower difficulty N (choosable by the pool; eg, the
> share difficulty) iff they are submitted with a candidate for the next block
> and SHA256(SHA256(NewBlockHash + NextBlockCandidateHash)) meets difficulty M.
> The relationship between M and N must be comparable to the normal network
> difficulty; details on the specifics of this can be figured out later, ideally
> by someone more qualified than me. M and N must be chosen prior to searching
> for the block: it should be safe to steal some always-zero bytes from the
> prevblock header for this.
So the goal is to prevent the attacker double-dipping by submitting
cycles to the pool, which if he
found a correct answer he could submit himself. I don't see how this
does that: if he finds a valid
block he finds a valid block. Only if the operator has a secret is
this prevented.
>
> This algorithm should guarantee that every share has an equal chance of being
> a valid block at the time it is found, and that which ones are actually blocks
> cannot be known until the subsequent block is found. Thus, attackers have no
> way to identify which shares to withhold even while they have full knowledge
> of the shares/blocks themselves.
This further delays the finalization of a transaction. That's not a good thing.
>
> ==Backward Compatibility==
> Obviously, this change creates a hard-fork in the blockchain. I propose that
> if it solves the block withholding risk, the gain is sufficient that the
> community may approve a hard-fork to take place 1-2 years from consensus.
>
> Since mining continues to use a double-SHA256 on a fixed 80 byte header,
> existing miners, FPGAs, etc should work unmodified. Poolservers will need to
> adapt significantly.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> 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
--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither Liberty nor Safety."
-- Benjamin Franklin

2023-06-07 03:12:34

- reply

📅 Original date posted:2012-03-11
📝 Original message:Dear all,
A draft of my paper is up at
http://wbl.github.com/bitcoinanon.pdf
Comments are welcome, as is discussion about implications I haven't thought of.
Sincerely,
Watson Ladd

2023-06-07 03:11:38

- reply

📅 Original date posted:2012-03-21
📝 Original message:On Wed, Mar 21, 2012 at 3:54 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Fri, Mar 2, 2012 at 2:57 PM, Watson Ladd <wbl at uchicago.edu> wrote:
>> 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.
>
>
> Here is an alternative protocol:
>
>
> N parties wish to purchase equal amounts of Bitcoin without the
> exchange being able to link their future transactions, they each put
> the relevant amount of gold/whatever up at the exchange.
>
> The exchange provides the exchanges public key, and the user provides
> a public key for signing. Externally the N participants agree on a
> collection of non-cooperating mixers (the mixers may actually just be
> the participants themselves, independent third parties, etc). Each
> participant generates a new bitcoin address, and encrypts it with the
> the public keys of the the exchange and all the mixers using an
> appropriate communicative homorophic scheme (or just a layers stack of
> regular encryption keys). The participants then combine their
> encrypted addresess into a block and hand it off to the mixing chain.
> Each mixer randomizes the order and decrypts all the messages with its
> key.
>
> At the end of the chain the exchange does the final decryption and
> presents a list of addresses to the involved users. Users validate
> that their address is in the set and sign the entire set. Once all
> involved users have signed, the exchange pays.
>
>
> This requires no changes to the Bitcoin system and could be trivially
> implemented by anyone interested. It provides anonymity which is
> strong so long as any one of the mixers is uncompromised. It has very
> low overhead. It is not directly resistant to disruption, but if
> participation in an identified round requires a key provided by the
> exchange, abusive users can be detected and excluded.
>
> Have I explained this clearly enough? I could probably implement the
> whole system it if its unclear.
>
> Can you contrast this with your proposal for me?
Contrasts
-My protocol works, your's doesn't. It's not enough to have a mix, the
mix needs to be verifiable to avoid
one of the mixers inserting their own key and removing a key that
should be in there. That doesn't mean you can't make your protocol
work with some more magic, but magic is required.
-You need a lot of online computation: the recipients need to be
involved with validating the mix. By contrast in mine you need to wait for
enough people to get their bitcoins to avoid partitioning. But this
might be a strength,
not a weakness.
-You avoid the problem of de-anonymizing through having the protocol
run incompletely: if the permutation is correctly computed the
transaction goes through.
-You also avoid all the problems with modifications to the bitcoin
clients and miners.
It's definitely a good alternative, once you fix the problem in 1.
On a related note, private keys and signatures have better proofs of
knowledge then hashes. Has this been considered in the P2SH
conversation? There might be ways to use this to make even better
methods for enhancing anonymity.
Sincerely,
Watson Ladd
--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither Liberty nor Safety."
-- Benjamin Franklin
--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither Liberty nor Safety."
-- Benjamin Franklin

2023-06-07 03:11:26

- reply

📅 Original date posted:2012-03-06
📝 Original message:On Tue, Mar 6, 2012 at 6:05 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Fri, Mar 2, 2012 at 2:57 PM, Watson Ladd <wbl at uchicago.edu> wrote:
>> 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.
>
> I believe I understand what the opcode does directly— it just
> validates an opaque signautre. I don't understand how it enables
> anonymous transactions.
>
> Can you spell this out for me?
One doesn't use this opcode as the sole thing to secure a transaction.
Instead this opcode prevents double spend attacks against
anonymization schemes. The idea is for Alice to give signatures to the
recipients of funds, all signatures being equivalent. To avoid this
from leading to a double-spend, we use a quorum method based on
showing earlier redemptions happened.
>
> In particular I don't see why it is not, from the perspective of the
> blockchain, isomorphic to a hash locked transaction. (This
> equivalence is more obvious when you think about how lamport
> signtures turn simple hashing into a one time signature).
Because you can't blind a lamport signature, it isn't. I'm searching
for a place to post the current draft: it's not ready for anything
official yet, but does seem to be of interest. Drop me a (offlist)line
if you have ideas about where I can put it.
Sincerely,
Watson Ladd
--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither Liberty nor Safety."
-- Benjamin Franklin

2023-06-07 03:11:17

- 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