Thanks for your comments!


That really to me sounds more like luke-jr justifying his historical practice of putting bible quotes and other bitcoin-irrelevant material in blocks.  I don't think it really answers anything.   There are many fields in Bitcoin -- like the entire content of the output scripts of a transaction that the consensus rules don't do anything with, just like the consensus rules don't do anything with the scriptsig of a coinbase transaction (the '95 bytes' the reply refers to).   I've seen no indication that the anti-spam contingent is okay with stuffing arbitrary data into *those* fields.   And it's probably worth remembering the the history of Bitcoin "anti-spam" started with Satoshi dice an "on chain gambling site" (really probably a money laundering operation (see the first and second MTGOX hacker indictment, and dooglus' forensic accounting), but it at least pretended to be a gambling site-- history may not repeat but it rhymes).  Luke created, ran, and distributed patches that blacklisted their addresses and even put the patches into the gentoo distribution of the Bitcoin software, not just his own knots.  

So even if we go back to the very start of anti-spam in bitcoin we can see that it has always hinged on a subjective judgement of the users activity.   The Bitcoin project (now called core) has always eschewed that sort of thinking and tried very hard to make any restriction as content neutral as possible-- even when, or especially when, the contributors didn't like the usage.

At the same time that answer also strikes on why filtering efforts are pretty doomed-- he starts by assuming that the user is willing to disguise their activity as something it isn't.  But that same willingness is why it can't be blocked, or at least the portion of "spam" that really is disguised.

I think in general the term spam is a poor fit. With email spam you win so long as you don't see it, it doesn't matter if your computer sees it or your ISPs computer sees it.  And all this stuff in bitcoin that gets called spam is never seen by anyone who doesn't want it, so by the email definition bitcoin has (almost) no spam.  There is ONE thing in Bitcoin that is very much like email spam:  Dusting.  And yet dusting wouldn't fit in the definition above, as it's not disguised as something it isn't.  It's a payment, just one that you don't want and probably causes you more harm than good.   There is a fair amount of dusting, it seldom generates much complaint. There are things that can be done to deal with it (e.g. wallets not showing the small payments)-- but it seems there isn't much interest in trying.   So I think there is an issue, sure, but spam isn't the right word.

Similarly, op_return traffic isn't disguised. But clearly no one is arguing that it is definitionally impossible for OP_RETURN material to be spam.

I think the thing people are actually mad about today is shitcoin issuance and the fact that people are willing to burn up Bitcoin's capacity on tokens whose value is essentially independent of Bitcoin.  But none of the anti-spam stuff really addresses that, and to the extent that the shitcoin stuff is made more valuable by limited supply, it might even make it worse.

I'd agree except for the fact that isolated participants setting that setting don't actually have any beneficial effect to themselves.  I don't think the easy of an ineffectual choice is a relevant development criteria.  There is a real cost to users and developers in having more options, and the software shouldn't offer knobs that essentially don't work.    In any case, at least for now it looks like the knob is staying.

I mean it's a sybil attack and probably a CFAA violation, though obviously no one is going to be pressing charges over it.  If anyone cared about it, it's easy to bypass, by simply observing the peers behavior and banning peers that are clearly filtering transactions or going farther and periodically asking peers how much the next block is worth, fetching it if they have something more valuable, and banning them if they can't deliver.

Bitcoin Core already does this for blocks-- basically testing the peers accept the chain they're on, and disconnecting ones that don't and also by slowly probing the entire network to make sure no one has a better chain.   This was implemented because of a similar "pretend to be compatible" behavior put into segwit2x as part of an effort to force nodes into accepting a hardfork by surrounding them and denying them access to a chain they were compatible with.

Librerelay itself mostly seems to be performance art, pointing out that censorship is substantially undermined by even a small amount of parties being willing to route around it.  The point really isn't defeated by an attempt to undermine librerelays rather minimal and half-hearted efforts... and you got to kinda wonder what people are thinking there?  Because while Librerelays point is that censorship is ineffective, the counter's argument is that they can make it effective by trying harder.  Is that really where we are? With supposed Bitcoiners arguing that censorship is effective and cooking up better roadmaps for trying it?

Bleh.

(And sure, I'm aware of the position that the filtering isn't censorship due to some value judgement over the usage, but the tools and methods are the same...)

