Nathan Cook [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-01-09 to 2019-05-23
💬 Posted a total of 8 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 20:18:13

- reply

📅 Original date posted:2019-05-23
📝 Original message:You're right, I didn't remember the whole procedure. You provide the
80-byte header in the spend script, duplicate it on the stack, hash it, and
compare to what OP_CHECKBLOCKATHEIGHT gives you. Then you do bit masking on
the header with OP_AND to extract the difficulty. You can compare two
compressed difficulties directly by using more bit masking to separate the
exponent and mantissa.
On Thu, 23 May 2019 at 22:54, Tamas Blummer <tamas.blummer at gmail.com> wrote:
> Block hash can suggest much higher difficulty than what is in effect, so
> OP_CHECKBLOCKATHEIGHT would not work to decide if difficulty is above the
> level of the bet.
>
> > On May 23, 2019, at 21:45, Tamas Blummer <tamas.blummer at gmail.com>
> wrote:
> >
> > I see. The uncompressing needs to be done either to compare. How are
> chances for that BIP?
> >
> > This BIP would be explicitly offering risk managment of miners biggest
> risk.
> > Doing so without relying on external markets or oracle, self cointained
> would be an impressive and adequate feature.
> >
> > Tamas Blummer
> >
> >> On May 23, 2019, at 21:21, Nathan Cook <nathan.cook at gmail.com> wrote:
> >>
> >> It's true that it fetches the block hash; the idea is to compare the
> block hash's numeric value to the desired (uncompressed) difficulty
> directly, using a 256-bit version of OP_LESSTHAN.
> >>
> >> Nathan Cook
> >>
> >>
> >> On Thu, 23 May 2019 at 22:18, Tamas Blummer <tamas.blummer at gmail.com>
> wrote:
> >> That opcode would not help as it fetches block hash and not the content
> of the header.
> >>
> >>> On May 23, 2019, at 21:05, Nathan Cook <nathan.cook at gmail.com> wrote:
> >>>
> >>> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by
> Luke Dashjr (
> https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki) if you
> also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN. See
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html
> and the ensuing thread.
> >>>
> >>> Nathan Cook
> >>>
> >>>
> >>> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>> Difficulty change has profound impact on miner’s production thereby
> introduce the biggest risk while considering an investment.
> >>> Commodity markets offer futures and options to hedge risks on
> traditional trading venues. Some might soon list difficulty futures.
> >>>
> >>> I think we could do much better than them natively within Bitcoin.
> >>>
> >>> A better solution could be a transaction that uses nLocktime
> denominated in block height, such that it is valid after the difficulty
> adjusted block in the future.
> >>> A new OP_DIFFICULTY opcode would put onto stack the value of
> difficulty for the block the transaction is included into.
> >>> The output script may then decide comparing that value with a strike
> which key can spend it.
> >>> The input of the transaction would be a multi-sig escrow of those who
> entered the bet.
> >>> The winner would broadcast.
> >>>
> >>> Once signed by both the transaction would not carry any counterparty
> risk and would not need an oracle to settle according to the bet.
> >>>
> >>> I plan to draft a BIP for this as I think this opcode would serve
> significant economic interest of Bitcoin economy, and is compatible with
> Bitcoin’s aim not to introduce 3rd party to do so.
> >>>
> >>> Do you see a fault in this proposal or want to contribute?
> >>>
> >>> Tamas Blummer
> >>>
> >>> _______________________________________________
> >>> 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/20190523/d5bd334b/attachment-0001.html>

2023-06-07 20:18:13

- reply

2023-06-07 20:18:12

- reply

📅 Original date posted:2019-05-23
📝 Original message:It's true that it fetches the block hash; the idea is to compare the block
hash's numeric value to the desired (uncompressed) difficulty directly,
using a 256-bit version of OP_LESSTHAN.
Nathan Cook
On Thu, 23 May 2019 at 22:18, Tamas Blummer <tamas.blummer at gmail.com> wrote:
> That opcode would not help as it fetches block hash and not the content of
> the header.
>
> On May 23, 2019, at 21:05, Nathan Cook <nathan.cook at gmail.com> wrote:
>
> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke
> Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki)
> if you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN.
> See
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html and
> the ensuing thread.
>
> Nathan Cook
>
>
> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Difficulty change has profound impact on miner’s production thereby
>> introduce the biggest risk while considering an investment.
>> Commodity markets offer futures and options to hedge risks on traditional
>> trading venues. Some might soon list difficulty futures.
>>
>> I think we could do much better than them natively within Bitcoin.
>>
>> A better solution could be a transaction that uses nLocktime denominated
>> in block height, such that it is valid after the difficulty adjusted block
>> in the future.
>> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty
>> for the block the transaction is included into.
>> The output script may then decide comparing that value with a strike
>> which key can spend it.
>> The input of the transaction would be a multi-sig escrow of those who
>> entered the bet.
>> The winner would broadcast.
>>
>> Once signed by both the transaction would not carry any counterparty risk
>> and would not need an oracle to settle according to the bet.
>>
>> I plan to draft a BIP for this as I think this opcode would serve
>> significant economic interest of Bitcoin economy, and is compatible with
>> Bitcoin’s aim not to introduce 3rd party to do so.
>>
>> Do you see a fault in this proposal or want to contribute?
>>
>> Tamas Blummer
>>
>> _______________________________________________
>> 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/20190523/af280d71/attachment-0001.html>

