Had hoped we'd be done already, but doing things right takes time😓
You'll need a Lightning wallet with bolt 12 support, and a way to sign a message with your current L1 address.
No, but it's likely going to be much sooner for 1-style addresses (the only kind currently which support signed messages / proof you're the recipient).
Supporting others need BIP 322 to be completed (I may need to help out to get it past finish) and/or accounts of some sort
The CVE is for the vulnerability enabling Inscriptions to bypass node policy (regardless of what it's set to).
There should be no reason to be angry. It's just the normal procedure for security issues
The standard datacarriersize Knots has always used is 42 bytes. They knew that and ignored it. We haven't changed anything in this regard.
Brc20 comes in at 45 bytes, so just increasing it isn't a viable solution. That doesn't mean we're giving up - we do want to mine these - but it's going to take some work if Samourai doesn't fix the issue on their end (ultimately there's no good reason for ANY of this data)
With the bug, whatever you set it to is IGNORED for Inscriptions. So if you set it to 0, it won't do anything. If you set it to 40 or 80, still won't work.
That's my point. It's a bug. Fixing the bug just puts you back in control of your own node
More pools isn't enough. Each and every miner needs to be deciding for himself.
Until OCEAN, miners had no choices. Now they have one more. Soon, we'll release the flood gates so they have infinite possibilities
The UI is already updated for the Hestia rectangle, just a matter of configuration (assuming I pushed the code to GitHub...)
Lmk if any issues, or if I need to push it
The OP_RETURN discussion is not new and dates back to 2014 when Bitcoin Core 0.9.0 was released with the OP_RETURN policy included which was intended to discourage more egregious forms of spam. At that time, 40 bytes was the default max datacarriersize limit across all node implementations; this was and still is sufficiently large for tying data to a transaction (32 bytes for a hash and 8 bytes for a unique identifier). Core subsequently increasing the default to 80 bytes was an entirely voluntary decision and in no way contradicts the design objective that OP_RETURN creates a provably-prunable output to minimise damage caused by data storage schemes, which have always been discouraged as abusive. There are also other good technical reasons which I have chosen to retain the lower default in Bitcoin Knots, and no justification for increasing it.
It is not my intention, nor that of my team at
@OCEAN, to filter coinjoins. These present an innovative tool for increasing Bitcoin’s privacy and, when constructed properly, coinjoins can easily stay within the OP_RETURN limit (indeed, there is no reason for them to have *any* OP_RETURN data at all). I have some ideas on how to alleviate the recent issue where some coinjoin transactions were flagged as spam from Knots v25, and I am willing, with the full resources of my team, to work collaboratively on a solution in good faith.
Bitcoin does and always has allowed nodes to set filters based on multiple sets of criteria and Knots v25’s defaults are IMO what is best for Bitcoin at this time. Others may disagree and that is ok. They are free to (and should) run their own nodes - it is good for Bitcoin to have more people running nodes, including miners, and there should be a natural diversity in node policies. As was stated before, OCEAN is on a path to decentralization and very soon we are going to be in a position where hashers will be able to fully participate as miners and perform the intelligent parts of mining such as deciding which version of node software to run and what filters or other policies to apply to block template construction.
PSA: “Inscriptions” are exploiting a vulnerability in #Bitcoin Core to spam the blockchain. Bitcoin Core has, since 2013, allowed users to set a limit on the size of extra data in transactions they relay or mine (`-datacarriersize`). By obfuscating their data as program code, Inscriptions bypass this limit.
This bug was recently fixed in Bitcoin Knots v25.1. It took longer than usual due to my workflow being severely disrupted at the end of last year (v24 was skipped entirely).
Bitcoin Core is still vulnerable in the upcoming v26 release. I can only hope it will finally get fixed before v27 next year.
Oddbean new post about login | logout
Notes by Luke Dashjr | export