|
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"
|
|
|
|
i am using bitcoinjs to generate address 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. |
|
|
|
Since launching in 2017, LedgerX has cleared over 10 million options and swaps contracts. I might be a complete dumbass, but why have I never heard of them? I'm particularly surprised at my ignorance that they've been doing this for years since there was so much hype over Bakkt, which offers similar options contracts if I'm not mistaken. Why was there so much anticipation about Bakkt's launch if LedgerX was around the whole time? Again, this is probably just my ignorance of derivatives trading. Is it because Bakkt was meant to cater to large institutional investors trading huge amounts of bitcoin, whereas LedgerX is smaller? Also, their name is forever going to confuse me with the Ledger Nano X. There's no corporate connection, I assume? 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. |
|
|
|
|
The address problems you had are purely a result of *extraordinary* incompetence (and sometimes malice) by the developers of altcoins and tokens. -- Malice in the case of coins which have fraudulently claimed to be bitcoin.
Bitcoin addresses already have extremely strong built in validation (even stronger in BC1 addresses), unfortunately various shitty clones and tokens did such a small amount of development that they just literally copy and pasted Bitcoin's addresses.
Because they copy and pasted from Bitcoin their addresses will obviously count as valid in Bitcoin and vice versa. The only technology that can cure gross incompetence is the one we're using now: A web forum where well informed people can urge you to steer clear of garbage so ineptly constructed that it can't even bother to get not shoot itself in the foot trough copy and paste.
You can improve your situation somewhat if you always use BC1 addresses for Bitcoin: So far I'm not aware of anyone dangerously copy and pasting it, and we particularly stuck the human visible "BC" at the beginning-- at a cost of a bit more typing-- to try to make it less likely that things will just copy it unmodified. But this is no guarantee and there is essentially no floor on how incompetent or unethical token pumpers can be, so you can expect eventually they'll copy the BC prefix too.
|
|
|
|
|
Please don't. Using transactions below the standard size limit will interfere with fixing a security vulnerability in the protocol.
|
|
|
|
|
Stale blocks (the correct term for what you want) are not generally accessible.
|
|
|
|
Here is an email I wrote about this a few days ago: I am really disappointed-- on the basis the content excerpted in this thread: https://twitter.com/francispouliot_/status/1298423415594840066Long before cryptocurrency existed I was regularly asked by friends to help them understand investments, taxes, and finance stuff-- since I'm the sort of person that finds numbers and contract terms fun. If cryptocurrency had never existed and a friend came to me asking about an investment with INX's terms I would strongly caution them away from it; I might even say it smells like a scam. -- because if it's a scam or not depends critically on unknowable post issuance management decisions: Do they actually pay out income or do they shovel all income back into operations and grow the company until they ultimately sell it out from under the token holders? AFAICT nothing about the terms suggests that they're particularly incentivized to ever pay the token holders even if their revenue becomes substantial, much less obligated. I think at a minimum to be equitable there would need to be an option-like component to the terms which in the event that the company was sold token holders would receive a share of the companies' gain in value minus the dividends already paid out. Otherwise, I think an argument can be made that the management is legally obligated to the shareholders to rip off the token holders in this manner. Even with that I'd still probably caution against the investment due to how complex and unusual it is and the potential for gotchas. The fact that it is issued on some cryptocurrency system just makes it a little less trustworthy (potential for technical snafu), taps into an established market of read-made victims, and imports a collection of people incentivized to pump a sketchy investment. None of this helps but it is not the most fundamental issue. Some people have pointed out that unlike many ICO's this one doesn't appear to be an outright scam. I think it would be more accurate to say that it's not necessarily true that it is a scam, maybe it turns out to be one, maybe it doesn't. Then again, if someone were making a really attractive offering in a market of scammy products you would expect them to put in a real effort to make it extremely clear that their investment isn't a bad one. They haven't done that and I think that is a pretty bad sign. So, sure, while they might meet a "not certainly a scam" bar, that is an extremely low bar and the fact people think this is noteworthy is really just an indictment of the ecosystem. That well respected Bitcoiners are sticking their names on it-- for what sounds like more or less an immediate $250k payment-- is really disappointing to me. If INX merely goes as poorly as explicitly permitted by the contracts their reputations should be justifiably trashed-- because it'll be impossible to tell if the holders weren't paid because the company tunnelled out real profits as payroll and other expenses vs just failed in the marketplace. Considering the failure rate of businesses, even if all intentions are good, the odds of it going poorly can't be extremely low. So to me that says that they assign a fairly low value to their reputations, or that they believe that it's likely that even if it fails and takes everyone's money they won't take a substantial reputational hit from it, or that they're being foolish and don't actually see what an inequitable setup the whole thing is. I think the first two are likely and the last isn't likely. All of them are bad. I don't know if other people have similar thoughts but this is my impression. |
|
|
|
|
My best guess (and it's just a guess) is that you're being some kind of (national?, local?) firewall or anti-virus that is censoring or otherwise corrupting the transmission of a particular block. Unfortunately, Bitcoin P2P is still not encrypted which makes it vulnerable to being screwed up by random censorware in the network.
Can you post what your current best block hash is? It'll be the bestblockhash field in the getblockchaininfo output.
We could try getting you past that block by giving you a hex copy of it over https then you could submit it via the rpc.
If would also be useful to add logips=1 to the configuration so you can make sure that it's not connecting to the same peers over and over again (and we could try fetching the block in question from a peer that failed for you).
|
|
|
|
|
I think it is probably wrong to describe it as a bug. I think it was intended to indicate which signatures were present to fix the otherwise terrible performance of checkmultisig.
Regardless, there is no real point to fixing it: Any 'fix' would require that all software using checkmultisig get an incompatible change (as part of a highly disruptive hard fork). Because the extra value is now always zero (and was pretty much always, or was actually always zero before) you can compress it out completely over the wire or on disk if you really care-- so the only effect it has is its weight in transactions and the one or so extra cpu cycle going into a hash.
Instead a new operation can be introduced that just doesn't have that behaviour-- and that would be compatible, software that wants the new behaviour would just upgrade when it wants it, no flag day, no disruption.
BIP342 replaces checkmultisig entirely with something that is more computationally efficient and more flexible (and more space/weight efficient too, once you count that the signatures are 9 bytes shorter and the pubkeys are 1 bytes shorter).
|
|
|
|
|
I personally wouldn't use or run electrumx: It's author is a big outspoke advocate of a scammer. It's not much of a leap to worry that in the future the software will be changed to exploit users more directly.
If that happened everyone else will be going "well, duh, what did you expect?"
|
|
|
|
|
Your question isn't quite clear enough for me.
For N of N no interaction for key creation is needed. The keys have to be delinearized to prevent rogue key attacks-- but musig just multiplies each key with a value computed from the hash of all the keys.
For N of M interaction and storage are fundamentally required, not just for schnorr but for other efficient threshold signatures too-- efficient being a key word.
But taproot has other ways of doing N of M: You can do a checkmultisig-like checksig-add, or you can make a tree of all the N-of-N subsets and get a script that scales linearly with the participant count. Like for a 2 of 3 with keys A, B, C... the valid possibilities are A&&B, B&&C, and C&&A.
You can even make the taproot root key one of these N of Ns, e.g. if one is most likely to get used. So essentially the size of the signature scales with the log of the probability that a given choice will be made. It's not quite as efficient but it avoids interaction and storage.
In many applications there is some sufficient N of N that is much more likely to be used than others, so in practice the efficiency gap may not be large. For example, if you have 2 of 3 with you, an offline key of yours, and some 2FA service then you normally expect the 2-of-2 involving you and the 2fa will be signing 99.99% of the time.
Unrelated to efficiency/storage-durability there is another big reason that many applications may not want to use efficient threshold signatures: They're unaccountable. If an unauthorized payment is made there is no way to prove which keys were involved.
The above alternatives to native thresholds are all inherently accountable.
A couple years back I proposed an alternative construction that I called polysig which is not supported in taproot today but could be added in a leaf version later which had size that was linear in the number of non-participating signers, relatively private (observers only learn the number of missing keys not the total number of keys) and completely accountable. But given that taproot can efficiently do the "A specific N of N" or "something else"-- there wasn't a lot of interest in going forward with completing the polysig work (e.g. formally proving its security).
|
|
|
|
|
I think that while the OP is technically wrong, there is a kernel of truth in their claim.
Vanity addresses, generated correctly, aren't inherently weaker-- as people were quick to point out.
Attackers can generate lookalike addresses for any address, vanity or not-- but they can only look so alike due to exponential complexity.
It's unsafe to tell if a an address, ANY address, is the right one by comparing only a couple characters especially if an attacker can predict what characters you'll check. Just like statistical methods in password guessing are surprisingly effective I imagine that a sufficiently smart attacker could make more successful lookalikes than you'd assume on first guess-- maybe because he uses fancy techniques to compute really fast, maybe because he is really good at predicting the visual similarity of addresses.
Why would do people use vanity addresses? Mostly because they expect people to recognize the name as being associated with them. They use them because they want people to be comparing those friendly human readable characters.
So essentially vanity addresses encourage an unsafe behaviour-- users validating an address by comparing a few easily predicted characters. Making a predictable and weak comparison is unsafe for any kind of address, but for a vanity address enabling a weak comparison is a lot of the point for people.
Is it possible to use vanity addresses safely? Absolutely-- validate them by comparing parts other than the vanity part. But do most users compare them safely? Probably not.
If users could be relied on to compare as much non-vanity part as they would on a non-vanity address, you could make an argument that they increase security by making it more expensive to generate vaguely similar addresses. But I think it's clear that this benefit is dwarfed by people-- even experts-- not being as diligent in comparing them. While working on BIP173 I contemplated making it expensive to brute force similar addresses-- e.g. applying a expensive cryptographic permutation to the data before encoding it in an address. But I felt I just couldn't justify making implementers life harder for a speculative benefit that only helps really sloppy users. Any operation expensive enough to really slow attackers would be painfully slow on hardware wallet devices which are uniformly very underpowered. ... and I also expected that because that kind of strengthening would make vanity address generation much harder too I might have had to navigate opposition from users that didn't want vanity addresses to be much less available to them.
Another alternative I considered but didn't go for was requiring the underlying address data to have an all zeros suffix. This would also make generation expensive-- but would have the additional benefit of allowing shorter addresses-- so at least the benefit wouldn't just be against sloppy users. But it would really complicate hdwallet/taproot/multisig usage where generating a key is already complicated.
In any case, ... just because something exists doesn't mean it's a good idea. There is evidence in the wild that lookalike vanity addresses being used to rob people and lookalike onion domains in Tor, so the security concern isn't just a theory.
Given that, as mentioned, they're also pretty toxic for privacy (both due to encouraging reuse and being identifiable) they're probably better avoided.
|
|
|
|
Pieter has posted about changing BIP340 to us a different R tiebreaker: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-August/018081.htmlThis is some signature algorithm behavioural minutia. Basically BIP340 did an unconventional thing because we believed it was faster enough to be worth a small increase in implementation complexity but it turns out that our belief was based on a both a broken benchmark and a supporting (wrong) assumption and it's not actually faster and might, in fact, be slightly slower in the long run. Changing to the more conventional thing would simplify implementations and make them somewhat faster. He tells me that he's received a bunch of positive commentary on it, so I expect the change will be made soon! |
|
|
|
No and I'd avoid any wallet that displayed it. That data comes from an third party and can be malicious. If not malicious, it can be and often is spam. E.g. if FooWallet had a behaviour to display it what would happen if someone started spamming FooWallet users with "Emergency FooWallet Upgrade required: Load www.emergencyfoowalletupgrade.com for more info!"? The best defence against malicious messages and spam is both to just to avoid displaying human readable information sourced from untrusted sources. |
|
|
|
You also can't just come up with any domain parameters you like,
Unless you're microsoft.  This thread is silly. If you can change the basepoint the problem is trivial. Set the basepoint to any number times the pubkey. The private key is the modular inverse of that number. |
|
|
|
The reason I'm such a huge fan of the idea of "utxo-giftcards" is that it's pretty phenomenally space-efficient (as you can give someone money without even making a transaction) and a death-blow t entire classes of bitcoin analysis attacks. (Of course there are drawbacks in transferring a private-key, but I feel those are pretty obvious and understood enough that it's easy to use what is most suitable)
It's also a perfect match to the model of a gift or a donation-- you don't care if the donor/gifter claws their money back at the last moment (-- you'd rather that didn't but you weren't relying on them not doing it). It also addresses the problem that small bitcoin gifts usually result in lost coins. I'm very happy that Bitcoin I gifted in the past was gifted using by handing out private key. People lost their gifts and I was able to recover them for them. |
|
|
|
What you signal is mostly moot however, if you're not even listening for connections from outside. Wouldn't my outbout 8 peers receive whatever I broadcast with sendrawtransaction? I will set maxconnections to 20 then, just to be safe. I mean it doesn't matter if you are node-limited or not. Nodes that you connect out to will not request historical blocks from you unless they're weird and modified. This is done specifically to avoid burdening users on limited connections behind NAT with hundreds of gigabytes of block requests per month. You only end up serving historical blocks if you accept incoming connections. |
|
|
|
|
Show Posts
