0 sats \ 0 replies \ @0260378aef 22 Jan \ parent \ on: Fedimint is Self-Custodial ecash
The difference is the case where no one can spend at all :)
(Not disagreeing, I also don't really get what is Ben's point there.)
I suppose ecash is non-custodial in the framework you propose as long one considers it completely separate from bitcoin and not a promise for Bitcoin.
No, the argument for "even federated ecash is custodial" would not be dependent on that. It's an argument to be sure, there is more than one facet here, but the power that the (federation) mint has over you is the issue, and that doesn't disappear because what their token represents is not bitcoin.
(In the extreme, if they didn't claim their token represented anything, not even trust in their integrity, then the token is meaningless. If the token is supposed to represent value, then there is a trust issue, so that "self-custodial" is a problematic description).
0 sats \ 0 replies \ @0260378aef 5 Jan \ parent \ on: Why do people declare the LN a failure? Ask_SN
LN was going to enable the planet to use BTC at scale, no more high fees onchain.
According to absolutely no one, including the authors themselves, who went to great lengths to explain to people both in the paper and in follow up talks, that it doesn't scale to the whole world. (there isn't enough block space for every one to have a channel of their own).
It does, and so do many other websites. However that's taking someone else's word for it, if you do the above you are calculating it yourself, on the actual real bitcoin blockchain (and you know it's "the" bitcoin blockchain because of the whole proof of work concept - it's essentially physically impossible for anyone to generate an alternative).
No, I don't think there was any confusion in that second point. I read the function in your library, then I went looking for
secp256k1.GenerateShared Secret that you use, there.I don't think there's any issue apart from the one you mention about how the private key is generated, i.e. what they warn about in your original comment. (and this is always a big concern to address, whether doing ECDH or anything else).
And as for pubkeys, which are the only source of a "twist attack" type concern, The
secp256k1.PubKey object is almost always going to be generated from ParsePubKey right? The only other way is via a constructor, and there is no concern there anyway.So I guess it must be this one?
What's input is a PubKey object, which I guess will be got by calling
ParsePubKey, here?:and it is checking that it's a valid point (actually, it's also checking in the case when the point is uncompressed, as you'd hope/expect. (line 141)
I guess it's just my lack of knowledge of something about golang? But I can't find github.com/decred/dcrd/dcrec/secp256k1/v4 , nor can I find a v4 (or v4.*) branch?
No, it's to generate the conversation key (shared secret)
Ah! I had a feeling I was missing something, indeed :) Should have read the function :)
So the question is whether the operation in the called library is checking the input public key. Where is that function? The decred github link in the comment is (no longer?) valid).
The warning is telling me that is that it does not check, it just truncates the value. Checking would mean that it would throw an error imo:
I think that warning is just talking about how it truncates the input private key argument, i.e. if it's > N but < 2*256. N is a few bits smaller than 2^256. So if you enter a value m s.t. N < m < 2 **256 it will truncate it by doing m mod N, which will be an extremely small number, and therefore a valid, but completely insecure private key. At least that's how I read the comment.
I'm not sure if I'm misunderstanding something, but when you talk about
GenerateConversationKey you're talking about generating private keys? But there's no danger from an invalid curve point here, that function just needs to check that a given 32 byte random string is less than the curve order (N or whatever); the comment warning is basically telling you to do that.Re: "twist attack": It's when "you" (the program) is receiving a public key from an external input (to do an ECDH operation), that you need to check "is this point on the curve" (or, more normally, it's compressed, so the issue doesn't even arise).
Just quickly skimming the audit, they themselves note that this error is basically irrelevant as long as you stick with compression (which everyone using secp256k1 in bitcoin has, for like, 8+ years). Still something an audit should include though, for sure.
This might be due to the location of your IP address.
At one point, the white paper was entirely removed from bitcoin.org, because of the fraud Craig Wright's lawsuits threating people (specifically here, the owner of the domain bitcoin.org). I can't say for 100% but I think Cobra probably has it now set up to not deliver the whitepaper to certain jurisdictions(?).
Fascinating illustration of the difficulty of carrying cryptography over human communication. As is famous, in Bletchley Park, "cribs" were key to cracking Enigma messages, so it's not surprising that in '44 the Americans were keenly aware of the need to not use guessable starts and ends to messages, but using properly random padding is super hard for a human to transfer over a radio.
449 sats \ 1 reply \ @0260378aef 22 Dec 2023 \ parent \ on: History of Cryptography in the U.S. crypto
Fun fact, the t-shirt was made by Adam Back :)
I wouldn't have said 'pumping the bags', lol, but this was also my immediate reaction to the blog post. It will leave any reader under the impression that MuSig2 isn't ready and can't be used - in a very fundamental sense, both are not true. (Like, we've both used it, for a start :) ).
I guess I should clarify that it's not like there's zero "value" in using bare multisig vs say data embedded in a pubkey-hash standard output here. There's some few bytes of savings by using one output instead of multiple; and from the point of view of coding some jpeg-tracking thing it's always easier to track one output instead of many.
But just talking in general, at the highest level, you can't stop this by disabling one output type
The problem is not only bare multisig.
If you banned bare multisig, they can do the same with hash values. In both cases (a EC pubkey, a hash function output, there is no structure you can enforce [*], and no way for you to know if the creator has a preimage for what they're publishing. So they can embed data in it.
It's pretty strange how many otherwise very technically knowledgeable people think that we can stop this with some new standardness rule or whatever. We basically can't, unless we do something very drastic to what Bitcoin even is. (Demurrage? )
[*] Apart from the fact that only approx 50% of random 256 bit strings are valid x-coords on the curve, for the former
Outstanding work, looks really good! I only did Chapter 1 but it was very smooth.
This could work for e.g. a young teenager with an interest in the area, to slowly get them comfortable with the idea of coding and technical details about bitcoin.
Maybe I'm missing something but I don't get the argument that somehow this de-duplication was bad because "there proved later to be tons of special cases for each shape" etc.
That's why object hierarchies work, right? You have a Shape object with all the basics, then the exceptions that occur in e.g. Oval are isolated the Oval sub-class. Makes way more sense than having Oval just repeat all the boilerplate that's already in all the other shapes.
Deduplication matters a lot. Especially for productivity. (For example, if you repeated the same logic in 10 places, then made a patch and forgot to update 1 of the 10, it would be fine if you have a test suite that catches the error, but it sure wasted a lot of your time!).
The stuff about team work etc. sure, but that's completely orthogonal.
Zero chance that that graph shows the change in real estate prices in China. Even outside of Tier 1 cities, where by any measure, there has been a substantial fall - but not a 75-80% one ... (and most of the value measured in yuan, is in Tier 1 and Tier 2 cities).
I'm guessing it shows real estate stocks? That would make perfect sense.
(Of course the usual caveat - you can't trust any statistics coming out of China, generally - if this is a stock price chart (aggregate over several companies), it may be coming out of HK rather than the mainland market, and generally that's substantially more trustworthy).
But without a link to the source or a mention of what the y axis actually is, I can guarantee people (most?) responding to you in the thread are assuming that it shows real estate prices.
422 sats \ 1 reply \ @0260378aef 5 Dec 2023 \ parent \ on: What else is trending towards becoming "free"? meta
It's also the conclusion you'd reach by realizing that there are people who produce this stuff recreationally or for ideological reasons and want others to have free access.
That's a part of it, but the other part of it is that software itself is information. It's just a digital pattern, which can be copied. So there is no "rivalrousness" as the theorists of this type of thing, say. That's the main reason why the natural price of software is "kinda-sorta" zero.
Imagine that a supervillain devoted to the enslavement of mankind gets control of 75% of btc hashpower, and proceeds to censor transactions, double-spend strategically, decry carnivory, etc. What happens?
That's a really good thought experiment, but the point that's missing is that the coordination problem.
That's exactly what the Byzantine Generals (and Satoshi's update "the king's wifi") are about - if you presuppose the ability to globally coordinate and trust non-defection, then proof of work as a solution is not needed.
And indeed, your analogy is not at all contrived - it's the true state of the world. Governments and other large powerful entities could coordinate to attack bitcoin at the level of hashpower, but they have not, and I contest, they will not succeed in doing so, exactly because of that inability to coordinate at a sufficiently overwhelming scale (in geography, in time, in category etc.).
We've seen an example already - China hosted the majority of the world's hashpower and then suddenly outright banned mining - but they couldn't get other large powers to coordinate, so Bitcoin was (more or less!) fine.
If the community -- defined in the hazy way that's necessary when talking about something as nebulous as the people who have some kind of stake in btc -- believes, collectively, that this state of affairs violates the ideas that it's committed to, they'll fork away from that chain, despite its preponderance of PoW, and direct their various efforts toward the new enterprise. The fact that there's exahash sitting on the sidelines is not the issue.
In the same way that hashpower follows price, and not the reverse, hashpower is a function of commitment, which itself is mediated by price.
Yes I always get this line of counterargument when I say these things, and of course, it must be partly true - one of the main two factors here (let's say "network effect" and "proof of work") doesn't work without the other.
The reason I see network effect as a proximate cause, not an ultimate cause, is a matter of simple logic - network effect could somehow arrive in any other system of money, why doesn't it (hence me saying "unstable equilibrium")? You're not getting at the ultimate cause of bitcoin's success if you focus on network effect.