Likely because those conversations didn't exist at all or at least not like described.  There is no particular reason to believe Cryddit was telling the truth, especially because a simple glance at the original release demonstrates that he was wrong about a lot.

See:
https://www.reddit.com/r/Bitcoin/comments/e9v48b/how_can_sirius_claim_to_be_bitcoins_2nd_developer/falysvv/

and later down the thread:
https://www.reddit.com/r/Bitcoin/comments/e9v48b/how_can_sirius_claim_to_be_bitcoins_2nd_developer/fam2aut/

I believe you will only be able to distinguish the lightning transactions if they are non-cooperative.  Openings and cooperative closures should be indistinguishable from ordinary single key payments.

[I say I believe because I'm not super well versed in lightning details, but this is indeed the idea.]

That would be really cool, but I dunno that it's almost certain.  One thing you can be certain of is that they'll be ready when they're released.

I said "no" but it's also not clear to me what the question means.

Last time I used USD to buy coffee instead of a card was probably over twenty years ago-- okay maybe I used some pocket change a couple times in between--  is USD a failure because of that?

USD is a worse money than Bitcoin from several different perspectives, so in general I try to get rid of it ASAP-- and that means spending it preferentially and preferring to be net short it (e.g. by having a zero interest rate credit card balance for a month). By comparison, Bitcoin is better so I prefer to spend it last unless its uniquely good properties are called on.

These days Bitcoin isn't a great match for spending a couple bucks on coffee-- and no I don't mean transaction fees (since obviously lightning is a good fit for that usage)-- but because it has disadvantageous tax treatment: spending time to account for and report cap gains for a $1 cup of coffee would be absurd.  But so what?


I think it's even simpler than DooMAD's answer:  For the most part they don't run nodes themselves (otherwise ... they probably wouldn't be big blockers!) and admitting that the absurd resource costs even at current load levels is a factor would crush their arguments, yet they're already suicide-pact committed to blocksize-go-up and so to resolve the dissonance they take the position that it doesn't matter how resource intensive it is because people shouldn't be running them.

I wonder if these companies are considering that this move may make them attractive targets for asset stripping in the future?

Bitcoin price goes up 20x... now most of the companies value is the bitcoin but their profits haven't increased...  take over the company just to strip it of the bitcoin.

Reducing the incentive to asset strip is one of the reasons public companies often prefer to return funds to investors ASAP and finance operations via debt.

This is how you advertise yourself. When you send the addr message to your peer it will (sometimes) pass it on to other hosts so that they learn about you.

Yes, they might know about it (or they might have just had it manually configured w/ an addnode), but even if they do their knoweldge doesn't serve the purpose of causing your address to get advertised to the network. For that to happen, you have to advertise it.

Worse, it's like putting dollars in shady sal's back alley bank and getting credited SalDollars in return, which can at most be redeemed 1:1 for real dollars, -- if you can track down Sal and convince him to do the redemption.

Foreign exchange could make you money or at least hedge a liability...  tokenized USD?  That's just fiat with extra risks. To the extent that there is any use for it at all, if you had a use you'd know it and wouldn't be asking about it here.

If you want to own Bitcoin (for its multitude of benefits) but are worried about taking on extreme losses,  you can buy put options to insure your bitcoin.

So for example:

Right now you can buy 1 BTC for $10708 and stash it safely in a secure wallet.  You could also buy 1 BTC worth of 12/18/2020 (roughly 3 months out) $7500 strike BTC puts for $278 on LedgerX.

If three months from now the BTC price holds steady or goes up, then your puts will expire worthless-- like when you pay for insurance on your house and it doesn't burn down. Then you buy new puts, dated 3 months out.  So you'd end up paying around thousand bucks a year or whatever for that level of crash protection.

If the BTC price crashes to $7500 or below then on the expiration date, you execute the put and get $7500 for your *whatever the current price is*.  So if the price drops to $5000.  You execute, you get $7500. If you wanted you could buy back the bitcoin and get 1.5 BTC.

