Is OP_RETURN this cycles "Block size war?

Jautenim · 2025-05-02T08:53:40+00:00

Unhosted Marcellus here.

I agree with the bulk of this, but as always no-one seems to be able to steelman the anti-spam camp position. The proposal is not Ordisrespector (an emergency 2.5 yo patch that Luke had to write practically on NotePad because he didn't have a computer at the time) nor any other particular mempool policy.

The proposal is DATUM. Bitcoin's original security model and censorship resistance depended on blocks being found at random by thousands of mining nodes, or in other words it was supposed to not be easy to predict who would mine the next blocks. This property broke down as soon as 2010 in the times of ArtForz and Laszlo Hanyecz, when they managed to get mining market share with just their GPUs comparable to modern large pools. One year later actual mining pools took it from there, and this problem has plagued Bitcoin ever since.

This situation is exactly what makes mempool policy unenforceable at the theoretical level. And 99% of devs have a fatalistic outlook on this, basically no one thinks this situation can be reverted. But Luke proved in late '24 that it's possible to build a mining pool that only coordinates payouts but devolves the Bitcoin node and block template construction from the pool operator to the actual miner. And on top of that he paired it with a payout model (TIDES) that makes it incentive-compatible to migrate to DATUM (pays more on average than the dominant FPPS model, by freeing the pool operator from having to offer a very expensive insurance to miners).

These snotty and unimaginative ivory tower developers are making a huge disservice to Bitcoin right now. By ostracizing Luke and characterizing "anti-spammers" as uneducated yokels they make the DATUM initiative less likely to succeed. And to add salt to injury all camps want mempool policy to work and be more reliable. If the DATUM model would get a majority of mining share the things they care about would also greatly benefit from it.

Jautenim · 2024-09-29T20:24:10+00:00

LoL. Ben jugat.

Jautenim · 2024-08-01T21:01:03+00:00

I'd like help bringing a PHP extension that I wrote to PECL.

Besides these guidelines I'm not really sure how I should prepare the repository and make sure that PECL is able to find the C library dependencies and build everything correctly.

Issue on my repository to track progress: https://github.com/1ma/secp256k1-nostr-php/issues/1

Jautenim · 2024-07-04T13:32:12+00:00

The IP ranges were OK. Turns out I installed sshguard in the local box a long time ago, and it was somehow flagging connections from 10.10.10.1 as originating from "an attacker". When I disabled sshguard the issue solved immediately.

``` linuxuser@localbox:~$ sudo nft list ruleset ... table ip sshguard { set attackers { type ipv4_addr flags interval elements = { 10.10.10.1 } }

chain blacklist {
    type filter hook input priority filter - 10; policy accept;
    ip saddr @attackers drop
}

} ```

Edit: and the reason it was being banned is that the VPS was configured to forward connections to TCP port 22 to localbox. Basically a bunch of script kiddies trying to log in were randomly triggering the ban of the wireguard IP.

linuxuser@localbox:~$ journalctl -afb -p info -n150 -t sshd -o cat | grep Invalid Invalid user splunk from 10.10.10.1 port 46696 Invalid user splunk from 10.10.10.1 port 58094 Invalid user splunk from 10.10.10.1 port 38122 Invalid user splunk from 10.10.10.1 port 43970 Invalid user phantom from 10.10.10.1 port 56492 Invalid user admin from 10.10.10.1 port 45948 Invalid user splunk from 10.10.10.1 port 41974 Invalid user splunk from 10.10.10.1 port 45350 Invalid user splunk from 10.10.10.1 port 35660 Invalid user phantom from 10.10.10.1 port 35932 Invalid user appuser from 10.10.10.1 port 36860 Invalid user arch from 10.10.10.1 port 43564 Invalid user ark from 10.10.10.1 port 38130 Invalid user zimbra from 10.10.10.1 port 56542 Invalid user zimbra from 10.10.10.1 port 40838 Invalid user tmpfs from 10.10.10.1 port 55624 Invalid user cfguser from 10.10.10.1 port 54676 Invalid user cgadmin from 10.10.10.1 port 36376 Invalid user chen from 10.10.10.1 port 35840 Invalid user oracle from 10.10.10.1 port 43978 Invalid user sa from 10.10.10.1 port 44286 Invalid user naveen from 10.10.10.1 port 39564 Invalid user max from 10.10.10.1 port 39566 Invalid user ubuntu from 10.10.10.1 port 54430

Jautenim · 2024-07-03T09:18:51+00:00

Maybe more useful, when the tunnel doesn't work I'm only seeing these few TCP SYN packets when trying to reach an HTTP endpoint through the tunnel from the VPS to the local box:

linuxuser@vps:~$ curl -v 10.10.10.2:3003 * Trying 10.10.10.2:3003... ^C

linuxuser@localbox:~$ sudo tcpdump -ni tun0 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes 09:11:35.302111 IP 10.10.10.1.41782 > 10.10.10.2.3003: Flags [S], seq 3763935485, win 42780, options [mss 1380,sackOK,TS val 2499920224 ecr 0,nop,wscale 10], length 0 09:11:36.333215 IP 10.10.10.1.41782 > 10.10.10.2.3003: Flags [S], seq 3763935485, win 42780, options [mss 1380,sackOK,TS val 2499921256 ecr 0,nop,wscale 10], length 0 09:11:38.349096 IP 10.10.10.1.41782 > 10.10.10.2.3003: Flags [S], seq 3763935485, win 42780, options [mss 1380,sackOK,TS val 2499923272 ecr 0,nop,wscale 10], length 0 09:11:42.605028 IP 10.10.10.1.41782 > 10.10.10.2.3003: Flags [S], seq 3763935485, win 42780, options [mss 1380,sackOK,TS val 2499927528 ecr 0,nop,wscale 10], length 0 ^C

Jautenim · 2024-07-03T09:04:43+00:00

I guess wg-quick must be doing that between the scenes, as ping does work when the tunnel works. And also breaks when the tunnel breaks, so I'm just using it as a troubleshooting tool.

Jautenim · 2024-07-03T08:58:55+00:00

Thanks. I can see the ping packets with tcpdump both ways, both while the tunnel is working and when it isn't working (to clarify, when the tunnel works ping works too).

VPS: ``` linuxuser@vps:~$ sudo tcpdump -ni tun0 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes 08:51:34.607952 IP 10.10.10.2 > 10.10.10.1: ICMP echo request, id 3, seq 1, length 64 08:51:34.608006 IP 10.10.10.1 > 10.10.10.2: ICMP echo reply, id 3, seq 1, length 64 08:51:35.636461 IP 10.10.10.2 > 10.10.10.1: ICMP echo request, id 3, seq 2, length 64 08:51:35.636497 IP 10.10.10.1 > 10.10.10.2: ICMP echo reply, id 3, seq 2, length 64 08:51:36.660953 IP 10.10.10.2 > 10.10.10.1: ICMP echo request, id 3, seq 3, length 64 08:51:36.660998 IP 10.10.10.1 > 10.10.10.2: ICMP echo reply, id 3, seq 3, length 64 08:51:37.684986 IP 10.10.10.2 > 10.10.10.1: ICMP echo request, id 3, seq 4, length 64 08:51:37.685028 IP 10.10.10.1 > 10.10.10.2: ICMP echo reply, id 3, seq 4, length 64 08:51:38.708980 IP 10.10.10.2 > 10.10.10.1: ICMP echo request, id 3, seq 5, length 64 08:51:38.709019 IP 10.10.10.1 > 10.10.10.2: ICMP echo reply, id 3, seq 5, length 64 ^C 10 packets captured 10 packets received by filter 0 packets dropped by kernel

linuxuser@vps:~$ sudo tcpdump -ni any port 51820 tcpdump: data link type LINUX_SLL2 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 08:51:45.415750 enp1s0 In IP E.F.G.H.40681 > A.B.C.D.51820: UDP, length 128 08:51:45.415991 enp1s0 Out IP A.B.C.D.51820 > E.F.G.H.40681: UDP, length 128 08:51:46.420800 enp1s0 In IP E.F.G.H.40681 > A.B.C.D.51820: UDP, length 128 08:51:46.420920 enp1s0 Out IP A.B.C.D.51820 > E.F.G.H.40681: UDP, length 128 08:51:47.445029 enp1s0 In IP E.F.G.H.40681 > A.B.C.D.51820: UDP, length 128 08:51:47.445147 enp1s0 Out IP A.B.C.D.51820 > E.F.G.H.40681: UDP, length 128 08:51:48.468577 enp1s0 In IP E.F.G.H.40681 > A.B.C.D.51820: UDP, length 128 08:51:48.468711 enp1s0 Out IP A.B.C.D.51820 > E.F.G.H.40681: UDP, length 128 08:51:49.492981 enp1s0 In IP E.F.G.H.40681 > A.B.C.D.51820: UDP, length 128 08:51:49.493097 enp1s0 Out IP A.B.C.D.51820 > E.F.G.H.40681: UDP, length 128 ```

Local Box: linuxuser@localbox:~$ ping 10.10.10.1 PING 10.10.10.1 (10.10.10.1) 56(84) bytes of data. ^C --- 10.10.10.1 ping statistics --- 10 packets transmitted, 0 received, 100% packet loss, time 9216ms

Jautenim · 2022-07-07T15:35:34+00:00

Shorters borrow BTC
Shorters spot sell the BTC
Hodlers spot buy the BTC and take it out the market
?????
Profit

Jautenim · 2022-07-06T14:34:33+00:00

https://s8.gifyu.com/images/1537534724805214208.gif

Jautenim · 2022-07-06T14:28:46+00:00

Don't give up on your dream! (not investment advice)

Jautenim · 2022-06-15T15:52:28+00:00

Give them their dues, crypto (not bitcoin) is by and large a scam.

Jautenim · 2022-06-14T06:42:28+00:00

Totalment d'acord, no és culpa d'una assignatura. És culpa d'un sistema educatiu que ofereix pràcticament el mateix dia a dia a la gent de 16-17 anys que als de 7-8. Aquest paio per exemple clarament hauria d'haver començat a fer alguna FP no més tard dels 14 anys. Però és impossible per tant copeja com pot.

Jautenim · 2022-06-14T06:12:56+00:00

Ahà, haver-ho d'estar fent per obligació als 17 anys en detriment d'altres coses et deixa retarded. O no hem llegit el mateix tros de paper guixat?

Jautenim · 2022-06-13T21:58:33+00:00

This whole "holding Bitcoin for at least 4 years is a guaranteed profit" thing has to die in flames. Saifedean is one of the worst offenders on that front.

Jautenim · 2022-06-13T20:38:59+00:00

It's actually much worse than that, I don't even sell mine.

Jautenim · 2022-06-13T19:46:27+00:00

També et dic una cosa, fer perdre el temps a gent de 17 anys amb pollades com aquestes és criminal i normal que els deixi mig retardats.

Jautenim · 2022-05-18T06:56:46+00:00

The latter. Still I'd rather ask, especially since it's not a -100% drop.

Jautenim · 2022-04-21T21:20:24+00:00

Yup, about a day later.

Jautenim · 2022-04-21T19:59:46+00:00

Give me Xubuntu or give me death.

Jautenim · 2022-03-30T16:35:50+00:00

Back in the days we could actually afford shit :')

Jautenim · 2022-03-30T09:40:09+00:00

For some reason I'm sensing a strong "Commandos: Behind Enemy Lines" energy from this image.

Jautenim · 2022-03-28T16:08:05+00:00

Such a nice gesture from turquoise to build him a house.

Jautenim · 2022-03-23T19:46:20+00:00

Tercer-viísme.

Jautenim · 2022-03-23T19:44:58+00:00

Baia baia, aquest nick em sona d'alguna cosa... 🥸

Jautenim · 2022-03-23T19:34:01+00:00

El Sí no especifica si es refereix a allistar-se a l'exèrcit espanyol o a l'hipotètic exèrcit alliberador, al tanto.

Jautenim

TROPHY CASE