My understanding is that Wright threw an hour long tantrum.  This is a common manipulation technique.

It still doesn't prevent the whole thing and the lack of a forceful retraction later all that explicable... but it's only finitely insane.

I dunno, he usually thought security stuff was theatre.  This is also the person who tried to start a business where you send your random secrets to him to determine if they're really random or not (later made into a free 'public service' after the business failed to get investors).

As he said-- he was convinced before he ever got onto his flight.  That alone could have doomed the exercise.  Some people can be convinced going in and still make a good judgement, but many people couldn't.

Toom is likely appropriate at these sizes.

I do not expect Montgomery to be useful except where there are many consecutive multiplies and squares-- such as performing an inversion with a power ladder.

In software at least delayed carry processing is a big performance increase, maybe in logic it wouldn't matter.

The secp256k1 field has special structure: 2^256 - 2^32 - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1

This simplifies reduction but I haven't really given any thought to what a dedicated logic implementation would look like.

On doubling:  You don't need to double because you should use a table per digit where each table entry has already been multiplied by a power of 2.

With that there is no need for doubling at all.  Though if you do have a need for doubling you can do it in 3mul 4sqr.

Computing  scalar times point will never have an infinity as an intermediate.  Infinity is functionally 0.   If you are adding up some number by summing its digits, you'll never encounter 0 in your incremental sum.  E.g. If I want to compute 1984G   4 + 80 + 900 + 1000  ... none of those sums can be zero.  If you consider it, you can see this applies to any number base.   Infinity can only be encountered if the scalar is larger than the group.

That is a snapshot from 2014. Archive.org actually shows that he added that backdated page in 2014:  https://twitter.com/mylegacykit/status/1220264990810300416

The block was archived prior to 2014-- back to 2011. But pages like that simply did not exist prior to 2014.  You can also verify this by loading

https://web.archive.org/web/20111123102230/http://gse-compliance.blogspot.com/

Which is a page actually archived in 2011.  And notice that it says that there are 81 posts in 2009.  If you load any version of any page up until 2014 they all say that there are 81 posts in 2009.  But the in 2014 that page is added to the archive and the history says 82 posts in 2009.


As you note, he also made other deceptive backdated edits.