If you get tired of holding the insurance -- perhaps you sell your bitcoin or feel less concerned,  you can sell your put contract for whatever its worth at the time.  (potentially more than you paid for it if BTC went down enough-- less if it went up or stayed stable).

You can pick the strikes and dates you want to adjust your risk tolerance vs what you're willing to pay for insurance.

Right now, 12/18/2020 puts at $5k are available at $148/btc,  7.5k at $278/btc, and 10k at $1200/btc on LedgerX.  Perhaps they'd trade at better prices if you left a standing ask.   LedgerX contracts trade in 1/100th of a Bitcoin increment.   If in the future bitcoin is less volatile it'll cost less to protect your position this way,  if it becomes more volatile it'll cost more.

If this makes sense for you depends on your particular finances and risk tolerance.  If you're assuming Bitcoin is going to go way up then you could imagine buying this protection is just throwing money away-- but if the fear of losing money is keeping you from owning Bitcoin at all, then the cost of hedging it may itself be a very good decision even if the prices do go up a lot.

Of course, doing this exposes you to some risk in using a centralized platform e.g. they could get goxed... but w/ this strategy you only have the put you bought there-- your Bitcoin can be safely stored privately, in your own possession, offline.

Personally, I'd take the other side of these sorts of trades because I'm not worried about Bitcoin volatility. But everyone's situation is different and I think it's completely reasonable for people to buy low-strike puts for hedging purposes.  Shuffling around risk to parties that are more tolerant is a natural economic win/win.

Maybe this is the start of what it's going to take for there there to be arrests over some of the more extremely scammy shitcoins.

Authorities will look the other way when it's all niche idiots ripping off other niche idiots.  Start defraud retail investors and eventually they'll hit someone with political clout and a taste for vengeance.

Depends on the part, the ASN1 parser stuff is and was extremely difficult to review. The basic cryptographic code OTOH is mostly fine, readability wise-- though there are a lot of different platform specific optimizations and different cryptosystems in there, so a lot of work to review.

A lot of the "readability" fixes that they did do were just running the entirely codebase through an autoformatter. I think this was a complete and utter disaster for reviewability-- it caused them to issue a 400k line diff (which they also mixed in with security changes).  Presumably they were also hiding undisclosed fixes in that massive change, but-- perhaps they also hid new vulnerabilities.  It's completely impractical to review that, so only history will tell.

If your "readability" problem was one that could be solved by mechanically adjusting formatting, you could have done that locally without any fear that something naughty was slipped in.


