Quote from: z on Today at 04:25:12 PM

I firmly believe that simpler is better. I Removing OP_return limits is definitely a huge mistake.

Simpler is better ... so removing complexity from the bitcoin codebase is a huge mistake? Huh

?

Quote from: OgNasty on Today at 09:33:19 PM

by not living up to promises made in the New York agreement [...] and fulfill their 2017 obligation that was made

(added hyperlink)

Hi Og, I made an agreement with another forum poster that you would give me all your assets. Of course, your participation was expressly and explicitly excluded from our negotiation, but none the less you have obligations and aren't living up to them right now. Pay up! I'll let you keep a cardboard box to sleep in, and if you're nice a swamp cooler. I'm sure you wouldn't want to fail to live up to your obligations. Grin

Quote from: philipma1957 on Today at 10:03:45 PM

But as a person running a full unpruned node I do not want to be charged with distributing
illegal data.

That risk sucks but it exists today and isn't changed by alterations to opreturn filtering on nodes.

You can mitigate the risk by setting "prune=1" in your bitcoin.conf. This won't actually prune any blocks, but will behave to the outside world as if you have-- so it won't serve any historic blocks more than about two days old. You can also make sure your block files are new enough that they're encrypted so that scanning tools won't flag anything in them.

It's important to keep some perspective: No one has ever gotten in trouble with this and it's only one of many fringe theoretical risks. Life just has risks-- someone could relay a north korean transaction through your node and authorities could potentially try blaming you for it or just come to seize your node to try to get logs to determine the transaction's origin. Also very not likely. You could be sued for patent infringement by Craig Wright's co-scammer business partners as they've repeatedly claimed Bitcoin violates their patents the fact that they're full of shit doesn't mean that they couldn't cause you bankrupting levels of legal expenses.

But if you don't run your own node maybe you're the last straw that otherwise would have helped hold back a bad consensus change.

Basically if you're going to commit yourself to worrying then there is no end to it. The best you can do is be aware of more significant risks, mitigate what you can affordably mitigate and deal with problems as they arise. Only the dead are invulnerable to risk.

Quote

I can not be assured that the node does not carry criminal data and there is no plan in action to stop that issue

It's not that there is no plan, it's that it's a fundamental issue that appears to be largely unsolvable. It also isn't unique to bitcoin-- anyone who publishes anything could accidentally transmit illegal data that someone snuck in, even if they were engaging in editorial oversight.

Beyond the block file and utxo set encryption bitcoind/bitcoin-qt doesn't provide any facilities to decode/display these embedded things, quite intentionally, to avoid any argument that the node operator meaningfully had access. Also the P2P protocol got encryption a while back, though I worry that drama adverse behavior is delaying developers doing the right thing and offering an option to only use encrypted connections. I have a patch available that I made for a friend if you want one, it's required no revisions to apply cleanly for more than a year now.

There are also ideas like assumeutxo which will allow people to bring up a full node without validating (thus downloading) the far past that would help. Though of course this comes with a security tradeoff in that you only have 'assumevalid' like security of the part you didn't validate... but it's another way Bitcoin has worked on mitigating risk from illegal content.

Quote from: d5000 on Today at 06:33:33 PM

I'm also a bit in conflict with this part of the PR, even if I (as I wrote above) also understand the arguments in favour of removing that possibility mentioned by @gmaxwell.
I also want to point out that if the datacarriersize parameter is removed, then the incentive to use alternative implementations like Knots could increase. This would create additional complexity: Now both versions are in conflict regarding a relatively minor issue like standardness. But in the future it's possible that alternative implementations, encouraged by increased use, could move towards protocol changes, like the reduction of block size to something like 150 kB proposed by the Knots main developer.

There are two PRs, one which leaves a setting but unlimits it by default. Of course, most people 'following' the debate don't even know that...

It's less advanced in development in part because its a somewhat harder change. I'm not really that opinionated on leaving a useless option in, though because of the character of the response I do lean towards removing it: Removing it is simpler, results in less complexity. Perhaps less good reasons, conceding to an attack driven by misinformation or collateral concerns creates ongoing risk. For people who intentionally have exaggerated the issue a concession just amplifies their social clout. Some people running some other version isn't inherently bad, and if they're doing it because they've been bamboozled then the solution is education. If they're doing it because they're so angry at other uses that they'd harm bitcoin in order to harm the other uses, I'd rather they go off and do their own thing and not distort future development priorities with future unreasonable demands.

Also running another version is overkill for this, this is exactly the kind of small change that it ought to be easy to carry a local patch for. The ecosystem would be better off if more people felt comfortable doing that. True, I believe this is a silly and unhelpful thing to carry a local patch for.. but if it causes people to learn how and not be afraid of it, then that sounds like a winning outcome to me.

It's extremely easy to drum up or even outright fake public outrage... more sybil vulnerable than even P2P. If developers are going to be diverted from what they think is best via that kind of attack, then that is a really serious and concerning vulnerability. That doesn't mean they shouldn't listen-- they should, but all that should matter is good arguments that go directly to the issue in question, and not unfocused outrage or abusing the subject as a proxy issue.