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.
Topic: There is a problem with core development - page 2. (Read 1411 times)
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.
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.
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.
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.
no amount of consensus rules can make them safe
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.
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.
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...
and somehow someone hacked a retail terminal to charge 300% fee
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.
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.
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.
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.
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.
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.
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. I hope it was a good investment. I wish I could turn back time and do this in a number of other places.
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:
Quote
my guess is whoever it was is using a client that does not auto adjust fees
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.
No offense to the OP but it really is an unnecessary change. The community here could have pointed that out just as easily.
I first tried at github and was specifically told to take it to the dev list.
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
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
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.
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.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.
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. the community cannot spend unbounded time on any particular person's pet issue-
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?
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.
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.
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 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.
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.
Jump to: