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.
Someone's lying to you
Core changed theirs to 80, but 40 is what the standard was.
If they don't want to comply, that's fine, but blaming me for their decision not to is dishonest.
Also note that having ANY extra data hurts your privacy, which seems to contradict the goals of coinjoins. Not really sure what Samourai is thinking here ...
42 is 40 + 2 opcodes (which are counted in the current versions)
If you think Core gets to just dictate things, get over your centralization mindset.
Knots has used 40/42 since 2013. Samourai are the ones who chose to exceed it.
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.
TIDES is basically PPLNS as it was originally supposed to be, with a very long N.
PPLNS today has become something very different, so we picked a new name to avoid confusion
If you were waiting for me to publish my new "master" OpenPGP key announced at #FutureOfBitcoinMining, it should now be available from keyserver.ubuntu.com along with signatures:
- master key signing codesigning key (used for Knots v25.1)
- master key signing security communication key (for email about security issues)
- codesigning key signing master key
Master key: 93CB4961F69A65082D4410802CBA8253089655C3
Codesigning key: 1A3E761F19D2CC7785C5502EA291A2C45D0C504A
Security comms key: FAC098FE8DF9975F902418813666E2B1782A18E1
There was a minor issue with one of the three main features that we promptly fixed. 🙄
The known-late feature (better spam filtering) was not advertised yet as it wasn't/isn't ready.
We never custody, but you're right below the threshold wouldn't be paid yet.
However, a huge reward like this is going to push many more past that threshold
At 300, it's about 11 days between blocks on average (likely a bit shorter in practice)
Normally a block reward is split across the past 8*difficulty work performed. But that much work hasn't been done yet, so early miners would get a higher payout for a while
Looking forward to presenting at the #FutureOfBitcoinMining conference next week.
Even if you won't make it, I recommend joining via the livestream. 😉
nostr:nevent1qqsgy8mj8qwfcxcv9dswnkkx3530f32rj9knrzvv6wy7ku7lyj5mwtqpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzqqke74nkll7r88l7jn06kw97hcsuuytudu2snkvj92pdg485yrdzqvzqqqqqqyjvxusa
Only difference between Core and Knots fee estimates is Knots by default targets confirmation within 24 hours.
Looking at your current mempool for fee estimation is broken by design
#Bitcoin Knots 25.1.knots20231115 (finally) released! 🎉
Be sure to _verify_ your download(s)!
New PGP key: 1A3E761F19D2CC7785C5502EA291A2C45D0C504A
https://bitcoinknots.org/?25.1?nostr
Liquid is multisig to begin with... The point is they're transparent with the security model unlike Ethereum which pretends it's something it really isn't in practice.
(Also, IIRC those backups aren't actually accessible by Blockstream without the functionary giving it to them - they're encrypted so the functionary can't use it alone: it functions as an effective 2-of-2)
No, a dispensation is required to marry heretics too - and even then, the marriage would still be invalid if the non-Catholic intends to convert the Catholic or their children to another religion.
Notes by Luke Dashjr | export