Of course, fixing librerelay to punt the sybil attackers takes some code and Peter Todd is not likely to waste too much time on his performance art... But the more fundamental point is that you can (and today the 'spammers' largely do) just give the transactions directly to large miners.  This is just horrible for mining centralization, and at least librerelay was a little corrective pressure against direct miner relationships.

I'm very saddened that people's thinking has become so distorted and in favor of blocking stuff that they don't like that they're cheering what is effectively a sybil attack against an effort that bypasses blocking to avoid creating direct miner relationships.  I'm really glad that Petertodd is a good sport and views that sort of thing as just another interesting challenge.


Indeed.


Bitcoin nodes are all about making a statement about what Bitcoin is by literally defining it via their consensus rules.  During the whole blocksize war drama there were a lot of people who just didn't get that.
Part of why they didn't get it is that they were focused on another truth:  When it comes to what Bitcoin does *within those rules* those nodes have little to no influence unless they are mining, and even if mining they have the power to permit without the power to refuse.  The power to refuse comes only from a supermajority hashpower and/or consensus rules. And this is a point that I think today's hyper-bitcoin anti-spam advocates are missing.

The situation would be different, perhaps, if the anti-spam army were proposing consensus rules-- but so far they haven't, and that is no shock because there isn't any rule consensus or otherwise that blocks traffic that doesn't need consensus enforcement and is willing to change its appearance (well not any short of radical changes that would cause massive functionality loss).   They stick instead to policy rules, which at least allow for a perpetual ineffectual game of cat and mouse.  One I think might provide for full employment for filter authors and filter evaders, but be no good for the rest of us.

Thanks for your comments!


That really to me sounds more like luke-jr justifying his historical practice of putting bible quotes and other bitcoin-irrelevant material in blocks.  I don't think it really answers anything.   There are many fields in Bitcoin -- like the entire content of the output scripts of a transaction that the consensus rules don't do anything with, just like the consensus rules don't do anything with the scriptsig of a coinbase transaction (the '95 bytes' the reply refers to).   I've seen no indication that the anti-spam contingent is okay with stuffing arbitrary data into *those* fields.   And it's probably worth remembering the the history of Bitcoin "anti-spam" started with Satoshi dice an "on chain gambling site" (really probably a money laundering operation, but it at least pretended to be a gambling site-- history may not repeat but it rhymes).  Luke created, ran, and distributed patches that blacklisted their addresses and even put the patches into the gentoo distribution of the Bitcoin software, not just his own knots.  

So even if we go back to the very start of anti-spam in bitcoin we can see that it has always hinged on a subjective judgement of the users activity.   The Bitcoin project (now called core) has always eschewed that sort of thinking and tried very hard to make any restriction as content neutral as possible-- even when, or especially when, the contributors didn't like the usage.

At the same time that answer also strikes on why filtering efforts are pretty doomed-- he starts by assuming that the user is willing to disguise their activity as something it isn't.  But that same willingness is why it can't be blocked, or at least the portion of "spam" that really is disguised.

I think in general the term spam is a poor fit. With email spam you win so long as you don't see it, it doesn't matter if your computer sees it or your ISPs computer sees it.  And all this stuff in bitcoin that gets called spam is never seen by anyone who doesn't want it, so by the email definition bitcoin has (almost) no spam.  There is ONE thing in Bitcoin that is very much like email spam:  Dusting.  And yet dusting wouldn't fit in the definition above, as it's not disguised as something it isn't.  It's a payment, just one that you don't want and probably causes you more harm than good.   There is a fair amount of dusting, it seldom generates much complaint. There are things that can be done to deal with it (e.g. wallets not showing the small payments)-- but it seems there isn't much interest in trying.   So I think there is an issue, sure, but spam isn't the right word.

Similarly, op_return traffic isn't disguised. But clearly no one is arguing that it is definitionally impossible for OP_RETURN material to be spam.

I think the thing people are actually mad about today is shitcoin issuance and the fact that people are willing to burn up Bitcoin's capacity on tokens whose value is essentially independent of Bitcoin.  But none of the anti-spam stuff really addresses that, and to the extent that the shitcoin stuff is made more valuable by limited supply, it might even make it worse.

