Bitcoin Forum

I submitted an issue on github.

It was closed because it was considered to be a consensus issue and not a core code issue, suggested I send the issue to dev mailing list.

I did so, it's a moderated list, and it was posted.

Several responses.

I responded to a single response - just one.

My response was rejected by the moderator.

If there is not a place for open discussion that bitcoin will fail.

Nothing in my response was antagonistic or insulting or otherwise bad behavior, but the moderator made a decision that it should not be part of the conversation - the developers did not even have the opportunity to see my response because it was never posted to the list.

That is simply not acceptable in an open project.

I don't really care if they reject my suggestion, but a non antagonistic response to a discussion on the topic shouldn't be hidden from the developers by a list moderator especially when list moderator already allowed the discussion to take place.

I think it's interesting that you've omitted any links to the discussion.

Let me help out:

You opened an issue asking Bitcoin Core to "hardfork" modify the rules of the Bitcoin Blockchain to prohibit transactions that pay over some arbitrary limit in fees.

https://github.com/bitcoin/bitcoin/issues/7638

Doing so might even effectively confiscate coins created by people who locked them up in precomputed nlocktime transactions. (Though this is unlikely, I hope it makes it more clear what a substantial change that would be!)

Paveljanik, a lower activity contributor, pointed out that Bitcoin Core already has a "-maxtxfee=" configuration option, and if that wasn't enough-- and you were insisting on the consensus rule change it should be taken to the mailing list. You indicated you would.

Wladimir responded pointing out the absurd fee protection in core, that users may have sensible reasons to override it and 'pay' high fees in transactions so precluding it in consensus would be unwise.  He agreed that the issue was the incorrect place to advocate for such a change. The issue was closed.

You posted to the bitcoin-dev list:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012509.html

Five different people responded:

"I think there is no need to do a hardfork for this. Rather it should be implemented as a safety-mechanism in the client.",  (Henning Kopp)

"Bitcoin Core already implements this safety limit with the "absurd fee" limit of 10000 * the minimum relay fee", (Peter Todd)

"And it's the responsibility of the operators to make the wallet user friendly. Apart from that, there are legit use cases where one would want to "pay" a large transaction fee:", (Marco Falke)

"There's  an absurd fee (non-consensus) check already. Maybe that check can be improved, but probably the wallet layer is more appropriate for this.", (Jorge Timón)

"It would be a shame to prohibit someone from rewarding whoever mines their transaction" (Dave Scotese)

You responded to the forth one with (entire message):

"A consensus rule however would protect users from a bug in the wallet  protection. Just like the checksum in a payment address does."
(https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/2016-March/000082.html)

This is almost a word for word repetition from your initial email: "Adding protections may help give confidence and there is precedence to  doing things to prevent typo blunders - a public address has a four byte  checksum to reduce the odds of a typo."; and it's clear that the people you were responding to were aware of that argument. Nothing here is hidden-- the moderation rejects for that list are all public.

I'm sorry you don't feel that your opinions are adequately heard here; but the community cannot spend unbounded time on any particular person's pet issue--  each post to the developer mailing list ends up consuming many man hours to man days of time across all the readers; it's counterproductive to continue a looping discussion.  It wasn't my call to not forward on your message (I'm not a moderator there), and I hope whomever did wrote an explanation to you-- but I think it was probably the correct call.

Ultimately there are thousands of ways poorly written software can cause losses for users-- they can leak private keys, use insecure nonces, munging scriptpubkey data, etc. Additional consensus rules make the system less flexible and more costly to maintain. Cutting down the flexibility of Bitcoin with limits that could only help to protect people against a very narrow class of software bugs, is probably not a great idea right now-- at least not without a unique, compelling, well considered argument and _concrete_ proposal.  There are too many other more important things going on.

But just because one community isn't giving you a free pulpit to argue your point isn't any reason that you couldn't work on it elsewhere; you just don't have the right to demand that other people spend their time on it.  I'm not sure what experience you have with Open Source projects; but no large one survives without methods and process to avoid an unbounded time loss from every wild idea and wish that comes along.

Interesting that you had plenty of time to write that long winded response though. If you didn't have time then why do you have time now?

