andrewtoth

Public Key

npub1zrwrpdmavhpgsngzymvw45k494gdwens8l7ua7l55pcm8eejlfnsvk38tm

Profile Code

nprofile1qqspphpska7kts5gf5pzdk826t2j65xhvecrllwwl062qudnuue05ecpz3mhxue69uhhyetvv9ujuerpd46hxtnfduh6am5c

Publishing to

relay.damus.io

Author Public Key

npub1zrwrpdmavhpgsngzymvw45k494gdwens8l7ua7l55pcm8eejlfnsvk38tm

Show more details

Last Notes

2024-09-06 21:13:39

- reply

köszönöm

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 14:37:41

- reply

I suppose because many of his other investments depend on a strong USD.
He is British and I am Canadian so there is definitely no oath to USD in this conversation.

2024-08-31 14:11:02

- reply

https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1719s

2024-08-31 13:43:43

- reply

You can't force us all to learn rust!

2024-08-31 13:36:54

- reply

Are you me?
Just had an uncle tell me he should have bought some, but also he can't invest in anything that would threaten the USD. 🤷

2024-08-29 18:18:43

- reply

Severed lime and mango chainsaw?

2024-08-16 15:10:59

- reply

Center

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:09:10

- reply

#nevent1q…wd32

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-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-14 20:17:26

- reply

R u not?

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-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
```

2023-09-28 04:16:07

- reply

Can't he just change his name?

2023-09-03 20:08:10

- reply

Is that broccoli on your pizza? 🤢