So fees are good! As long as they have to pay a minimum fee of 0.0005 BTC / transaction, even if I set up a very poorly rate-limited exchange...| They send | They pay in fees | You send them | You lose reserves with a negative balance
June 26, 2011, 10:37:17 PM
If only it was that easy! It also would be a lot easier if fees were a fixed amount per transaction, as grue believes, instead of per KB, but that's not feasible. The whole problem is that tx fees are added on top of the withdrawal amount. The user's withdrawal transaction proceeds without warning even if the amount+fee is larger than the user's account balance, which depletes your reserves. They just end up with a negative balance. The fees are unpredictable and can be very large - I'm talking 30% as seen in others' posts - when made up of lots of small inputs, even if the inputs are old. You can't charge them the fee if the withdrawal is of their entire balance. Neither can you only allow them to withdraw a small amount at a time because that just compounds the problem. Citation on the 30%? I recall someone here claiming 30% when it was really more like 5% because they failed at math. It takes about .1816 KB per input, if all inputs are 0.01 and you're paying 0.01 per KB (.20 node behavior) you'll have no more than 18.2% fees for large transactions made of many 0.01 inputs. With 0.0005 BTC/KB it's a 0.9% fee for a big transaction made entirely of 0.01 inputs. Of course, this goes down very fast when the inputs are larger. Since acounts are just a daemon local bookeeping function and don't control the inputs, I think it wouldn't be reasonable to change someone a txn fee of more than the base fee just because their TXN got an unlucky selection of coins from the shared inputs. Instead you should just have a constant fee that covers the average and then some. It's just a simple cost of doing business. Of course, an RPC could be provided to query the fees for a TXN in advance (if you can tolerate an approximation, since additional inputs will change it), or a the send could get a maximum fee argument and reject with the required fee if you don't authorize enough. The txn size related fees (which, FWIW, these patches do _nothing_ to) are simply not going away. The tx_data has a direct cost on the network— every megabyte stored in the blockchain results in something like 40gigabytes transmitted and stored in the bitcoin network. Without fees for large transactions people will have a good reason do do psycho "backup my data into the blockchain" games and other such stuff. June 26, 2011, 10:36:06 PM
If only it was that easy! It also would be a lot easier if fees were a fixed amount per transaction, as grue believes, instead of per KB, but that's not feasible. I didn't say it was 0.0005 for all transactions. I meant that most of the time, it was 0.0005The whole problem is that tx fees are added on top of the withdrawal amount. The user's withdrawal transaction proceeds without warning even if the amount+fee is larger than the user's account balance, which depletes your reserves. They just end up with a negative balance. The fees are unpredictable and can be very large - I'm talking 30% as seen in others' posts - when made up of lots of small inputs, even if the inputs are old. You can't charge them the fee if the withdrawal is of their entire balance. Neither can you only allow them to withdraw a small amount at a time because that just compounds the problem. this could easily be fixed with a simple patch. somehow integrate the GUI function to determine if a fee is needed to a JSON-RPC method. besides. this is not a very good way to attack a business.That would be the way to do it. You would have a loop reducing the amount until amount+fee = intended amount. Can it know for sure what the required .0005 BTC/KB fee will be before sending it? June 26, 2011, 10:17:56 PM
If only it was that easy! It also would be a lot easier if fees were a fixed amount per transaction, as grue believes, instead of per KB, but that's not feasible. I didn't say it was 0.0005 for all transactions. I meant that most of the time, it was 0.0005The whole problem is that tx fees are added on top of the withdrawal amount. The user's withdrawal transaction proceeds without warning even if the amount+fee is larger than the user's account balance, which depletes your reserves. They just end up with a negative balance. The fees are unpredictable and can be very large - I'm talking 30% as seen in others' posts - when made up of lots of small inputs, even if the inputs are old. You can't charge them the fee if the withdrawal is of their entire balance. Neither can you only allow them to withdraw a small amount at a time because that just compounds the problem. this could easily be fixed with a simple patch. somehow integrate the GUI function to determine if a fee is needed to a JSON-RPC method. besides. this is not a very good way to attack a business. June 26, 2011, 09:10:55 PM
Quote It's not a problem that actually exists. You simply charge your clients for the txn fees generated when they are generated. ...simply passing on txn fees to your customers in one form or another where they exist. If only it was that easy! It also would be a lot easier if fees were a fixed amount per transaction, as grue believes, instead of per KB, but that's not feasible. The whole problem is that tx fees are added on top of the withdrawal amount. The user's withdrawal transaction proceeds without warning even if the amount+fee is larger than the user's account balance, which depletes your reserves. They just end up with a negative balance. The fees are unpredictable and can be very large - I'm talking 30% as seen in others' posts - when made up of lots of small inputs, even if the inputs are old. You can't charge them the fee if the withdrawal is of their entire balance. Neither can you only allow them to withdraw a small amount at a time because that just compounds the problem. June 26, 2011, 08:32:24 PM
There are only two lines of code changed, and the change is very minor... So i **seriously** doubt anything could go wrong currently. Those sound like the famous last words of the Debian OpenSSL package maintainer.  June 26, 2011, 08:26:21 PM
They could also flood you with HTTP requests sent by a million node botnet. Whats your point? There is nothing special about bitcoin here, you're also offtopic for this thread as far as I can tell. FWIW, bitcoin itself resists big coin bitdusting by making the priority depend on tx_value * input_age / tx_size. So quickly recirculating a large coin doesn't magically get you past it. This is the type of problem that ShadowOfHarbringer is trying to solve. A DDOS doesn't bankrupt you and your clients. The values can be randomized. It doesn't have to be done that quickly. Please don't get confrontational. No he isn't. It's not a problem that actually exists. You simply charge your clients for the txn fees generated when they are generated. Whats the issue? A DDOS can certainly bankrupt you— it can drive up absolutely astronomic connectivity fees, force you to use commercial mitigation services, and take you offline so that you can't earn the income you need to pay the bills. Worse, they are hard to stop, compared to simply passing on txn fees to your customers in one form or another where they exist. I'm not being confrontational, I just didn't follow that you thought this software would be desirable for exchanges simply because no competent exchange is going to run a fork of bitcoin that causes them to get stuck and unspendable outputs in their wallets and makes users wait days or weeks for payments to arrive. Presumably they care enough about the success of bitcoin to not allow this outcome. June 26, 2011, 08:18:04 PM
So, developers, what's the solution if... is 0.0005 fee on a transaction is too much? There are better ways of sabotaging the system, like getting a bunch of bitcoins, and deleting the wallet. 1. You run an exchange where your clients have accounts in your wallet. 2. A malicious client / competing exchange operator makes many small deposits to his account. 3. The malicious client withdrawals all of his money at once and the huge fee gives his account a negative balance, which eats into your reserves. 4. He opens a new account and repeats the process until you're bankrupt and owe your other users their bitcoins back, which you now don't have. Will any of these solutions work? - Patch to pay no fees and only allow withdrawals of bitcoins with > X confirmations. - Institute some convoluted system that disregards small deposits. - Patch to estimatetxfee and subtract that from withdrawals before sending them. Or what?  June 26, 2011, 08:08:53 PM
Well, whatever are the details of all this, none of the devs seems to care even to talk to me about this. 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"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 ? last 3 blocks: Generation: 50 + 0.80834234 total fees Generation: 50 + 0.30386 total fees Generation: 50 + 0.1656 total fees Jump to:
|