Because a direct response here doesn't waste any of the other developers time, time wasted for the Bitcoin dev community is at most the ten minutes I'm spending here-- and potentially a large amount of time _saved_; if the sunlight I shone on the issue prevents it from turning into another forest fire FUD fest. Not to mention that anyone spending their time reading the general discussion here is by definition not trying to get something useful accomplished.  The bitcoin-dev list is a working forum, not a place for low impact casual discussion.

I suppose. My concern is that I've heard far too often that the developers are too busy to respond to such small things. I have no doubt that's the case. But how then do you determine what to actually respond to? What is not worth your time and what is? This was something anybody else could have responded to. No offense to the OP but it really is an unnecessary change. The community here could have pointed that out just as easily.

Yep. Thought it often does a fairly inconsistent job.

OP failed to actually mention or link to any of the discussion and only wrote about it in vague terms. If I hadn't actually linked to the requests and quoted from the messages would you be saying "but it really is an unnecessary change" now?  If you only went on what the OP said, I think it would sound pretty bad...

Unfortunately, there has been a rash of misinformation where I looked at it and thought exactly as you suggested-- this isn't important and other people will handle it-- and then people didn't handle it, and not it's being continually repeated as fact from so many directions that it seems hopeless to correct. (or the corrective effort would be so great that it would just send the wrong message implicitly; and so it goes uncorrected.)

In this case, a pretty clear response took about 12 mouse clicks to bring up all the relevant messages and then copy and paste some quotes... which allowed fully contextualizing the issue. This was easy for me since I saw but didn't participate in the original discussion --  in fact, I thought that the other respondents "had it"-- but seemingly not since it had now spread to here in a more accusatory meta-issue form.

In any case, I hope it was a good investment. I wish I could turn back time and do this in a number of other places.

The point I was responding to is the point that it is was client responsibility.

My response, not part of my original post, is that clients do not always do what is necessary to protect users and often have code bugs.

Since a consensus rule can protect the user when a client doesn't, then a user does not need to know how well the client is coded to be protected from that kind of a mistake.

I don't care if the developers reject that point, but it should not have been hidden from them by a list moderator. That's my point in this thread.

If you want this to be an open project, then giving a list moderator the power to veto a message in an approved discussion is counter to that.

And that is exactly the kind of atmosphere that fuels forks like XT and Classic that I believe are bad for bitcoin.

It doesn't matter if the devs think it is too stupid to respond to, it shouldn't be hidden from them or from others reading the thread in an archive.

P.S. - I love Opus :D

I first tried at github and was specifically told to take it to the dev list.

Understood. I read the OP and my first thought was...well what was the issue? I was going to ask but when I scrolled down I was surprised to see a response from you. I guess I was just wondering what compelled you to respond here.

To the OP I would say that I agree with most of what was written on the issue page. You said on Github:


There is already a mechanism to prevent accidental large fee transactions and to auto adjust. Its up to the user to make use of them. Anything additional should be implemented by a third party wallet. I understand you want to prevent accidental large fees but that really isn't something the base layer should be concerned with.

i think what the OP is trying to say

if Mastercard usually had a 2% fee. and somehow someone hacked a retail terminal to charge 300% fee
EG $6.70 transaction with a $15.70 transaction fee.
comparable to
6.7btc tx out with 15.7btc fee
https://blockchain.info/tx/6fe69404e6c12b25b60fcd56cc6dc9fb169b24608943def6dbe1eb0a9388ed08

now knowing the retailer cant amend this issue as they never received the funds and the funds are alreadygone and its visa that received the fee (bitcoin mining pool received)
there shouldnt just be something at the retailer(wallet) side that prevents over spends. there should be something deeper at the pool/network level that realises that something has gone wrong.

though i still oppose the dire need of transaction fee's to suppliment the block reward(for atleast a decade), those that do want to pay a fee should still be protected from making mistakes. EG. if fee is $1+(0.0025+), then nodes shouldnt relay it. same for miners if fee is $1 (>0.0025) then dont add to block.

that way people can still pay 4cents. or if stupid upto $1 in a race for priority.. but anything more is an obvious mistake especially a $6000 fee.