So you're saying you didn't buy the account?    (That's permitted on bitcointalk...)

I don't believe there is any known not provably forged evidence of him having touched Bitcoin prior to 2013.  Or did I miss something?

I agree, this deserves more elaboration.  Options exist in "physically delivered" and "cash settled" form.

Physically delivered works basically like what you would imagine an option to work: To write a call on a Bitcoin someone posts a Bitcoin and writes a contract.  At maturity, whomever owns the contract can opt to pay the strike and get the Bitcoin.  (Same thing for selling calls, but they'd post dollars and if it gets assigned the contract holder pays the bitcoin and gets the dollars).

With cash settlement, the covered Bitcoin may not actually exist, and at expiration if the option is in the money the seller will pay the buyer the difference between the strike and the price.

Physically delivered avoids a lot of complexity and risk.

Cash settled is essentially a side bet on the price of Bitcoin.  With cash settlement you need a "the price", which means you need an index.  As a seller of a cash settled option you can potentially get screwed if the index prices aren't reliable-- e.g. someone could buy an OTM option right before expiration, then at moderate cost manipulate the index and force you to pay them a bunch.  As a buyer of cash settled options the assets to make good on them may simply not exist in the event of a black swan that turns your position extremely valuable-- potentially resulting in a cascading failure of the exchange.

To protect against that risk any exchange engaging in cash settlement will need to have extensive exposure management-- this will automatically force traders to post additional balance if their positions get out of wack.  They'll also need to auto-liquidate positions-- potentially profitable ones too.  Kind of ironic that when your predictions are right and are moving in your favor you might be liquidated to protect the platform exposure.  Platform risk management to users is inherently fairly opaque, traders should be accounting for it in their prices but it's not clear how they can do so rationally without a great deal more information.  Any kind of auto-liquidation also disrupts the potential value proposition of options, since part of that value is that you can make a trade once then ride out volatility along the way to the expiration date.

So why would anyone ever want to touch cash settled?  There are a couple reasons:

One is that the settlement process of a physically delivered asset can be inefficient.  Say you are super bullish bitcoin-- you bought a bunch of calls, and they're about to expire ITM.  Great, but now you need to get a bunch of USD to fund their execution, but you don't have any because you're super bullish on Bitcoin!  You can, instead, trade out of the position but the market may not be liquid enough to do this at a good price.   In mature markets this is mostly a solved problem:  For a modest fee retail brokers will loan you the cash you need for whatever milliseconds it takes to receive the shares and sell them on the spot market. But this is not solved for the Bitcoin options market yet.

Another is that regulatory complications make it harder for exchanges to handle USD at all.  In a cash-settled options market you can use BTC as your cash, so you can make a platform that is 100% all Bitcoin, no USD (It can even be 100% all bitcoin even when it has options on altcoin/btc).  This is also a convenience for customers that don't want USD exposure.

Another reason is that since cash settled platforms are inherently having people trade on margin there is no fundamental problem with customers keeping custody of the coins covering their positions in their own wallets. But the flip side of this is that the platform can't guarantee delivery.

Cryptocurrency markets and options based on them are already volatile enough that I'm dubious of the belief that market efficiency requires a lot of leverage on these positions.

Unfortunately, by their very nature these side bet markets easily generate a lot more volume than physically delivered markets, so to some extent they also may be denying air to the more robust alternatives.

Personally, I think cash settled is fraught with long tail systemic risk --  I suppose it has a place in mature and highly liquid markets, but cryptocurrency markets aren't that.  I think the risks while clearly large are also not particularly simple or easy to understand-- in theory there is some price where I should be willing to trade at a cash settled market, but I don't believe I could calculate that price.

There is an informal proof up thread that 765 is enough, I haven't considered it carefully.  I find it a little concerning that he found a 760 iteration input so easily-- for safegcd we've found it fairly hard to find inputs close to the bound.

Perhaps for estimation purposes you could just assume 765 but I think that if I were going to fabricate this circuit I'd want to make a more formal proof of the bound.

aside,  Pieter has started writing an accessible writeup about how safegcd works.

Affine + Jacobian is actually what you want for this, your circuit never performs a GEJ+GEJ operation. (You might perform a GEJ doubling, but doubling is special and much simpler operation though as j2002ba2 points out, the doubling can and should be eliminated)

(Though there is a gej_gej addition in that codebase a little bit higher, which is 12 mul, 4 sqr-- but that isn't what you want).

If you want a real mind blower--

Given a field element t, compute


       c = sqrt(-3)
       d = (c - 1)/2
       w = c * t / (1 + 7 + t^2)
       x1 = d - t*w
       x2 = -(x1 + 1)
       x3 = 1 + 1/w^2


And at least one of x1, x2, or x3 will always be the x coordinate of a valid point.

If you look at the links in my prior posts, I linked to a GEJ+GE that uses 8mul+3sqr.

I think your post might make a better case against using deribit.   I use LedgerX -- I don't use deribit because it's not physically delivered, doesn't allow US customers, etc.


This highlights why its not very useful to consider a position without its hedges or what its hedging. E.g. the isolated analysis has you characterize the loss as  unlimited-- but for covered positions (which are the only kind of short you can get into on LedgerX) the worst case loss is the value of the collateral minus the premiums you received, which is a very different story.  If you were going to hold the collateral for the duration regardless then no loss is possible.

The positions I take are a bit wider than you assume-- $7.5k, 5k, or 2k strikes on the put side (which I try to get a premium comparable to a 15-20%/yr on the collateral, depending on the strike/date), and I'm getting more on the call side than you expected:  E.g. recent trades have me receiving  $2,699/BTC for JUN2021 50k, $6,985/BTC for DEC2021 35k,  and $4920/BTC for DEC2021 50K, to give some examples.

So lets look at the value at expiration of a position consisting of {2 BTC, -1BTC 35k DEC2021 call, -1BTC 5k DEC2021 put} using some recent trade prices, and compare that to just hodl the same 2 BTC:



In exchange for diminished returns over a BTC price of $42,866, the position gets increased value at all lower prices.

Another way to look at is is in terms of ratios of dollar values:



So under a hypothetical crash to $2,866 the position is twice as valuable in dollar terms compared to hodl. If Bitcoin crashed to nothing the position would be worth $2867.  Back when I acquired most of my Bitcoin $1,433/BTC would have been considered a fantasy moon price, its a price below the ATH up until May 2017.

At the ATH price of (say) $21,000/BTC,  the position is 18% better off than hodl and even at $36,953/BTC the position is a respectable 8% ahead of hodl.  True, at a super-moon price of $500k/BTC the position is only worth 54% of HODL,  but it's still worth 14.28 times its current value at that price.

Of course, in the crash situation I'd be better off selling now but we don't know the future.  I think crashes and supermoons are certainly possible, but I also don't consider either to be extremely likely in the next year.

It's also worth considering in BTC terms:



These trades help avoid regret:   If the BTC price crashes the seller (me) at least locked in some income (or, alternatively, gets a lot more BTC),  while if the price stays flat-ish this position gets a ~20%/yr return and the seller doesn't need to regret not selling BTC and investing the funds elsewhere. In the moon case the trade limits the returns but there are only so many lambos a person can need (in my case I need exactly zero lambos, but you get the point).  

I'm pretty bullish on the future Bitcoin price, but I'm also not in dire need of astronomical amounts of wealth.  I find it generally more valuable to me to mitigate risk.

Even under the most aggressive model of mid term future prices that I find vaguely justifiable-- assuming the future price is a random walk with the same distribution as the returns since 2013 that 35k call is <50% likely to get assigned. Under a more conservative model -- using the derivative of delta at the options premium to get the assignment odds under black-scholes

• , the 35k call 1yr call is about 12.5% likely to get assigned.   Assuming the price is flat, this trade just yields a extremely respectable 20%/yr from selling volatility (I say extremely because half the btc isn't even 'at risk' when reasoning from the perspective of a hyperbitconized world).

There are a lot of people who seek to profit off volatility in other ways, e.g. day trading the bitcoin spot market.  But the fees and taxes from doing that can be considerable and the risk is substantial.

Of course there is also custodial risk, though this position only needs to expose half its Bitcoin to third party custody. I've also ignored the tax implications.  But I think whatever your tolerance for risk and/or ideas about the future values of Bitcoin say, there is usually a way to use options to get an outcome that better meets your needs.

• And yes, Talib would point out that black-scholes assumption of normal returns doesn't have fat tails-- while market history including Bitcoin history does (Bitcoin historical returns are heavily skewed and have mac-truck sized tails).

The way I see it, owning Bitcoin on an ongoing basis is a massive bet for and against a collection of black swans: Owning Bitcoin is a bet for BTC becoming a world currency, fiat hyperinflation, widespread distrust in institutions/monetary policy, and massive globalization of economies (with concordant lack of functional legal process across borders, making irreversible and machine arbitrated transactions more valuable).  Owning Bitcoin is also a bet against technical/economic fault destroying Bitcoin's viability, effective adverse regulation denying people access to Bitcoin, Bitcoin businesses being so corrupt or incompetent that they scare everyone away, the collapse of technological society, or Bitcoin not being the solution to the prior list of pro-bitcoin black swans that people adopt. I believe that the current price substantially reflects a balance between these considerations.

In general I share the view that these black swans-- both the positive and negative ones-- are credible but at the same time I also believe many people over-estimate their likelihood especially in the short to mid term.  So by owning Bitcoin (as well as non-cryptocurrency assets) and selling the BTC/USD return tails I seek to turn the the difference between my beliefs and more extreme beliefs into profit, along with locking in some of those black swan gains now when they can do me some good rather than in some hypothetical future that I might not even live to see. Simultaneously,  I believe the marginal value of additional wealth isn't constant-- and so I think there is the potential for mutually beneficial trade even with someone who shares a similar perspective on the distribution of future prices but just has a different risk preference than I do.


Aside, I did some image processing magic and managed to make a 'flatter' projection of my bookshelves.

This sounds more reasonable.

By a "tight bound" I mean the exact number of iterations which is enough for the worst input, but no longer.  Instead, what we can compute is a loose bound: a number which is large enough for any input but might be too large.

"worst-scenario should be no smaller than 512 iterations for binary GCD." might well be true, but "no smaller than" is not useful to you. For determining the circuit size you need to know that the worst case is no larger than some size.

As an aside, I found some random binary GCD from an internet search and it typically needed around a bit over 1000 iterations for random inputs and the secp256k1 field prime. (I would have tried the one from j2002ba2's earlier post but it gave wrong results when I tested it, though perhaps I made an error while transliterating it).

Nope that is just incorrect.

There aren't any dummy iterations except in the sense that on some numbers it takes fewer than the maximum so there will be some iterations that don't do anything useful-- but those iterations will still be there in the logic implementation. ... also in the sense that the known maximum bound isn't tight, even on the worst number it probably takes a few less.

The algorithm of the safegcd paper takes more iterations than some other constant time binary egcds because it is a least-significant bit algorithm:  each iteration only looks at and updates the least significant bits of their numbers.  In software with 32/64 bit numbers this ends up being a LOT faster than versions that have to update the whole 256 bit numbers at each step.

Implemented as raw logic I suspect a MSB binary egcd will be more efficient because you can shrink the numbers that it works on a bit at a time as their magnitude is guaranteed to be decreased by the algorithm.

It would be nice if it were true, but it is not.  In the Bitcoin protocol you cannot verify the transactions in a block without the transactions each of those transactions is spending the output from (to obtain their amounts, heights, and scriptpubkeys), along with _all_ transactions between those transactions and the current block to verify that the outputs being spent weren't already spent by another block.

A block can easily be invalid in a way which I cannot convince you that the block is invalid without sending you most of the blockchain (or with other similarly currently non-pratical approaches).  Some types of invalidity can be efficiently be shown, yes, but an attacker just wouldn't use one of those.

No, all the headers show is that proof of work was applied.  This is the SPV security assumption: that if there is proof of work the blocks will also be valid, because miners would not have chosen to throw away work on blocks that nodes will ignore.  This assumption is only plausible so long as a significant portion of economically important users are not using SPV.

Someone asked me off thread about books, so I added a link to a somewhat old gigantic picture of my main library to my interview in the section about books. Might be of idle amusement to people who enjoyed my interview.

In the case of an unrolled logic implementation, *all* candidates will be constant time.  Algorithms like binary gcds are made constant time by unrolling to their maximum number of operations.

If you allow memory and looping then the problem can be computed with an extremely small number of gates... (just the smallest computer with an ALU you can find, plus enough gates for them memory for a point, the input, a couple hundred bits of temporaries, and the program itself)

That is how I understood what you wrote. But all of the binary gcd variants will perform (many) more iterations than the classical GCD. You cannot use the behaviour of the classical gcd to reason about the iteration counts of some binary gcd.

The efficient multisig referred to in your message requires that the spending parties interact before computing their single collective address.  This wouldn't help with spending multiple coins, since they are sent by uncoordinated parties at different times and you don't know until the moment you spend which ones you'll use.

That said, separately I did propose a way to aggregate signatures, which does allow combining the signatures of multiple keys purely at signing time (but still interactively).  This was not included in taproot for basically engineering reasons-- too much change to manage at once and there was a risk that the feature would never complete if it was too big.  The idea is that after taproot is deployed and we've learned from the usage, a new version can later be introduced which adds the aggregation along with whatever improvements are learned from the usage.  Aggregation wasn't the only thing left out either.

I'm not sure if this was ultimately wise: taproot has taken years longer than expected regardless... but it is what it is.

Then they would *be* full nodes.  What allows a full node to tell a rule complying node from a rule violating node is that they fetch all the data from all the blocks and apply the rules of the system to make sure the blocks are valid.

It's extremely easy for attackers to spin up huge numbers of fake nodes. If "ask more nodes" provided meaningful security bitcoin wouldn't have had mining at all.

No, that is entirely untrue, unfortunately.

Binary GCD is faster to use not because it makes fewer iterations but because there isn't a very expensive division in each iteration.

Pretty much exactly as good as any other node.  Connections can't be initiated in from the internet to them but they connect out and the protocol is symmetric-- it doesn't really matter who called who, it works just the same either way.  (Also some of those that don't accept connections publicly still accept connections privately, e.g. from friends or over tor)

That page is a lie.  It compares inbound reachable Bitcoin nodes to all ethereum nodes.  The vast majority of Bitcoin nodes are not inbound reachable, as there are plenty of inbound reachable ones and being reachable exposes them to some attacks. Total Bitcoin nodes are much larger and ironically 30% of those ethereum "nodes" have fallen out of sync.  So there are 5.6x the number of Bitcoin full nodes as there are in-sync ethereum nodes.

There is also no real capability comparison. Ethereum nodes normally only have SPV-like security-- they blindly trust miners and don't validate the history. There is no exact analogue in Bitcoin.  Their 'archive' nodes do more but also carry a huge amount of cruft too and it's so difficult to run one that even blockchain infrastructure companies have problems doing it.