Could any Rustaceans out there explain:

I have a package (toy-rpc), if i enter its version in Cargo.toml I get one specific error when i run `cargo check` (or build ofc). This is ok, i can solve that error.

When I change from version to local file in Cargo.toml **, while making sure the local git repo is checked out at exactly the same commit (one that is tagged with the same version no.), I get a bunch of different errors.

I'm stumped; considering as, per commit hash, I'm compiling against literally the exact same code.

Any one know what I missed?

** i.e `toy-rpc = {path = "/path/to/toy-rpc", ...}`

Interesting to consider that, to whatever extent nostr fixes this, it's not due to an uncensorability property.

It's good advice for privacy reasons. It *does* make some attacks on funds security easier, but in itself, it doesn't break that security. I would say 'never share it' is a good default position.

Oh 100%.

Good work!

Just read the "Dark Skippy" attack ( darkskippy.com ) from Lloyd Fournier and Robin Linux (h/t Alex Waltz). Nice write up! I've always thought it should be simpler than grinding, though (but the grinding in that attack is very practical). I feel like a variant of what they call 'predetermined nonce attack' on that page could work. If I make a *big* assumption - that the attacker has access to the victim's wallet's xpub - then I think you can extract the master secret from only 1 signature or 2 signatures, without any grinding or pollard rho. With 2 signatures the full master secret of the wallet; with 1, only the xpriv for the (BIP32) account (so compromises only 1 account; but many wallets just use one account anyway!).

Let's see if there's any error in these steps:

1. Attacker uses RNG to generate sequence of 32 byte randoms (b1, b2  ..)

2. First signature that the client requests is generated using b1 as nonce. hence attacker can obviously extract the secret key x1 = (s1 - b1) / e1.

3. We have to assume knowledge of xpub. Given xpub and one private key (x1) from the account branch, then due to unhardened derivation, we can already derive the xpriv for the account (though not for the level above; so this is equivalent to master secret, only for single-account wallets, not for multiple account).

But if we have access to 2 signatures we can exfiltrate anything, including the full master secret:

4. Second signature that the client requests, on (currently unknown) private key x2, is generated using nonce = (b2 + master secret), which is still indistinguishable from random because b2 is. Here we need the xpriv as per above to regenerate (poss. by trial and error, but that's trivial) the correct x2 given the above xpriv derivation. Then attacker extracts master secret = s2 - b2 -ex2.

(Am I wrong somewhere there? Wouldn't be too surprised. But either way, exfiltration via these channels *one way or another* seems like it's very hard to prevent. (I know there *are* anti-exfil measures in existence, so please don't take this as me dismissing them - I haven't even really studied them!).To generate bitcoin signatures on serious amount, use the software that's as easy as possible to vet and has the least layers between your eyes and it .. is my extremely unconventional advice on this topic).

Haven't tried it but seems like a smart idea.

nostr:nevent1qqsqklns4s4utcst87cee6qgp2kygaqdu5axvgg3s29veja32k5uwcqpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsyg9ukyyz93nwrndmzmxk9k4frwc0yfkus5lfcg03wg3w4f50nw80mspsgqqqqqqs7kwqxq

No, regrettably (or yes? depends how to interpret the Q.). When i was a kid people did read on trains, but it was mostly shitty newspapers (we used to call them 'rags'). People reading actual books was really rare. Reading 'broadsheets' (which contained words with more than 2 syllables, instead of sensationalist gossip) was a class indicator. If anything it was worse than today, because of the extreme centralization of voice.

You can use a self custody wallet like phoenix. No need to have the money held by a third party, just because running one's own node is too high of a bar.

Quotes: "The secret key sk: a 32-byte array, freshly generated uniformly at random" and as I already pointed to you, in "Default Signing":

Let d' = int(sk)

Fail if d' = 0 or d' ≥ n

Let P = d'⋅G

Let d = d' if has_even_y(P), otherwise let d = n - d' .

The secret key is still sk as defined above; d is *not* the secret key. It is a step in the signing algorithm.

Yes you can do those things but you are not fixing an error. It is not an error to use a private key x fir which the corresponding pubkey xG has odd parity.

Doesn't nostr use BIP340 keys? A private key that has a public key with odd parity is not invalid; you just use the corresponding even parity point in encoding. It's effectively using -x * G for specific algorithms (see the "Default Signing" algorithm in bip340), but it's not that x is an invalid private key.

Honestly the x-only encoding was a bad choice, it has led to a lot of confusion and complexity.

You can now run an autct server by just downloading the binary here: https://github.com/AdamISZ/aut-ct/releases/latest and running it with `./autct -M serve -k mycontext:mykesetfile` (or use an example keyset file shown in the worked example), then make RPC calls from Python with no crypto code (just do `pip install autctapi` ... though you'll want to look at the github repo for the example.py script), to prove that your taproot utxo is in the utxo set. The proving takes 5-15 seconds for keysets up to a couple hundred thousand keys, while the verifying is basically instant.

If you did want to use mainnet keys, you can get a daily-updated set of taproot keys from https://hodlboard.org/keysets. This is filtered to be only keys for utxos > 500k sats, and so it's small, about 17MB. You can demonstrate that it works "for real" by funding such a utxo and then trying the prove and verify operations the next day. It's fiddly mainly because most wallets don't support taproot, and those that do don't let you copy the private key. See https://hodlboard.org/proofs for how to get around that.

(Better to generate the keysets yourself of course, but it takes some time to figure that out, detailed instructions in first repo mentioned)

I want to upvote this sentiment, but somehow feel the second sentence misses the mark.

The whole point of politicians is that they won't leave us alone.

And the whole point of bitcoin is to make that matter less.

Imagine that the ownership of a utxo could be traded directly - ignore, for a moment, that you can't trade ownership with private keys, ignore trading costs etc. etc., not because those issues don't exist, but because I want to focus on the economic calculus outside of it.

Now this question is only interesting if the utxo is somehow encumbered, and ignoring general covenants, let's focus specifically on timelocked utxos (which is in fact a primitive covenant).

So concretely, imagine 1 BTC which is timelocked for 1 year, and imagine you could somehow freely trade it. What would its market value be?

Note that this is *not* similar to traditional put/call options, because we are not talking about the *option* to buy something, but about directly trading it. So it seems to be the same contract as a future (except not requiring a court to enforce!). You're buying the thing (in this case "a" bitcoin), but not able to do anything with it until 1 year expires. Is that worth more or less than 1BTC today?

In normal futures markets, there is another factor to consider: the base currency in which the "commodity" is being priced. So nobody talks about the price of a futures contract on a barrel of oil, measured in barrels of oil, they only talk about it measured in USD. For that case, we have "normal" curves where the further out into the future you go, the more it costs to buy such a contract, because you are hedging risk of volatility and you pay a premium for that, and then you have inverted or "backwardated" curves where it's actually cheaper to buy well into the future, because of competing factors like storage costs and others.

We could try to apply that logic to trading bitcoin/usd futures and indeed, they exist! So people do exactly that. But I'm thinking of the price of the contract in BTC. It seems obvious that the price of 1 BTC in 1 year is less than 1BTC today, because the buyer forgoes the *option* to use the money in the meantime, for anything else, including productive investment. That discount is sometimes called the "time value of money". So you could imagine some formula like 1 BTC - r*1year*1BTC where r is some vague idea of a riskless interest rate.

That's all very kind of "standard" thinking but I am not sure if it's the real story. If I buy a futures contract I have to literally hand over the money to a broker and I receive a contract. But if I somehow gain ownership of a timelocked utxo (see caveat at the start), I have something slightly different. Can if I borrow against it and gain independent value from it while it is locked? I thought about this but the picture appears to be very muddy. So, can I? What do you think? :)

concordium.com

We've come a long way from the 2015 days of 'enterprise blockchain' **, now it's:

Web3ID

AI Accountability

Identity-centric L1 blockchain

Compliance-ready

Energy-efficient blockchain

NFTs

Metaverse

DeFi

** .. or have we?

On a first scan read, I'm not sure there's much of interest here. As he notes in the efficiency section, it's comparable in verification cost to pre existing C(LSAG), at least that's intuitive, so I just believe it. It *is* very compact, but I don't think that's new.

I think curve trees + signature of knowledge of the rerandomised key gives the same effect with much faster verification, at the cost of a fairly trivial increase in size of proof (and with very sublinear scaling, imagine 2.6kB for 50K keys and 2.6kB for 200K keys).

In a blockchain proof size is paramount, but verification speed is also important. Luke Parker's FCMP stuff is actually trying to get both together.

No I'll take a look later, thanks!

I'm terrible with this, I definitely get your point.

But your note could be more concise ;)

I don't know, perhaps try the Jam telegram group: https://t.me/JoinMarketWebUI ?

Define 'soon' 😄

People in Europe think they know what rain is ... they do not!

Just read the first couple paragraphs... it comes on a bit strong, but, yep 😄

Oh sorry it's a joke reference to a critique of string theory, criticizing it as not being real science. Stimuff like ALARA/P is not really anything to do with science imo.

Into the third day of what is likely 6+ days of *constant* very heavy rain here in El Salvador.

Country is now in a 'red alert' condition.

Esrmtimated 600mm of accumulated rainfall. I think it's going to be really bad in the low lying areas with poor infrastructure.

So you believe there's a threshold. Back when I was studying this, I remember also feeling strongly that this should be true, logically.

Reminds me of the old (possibly apocryphal) story of the guy who dropped his banana from lunch on the floor of a nuclear power plant and it triggered alerts on people's dosimeter readings 😄

Natural sources are easily high enough to matter, a lot, with LNT. So yeah i agree it's probably just wrong, and 'ALARA' is ... not even wrong 😄