I understand but what happens if the fee is not a mistake? It should not be the responsibility of the base protocol to assess what is and isn't a valid fee. Any sort of protection of the end user should be handled by the wallet, and most importantly by the user. That means check what you're sending. It could be as simple as adding an extra confirmation step for fees over a certain amount, say 10x the current estimated fee. But this would be handled by the wallet application.

Your scenario relies on a hacker getting access to a payment terminal. That's an extreme case and I would hope whoever is responsible for the terminal to accept responsibility and come to some sort of resolution. At this point the core Bitcoin software is not really suited for day to day retail transactions. But many other wallets/services are. Most retailers rely on services like Bitpay, which are similar to Visa or Mastercard in the fiat world in that they act as a third party to process the transaction, taking on some responsibility. When something goes wrong, i.e. hacked terminal, Visa and Mastercard will often foot the bill. I would expect the same from Bitpay or any of its competitors.

Yes and there is _nothing_ that can be done about that generally. Even the example you gave of address checksums are enforced purely in the client, and never show up in the Bitcoin protocol-- and no one is arguing that the txout size should be increased by 20% to accommodate them. You've already had something like seven developers respond (now eight, with me) to you telling you that these kinds of checks can only sanely be implemented in clients (and already are implemented, by me in fact, in Bitcoin Core).

If the client software is broken (or worse, malicious) all bets are off-- no amount of consensus rules can make them safe;  by adding arbitrary restrictions you might cover up one or two corner cases in incompetent clients, but at a cost of handicapping Bitcoin and making node implementations more complex and buggy; leaving us with strange economically significant paramters hard coded into the protocol... and would likely fail to prevent the broken clients from actually losing any money. It's not a meaningful protection; and mishandling fees has never been a bug in any widely distributed wallet software that I'm aware of...


They're not hidden, they're moved elsewhere in public-- according to the rules of the list, almost certainly by someone who isn't a Bitcoin Core developer-- presumably because you were simply repeating yourself in a non-productive way. As a reader of the list I'm thankful for that service.  Just because a message is accepted doesn't mean that it's reasonable for a discussion to go on forever.

If someone is hacking your terminal you likely have much greater things to worry about than them making you pay higher fees-- like them directing all payments to themselves.  Software is not magic.  Sprinkling around an endless series of handcuffs to close off implausible what creates a spiked trap of complexity that would undermine the survivability of the system and provide negligible to no protection.   You're welcome to disregard concerns like that add such things to your own software; you're not welcome to waste unbounded amounts of other peoples time demanding they do it for you in their own.

Blocks that contain transactions with absurdly large TX fees would not be valid, hence why it would have to be done same time as a hard fork and would have to wait until there is a reason to do a hard fork.

If the TX can't be put into a block then the sender is safe even if the client didn't protect them, they can still use the inputs for something else.

The good news is that you can code that into your own version of Bitcoin.  If enough users agree with you, it will happen.

But if not one person on Planet Earth agrees with you, then maybe you should understand why your issue was closed.  People seem to think that your idea is bad and it doesn't make sense.  No big deal, we all have ideas and most of them don't work.  It's okay to let it go.  You'll have more ideas later.

For like the twentieth effing time I don't give a damn that it wasn't acted upon.

At some we are going to need a hard fork for bigger blocks. That's reality. SegWit gives us some breathing room, and one of the valid justification (valid to me) for waiting with the HF is so that when it is done, any other issues that need a HF to address could be done at the same time. I simply was presenting one, if they disagree no skin off my back. That's the way it works.

But why I started this thread is because the moderator of the dev list chose not to even present my response to the discussion to the developers for them to decide if it should be ignored by them.

That's a very broken system.

What we have right now is a system where miners can anonimize their own coins by putting a TX only in the blocks they try to solve with a small payment to a burn address and a huge TX fee.

So miners can anonomize their coins but the users can not. Not exactly balanced. Since most double spend attacks involve the ability to mine blocks, I'm not sure I want them to have the ability to then anonomize their coins after doing so.

And we have a system where a bug or mistake can result in a large loss of funds that can't be reversed. That can be protected against at the protocol level even if the clients do not protect against it.

If the devs don't want to, fine by me. But the discussion should have been open and rejected with all the points made. That can't happen the way the list is currently run.