Libsecp256k1 should be roughly equally portable (in fact, in some respects it is more portable just because it's smaller and does less-- so any adjustments needed for a weird platform would be smaller).  I test libsecp256k1 back to GCC 2.95 (from 2001, which is extremely old by modern standards-- though OpenSSL originally worked with older toolchains I have no idea if they continue to test with anything that old).  Libsecp256k1's tests also pass when compiled to a 16-bit DOS executable (though a couple of changes are needed to the tests to keep them from exhausting the stacks).

Well there are orders of magnitude, even the worst parts of the OpenSSL code are much more reviewable than a binary.


It's always good to be a bit wary when someone is pitching that their reimplementation solves all the problems unsolved by the Standard Solution-- often it means that the reimplementation didn't understand the entire problem domain (or they did and are intentionally ignoring a big chunk).

Some of OpenSSL's awfulness is self-inflicted legacy baggage, but a good chunk is simply because of what it's being asked to do. Some of OpenSSL's flaws also appear to stem from interface decisions that cause callers to introduce flaws, -- and the drop in OpenSSL alternatives preserve those interfaces for compatibility.

To the extent that some of these alternatives have dropped support for older standards or weird platforms they might also have improved on the "being asked to do" front, ... if your usage is okay with those limitations.  As far as legacy baggage goes-- we remain in a state where virtually none of the folklore advice about code-smell has been backed by rigorous scientific study.  Programmers are often _extremely_ opinionated about "bad code" yet there are relatively few examples of widely code style differences which are uncontroversially and unambiguous causes of defect-- often complaints about "bad code" really just means "not my preferred style".  In so far as an alternative is only an improvement with respect to some person(s) subjective impression of "bad code" I am extremely wary,  the hardening that software gets from widespread use is commonly and easily undervalued-- if I had to pick between a widely deployed solutions with well understood weaknesses vs something new which is supposed to be subjectively better, I'd pick the former every time.  It seems the market agrees: OpenSSL is extremely widely used compared to some of the new alternatives.

For Libsecp256k1 in Bitcoin we switched not because subjective "code smell" sorts of reasons but because of more objective criteria like:

* Designed for consensus consistency: OpenSSL was provably not consensus consistent and was continuing to actively make changes which damaged consistency with little to no consideration of this class of concern or even adequate disclosure of the changes.

* Free of timing sidechannel secret leaks for secp256k1: OpenSSL's code for this curve wasn't even trying to be constant time. Ours was.

* Formal validation: Libsecp256k1 is partially formally validated, none of the parts of OpenSSL we were using are, to the best of my knowledge.

* Speed: libsecp256k1 was 5-7x faster than OpenSSL.

* Extensive testing: libsecp256k1 had many kinds of tests openssl didn't have at all, and has more now-- tests in libsecp256k1 found serious bugs in openssl, etc.

And sure I think the libsecp256k1 is a lot more readable and maintainable than the relevant code in openssl, and I hope those differences also help lower defect rates... but its all the items above that made it the right thing for Bitcoin to use vs something with a much longer track record, and not some formatting stuff which is inherently pretty subjective and may not actually make the software better.

Even putting aside suitability-to-application, OpenSSL's implementation of secp256k1 has significant secret dependant timing-- so it's not secure if an attacker can measure the time it takes you to construct signatures (potentially even over the internet).  I think that is pretty unfortunate!

This isn't the case for all the curves OpenSSL implements-- e.g. Their P224 and P256 at least attempts (I haven't personally reviewed them) to be constant time.  So you have yet another problem with big grab-bag systems like OpenSSL: the provided security properties are extremely uneven,  and you might think it is secure on the basis of someone's comments with respect to some configuration but find out the hard way that your own configuration is not sufficiently secure.

Then again, *other* than libsecp256k1 ... other implementations of secp256k1 out there, even ones claiming to be "high security" are not particularly free of secret leaking timing side-channels either.  Nor do they usually have tests beyond a couple static test vectors, etc.   From my perspective almost everything else is a joke, but no one cares because the limiting factor in user security is usually something else.  Attackers need not worry about triggering targets to sign a bunch of things on command and then performing complex mathematics to recover the private keys-- they can just spoof an email as the target company's CEO and tell someone to send over their wallet.dat and all too often they will.

Siphash's output is 64-bits and we needed fewer based on an analysis of collisions rates.  It didn't matter which bytes of the output got dropped, some just had to be picked.

It wasn't an option in Bitcoin, other than you could go modify the software to enable it-- which you could always do even if we'd never heard of the optimization. There is no case law that supports a conclusion that implementing something to test it in a non-commercial non-production scholarly manner is a patent violation: considering that the unequivocal case law in the US on the distribution of source code being a first amendment protected right, any attempt to block the scholarly evaluation of patented algorithms in this manner would be on pretty shaky constitutional grounds at best.  Plus how could you even decide if you wanted to implement something without actually trying it?

I can't make any sense of this statement.

This doesn't have anything to do with python. It's a 27% speedup.

Transaction relay is batched and relayed at random intervals because doing so greatly reduces bandwidth usage for relay (due to reducing overheads and due to reducing the number that are advertised both ways on links) and also because its important for privacy as otherwise it's much easier to tell where transactions came from based on when they showed up.  ... and also because there is no particular need for transaction relay to be extremely low latency: blocks are 10 minutes apart on average, after all.


Almost all the data in blocks has already been relayed and validated.  It only takes a 6 or so bytes per transaction on average to relay a block and the only processing needed is a bit of hashing.

pbies, please revise your message to not be acutely nasty.

JeanLuc (and others),

Do you have any references for the work required for the best multi-target discrete log attacks?

