Seems to indicate that he is very interested in fixing the underlying problem instead of hacking up the code to make a branch that doesnt even work
How do you know it doesn't work ? Did you even try to compile it ? Oh, I have no doubt it compiles and runs, but remember transactions it creates oftenalmost always will not be relayed or confirmed. Sorry, but you have no idea what you are talking about. I find this discussion completely useless & unnecessary. EOT. |
|
|
|
Seems to indicate that he is very interested in fixing the underlying problem instead of hacking up the code to make a branch that doesnt even work
How do you know it doesn't work ? Did you even try to compile it ? Did you even read Gavin's response? A long-term fix for transaction fees (as opposed to the ad-hoc "we'll just try to guess what the 'right' fees are") is high on my priority list for bitcoin. There are only two very-high-priority things on my bitcoin wish list: fix scaling issues and make sure we have any infrastructure in place to support ultra-high-security wallets. Fixing transaction fees is a scaling issue.
. Remember that Gavin is not in charge of any of the miners, and all of the largest miners run modified bitcoin daemons with custom transaction handling anyway. There is no cartel here, just miners who will accept any transactions with fees and dont care to support transactions that create a larger load on the network as a whole without fees. This is Open-source, no one gets paid to do this, not gavin, not sipa, noone. If you want a solution to the problem, you need to make one (and again, this is no where near a solution as the transactions it generates dont get relayed or included in blocks, so you might as well just not create the transactions) or wait until someone has time to come up with, and code a solution in their unpaid free time. Sorry, still not convinced. ---- BTW.
Project update.
- I have merged back all of the current mainline client changes back into the fork.
- Between others, Polish translation was added by somebody into the mainline client
- Small code beauty & compatibility changes in the fork.
|
|
|
|
Mt.Gox Account recovery service
Step 1/2: Identify your account
An email has been sent to your address with further instructions.
This is all i get after trying to recover one of my accounts with 125 Bitcoins on it. I was trying this form for about 50 times already, and i STILL get no email at all (i have a GMAIL address). So my question is: WTF is going on here ? Anybody got similiar experiences ? |
|
|
|
Until then, making it very difficult to send low-fee transactions is necessary.
Very difficult, but not impossible. BTW, Because of Gavin's aggressive responses to my pointing out of an obvious bug I am now more convinced than ever that this is a typical Mining Cartel Scam™. Not nice. |
|
|
|
Already done.
Uh, where? As Gavin pointed out, allowing users to send no-fee transactions which wont even be relayed is not a solution, instead the fee algorithms (which currently arent very good) need to be redone into something more workable. I am talking about thinking this whole case over, which is already done. And my conclusion is that experts settings should be added for people who want to risk their money. |
|
|
|
Yes, but users are, in general, stupid and will do it anyway,
Easy. Add expert settings in config file. So called "stupid" users usually don't know what config file is and how to use it. Problem solved. If you want to help, think through,
Already done. suggest,
Done. take comments on,
Done. and implement a new fee system
Can't do. I can diff, merge, patch, fork, compile, package, change minor things, but I cannot develop things with medium to big complexity on my own as it would be irresponsible & dangerous with my minimal C++ skill. So I think I did all I could here. |
|
|
|
|
So I guess no mainline client developer is going to talk to me seriously about this.
Somehow, I am not surprised.
|
|
|
|
First, thank you for responding at last. I didn't realize that i will have to make a fork to get your attention. "Pick a fee and hope my transaction makes it into a block" is NOT the right answer. And we've already seen what happens when there is a mismatch between miner transaction fee policies and client transaction fees (remember the big backlog of low-priority transactions we had a couple of months ago?).
Of course i realize this is not the proper solution to the problem, this is only a temporary fix. As i said earlier in this topic, there should be additional dialog saying like "Are you sure you want to do this ? Your coins may get lost forever", which perhaps only shows up when "expert mode" is selected either in bitcoin config or in preferences somewhere in the GUI. The whole point is, forcing a fee on everybody is so very very, VERY not libertarian. I am a free man, and if i want to risk losing my money, then so be it. That is my choice. I hate when somebody imposes something on me. I want to be given a choice. Always. Isn't this the whole point of open source ? |
|
|
|
I would have your client be better and more simple if you are really gonna mess around with txfee. You can get rid of the confusing "this is over the minimum size" message. However, no TX fee = block bloat DOS tool. A naughty boy could scrape the forum and the net for bitcoin addresses and send them all .00000001 thousands of times for $10.
You are talking about a "naughty boy" who cannot change the code himself. It will still be easy for all technical types/hackers/people with a lot of money to change the mainline client and send as many spam/dust transactions as they want. No, a "naughty boy" who can't change the software other people are using. The DDOS protection comes not from the fact that your client won't do it, but from the refusal of most potential neighbors to relay it and miners to miner it. Your client's refusal is your protection from the protection. Didn't I say like 5 times in this topic that i didn't touch any relaying code, did I ? This is what I am talking about the entire thread (about the devs not letting me create transaction without a fee), were you actually listening ? |
|
|
|
I would have your client be better and more simple if you are really gonna mess around with txfee. You can get rid of the confusing "this is over the minimum size" message. However, no TX fee = block bloat DOS tool. A naughty boy could scrape the forum and the net for bitcoin addresses and send them all .00000001 thousands of times for $10.
You are talking about a "naughty boy" who cannot change the code himself. It will still be easy for all technical types/hackers/people with a lot of money to change the mainline client and send as many spam/dust transactions as they want. ----------- I added a proper warning in the starting post of this topic. As of now, this fork is not suited for Bitcoin newbies. |
|
|
|
Actually, in the latest update i fixed the AllowFree() to be normal and only modified bool CreateTransaction(), so that dust spam relaying code becomes unchanged. Unless I am wrong, the only thing that is changed now is creating new transactions. In CreateTransaction():
Before:
bool fAllowFree = CTransaction::AllowFree(dPriority);
int64 nMinFee = wtxNew.GetMinFee(1, fAllowFree);
After:
//Bitcoin NFTF Patch - changed by ShadowOfHarbringer START
int64 nMinFee = wtxNew.GetMinFee(1, true);
//Bitcoin NFTF Patch - changed by ShadowOfHarbringer END
So you're willing to put pre-built binaries out there that let people send transactions that wont pass the spam checks. And said binaries also will not forward transactions that don't pass the spam rules if they see them? You don't see the problem here? Unless i overlooked something in the code, CreateTransaction() is not used for relaying transactions, but for creating them (=sending money) is it ? So what is the problem exactly ? Well, whatever are the details of all this, none of the devs seems to care even to talk to me about this.
So i find this extremely suspicious.
I wonder if some (or all) of them didn't invest heavy money in mining. After all, who would want to intentionally decrease their profits ?
lol, look at all the recent blocks. the transaction fees were super low. take off your tinfoil hat, and admit to yourself that your concern is useless. "derp a dev won't respond to me. MUST BE SOME CONSPIRACY GOING ON INVOLVING THE DEVS, THE ILLUMINATI, AND THE 9001 YEAR OLD MINING CREED" last 3 blocks: Generation: 50 + 0.80834234 total feesGeneration: 50 + 0.30386 total feesGeneration: 50 + 0.1656 total feesNot all of them are "super low". There is a topic on this forums with a guy which claims that he was forced to pay something around 20% fees for sending 50 BTC of money (I may remember the exact numbers wrong, but you get the idea). But that is of course talking about the old version having 0.01 fee, not 0.0005. |
|
|
|
Until one or both of those are done it is EXTREMELY DANGEROUS to remove the fee requirements. I hope you're prepared to recover all the stuck coins your patch will create.
To this day i was using 0.3.20 all the time and guess what: no coins were lost. The patch i created reverts the fee forcing behavior to 0.3.20 and that is all it does. Also, on http://bitcoincharts.com/bitcoin/ there is only one transaction that is due 20 days, but it contains coins from unconfirmed transactions. Really bad. So i guess this isn't so extremely dangerous after all, you just need to be a little more careful and only send stuff after you get 7 confirmations or more. |
|
|
|
I've been finding it odd that your concerns were being ignored. Not being able to send 10btc received an hour ago without paying a transaction fee seems a bit harsh. Perhaps the client coin selection algorithm is trying to send other coins instead of the 10btc one. Maybe "one-hour old" is considered immature by the coders (although for an amount like 10btc, I find that a little surprising.) But it seems like the requirements to prevent dust spam need to be relaxed a bit, at the very least... at the worst, there may be some subtle error in the calculation for spam.
Well, whatever are the details of all this, none of the devs seems to care even to talk to me about this. So i find this extremely suspicious. I wonder if some (or all) of them didn't invest heavy money in mining. After all, who would want to intentionally decrease their profits ? But as is often said on these forums... it's open source, you can make any changes you feel you need. And so you have. Personally, I'm curious as to how problematic your changes actually are/aren't.
There are only two lines of code changed, and the change is very minor... So i **seriously** doubt anything could go wrong currently. I'd appreciate hearing if you wind up with unconfirmed transactions, how long they stay that way, etc., if you wouldn't mind keeping us up to date on the performance.
No problem. I will keep everybody posted if i encounter any problems. |
|
|
|
|
+1, Excellent idea.
The same could be done to all kind of cryptographic information in Bitcoin - transactions, public keys, private keys and so.
This would make it possible to store your Bitcoin wallet entirely in Your brain !
|
|
|
|
More: ---------- This is silly. The way the dust spam logic treats insufficient fees as non-existent. Simply reducing them by 10x isn't really any better than not paying them at all, unless you're fortunate enough to manage to connect to eligius (which has a mandatory fee on every transaction but only a very small one). In that case you might as well just apply the eligius fee rules directly.
You are correct, i will remove the LowTxFee branch. You've also failed to completely remove the need for fees, but I'm not going to show you what you missed, lest you footgun yourself and others even worse.
It wasn't my intention to COMPLETELY remove the need of fees. My intention was to restore default 0.3.20 behavior, which didn't force the fee on me when i tried to send transaction that the client doesn't like. ---------- Also: I realize my current fork isn't perfect, it only reverts creating transaction to default 0.3.20 behavior. This of course isn't the best way to do this. To do this properly, there should be additional dialog saying " Are you sure you want to send the bitcoins without a fee ? Without the transaction fee, it may never get confirmed", and only when the user selects "YES", the transaction should be sent. The way it is now in the mainline client, everybody is FORCED to pay a fee, and THAT IS JUST PLAIN WRONG. But as you can see, nobody cares to fix it, so here I am. |
|
|
|
If you don't understand it then it is exceptionally irresponsible of you to modify it and encourage other people to run your modified version. Screw yourself, if you like, but not other people. I hope other folks here are smart enough to not run code from someone
Sure i agree it may be little risky, but what you are doing is complaining isntead of trying to help me here. Not very constructive. I bugged main developers many times that 0.3.21 is broken, and they didn't even comment on it - it's like they intentionally ignore the obviousness of the algorithm being flawed. So there is something seriously wrong here. Perhaps, instead of complaining, do something constructive and simply improve the code. who admits that they don't know what they are doing.
I never said i completely don't know what I am doing. I programmed in many languages in my life and I should be able to make minor changes without doing harm. I understand the code to some point. If i tried to do something more complex then it would be irresponsible - I agree. But that is not the case here. The relay and mining rules of other nodes is the only thing that protect them and the network from penny flooding attack. You can't change those except by convincing them to run software that you've made vulnerable.
Actually, in the latest update i fixed the AllowFree() to be normal and only modified bool CreateTransaction(), so that dust spam relaying code becomes unchanged. Unless I am wrong, the only thing that is changed now is creating new transactions. In CreateTransaction():
Before:
bool fAllowFree = CTransaction::AllowFree(dPriority);
int64 nMinFee = wtxNew.GetMinFee(1, fAllowFree);
After:
//Bitcoin NFTF Patch - changed by ShadowOfHarbringer START
int64 nMinFee = wtxNew.GetMinFee(1, true);
//Bitcoin NFTF Patch - changed by ShadowOfHarbringer END
|
|
|
|
It is always up to the miner to decide whether they want to include your transaction or not.
Yup. You have a point. But still, most miners accept my transactions even though the mainline client says he doesn't like it. I get many confirmations pretty quickly. So perhaps the intent could be sincere (but i highly doubt it), but still, the algorithm is broken. It should be more dynamic, not fixed like this. Bitcoin is very volatile so making algorithms which are based totally on fixed constants is not a good idea. |
|
|
|
@OT, Didn't someone point that simply returning true has broader impact that just removing the fee?
OK, never mind. I fixed this myself in all branches. AllowFree() returns correct values now. ---- Ah, one more thing. IIRC, fee is the only known mechanism to protect against the "penny flooding" attack.
Incorrect. I just looked at the code and it seems that it only protects against people who don't know programming well enough to change it themselves. And hackers & bad guys usually do, or simply pay somebody who knows. Basically by changing one line of code in the client, you can do whatever you want (and send whatever transactions you want). So i don't really understand what was the point of forcing everybody to pay the miners additional fees if it wasn't necessary. Mining cartel of whatever ? |
|
|
|
Welcome for the change. But I think it would be more useful if you can show calculated fee in the send coin dialogue. When the user input the amount, then it should automatically calculate the minimum fee (COIN * 144 / 250) or when the user click the button. The user can freely adjust the fee as they want in the fee input field.
After they click send, it will give them a warning of the consequence of low fee and then asking whether they want to process payment with low fee. It should send out the transaction no mater what fee they enter. It should give a much higher usability improvement.
Yeah, i had the same idea that a while ago, but i was either unnoticed or ignored by main devs. Also, i cannot create a new dialog box myself, because I am not really a C/C++ programmer (and i don't have a proper C/C++ IDE installed at the moment) so i can only do minor changes & code merges at most. I programmed several languages in my life and I was thinking many times about learning C, but it always was too time consuming and i never had the time. But if you know how to implement this, you are welcome to do so yourself. |
|
|
|
Many one should be happy for such change so that you may then ask a pull request then.
IIRC, fee is the only known mechanism to protect against the "penny flooding" attack. @OT, Didn't someone point that simply returning true has broader impact that just removing the fee? This was default behavior in 0.3.20 and it worked fine for me. EDIT: Err i checked in the code and actually it wasn't but if you know how to do it better, you are welcome to try.0.3.21 and later versions has brought me only problems. I can't even send 10 BTC i received hour earlier, because dialog says it needs a fee. So i downgrade to 0.3.20 and poof ! Problem fixed. I can resend the money, and later i get 2-3 confirmations after about an hour. So this is why i said that the algorithm is broken. |
|
|
|
|
Show Posts
