andrewtoth

Public Key

npub1zrwrpdmavhpgsngzymvw45k494gdwens8l7ua7l55pcm8eejlfnsvk38tm

Profile Code

nprofile1qqspphpska7kts5gf5pzdk826t2j65xhvecrllwwl062qudnuue05ecprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqy08wumn8ghj7un9d3shjtnwdaehgu3wvfskuep0w3e82um5v4jqy0p6ty

Publishing to

relay.noswhere.com

relay.nostr.band/trusted

relay.damus.io

Author Public Key

npub1zrwrpdmavhpgsngzymvw45k494gdwens8l7ua7l55pcm8eejlfnsvk38tm

Show more details

Last Notes

2024-10-05 22:27:09

- reply

metal

2024-09-18 14:34:54

- reply

Not sure, but it is a work in progress for libsecp256k1 https://github.com/bitcoin-core/secp256k1/pull/1134

2024-09-15 23:45:40

- reply

It *should* suggest using migratewallet RPC to migrate the wallet. Not sure what happens exactly.
https://bitcoincore.org/en/doc/27.0.0/rpc/wallet/migratewallet/

2024-09-06 00:24:08

- reply

Can't you do something like this with pow?

2024-09-04 01:17:34

- reply

That's nostr for you!

2024-08-31 22:37:23

- reply

This too shall pass

2024-08-16 19:09:27

- reply

Makes sense, yes. I'd follow.

2024-08-08 22:43:15

- reply

https://m.youtube.com/watch?v=gVGbDEAnDyo

2024-08-08 13:23:01

- reply

Indeed, and dbcache will also help connect blocks faster in v28
https://github.com/bitcoin/bitcoin/pull/28233

2024-08-08 13:08:33

- reply

https://github.com/bitcoin/bitcoin/pull/28280

2024-08-08 12:37:08

- reply

The IBD is only faster for pruned nodes, but otherwise yes banger indeed!

2024-07-16 02:33:55

- reply

https://youtu.be/eBxTEoseZak

2024-07-06 02:46:08

- reply

Long or short?

2024-06-29 02:13:35

- reply

Who won?

2024-06-28 14:17:20

- reply

Great 'sode named after that quote
https://m.imdb.com/title/tt6483046/

2024-06-22 20:07:32

- reply

Setting higher dbcache benefits block validation time in addition to initial sync time. It should always be increased if there's enough free RAM.

2024-06-22 20:05:27

- reply

The dbcache *is* a read cache, and this misconception has kept block validation times longer than they need to be. This problem will be fixed in v28. https://github.com/bitcoin/bitcoin/pull/28233

2024-06-16 02:30:34

- reply

Lisan al-gaib!

2024-06-15 22:10:45

- reply

Nobody's mentioning the ostrich?

2024-06-14 20:17:26

- reply

R u not?

2024-06-13 14:31:01

- reply

Could be worse

2024-06-09 14:52:12

- reply

Silent payments lets you publish a static payment address, and no observer can see any payments made to it. You need the private key to see your payments. This means no more address reuse, no more having to generate new addresses for payments. No more looking up wallet balances on block explorers. Huge UX and privacy boost for Bitcoin.

2024-06-07 19:10:37

- reply

The majority are run on AWS

2024-06-07 14:30:43

- reply

A softfork does not violate the rules of the network though, that is the difference between a soft fork and hard fork. Miners are free to choose what software to run the same as any other network participant. If a minority of hash power doesn't follow it, the majority chain will always overtake the minority fork. So any miners that don't follow it will lose a lot of money.

2024-06-07 13:14:05

- reply

The segwit2x attackers were stopped by the community not explicitly running segwit2x nodes, but remaining on the status quo Bitcoin Core nodes. How would that help in the case where attackers are enabling a soft fork that is invisible to status quo Bitcoin Core nodes?

2024-06-06 13:56:22

- reply

They've been cultivating relationships with mining pools. If they convince a supermajority of hash power to run their patch (unfortunately not very many entities), how will they be stopped?

2024-06-05 23:09:45

- reply

I blame JavaScript

2024-06-05 22:50:54

- reply

Because of JavaScript?

2024-05-31 14:55:06

- reply

They're not trying, they're doing?

2024-05-30 22:14:08

- reply

Your mama likes it.

2024-05-30 02:07:08

- reply

This makes it impossible for anyone other than the sender to see any payments to the silent payment address. So you and I could both pay the same publicly posted silent payment address and we would never know about the other payment, and it would not be possible to look it up on a block explorer either.

