 Show Posts
|
|
Pages: « 1 [2] 3 »
|
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. 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 | | 1 x 100 BTC | 0.0005 BTC | 1 x 100 BTC | 1 Input x 0.1816 KB/Input x 0.0005 BTC/KB = 0.0005 BTC | | 10 x 10 BTC | 0.0050 BTC | 1 x 100 BTC | 10 Inputs x 0.1816 KB/Input x 0.0005 BTC/KB = 0.0009 BTC | | 100 x 1 BTC | 0.0500 BTC | 1 x 100 BTC | 100 Inputs x 0.1816 KB/Input x 0.0005 BTC/KB = 0.0091 BTC | | 1000 x 0.1 BC | 0.5000 BTC | 1 x 100 BTC | 1000 Inputs x 0.1816 KB/Input x 0.0005 BTC/KB = 0.0908 BTC | | 10,000 x 0.01 BTC | 5 BTC | 1 x 100 BTC | 10,000 Inputs x 0.1816 KB/Input x 0.0005 BTC/KB = 0.9080 BTC | | 100,000 x 0.001 BTC | 50 BTC | 1 x 100 BTC | 100,000 Inputs x 0.1816 KB/Input x 0.0005 BTC/KB = 9.0800 BTC | | 1,000,000 x 0.0001 BTC | 500 BTC | 1 x 100 BTC | 1,000,000 Inputs x 0.1816 KB/Input x 0.0005 BTC/KB = 90.8000 BTC |
So I guess this attacks isn't so bad because it asymmetrically costs them 5x as many bitcoins in fees as it costs you! Although they can still bankrupt you if they are rich and hate you  |
|
|
|
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.0005 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.
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? |
|
|
|
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. |
|
|
|
What is the minimum deposit size cutoff to be invulnerable to this type of attack? Someone could still dustbin you even with a lot of 1 BTC deposits. They could recycle the same bitcoins over and over.
So now what?
- Use a separate wallet for each user?
- Make a deposit buffer? e.g. Deposits go to one wallet and are sent to the main account wallet in large chunks, minus fees? (Convoluted)
- Join a free transaction relay network?
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. |
|
|
|
|
What is the minimum deposit size cutoff to be invulnerable to this type of attack? Someone could still dustbin you even with a lot of 1 BTC deposits. They could recycle the same bitcoins over and over.
So now what?
- Use a separate wallet for each user?
- Make a deposit buffer? e.g. Deposits go to one wallet and are sent to the main account wallet in large chunks, minus fees? (Convoluted)
- Join a free transaction relay network?
|
|
|
|
|
So, developers, what's the solution if...
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?
|
|
|
|
My favorite username and passwords were UserID Username Email Password
12558 hehehe\' 0 0 0)waitfor delay\'0: $1$ldybUNj/$jZ5XJRWM8DsOTM3FU9TyN0
14250 & 39 union select 1 2 3 4 5 6
|
|
|
|
|
Perhaps we should first define how many dimensions we are working with.
|
|
|
|
|
Wave function collapse? When I made my weekly "portfolio" check in Mt. Gox a few days ago, Bitcoins were at $17 and slowly going up. I put in a buy order for $100 and ten minutes later they were at 1 cent.
Although stocks usually go down right after I buy them, like when I lost my entire portfolio of $2500 in eight days last year, this is a little more like a lightning strike from Hermes.
|
|
|
|
|
Electrons in semiconductors are delocalized and have no definite orbitals, and electrons themselves are indivisible elementary particles: something bitcoins are not.
Although... bitcoins are like fuzzy objects that are sometimes not there when their owners look for them, as well as catlike objects that resist being put back in the bag...
What are, like bitcoins, mineable (by breeding), infinitely divisible (by fur), easily transferable (by purpose or negligence), and more? Cats.
Therefore, I propose that the official shape of bitcoins be the furball.
|
|
|
|
|
I cracked some of the passwords out of the Mt. Gox database.
I reset these passwords in the Bitcoin forum (as well as Gmail, Fastmail, Paypal, Twitter, etc. in some cases.)
I forwarded the new passwords to Theymos.
That is all.
|
|
|
|
|
Adding a positive and removing a negative are the same thing, last time I checked.
|
|
|
|
|
This time's it's different.
|
|
|
|
|
I started leasing Russian botnet time and now I use about 32,000 PCs at 25% load.
|
|
|
|
Mine's more of an underminer.  |
|
|
|
|
What happens when you use the command line?
|
|
|
|
|
Only ATI Overdrive can do it. Note that my 5770 becomes unstable when I underclock it.
|
|
|
|
|
Looks like you need to rebuild your database.
|
|
|
|
|
