Multiple hashing rounds are a common way to slow down hashing searches. The only question to my mind is why bitcoin only used two rounds, since the whole point is to make mining a computationally expensive enterprise. Good point. Why not implement 1024 rounds + 1024 rounds of each of other hashes (like whirlpool, tiger or ripemd) in some next version ? |
|
|
|
2011-09-24 Update:NFTF - version 0.4.0 released. Also: - Removed all the messy git tags merged previously from the mailine client - Created new, clean tag for NFTF-0.4.0 - Minor cosmetic changes in comments So from now on, code will be organized in tags, not versions - as it should be from the beginning. 0.4.0 code is avaiable in the tag: https://github.com/ShadowOfHarbringer/bitcoin-nftf/tree/nftf-v0.4.0/And trunk code is avaiable from the trunk, as always. I usually only update it on major version changes or important features/bugfixes, so don't expect me to keep up with mainstream client developers all the time. Trunk: https://github.com/ShadowOfHarbringer/bitcoin-nftf/tree/Also, i have performed few tests, sending back and forth small amounts of BTC (0.01) having only 2 confirmations, and it seems that my fork is stable enough for the payments to get confirmed easily (up to 2 hours) without using any fees.
|
|
|
|
Well the contrasting option would be if bitcoin had wired-in kill switches and backdoors so that he could control the network. Some alternative chains have this. Obviously (and luckily), this is not the case for bitcoin.
I can probably easily detect something very suspicious in code when I analyse small parts of it, and I am not ever a proper C/C++ programmer. Imagine what an experienced, "everyday-C++" guy can do given a week of time. Perhaps even review entire code for backdoors. |
|
|
|
Is TruCoin involved in mining by any chance ?
http://www.trucoin.com/They have a products list on the site: Exchange, Ewallet, store and more. Yes, with the lead developer working for a private company it won't be long before the people who control the client are also the people that control the exchanges and ewallets. Then when Bank of America buys a controlling share in Trucoin and winds down the business, you're all fucked. Stop panicking and spreading unnecessary paranoia. This is open source world. The "old" ways don't apply. As long as we have the Bitcoin source, nobody(or everybody) controls the currency. No company can take over an open source project. Ever. |
|
|
|
The problem was that 0.3.24 reintroduced a bug where that calculation went wrong, and occasionally up to 0.01 BTC would be sent as fee (instead of 0.0005 BTC). It's fixed in 0.4, by the way.
Can you point me to the particular piece of code ? |
|
|
|
|
Is TruCoin involved in mining by any chance ?
|
|
|
|
Also, to the lesser extent, the clients with a bug "change is to small to return it to the wallet, so send it to the miners." It was re-introduced in 0.3.24, which is the current official one.
Can you please point me to the exact source (line of code) ? I will also remove it from my fork. I didn't know that fee-skimming scams got so serious these days. |
|
|
|
As to who is bat-shit crazy it will be probably for the courts to decide. This pertains especially to those developers who reside in the USA and other coutries with an adversarial legal system. The various fee-skimming scams are just such an juicy target for a class action lawsuit in the Eastern Texas Circuit that somebody there will just grab this opportunity.
It either that or bitcoin will tank so low that not even a bottom-feeding lawyer will be willing to get out of the bed.
What fee-skimming scams? Are we still talking about network transaction fees? No, we are talking about not giving user the choice whether he/she should risk his/her money and send the bitcoins without any fee. Also, check out this topic: https://bitcointalk.org/index.php?topic=22434.0;allBTW, Today i did a small test. I re-sent 0.10 BTC having only 2 confirmations to another address, without paying a fee (using my modified client). The resulting transaction was low priority. Guess what. It was sent without any problems, got 6 confirmations after about 2 hours. So I wouldn't say that forced transaction fees are so needed. |
|
|
|
Actually, no, I don't run a pool. And my mining rigs are almost always on btcguild, which doesn't distribute fees to members, so I have nothing to gain directly by this.
[...]
Oh, and if anyone seriously believes that the devs are obfuscating the mining fees intentionally because they profit from it, you are bat-shit crazy, and I just thought you should know that.
Well, I apologise for being presumptious about your personal involvement in the fee-skimming scam. Its my personal bias I'm getting from the bitcoin promoters that I personally met. As to who is bat-shit crazy it will be probably for the courts to decide. I think that involving lawyers is not so necessary. This is an open-source project, everybody can write their own client. Also, it is a choice of the collective what fees will be enforced. If too many people will be annoyed by fee-skimming, they will move to forked clients, such as mine. The reasons why people are not rioting against it are probably 1) Larger fees do protect the network from penny flooding attacks 2) This is not annoying enough (yet). |
|
|
|
Should there be a method in the API like "checksendtransactionfees <address> <amount>" ?
Wouldn't work. The knapsack problem solver user to select coins is stochastic (uses rand()), therefore the coins selected from the wallet are really random for each call. You can probably propose a change where a rand() is replaced with some pseudo-random algorithm that seeds of some explicit value and therefore is 100% reproducible. That is not a problem really. The method i proposed could work the following way, by "preparing" the transaction: 1. Make the rand() and prepare the transaction + calculate fees 2. The transaction is stored in a "prepared" or "locked" state - all bitcoins from the transaction are locked, until the transaction is unlocked by user. 3. If the user likes the fees, he confirms the transaction, it becomes unlocked, and it is then relayed to the network. This shouldn't be extremely hard to implement. As I said, it already was implemented: https://github.com/TheBlueMatt/bitcoin/commit/5350a907a57b88bd86827c1f3e41b571cf130401. It seems to have been closed awaiting rebase... Nice ! However I will not be using an untested code in prod evironment. I hope it will be added to mainline client in the future. |
|
|
|
This shouldn't be extremely hard to implement.
Famous last words. Garbage collecting stale locks on the wallet is a nice gig, you'll spend endless nights debugging it. Perhaps. Unfortunately I don't do advanced C++ programming, so I cannot do it myself anyway. Also there seems to be a lot of unwillingness among current developers for working on any solution to this problem. That however does not surprise me, as the major devs probably invested heavy money into mining rigs, so why would they damage their business ? An easy & quick solution could be for example, to return error if transaction fees are set to 0.00, and requested transaction requires a fee. But obvious mining cartel is obvious. |
|
|
|
Should there be a method in the API like "checksendtransactionfees <address> <amount>" ?
Wouldn't work. The knapsack problem solver user to select coins is stochastic (uses rand()), therefore the coins selected from the wallet are really random for each call. You can probably propose a change where a rand() is replaced with some pseudo-random algorithm that seeds of some explicit value and therefore is 100% reproducible. That is not a problem really. The method i proposed could work the following way, by "preparing" the transaction: 1. Make the rand() and prepare the transaction + calculate fees 2. The transaction is stored in a "prepared" or "locked" state - all bitcoins from the transaction are locked, until the transaction is unlocked by user. 3. If the user likes the fees, he confirms the transaction, it becomes unlocked, and it is then relayed to the network. This shouldn't be extremely hard to implement. |
|
|
|
The fee is miniscule. Just eat it and call it a cost of doing business.
kjj probably runs a mining pool which collects those fees and doesn't distribute them to the actual miners. So your cost will be his gain. Isn't the bitcoin ecosystem wonderfully egalitarian that way? Actually, i am running my own fork of Bitcoin, which does not enforce fees. https://bitcointalk.org/index.php?topic=22434.0;allhttps://github.com/ShadowOfHarbringer/bitcoin-nftf/I just wanted to know, if there is a way to do it without using modified clients. |
|
|
|
|
Hello,
While developing a bitcoin-related app, i have stumbled upon some seriously annoying shit.
The problem is that apparently, using the default client's bitcoind, there is currently no way to determine what the transaction fee is going to be, before sending money ! (So i could, for example, tell the user how much will he be paying BEFORE he sends the money).
Should there be a method in the API like "checksendtransactionfees <address> <amount>" ?
Can somebody correct me please if am I wrong here?
|
|
|
|
Update:It would appear that the unstripped version is not production safe. It damaged the database and now when i try to run normal (non-compiled) client, it crashes with following error: ************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in AppInit()
terminate called after throwing an instance of 'DbRunRecoveryException'
what(): DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
EDIT:Actually, I can only run compiled versions now, the binary version from bitcoin.org crashes every time i try to launch it using the same database. Any ideas ? Perhaps different version of BerkeleyDB on my debian system or whatever ?
|
|
|
|
I would recommend not stripping it unless you have some specific need to. The larger size is due to debug information that is never loaded or used when the program is running (it doesn't actually bloat memory or slow execution in any way). But without it, you cannot make sense of core dumps.
I have just compiled it and it is also 17 MB... So you are saying this is completely normal, and i have absolutely nothing to worry about, including running that version on production servers ? |
|
|
|
You can't blame the exchange itself for the bad practices and naivete of the corporations that operate within it. Just like the real SE, some companies are solid, some companies are obviously a bad choice to invest in. GLBSE is a valuable and needed service.
Really? It's not the Exchanges role to vet 'companies' that have nothing to offer other than scamming people? Bit Ponzi just slipped under the radar huh? No. A honest ponzi scheme is no longer a deception/fraud and is no longer morally negative, as bitplane said below: BitPonzi isn't dishonest about what it does, I don't see anything wrong with people running gambling / pyramid schemes so long as they're honest about what they're doing.
Exactly. Volenti non fit injuriaIf you do something willingly and consciously ergo there is no harm done. If somebody risks his money and he knows what he is doing, then it is his freedom and his problem if he loses the money. http://en.wikipedia.org/wiki/Volenti_non_fit_injuria |
|
|
|
People suggesting a reddit/metafilter/slashdot style meta-moderating system are making the dangerous assumption that 'legitimate users' outnumber the trolls
Trolls will be quickly destroyed by lowering their reputation. And also only users having 50+ posts [the posts also cannot be rated too negatively] and registered for at least 3 months will get moderation rights. This way it is extremely hard for trolls to overcome legitimate users, even if they outnumber them many times. Additionally, "real" forum moderators may lower the reputation of persons behaving extremely badly even further. |
|
|
|
|
Show Posts