2024-05-30 02:03:25

- reply

The sender can find out the real address on send, because they are the ones who create the output. But they can't see any other sends to the silent payment address from any other sender. And no, nobody else can figure out any other payments to the recipient without the recipient's private key.

2024-05-27 00:46:10

- reply

Down wit' OPP?

2024-05-24 14:39:53

- reply

I feel seen. Except I don't run any part of society.

2024-05-24 00:30:33

- reply

Who are the fremen?

2024-05-22 08:45:51

- reply

I don't think any new onion routing network bolted on to the Bitcoin network will be able to be more reliable than Tor or I2P with decades of research and development. Not to mention that Tor and I2P exist today and dandelion is vaporware that will never realistically be built.
#nevent1q…e4c9

2024-05-22 08:26:44

- reply

That's not exactly true though, your node and the peer you anonymously connect to can both be clearnet for Tor. You just need a tor proxy available to your node and it can route it through an exit node.
Similar for I2P, except the peer must be behind I2P as well.
It breaks all heuristics if used today for any transactions sent with it. For dandelion, you need many peers running it to hide in an anonymity set.

2024-05-22 07:09:06

- reply

It offloads the onion routing to Tor and I2P, two of the best anonymity networks to achieve an even better level of privacy. Building out a Bitcoin specific onion routing network using a parallel mempool is a fool's errand and will not be able to achieve the same results as the best researched and developed networks built specifically for anonymity.

2024-05-22 06:55:27

- reply

> A supernode [...] can establish where a transaction was first seen in the peer-to-peer network, ergo ascribe whom a transaction belongs to.
It completely removed this ability of the supermodel, whereas with dandelion the supernode still has at least one peer it can ascribe ownership to. So it is even better than dandelion.
How do you think it falls short of achieving the same thing?

2024-05-22 00:01:20

- reply

This is a much simpler alternative that achieves the same thing, and has a PR ready to be merged today. IMO you should promote review of this to get merged asap instead of dandelion which has been around as an idea for a decade.
https://github.com/bitcoin/bitcoin/pull/29415

2024-05-21 16:12:03

- reply

Sapiens has a whole chapter about this

2024-05-20 05:41:26

- reply

It takes a long time for them to validate a new block, because they have to fetch all txs that were filtered from peers.
https://github.com/bitcoin/bitcoin/pull/28233 should help mitigate this.

2024-05-17 17:15:27

- reply

Good example!
Anything in the last hundred years though?

2024-05-12 14:14:15

- reply

Hmm that's not how a soft fork works. Soft forks are invisible to non-consenting nodes. The UASF forced all hash rate onto the soft fork. There's no way to force majority hash rate to *not* enforce a soft fork by running a node without new hard fork rules.

2024-05-12 13:53:04

- reply

Not sure, haven't been following closely. I'm just countering the assertion "Soft forks require economic majority of nodes to run." It only requires hash rate majority, which can be forced by economic majority without hard fork. It can't be stopped by economic majority without hard fork.

2024-05-12 07:05:50

- reply

2017 was an economic majority enforced soft fork with a minority of hash rate. Today the threat is hash rate majority soft fork. The only way for economic majority to stop it is with a hard fork.

2024-05-12 05:15:25

- reply

Soft forks only require a majority of hash power to run. Enforcing a soft fork with a minority of hash power required an economic majority.
The only way an economic majority can reject a majority of hash power enforced softfork is with a hard fork.

2024-05-12 05:06:56

- reply

Use i2pd, it's pure C++.

2024-05-08 13:44:04

- reply

Why is that worse than the fact that they're stealing?

2024-05-04 00:07:42

- reply

*one patent

2024-05-04 00:05:37

- reply

It's a long story, on twitter 🙊. Not really that big of a deal it's just patent in a sea of approvals unfortunately.
https://twitter.com/tuftythecat/status/1786463556520542247

2024-03-29 18:30:20

- reply

Oh, if the user is not compiling this will not work. You will have to generate the function and compile it for each L value you want your users to be able to configure. A declarative macro would work for that.

2024-03-29 17:19:45

- reply

Use a procedural macro that reads the config value and generates the const L using the value specified before compilation.

2024-01-26 01:49:57

- reply

The previous logic was
```
nwc_kinds && has_authors || has_pks
```

2024-01-03 23:51:00

- reply

9 out of 10 cats disagree

2023-11-11 15:09:10

- reply

https://m.youtube.com/watch?v=gjyFiqI54G8 Yeah but I'm partial to Auston Matthews 😁