And if the devs don't want that on the list, then it should be discussed at github where I originally wanted to discuss it but was told to take it to the dev list. To me that makes sense, discuss it at github and if a developer thinks there is merit then the developer can take it to the dev list. But that wasn't allowed either.

How many altcoins have implemented your suggestion?

Don't know and don't really care. Don't give a rats ass about altcoins, most of them scams and other than namecoin I have yet to see one that truly offers anything interesting of value.

Again this thread isn't about my suggestion anyway. It's about a single person, the list moderator, getting to decide what the devs see in a discussion taking place on the dev list.

-=-

If all my ideas were good I'd be a billionaire. I'm not, so clearly not all my ideas are good. I don't care that much that this suggestion won't be acted upon. The point is that the developers didn't get to even see the arguments being made in support of it - namely that the client isn't the best place for this protection.

Think about it, we patch SSL/TLS servers all the time to protect users for issues that could be *and should be* fixed in the client, do we not?

Clearly the devs understand this is an issue because they already have protection in place in the core client.

I believe that it needs to be a protocol level protection.

I would have been happy to discuss that on github but was told to take it to dev list, where I had never posted before (I was already subscribed) yet on the dev list, a moderator prevents open discussion from taking place.

That's the problem I see - not whether or not my idea is implemented.

If you disagree with the way the board or mailing list is moderated, move the topic to a different board.

If you bring up a notorious topics like hard fork over and over and over and over and over again, don't be surprised to get ban hammered.

Nothing prevents you to discuss or even develop such an idea for Bitcoin or an altcoin.

You are free to run Bitcoin Core with your custom fee filtering nonsense rules, but we all know the thing you actually care about is how to impose your own rules on the others. Fuck off back to reddit.

Everyone who runs bitcoin Core runs it with the fee filtering rules, they aren't nonesense.

Yes, if you run Core, you are running with those rules. I want it in the protocol, not the client, but again that isn't the point of this thread and I don't understand why I keep needing to repeat that.

I give up, I just effing give up.

Core has a problem with open discussion, and there are none so blind as those that refuse to see.

-=-

And how dare you tell me to "Fuck off back to reddit" - I loathe reddit and never visit that place.

And no, I don't want a hard fork until we need it - hence why I reject Classic.

Hard forks should be extremely rare, which is why when they happen we should get the most out of them, which is why open discussion on what goes into the next one should take place. And yes, there will be a next one.

I'm sorry but I spotted a nick like your on there.

anyway yes, we run Core and I'm not aware of anything that would prevent me to proccess a transaction with 15 BTC fee.


Who are you to give a fuck about someone else's money? Someone shot himself to the foot while laundering money on Bitcoin? Big deal.

Why do you care about Bitcoin's brand, image or PR?

You can process a TX with a 15 BTC fee.

You can't make one, the client protects you.

But you can't run core on Android. You can run core on a laptop if you have the disk space but the constant HD and network activity will use your battery and it uses a lot of memory.

There are legitimate reasons not to run core but to use alternate clients, and not all of them protect the user from an obvious preventable irreversible mistake. The protocol itself can prevent the mistake by making blocks that contain such transactions invalid. That's all I'm suggesting.

You are welcome to ignore block 400893, and the 841 successive blocks in your Core.



Why?

EDIT: How do you know it was really mistake. It was me and I did it on purpose. How do you know it wasn't me?
EDIT: Who is, according to you, supposed to decide what other mistake prevention mechanisms will be incorporated into Bitcoin in the future?

TLS clients should reject SHA1 in CertificateVerify

TLS 1.3 blocks it as part of the specification because not all clients will.

That's all I'm asking.

-=-

As far as ignoring existing blocks that already have obscenely large TX fees in a transaction, that isn't possible. If it happens at the protocol level it happens when there is a hard fork or it doesn't happen at all.

I shouldn't need to explain that to you.

And again - if the devs think it is a bad idea, that's their call and I will accept their call.

What I don't accept is the lack of open discussion - regardless of what the actual idea is.

And to be clear, I would have been more than happy to have that open discussion on github and never post to the dev list myself.

That's what I started to do, and only went to the dev list because I was told to take it there.

I represent a miner, in a way, so absolutely, you are welcome to explain everything.


