I was wondering how much in % of nodes must be running core 30 in order to have the op_return limit increased. In clark moody's website I see core 30 around 8%, is that too little or already enough? That's also surprising that 8% of the nodes already upgraded to 30.
pull down to refresh
2, your own and a miner, and then you connect to that miner. It's policy, not constrained by any threshold activation.
If you want to reliably be able to send a tx under the new policy, with outgoing connections only, at 32% adoption you would be able to do that reliably 95% of the time. With 125 connections, you need 0.3% adoption, much less than there is for v30 right now. But, you don't know how the v30 is configured.
For the inverse, to block every node with only outgoing transaction 95% of the time, you need about 99.4% of nodes to have a declining policy. With 125 connections, 99.96% of nodes is needed to block 95% of nodes from transmitting their txs.
So I need a newer SSD lol
for your Pi4? No. You need someone to fix the regression. I'm working on it but if you know someone that can do it faster, I will not be upset, lol.
what regression?
The one where it takes up to 2 minutes to validate a block on a Pi4.
when did it started? do you have some link about it? So that's why it's taking forever to sync on a rpi4 now?
I shared it with you yesterday!!! #1269950
Sorry my memory is almost dead, need more B12 lol
Roughly 0%. Miners can put an OP_RETURN up to 1MB in a block regardless of what P2P nodes set their config to.
This block that was mined 6 months ago is entirely filled by a 1MB OP_RETURN, long before Core V30's release: https://mempool.space/block/000000000000000000005bcbf03e6488be1ceb3b501ecfc2b11cce900a870636
oh so there's no limit on consensus rules other than the 1mb block limit?
8% of listening nodes should make it work pretty reliably.
So by that calculation we're there already.