I'd agree except for the fact that isolated participants setting that setting don't actually have any beneficial effect to themselves.  I don't think the easy of an ineffectual choice is a relevant development criteria.  There is a real cost to users and developers in having more options, and the software shouldn't offer knobs that essentially don't work.    In any case, at least for now it looks like the knob is staying.

I mean it's a sybil attack and probably a CFAA violation, though obviously no one is going to be pressing charges over it.  If anyone cared about it, it's easy to bypass, by simply observing the peers behavior and banning peers that are clearly filtering transactions or going farther and periodically asking peers how much the next block is worth, fetching it if they have something more valuable, and banning them if they can't deliver.

Bitcoin Core already does this for blocks-- basically testing the peers accept the chain they're on, and disconnecting ones that don't and also by slowly probing the entire network to make sure no one has a better chain.   This was implemented because of a similar "pretend to be compatible" behavior put into segwit2x as part of an effort to force nodes into accepting a hardfork by surrounding them and denying them access to a chain they were compatible with.

Librerelay itself mostly seems to be performance art, pointing out that censorship is substantially undermined by even a small amount of parties being willing to route around it.  The point really isn't defeated by an attempt to undermine librerelays rather minimal and half-hearted efforts... and you got to kinda wonder what people are thinking there?  Because while Librerelays point is that censorship is ineffective, the counter's argument is that they can make it effective by trying harder.  Is that really where we are? With supposed Bitcoiners arguing that censorship is effective and cooking up better roadmaps for trying it?

Bleh.

Of course, fixing librerelay to punt the sybil attackers takes some code and Peter Todd is not likely to waste too much time on his performance art... But the more fundamental point is that you can (and today the 'spammers' largely do) just give the transactions directly to large miners.  This is just horrible for mining centralization, and at least librerelay was a little corrective pressure against direct miner relationships.

I'm very saddened that people's thinking has become so distorted and in favor of blocking stuff that they don't like that they're cheering what is effectively a sybil attack against an effort that bypasses blocking to avoid creating direct miner relationships.  I'm really glad that Petertodd is a good sport and views that sort of thing as just another interesting challenge.


Indeed.


Bitcoin nodes are all about making a statement about what Bitcoin is by literally defining it via their consensus rules.  During the whole blocksize war drama there were a lot of people who just didn't get that.
Part of why they didn't get it is that they were focused on another truth:  When it comes to what Bitcoin does *within those rules* those nodes have little to no influence unless they are mining, and even if mining they have the power to permit without the power to refuse.  The power to refuse comes only from a supermajority hashpower and/or consensus rules. And this is a point that I think today's hyper-bitcoin anti-spam advocates are missing.

The situation would be different, perhaps, if the anti-spam army were proposing consensus rules-- but so far they haven't, and that is no shock because there isn't any rule consensus or otherwise that blocks traffic that doesn't need consensus enforcement and is willing to change its appearance (well not any short of radical changes that would cause massive functionality loss).   They stick instead to policy rules, which at least allow for a perpetual ineffectual game of cat and mouse.  One I think might provide for full employment for filter authors and filter evaders, but be no good for the rest of us.

Thanks for your comments!


That really to me sounds more like luke-jr justifying his historical practice of putting bible quotes and other bitcoin-irrelevant material in blocks.  I don't think it really answers anything.    There are many fields in Bitcoin -- like the entire content of the output scripts of a transaction that the consensus rules don't do anything with, just like the consensus rules don't do anything with the scriptsig of a coinbase transaction (the '95 bytes' the reply refers to).    I've seen no indication that the anti-spam contingent is okay with stuffing arbitrary data into *those* fields.    And it's probably worth remembering the the history of Bitcoin "anti-spam" started with Satoshi dice an "on chain gambling site" (really probably a money laundering operation, but it at least pretended to be a gambling site-- history may not repeat but it rhymes).  Luke created, ran, and distributed patches that blacklisted their addresses and even put the patches into the gentoo distribution of the Bitcoin software, not just his own knots.  

So even if we go back to the very start of anti-spam in bitcoin we can see that it has always hinged on a subjective judgement of the users activity.    The Bitcoin project (now called) core) has always eschewed that sort of thinking and tried very hard to make any restriction as content neutral as possible-- even when, or especially when, the contributors didn't like the usage.

