|
Could everybody please stop derailing this topic ?
I kind of wanted to use it to inform people about releases of NFTF.
|
|
|
|
The quickest and easiest solution is probably to change the coin selection algorithm to always select the oldest coin(s) possible for the inputs, thereby not triggering a fee in bitcoind. In most/many cases that will avoid the fee.
"Most cases" is still not satisfactory for me, hence the fork. I like my freedom served fresh & juicy on a plate. When the mainline client gets a proper "are you sure" dialog and/or a configuration setting "Always.AllowNoFees.IKnowWhatIamDoing = 0/1" implemented, this fork will become obsolete. Since then, i will continue maintaining it. |
|
|
|
|
The rule No. #1 is: Trust no one.
So why would i trust some pre-defined "authority" ? This is like taking a time machine and going back to pre-bitcoin era.
We are the Bitcoiners, we trust the code. Middleman are now obsolete.
|
|
|
|
You could work around it though. When you have a forced zero-fee tx, instead of just passing the tx to the local bitcoind, send a getaddr message to the local bitcoind, parse the addresses received, then connect to all of those nodes and broadcast the tx to them.
If I understand correctly, you need the local bitcoind for the blockchain, but there's no reason you have to use it exclusively for broadcasting transactions.
This might work, but using NFTF fork would probably be much easier & quickier solution. |
|
|
|
It seems, the only way for Armory to do this, is if this fork is used along with the over-ride min fee option (though, I haven't tried it). In the future, I will have some kind of independent networking that will allow me to sidestep this problem. Until then, I can't live up to my promise of supporting forced zero-tx fees!  I actually made this fork to save "the old way" of doing transactions, so that it will not be forgotten. You can use my code to implement the override properly, as the only thing it does (2 lines of code changed) is it reverts the client behavior to pre-0.3.23 one. It should be extremely easy to add an extra configuration switch/parameter/whatever, so you can choose between default Satoshi-client-behavior mode, or NFTF-client-behavior mode when creating a transaction. I am happy to see that my fork can be actually useful for something important. |
|
|
|
|
I'm quite devastated by this topic.
It seems that namecoin is doomed from the start. Why didn't the NMC developers account for that ?
|
|
|
|
These patches also don't do what they claim to do— they'll still apply fees in some cases. (Though at least thats a good thing)
Of course, it wasn't my intention for the patch to remove ALL fees. It only removes the necessity of paying the fee which started around 0.3.23. It reverts the client behavior to the one from 0.3.20. I'm not quite happy with that, why not eliminate forced transaction fees altogether? Because some fees are mandatory, and the network rejects transactions without those fees as being spam. I suspect the transaction you mentioned above won't ever be confirmed. Yes, exactly. The only mandatory fees that are not-really-so-mandatory are the ones which were introduced around 0.3.23. The first conception of my fork was to remove necessity of any fee. But removing other requirements can be IS dangerous (network would not relay such transacactions or other weird errors could happen) so i dumped that idea. A suggestion - If you want to be really useful, try coding a proper dialog like "Are you sure you really want not to include a fee ? Transaction may never be confirmed !" or/and a configuration setting in the bitcoin.conf file, so that power users/people who know what they are doing can send whatever transaction they want to. Right now, this fork is not a "proper" solution. With a patch like that, it could become good enough to be pulled into the main bitcoin tree perhaps. |
|
|
|
Surely, this is not all a coincidence.
We must remember that CIA is oficially & unoficially "interested" in Bitcoin. That may mean many things. They may be trying to either manipulate the currency to their advantage or destroy it, or perhaps both.
These guys aren't stupid.
Also you spelled your name wrong, it's Harbinger: http://www.merriam-webster.com/dictionary/harbinger OMG, WHY in the world did you have to tell me this ? Now i will have to execute a (surely) long, difficult (if even possible) process of changing my nickname on all of the Bitcoin forums ! Ohhh the pain... It's unbearable. |
|
|
|
|
Surely, this is not all a coincidence.
We must remember that CIA is oficially & unoficially "interested" in Bitcoin. That may mean many things. They may be trying to either manipulate the currency to their advantage or destroy it, or perhaps both.
These guys aren't stupid.
|
|
|
|
Ah.
What you're having happen there is that when you send your transaction is dropped by the network— lacking the required fees because it looks like a DOS attack (fast turnaround)—, but after every block that doesn't contain your transaction the client tries retransmitting it (with a random delay). After two hours or so, the input coins have matured enough that they no longer require a fee. After that when your client resends then it goes through.
If you'd just waited the same time it would have sent without a fee in mainline. From a usability perspective, when the times are reasonably short, it might be better to wait like that... but if you shut down right after sending the transaction will be stuck until you start back up and wait an hour or so, and a lot of people do that.
You are absolutely right, however still missing the point. It is my risk to take and whether i still want to gamble and send the coins should be my decision. This is why i bugged mainline devs multiple times for a simple configuration setting or a simple "are you sure" dialog, or both. They are acting like the issue doesn't exist at all. Why is a simple configuration setting such a problem ? Open source is all about choice. |
|
|
|
|
@gmaxwell
OK, seems you were right. Thanks for pointing that out, i could not notice it myself.
Some "weird magic" happened during my git patchwork, and some conflicts didn't merge properly.
The errors were so serious though that the program would probably not compile (at least i hope so). Lucky the changes were only visible for a couple of hours.
Updated & fixed tags are now avaiable, the old ones were removed. Everything is now merged properly, including the trunk.
Also, from now on i will always diff all tags & trunk with mainline client in case of some more merge errors.
|
|
|
|
Yes, and they are also seldom added in those cases. Moreover, The amount of the transaction itself isn't whats relevant for the fee calculations (unless it goes under 0.01 BTC).
I'm just stating a simple fact: The bitcoin software uses the _same_ code to determine if fees are required for relay as it does when adding fees to a transaction. If it decides to add one, it's only if other nodes wouldn't have relayed (much less mined) the transaction without them.
Yes, I'm sure you tested and found it worked fine. I expect that in those cases the unmodified reference software also would not have applied a fee.
Actually, I did a 2-level testing. First, i tested the "normal" client to check if it adds fees. Then i did an identical transaction with identical sum of money. And guess what. The mainline client ALWAYS (state as of december 2011) wants a fee when you resend money that are younger than 30 minutes. My client does not. And the transaction produced by my client got confirmed easily (up to 2 hours). I want to have freedom to choose whether i want to pay fees that may or may not be necessary.
[...]
Also, as i already stated somewhere in this topic, **this is not a "proper" fork, just a simple 2 line - patch ** for people who value freedom of choice the same as I do.
And freedom you have, there is nothing I could do to take that away from you even if I wanted to, though I don't. Your promotion on your signature, "Getting robbed by miners", however isn't just about providing a choice. As far as I can tell it's about spreading misinformation, fear, uncertainty, and doubt. Well, actually i think you may be at least partially right here. I will remove the "getting robbed by miners" ad, and replace it with something "lighter". It reduces choice by clouding people's judgement with the fear that they'll lose money and may cause them to run your fork when under a rational analysis they would not.
Your change is also not a 2 line patch. Diffing your RC tag and the reference client RC tag gives me a 289 line diff.
You appear to be missing at least one random patch from mainline in December. I'm sure this was a simple mistake, but what happens when such a mistake introduces a data corruption bug?
This is interesting. Gitk shows that my branch is fully merged with master, except for my little patch. I will diff it myself now and show you the results in a few minutes. In any case, I didn't post for your benefit, we've gone over this before. I was just making a regular cautionary post so that people who are just seeing this thread for the first time won't jump to the end and miss the earlier discussion.
There is a "cautionary" big, red warning in the first post, shouldn't that be enough ? |
|
|
|
This is a terrible patch that puts you at risk and no one should run it. The overwhelming majority of transactions with the stock reference client do not pay fees, the average _total_ fees per block are about 0.02 BTC— pointing out the lie that miners give a crap about collecting fees from you— the reference client only adds fees to transactions when it would not mine or relay them had they come from someone else, when they are objectively indistinguishable from a DOS attack.
Completely untrue, at least it was few months ago (i am not sure if current state is similiar, because i didn't have time to test it lately). The official client adds fees, even when they are completely unnecessary - meaning they get relayed and confirmed without any fee. Do some testing before you make claims such as this. I did such tests on my fork with only 2 confirmations (and small sums - like 0.02, 0.10) , and guess what. Fees were NOT necessary. Ever. Also, there is a proper warning at the start of this topic. When it does add fees they are usually only 0.0005 BTC.
You miss the point. I want to have freedom to choose whether i want to pay fees that may or may not be necessary. This is MY FREEDOM, not developer freedom to decide what to do. This is the exact reason i created this simple patch. Also, as i already stated somewhere in this topic, ** this is not a "proper" fork, just a simple 2 line - patch ** for people who value freedom of choice the same as I do. The **proper** fork/patch should implement a dialog saying "Are you absolutely sure that you do not want to include fee ? Your money may be lost in the process". These patches also don't do what they claim to do— they'll still apply fees in some cases. (Though at least thats a good thing)
Of course, it wasn't my intention for the patch to remove ALL fees. It only removes the necessity of paying the fee which started around 0.3.23. It reverts the client behavior to the one from 0.3.20. It's also the case that no one actively involved and informed in Bitcoin's development is reviewing these patches. If ShadowOfHarbringer was actually competent do this this work he would not be making misleading claims and would instead be working on code to help users safely recover from stuck transactions.
Unfortunately, I do not posess enough C/C++ skill (as i already mentioned above), but i do posess the skills to read&understand C/C++ code (to a certain degree) and do pretty advanced git patchwork. This is all I am doing here, nothing more is really required to maintain a 2-line patch for God's sake. I would not run code released by him.
This is your choice. Because you see: It is all about choice. My choice was to create this fork for myself and other people who value individual freedom and are willing to take some risks to achieve that freedom. |
|
|
|
You must KNOW that something is good and well tested before implementing it.
How do you test something before implementing it? On testnet perhaps ? Gavin said he's already done some testing on testnet, but the question is if that was enough. Perhaps people with considerate mining power should do some more heavy testing. |
|
|
|
My other major concern is that BIP 16 has not been adequately tested. What is the game plan to put BIP 16 technology into action before the migration? It would be nice to experience its use for a period of time and know that many more programmers and developers had examined/improved the code.
It would be a huge black eye for a few core developers to rush a migration on something they "feel" is ready for prime time only to be followed with "let's revert back" and/or "here's an emergency fix" followed by "here's yet another emergency fix". Solidcoin anyone?
I'm more than willing to donate hashing power on a temporary bitcoin fork for testing purposes.
+1 agree, as a side note the solidcoin resemblance of doing things is quite striking +1 to that. Let's go slow, and do a lot of testing before implementing something that breaks backward compatibility. It is people's money that is at stake here, so there is no place for "we feel" this is good.You must KNOW that something is good and well tested before implementing it. |
|
|
|
I suggest that we compile a list of everyone who knows a lot about the Bitcoin protocol, invite them to a two-week discussion via email
That is OK, as long as the discussion will be completely public. Openess is the fundament of any Open Source project. Perhaps we should create a mainling list read-write for developers and read-only for all others ? Or it could be done on the forums, so it is even more public. |
|
|
|
I was listening to Bruce Wagner interview Gavin after the CIA conference and just wondered why not much had been made about Satoshi and the real reason he gave up all Bitcoin contact? According to Gavin himself the CIA visit itself could have been the reason he quit? Bruce Wagner : When was the last time you chatted to satoshi? Gavin Andresen: Um... I haven't had email from satoshi in a couple months actually. The last email I sent him I actually told him I was going to talk at the CIA. So it's possible , that.... that may have um had something to with his deciding http://solidcointalk.org/topic/529-did-gavin-andresen-push-satoshi-out-of-bitcoin/Mmm, somebody with great necromancy powers I sense, yes. Topic so long dead reviving... |
|
|
|
Yes, but if what you say actually happened, all the people mining on those pools would drop out and switch to another pool (or mine solo). Still, it would be quite disruptive
Which is what i said. A number of months ago someone came up with an idea that would allow individual miners in a pool to craft their own blocks (including any transactions they see fit, but the coinbase would deliver coins to the pool, not the individual miner).
Yeah i have seen it, but i don't remember the Topic ID. Could somebody supply a link ? |
|
|
|
So all you need to do is get the top 2 or 3 pool operators to switch to the new code and you've secured the 55%. Are any of the pools on board so far?
Whoah, this went definately too easy. I mean, how decentralized are we, really ? What if US took over 5 biggest pools and having ~65% the next day we would have massive scale attacks on the network ? That would be a disaster. Perhaps a temporary one, but still a disaster. How long do you think it will take before they try something like this ? Shouldn't we all push for decentralized pools, like P2Pool ? |
|
|
|
|
Show Posts