2023-06-07 20:18:12

- reply

📅 Original date posted:2019-05-23
📝 Original message:You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke
Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki)
if you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN.
See
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html
and
the ensuing thread.
Nathan Cook
On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Difficulty change has profound impact on miner’s production thereby
> introduce the biggest risk while considering an investment.
> Commodity markets offer futures and options to hedge risks on traditional
> trading venues. Some might soon list difficulty futures.
>
> I think we could do much better than them natively within Bitcoin.
>
> A better solution could be a transaction that uses nLocktime denominated
> in block height, such that it is valid after the difficulty adjusted block
> in the future.
> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty
> for the block the transaction is included into.
> The output script may then decide comparing that value with a strike which
> key can spend it.
> The input of the transaction would be a multi-sig escrow of those who
> entered the bet.
> The winner would broadcast.
>
> Once signed by both the transaction would not carry any counterparty risk
> and would not need an oracle to settle according to the bet.
>
> I plan to draft a BIP for this as I think this opcode would serve
> significant economic interest of Bitcoin economy, and is compatible with
> Bitcoin’s aim not to introduce 3rd party to do so.
>
> Do you see a fault in this proposal or want to contribute?
>
> Tamas Blummer
>
> _______________________________________________
> 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/20190523/3cb49dd5/attachment-0001.html>

2023-06-07 20:18:12

- reply

2023-06-07 20:18:12

- reply

2023-06-07 20:02:20

- reply

📅 Original date posted:2017-06-12
📝 Original message:The problem with >100kb transactions isn't that there are a lot of
already-signed transactions out there, or even that there are good use
cases for them, but that such transactions and use cases could exist, and
there is no way of disallowing them without possibly costing someone a lot
of money. Slowly reducing the limit doesn't really solve this problem.
I propose to make them hard enough to confirm that no-one will use them
without a very good reason. Just require that any block containing an
outsized transaction be mined at a greater difficulty – quadratically
greater. Such a block is more expensive *for the block's miner*, not just
for the other miners, or for other nodes. Anyone who really, really needs
to use a 400kb transaction can pay a miner to mine it.
Quadratic hashing isn't risky when it is inherently limited by a
corresponding reduction in the rate at which the "bad" blocks can be
generated. That said, there's nothing I can see which is actually good
about large, expensive to validate transactions, and so >1MB transactions
should remain invalid, as they are today.
Nathan Cook
On 2 June 2017 at 22:40, Jared Lee Richardson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has
> quadratic hashing risks, and maybe James' 10KB is too ambitious; but even
> if so, a simple 1MB tx size limit would clearly do the trick. The broader
> point is that quadratic hashing is not a compelling reason to keep
> blockmaxsize post-HF: does someone have a better one?
>
> I think this is exactly the right direction to head. There are
> arguments to be made for various maximum sizes... Maybe the limit
> could be set to 1mb initially, and at a distant future block
> height(years?) automatically drop to 500kb or 100kb? That would give
> anyone with existing systems or pre-signed transactions several years
> to adjust to the change. Notification could (?possibly?) be done with
> a non-default parameter that must be changed to continue to use 100kb
> - <1mb transactions, so no one running modern software could claim
> they were not informed when that future date hits.
>
> I don't see any real advantages to continuing to support transactions
> larger than 100kb excepting the need to update legacy use cases /
> already signed transactions.
>
> On Tue, May 30, 2017 at 8:07 PM, Jacob Eliosoff via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has
> > quadratic hashing risks, and maybe James' 10KB is too ambitious; but
> even if
> > so, a simple 1MB tx size limit would clearly do the trick. The broader
> > point is that quadratic hashing is not a compelling reason to keep
> > blockmaxsize post-HF: does someone have a better one?
> >
> >
> >
> > On May 30, 2017 9:46 PM, "Jean-Paul Kogelman via bitcoin-dev"
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> That would invalidate any pre-signed transactions that are currently out
> >> there. You can't just change the rules out from under people.
> >>
> >>
> >> On May 30, 2017, at 4:50 PM, James MacWhyte via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >>
> >>>
> >>> The 1MB classic block size prevents quadratic hashing
> >>> problems from being any worse than they are today.
> >>>
> >>
> >> Add a transaction-size limit of, say, 10kb and the quadratic hashing
> >> problem is a non-issue. Donezo.
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> 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/20170612/4a6e1479/attachment.html>

2023-06-07 19:57:55

- reply

📅 Original date posted:2017-03-25
📝 Original message:Further to recent posts to this list concerning mining with more than one
hash function, Adam Perlow and me have a (longish) proposal/analysis on
combining multi-hash with bitcoin stake voting on what the mix of hashes
should be. Two novelties are:
* Targeting a ratio of blocks mined under each hash function, in a similar
way to difficulty targeting.
* Analysis of voting on this ratio in terms of "voting on a simplex", using
extant research to choose a good method of doing so.
One point about mining under multiple hashes is that it offers existing
miners a way back in after a contentious hard fork. Shame to waste all that
hardware…
Read at
http://topynate.net/wp-content/uploads/2017/03/proportionateresponse.pdf
(archived at http://www.webcitation.org/6pEZLlZoW)
Nathan Cook
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170325/ae48937d/attachment.html>

2023-06-07 19:53:40

- reply

📅 Original date posted:2016-10-04
📝 Original message:On 1 October 2016 at 08:02, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Saturday, October 01, 2016 4:01:04 AM Rusty Russell wrote:
>
> > - Otherwise <bits> of hash is compared to lower <bits> of blockhash.
>
> Lower in what endian? Why only that endian? Why only lower? I can see a
> possible use case where one wants to look at only the high bits to ensure
> their transaction is only valid in a block with at least a certain
> difficulty...
Why not use segwit versioning for all this stuff? That lets you re-enable
the bitwise operations like OP_AND, permitting arbitrary bit-masks.
Further, the "at least a certain difficulty" problem suggests a solution by
extending the validity of opcodes like OP_LESSTHAN etc. to 256-bit inputs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161005/c0497d3f/attachment.html>

2023-06-07 17:36:31

- reply

📅 Original date posted:2015-06-02
📝 Original message:On 2 June 2015 at 14:26, Mike Hearn <mike at plan99.net> wrote:
> But the majority of the hashrate can now perform double spends on your
>> chain! They can send bitcoins to exchanges, sell it, extract the money and
>> build a new longer chain to get their bitcoins back.
>>
> Obviously if the majority of the mining hash rate is doing double spending
> attacks on exchanges then the Bitcoin experiment is resolved as a failure
> and it will become abandoned. This has been known since day one: it's in
> the white paper. The basic assumption behind Bitcoin is that only a
> minority of actors are dishonest - if the majority are then Satoshi's
> scheme does not work.
>
> So you are not stating anything new here.
>
It's both consistent and credible for an agent to commit to honesty on a
chain that it openly supports and dishonesty on a chain that it openly
opposes. (Moral? Legal? Perhaps not.) That said, majority hashpower doesn't
need to be dishonest to stop a change to large blocks. It just needs to
refuse to build on blocks that it doesn't like. The minority isn't going to
mine blocks larger than 1MB if it knows they'll be orphaned.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150602/727c8409/attachment.html>

2023-06-07 17:28:23

- reply

📅 Original date posted:2015-01-09
📝 Original message:A limitation on most existing micropayment channel ideas is that payments
can only flow in one direction. This is because the payment receiver can
sign -any- transaction you send them, not just the most recent one, and so
it's possible to just sign the transaction transferring the largest amount
into their control. This is easily remedied by opening a second payment
channel in the opposite direction, but now both parties have to deposit
funds over the lifetime of the two channels. If one party doesn't know
ahead of time whether or not the other party will go into credit, having
only one channel may save the use of a deposit.
I propose a way of using CHECKLOCKTIMEVERIFY to allow a reversible payment
channel, introducing at most one additional broadcast transaction, with a
waiting period before the payment receiver can access deposited funds. The
extra transaction and waiting period apply only when the depositor doesn't
co-operate with the receiver.
In this protocol, the setup is identical, with a deposit made to a P2SH
address matching a script allowing either single-party+CHECKLOCKTIME or
2-of-2. In this case, however, payments made by the depositor occur in the
form of unbroadcast transactions to special -holding addresses-.
These holding addresses are themselves P2SH addresses, with scripts known
to both parties. Each script may be redeemed in one of two ways:
by the payment receiver, using their signature with a CHECKLOCKTIME
restriction that expires some period of time after the restriction on the
depositor's refund transaction, or
by the depositor, using their own signature, together with a hashlock.
In the second case, we actually use a double hashlock, i.e. the depositor
must provide a value which when SHA256-hashed twice produces the value in
the script.
The receiver generates these values according to the following algorithm:
Beginning with a secret S_0, they double hash S_0 to make the hashlock
value for the first payment, D_0 =H(H(S_0)). Then to make S_i+1 given S_i,
they create a public nonce, N_i, and let S_i+1 = H(N_i | H(S_i)), where a|b
denotes the string a followed by the string b. The hashlock values D_i are
not secret, and can be disclosed in advance or as part of the process of
receiving the associated payment.
When the receiver wants to refund some amount to the depositor, the
receiver finds the last payment which left the depositor with a balance
-greater- than the desired balance, and negotiates a rewind of the payment
sequence to that point, with an additional payment of the remainder by the
depositor. Suppose the last payment that will remain valid was the i-th
payment, counting from zero. The receiver creates a new nonce, N'_i,
creates the associated new secret value S'_i+1 by S'_i+1 = H(N'_i |
H(S_i)), and sends D'_i+1 to the depositor with a request for payment of
the right amount. This amount will be greater than that associated to D_i,
but less than that associated to D_i+1, so the depositor does not need to
trust the receiver in order to honour the request. The payment chain is now
forked at D_i, with a branch D_i+1, D_i+2... and a branch that only has
D'_i+1. The receiver now unwinds the old branch, back to D_i, by revealing
S_i+1 to the depositor. The depositor can now generate - and check - the
secrets S_i+1, S_i+2..., and so knows that if the receiver attempts to sign
and broadcast a transaction to an address using one of those secrets, the
depositor can take back all their funds before the receiver is able to put
their own (CHECKLOCKTIME restricted) transaction from that address on the
blockchain. Now the best usable payment to the receiver is the one
associated to D'_i+1.
When the two parties want to close the payment channel, one party signs a
transaction from the deposit address to whatever addresses are desired, and
sends the transaction to the other party to add their own signature and
publish. This avoids either party having to wait for CHECKLOCKTIME
restrictions to expire. If either party abandons the protocol at this
point, the other can use the CHECKLOCKTIME restrictions to ensure they get
at least as much as they would if both cooperated. Note that the holding
addresses are only used on the blockchain when the protocol is abandoned.
This protocol does not deal with the case of malicious attacks on a party's
network connection, which could keep them offline until CHECKLOCKTIME has
expired. This is something that each party should consider when choosing
how long the restrictions should be in place for. The protocol improves on
blueadept's use of a new nLockTime for each reverse payment[1], by keeping
the wait time independent of the number of payments, and not requiring
either party to predict ahead of time how many payments will occur.
A note on generating hashlock secrets: the protocol works perfectly well
without generating them deterministically. Using an HMAC-style derivation
is more of a convenience than anything else - it saves storing and
transmitting all the secrets when a chain needs to be invalidated - but it
does encode the fact that the addresses form a chain into the addresses'
scripts, which is a nice property to have.
[1] https://bitcointalk.org/index.php?topic=814770.msg9185225#msg9185225
I first posted this at https://bitcointalk.org/index.php?topic=918018.0 and
have edited it slightly for posting on this list. Thanks to Peter Todd for
the suggestion to submit it here for review.
Nathan Cook
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150109/dc18ce68/attachment.html>