At the same time that answer also strikes on why filtering efforts are pretty doomed-- he starts by assuming that the user is willing to disguise their activity as something it isn't.  But that same willingness is why it can't be blocked, or at least the portion of "spam" that really is disguised.

I think in general the term spam is a poor fit. Like withWith email spam you win so long as you don't see it, it doesn't matter if your computer sees it or your ISPs computer sees it.  And all this stuff in bitcoin that gets called spam is never seen by anyone who doesn't want it, so by the email definition bitcoin has (almost) no spam.  There is ONE thing in Bitcoin that is very much like email spam:  Dusting.  And yet dusting wouldn't fit in Luke'sthe definition above, as it's not disguised as something it isn't.  It's a payment, just one that you don't want and probably causes you more harm than good.

Similarly, op_return traffic isn't disguised. But clearly no one is arguing that it is definitionally impossible for OP_RETURN material to be spam.

I'd agree except for the fact that isolated participants setting that setting don't actually have any beneficial effect to themselves.  I don't think the easy of an ineffectual choice is a relevant development criteria.  There is a real cost to users and developers in having more options, and the software shouldn't offer knobs that essentially don't work.    In any case, at least for now it looks like the knob is staying.

I mean it's a sybil attack and probably a CFAA violation, though obviously no one is going to be pressing charges over it.  If anyone cared about it, it's easy to bypass, by simply observing the peers behavior and banning peers that are clearly filtering transactions.

Bitcoin Core already does this for blocks-- basically testing the peers accept the chain they're on, and disconnecting ones that don't.    This was implemented because of a similar "pretend to be compatible" behavior put into segwit2x as part of an effort to force nodes into accepting a hardfork by surrounding them and denying them access to a chain they were compatible with.

Librerelay itself mostly seems to be performance art, pointing out that censorship is substantially undermined by even a small amount of parties being willing to route around it.  The point really isn't defeated by an attempt to undermine librerelays rather minimal and half-hearted efforts... and you got to kinda wonder what people are thinking there?  Because while Librerelays point is that censorship is ineffective, the counter's argument is that they can make it effective by trying harder.  Is that really where we are? With supposed Bitcoiners arguing that censorship is effective and cooking up better roadmaps for trying it?

Bleh.

Of course, fixing librerelay to punt the sybil attackers takes some code and Peter Todd is not likely to waste too much time on his performance art... But the more fundamental point is that you can (and today the 'spammers' largely do) just give the transactions directly to large miners.  This is just horrible for mining centralization, and at least librerelay was a little corrective pressure against direct miner relationships.

I'm very saddened that people's thinking has become so distorted and in favor of blocking stuff that they don't like that they're cheering what is effectively a sybil attack against an effort that bypasses blocking to avoid creating direct miner relationships.  I'm really glad that Petertodd is a good sport and views that sort of thing as just another interesting challenge.


Indeed.


Bitcoin nodes are all about making a statement about what Bitcoin is by literally defining it via their consensus rules.  During the whole blocksize war drama there were a lot of people who just didn't get that.
Part of why they didn't get it is that they were focused on another truth:  When it comes to what Bitcoin does *within those rules* those nodes have little to no influence unless they are mining, and even if mining they have the power to permit without the power to refuse.  The power to refuse comes only from a supermajority hashpower and/or consensus rules. And this is a point that I think today's hyper-bitcoin anti-spam advocates are missing.

The situation would be different, perhaps, if the anti-spam army were proposing consensus rules-- but so far they haven't, and that is no shock because there isn't any rule consensus or otherwise that blocks traffic that doesn't need consensus enforcement and is willing to change its appearance (well not any short of radical changes that would cause massive functionality loss).    They stick instead to policy rules, which at least allow for a perpetual ineffectual game of cat and mouse.  One I think might provide for full employment for filter authors and filter evaders, but be no good for the rest of us.

Thanks for your comments!


That really to me sounds more like luke-jr justifying his historical practice of putting bible quotes and other bitcoin-irrelevant material in blocks.  I don't think it really answers anything.   There are many fields in Bitcoin -- like the entire content of the output scripts of a transaction that the consensus rules don't do anything with, just like the consensus rules don't do anything with the scriptsig of a coinbase transaction (the '95 bytes' the reply refers to).   I've seen no indication that the anti-spam contingent is okay with stuffing arbitrary data into *those* fields.   And it's probably worth remembering the the history of Bitcoin "anti-spam" started with Satoshi dice an "on chain gambling site" (really probably a money laundering operation, but it at least pretended to be a gambling site).  Luke created, ran, and distributed patches that blacklisted their addresses and even put the patches into the gentoo distribution of the Bitcoin software, not just his own knots. 