For the test vectors for BIP340 it would be extremely useful if there was a test vectors where the signature R or Pubkey's x value had an usually large value in the range the scalar order [0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141, 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F) (between the scalar order and the field order).  Test vectors using points with a value inside this range would test if an implementation isn't erroneously reducing these inputs mod Fn or considering them as too large (e.g. by mistakenly using the Fn overflow test that they use for deserializing the S value in signatures).

To construct tests like this we would need a point with an x in this range where we know the discrete log.

One way to perform this test is to just mock the choice of G in the cryptosystem, if you can pick G you can make any single chosen point have a known DL. ... but having test vectors which require the implementation to use a different G means that the test can't be just applied to an unmodified system, so it's less useful.

Because this range is pretty large-- about 129 bits-- there are ~2^129 acceptable keys...  It sounds to me like it might be feasible for a multi-target discrete log search to find a solution. If so, it would be a record breaking computation that would be practically useful in addition to offering bragging rights.

But it's not clear to me if this actually feasible or what the concrete computational cost would be of the best known multi-target attack.

[I'm posting in this thread because it's obviously most related to vanity search, in particular, it's a vanitysearch for an address prefix "BC1QLLLLLLLLLLLLLLLLLLLLLLLLL"

FWIW, bitcoinjs has several times had bugs where it would generate incorrect pubkeys which no one could sign for. Personally I would be extremely wary about using it for any serious application.

Most other implementations of bitcoin's crypto are extremely scary-- e.g. contain very little to no testing, had no rigorous review, were subject to no formal validation, are not implemented in a fault tolerant way, and are (IMO) unfit for high value usage compared to Bitcoin Core.

I'm aware of at least one non-public incident where over 10,000 BTC was lost due to less thoughtfully created "HD wallet" crypto code generating bad pubkeys.

I would strongly suggest that at a minimum to implement a redundant check of some sort.  Bitcoin core signs and verifies a message after generating each key.

When you import an address you can set a flag to force it to not rescan-- see the help for importmulti. So long as you're sure that you import it before any use was possible there is no need to rescan.

Bad marketing and also for a long time LedgerX was only open to institutional traders and QCPs (essentially parties with more than $5m in assets)-- they're open to retail traders now (and for about a year?).  No connection to Ledger that I'm aware of.  I also found the Bakkt hype pretty mystifying--  LedgerX does a lot more options volume, and is by far the largest physically settled Bitcoin option market AFAIK (deribit claims more trades, but deribit is cash settled).

I've been doing business with them since 2017. ::shrugs::

Their fee structure for swaps (essentially buying/selling bitcoin) is much more sane than most of the US targeting exchanges, so I think everyone trading significant amounts should give them a look even if your interest isn't primarily derivatives.  ... though also a lot of the price opinions I hear traders expressing would best be realized through options.  Prior to LedgerX I wasn't aware of any platforms doing options that weren't extremely sketchy, so that alone would be a good reason that options trading isn't more commonplace for BTC traders.

Another reason you've might not have heard of them is that a lot of the hype in the cryptocurrency space is driven by paid/unpaid shills promoting altcoins.  LedgerX has been Bitcoin only (though it seems likely that they'll add Ethereum soon).  I have mixed feelings about that:  I think any support for altcoins increases the risk profile of a service substantially (if nothing else, attention to the altcoin's trash fires distracts resources away from maintaining their Bitcoin integration), and we've seen a long history of "bitcoin exchanges" leaving their Bitcoin support extremely outdated and nearly unmaintained while continually investing in altcoin-dejure.   But support for other cryptocurrencies might help bring in a lot more trading volume, which would make the platform more useful.

https://medium.com/@ledgerx/ledgerx-announces-the-launch-of-exchange-listed-bitcoin-mini-futures-afceb1a046ae

LedgerX has been doing physically settled  BTC (european-style) options for a couple years, I've had pretty good expirences with them.

They've just started listing futures and apparently they have a lot of new products coming down the pipeline.

The above mentioned improvements have been applied and now the BIP340 support for libsecp256k1 is ready to be merged: https://twitter.com/pwuille/status/1300572711312265218