Many (most?) users are currently CPU bottlenecked on validation, so any additional CPU will slow down their sync.  Changing the speed of the compression just changes the point at which the tradeoff moves.

[Aside, Lz4 doesn't do that much on transactions]

I hope I didn't make it sound like I think it shouldn't be done.  I think it should be done, and probably supported over P2P too-- as a negotiable feature.  Local usage could easily be optional, I expect most non-pruned users would want it on to save space unless their node is stored on a 10TB spinning disk and they don't care about the usage or they're on a small arm device and the extra cpu would be brutal while peers are syncing from them.

It's just not trade-off free, and AFAIK no one working on core is interested in working on it.

The blockstream satellite node software contains a compressor that shrinks transactions by about 20% operating a transaction at a time.  (More could have been achieved by working multiple txn at a time, but at a great increase in software complexity and some loss of functionality).

It exploits all the redundancies described by pooya87 above and quite a few additional ones. E.g. it knows how to reconstruct the hash in the redeemscript for P2SH embedded segwit, it knows how to convert 65 byte pubkeys to and from 32 byte pubkeys, etc.  I think, though my memory is kinda fuzzy, it exploits reused scriptpubkeys/redeemscripts within a transaction.

Though your network needs to be fairly slow or your CPU extremely fast before its worth the CPU cost (for satellite it's an obvious win).

Technically thats not entirely true, due to things like pubkey and address reuse and common syntax elements, state of the art generic compressors do get some compression when working on one or several whole blocks at a time.  But not anywhere near as much compression as a data aware compressor can achieve. The two can be combined, of course.  But having to work one or more blocks at a time gets in the way of random access to data and potentially creates DOS vulnerabilities (e.g. from peers forcing you to decompress groups of blocks only to access one block in the group).

It's more efficient to use this stuff if you negotiated with peers sending the compressed form over the wire.  If all your peers were doing that, you could just keep the compressed form in memory and on disk and not have to decompress except for validation.

AFAIK no one is working on taking this work upstream, which is sad-- a 20% reduction in disk space would be nice, and post erlay this would also end up being nearly a 20% reduction in network bandwidth if used for transaction/block relay.

If it were just done for storage probably the best thing would be store every block using it,  and just keep a small cache of uncompressed blocks in memory for serving requests for recent blocks.  Any kind of rewriting of block data on disk is complicated due to the need to be able to recover from crashes.

Yes, though the fact that some use their own custom crypto libraries due to altcoin support and it may take them a little while to get around to writing it.

It's easy to find the s spellings and bloody as in intensifier in the writing of Americans, especially easy if they intentionally adopting a different style.  I wouldn't read too much into stuff like this.

Huh!  I had no idea that was at the conference, I would have found it pretty interesting I had been and would have mentioned it in the coinjoin post!

However, my work in that space substantially pre-dates the conference e.g. https://bitcointalk.org/index.php?topic=139581.0  which included demonstrating it on the network,  as well as describing how to cryptographically blind the participants from each other.  And even those posts were posted as late as they were because I had to wait until the software had the necessary functionality.  I believe public discussion of this kind of approach to improve privacy goes back to mid 2011.

The purpose of the coinjoin thread was just to popularize an existing concept,  driven by the reasoning that because it hadn't been given a catchy name no one was thinking much about it.

Thanks to everyone for taking the time to participate in the interviews and the contest, I found many of them interesting and I'm glad people enjoyed mine.

The address on my profile works fine: bc1q6qwd6l8nm9uad53c7jtl3ermds5cxwfnfevap6

Cheers!

In the US you can easily move millions of dollars into and out of bank accounts without it being a big deal. At least for just a couple million it doesn't usually generate any remarks from bank staff-- or if they say anything they just assume you're buying an expensive home or selling a business.

Blocks are not blockheaders.

Limited peers can serve all headers, but they only serve the latest 288 blocks from their tip.

https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki


If something is accepting connections but has a service flag of 0 it's probably some weird spything.  If it makes a connection to you with a service flag of zero it may be a SPV wallet, but its more likely a spynode pretending to be a spv wallet (as there are more spynodes than p2p spv wallets).

Did they never make good on these plans?

The only use for a 'privacy score' is introducing privacy concepts to someone who knows nothing about them and won't have as easy a time learning from reading a list by itself.

There is also potential for abuse.

For example after a prominent wallet added mechanism to improve privacy-- when it spends from one of a reused output it it tries to spend all of them-- one of these explorer sites changed to start reporting all those transactions as 0 privacy.  Were they just incompetent?  Trying to trash that particular wallet?  Trying intentionally to encourage users to use less private software?  No way to know.

Obviously anyone plugging their own addresses/transactions into these things are trashing their privacy.  Highlighting transaction properties can be useful for educating people, giving a score -- less so,   encouraging people to search their own transactions and/or addresses is just a bad move.

gibberish thread. I wonder what scam its peddling on the backend?

Alas, that page is about binary field multiplication, arithmetic in GF(2^n) rather than in GF(P).  Binary field arithmetic has special structure that make logic implementations especially efficient (and public key cryptography especially weak. ) and isn't what is needed here.

Oy. don't use 'converters'. Their efficiency will be poor and as you note they don't handle much power (unless they're expensive).

In the US we use 120/240v power.  Power hungry appliances like electric ranges and dryers use 240v.   Find/install a 240v plug to run your miners.

All my computers are run on 240v-- the PSUs are more efficient that way.

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).