So even if we go back to the very start of anti-spam in bitcoin we can see that it has always hinged on a subjective judgement of the users activity.   The Bitcoin project (now called) core has always eschewed that sort of thinking and tried very hard to make any restriction as content neutral as possible.

At the same time that answer also strikes on why filtering efforts are pretty doomed-- he starts by assuming that the user is willing to disguise their activity as something it isn't.  But that same willingness is why it can't be blocked, or at least the portion of "spam" that really is disguised.

I think in general the term spam is a poor fit. Like with email spam you win so long as you don't see it, it doesn't matter if your computer sees it or your ISPs computer sees it.  And all this stuff in bitcoin that gets called spam is never seen by anyone who doesn't want it.  There is ONE thing in Bitcoin that is very much like email spam:  Dusting.  And yet dusting wouldn't fit in Luke's definition, as it's not disguised as something it isn't.  It's a payment, just one that you don't want and probably causes you more harm than good.

I'd agree except for the fact that isolated participants setting that setting don't actually have any beneficial effect to themselves.  I don't think the easy of an ineffectual choice is a relevant development criteria.  There is a real cost to users and developers in having more options, and the software shouldn't offer knobs that essentially don't work.    In any case, at least for now it looks like the knob is staying.

I mean it's a sybil attack and probably a CFAA violation, though obviously no one is going to be pressing charges over it.  If anyone cared about it, it's easy to bypass, by simply observing the peers behavior and banning peers that are clearly filtering transactions.

Bitcoin Core already does this for blocks-- basically testing the peers accept the chain they're on, and disconnecting ones that don't.   This was implemented because of a similar "pretend to be compatible" behavior put into segwit2x as part of an effort to force nodes into accepting a hardfork by surrounding them and denying them access to a chain they were compatible with.

Librerelay itself mostly seems to be performance art, pointing out that censorship is substantially undermined by even a small amount of parties being willing to route around it.  The point really isn't defeated by an attempt to undermine librerelays rather minimal and half-hearted efforts... and you got to kinda wonder what people are thinking there?  Because while Librerelays point is that censorship is ineffective, the counter's argument is that they can make it effective by trying harder.  Is that really where we are? With supposed Bitcoiners arguing that censorship is effective and cooking up better roadmaps for trying it?

Bleh.

Of course, fixing librerelay to punt the sybil attackers takes some code and Peter Todd is not likely to waste too much time on his performance art... But the more fundamental point is that you can (and today the 'spammers' largely do) just give the transactions directly to large miners.  This is just horrible for mining centralization, and at least librerelay was a little corrective pressure against direct miner relationships.

I'm very saddened that people's thinking has become so distorted and in favor of blocking stuff that they don't like that they're cheering what is effectively a sybil attack against an effort that bypasses blocking to avoid creating direct miner relationships.  I'm really glad that Petertodd is a good sport and views that sort of thing as just another interesting challenge.


Indeed.


Bitcoin nodes are all about making a statement about what Bitcoin is by literally defining it via their consensus rules.  During the whole blocksize war drama there were a lot of people who just didn't get that.
Part of why they didn't get it is that they were focused on another truth:  When it comes to what Bitcoin does *within those rules* those nodes have little to no influence unless they are mining, and even if mining they have the power to permit without the power to refuse.  The power to refuse comes only from a supermajority hashpower and/or consensus rules. And this is a point that I think today's hyper-bitcoin anti-spam advocates are missing.

The situation would be different, perhaps, if the anti-spam army were proposing consensus rules-- but so far they haven't, and that is no shock because there isn't any rule consensus or otherwise that blocks traffic that doesn't need consensus enforcement and is willing to change its appearance (well not any short of radical changes that would cause massive functionality loss).   They stick instead to policy rules, which at least allow for a perpetual ineffectual game of cat and mouse.  One I think might provide for full employment for filter authors and filter evaders, but be no good for the rest of us.