Again, it is you who believes the devs are in charge of judging ideas. This is not the case here, anyway.
So tell me about the open discussion. How would it look like? So far we know that there would be zero moderation.

What else? Is there supposed to be some kind of tech support guy? Or do you prefer to talk to someone 'in charge'?

I don't know it was really mistake but there have been other cases where it was really mistake.

If it wasn't a mistake then the only logical explanation is money laundering in cooperation with the miner that mined the block.

As far as who is suppose to decide what mistake prevention mechanisms make it into Bitcoin, OPEN DISCUSSION is what ultimately decides those things.

That's all I wanted was open discussion. If the devs felt there was not reason to implement the suggestion, then they don't have to. But open discussion itself was not allowed to take place.

The devs implement ideas. The number of people with write access to the core code repository is limited and should be limited.

To make changes they don't make requires a code fork, and when that code fork involves a change that requires a block chain hard fork, it is extremely dangerous.

I would rather keep using core than use a fork that does something I like that core doesn't.

Great. We've had an open discussion on github, mailing list and here. So according to you, the decision has been made.

What's the next thing on the agenda?

Github did not have an open discussion. It was closed with instructions to move it to the dev list.

Dev list did not have an open discussion. At least one message (possibly more, I have no way of knowing) on the topic was kept from the discussion by the list moderator.

-=-

What I want to discuss here isn't the suggested change, hence why I didn't mention it in the opening post.

What I want to discuss here is the fact that open discussion on ideas isn't always allowed to take place.

And for that, yes, we are having an open discussion here - though it keeps going off topic to the idea of TX fee rate protection, which really isn't relevant to the fact that open discussion on ideas to protect users is broken in bitcoin development and needs to be fixed.

My suggestion is to make github more friendly to discussions on this type of issues, and if the devs who read github see something that merits further dev discussion, the dev can take it to the dev list.

That would solve the problem.

It seems to me that you demand either endless fruitless discussion, or some sort of unmoderated board.

Both of this is readily available, so there's no problem.

That's the way it seems to you but that's not what I wanted.

I simply wanted to make a point that in my opinion the client layer isn't the best place for the protection, and I was denied the ability to make that point by the list moderator.

Just to be clear, I have a high amount of respect for the bitcoin developers but no system should be above criticism. Criticism drives improvement.

Going radically off-topic here,

LibreSSL was not forked from OpenSSL because of heartbleed. That was the final straw but that is not why the fork happened.

The fork happened because of a problem with OpenSSL development in general. Concerns were ignored and not addressed, and it was a continual problem. Development wasn't really open.

So LibreSSL forked, cleaned up what needed to be cleaned up, and the developers are extremely responsive. I do post to that devel list, and some of my ideas are stupid and ignored, but not one has been moderated.

Many of the modifications they made improved security. There is no SSLv2 or SSLv3 support for example. OpenSSL retained them. So when a server is misconfigured to not exclude SSLv2 it is already safe from DROWN but the same configuration with the server linked against OpenSSL and it is vulnerable. They have a philosophy of protecting the users.

There were people like me calling for the removal of export ciphers from OpenSSL for years and it fell on deaf ears, that was a server configuration issue and to them it wasn't the job of the library to protect the server. That's a dangerous philosophy.

Nor have issues discussed on github been closed with instructions to "take it to dev list".

-=-

The point I am making - in the TLS world, forks are not devastating but forks in the crypto-currency world that implement consensus differently are dangerous. As such the core development process should try its best to avoid a situation like what happened with OpenSSL where frustrated users fork.

Who gives a fuck about other people and their problems?

LOL

You did. Several times, on several places, you even did so here several times even though according to yourself its not even the topic. Somehow you keep coming back to it with every 2nd[1] post.

You also had several developers disagree with your view on this, so i really dont see why there is any further need for a discussion. There can be different views on things, different stances and different philosophies. As gmaxwell explained to you the mailing list moderator probably thought the discussion was wasting time on the mailing list. Maybe here[2] is a better place to discuss your idea.

[1] its a guess
[2] https://bitcointalk.org/index.php?board=6.0

And that is the problem right there.

Of course as I have pointed out, I didn't even want to post to the dev list without proper discussion on github first.

I agree that the dev list isn't the proper place, github would have been much better.