Love Deer meat and Jerky. But would not Condone killing Deer for profit. Necessity is one thing Profit is another.
 You don't think shooting a deer to eat it is profit? |
|
|
|
So, as thms said (or rather discovered  ), the base unit is actually a Satoshi and not a BTC (in the code.) I'm really having trouble understanding this concept. Yes, the base unit is satoshi, fine. But the definition of 1 BTC = 100,000,000 satoshis is just set on paper then? Not even on paper. It's just an arbitrary unit that Satoshi decided upon early, because the value of any bitcoin unit would be so small to start with. The transactions hold the value as a 64 bit integer, Satoshi just added a decimal in the middle of the base-10 representation of that 64 bit integer, with 32 bits to either side. Again, that's nowhere in the code or protocol, just something Sathoshi decided upon to make the mental math easier for users. So what these lines in bitcoin / src / util.h are for? static const int64_t COIN = 100000000;
static const int64_t CENT = 1000000;
and then in bitcoin / src / core.h we see this: static const int64_t MAX_MONEY = 21000000 * COIN;
Taht's just the display code. |
|
|
|
|
I doubt any of the altcoins ever get above the 13th floor, much less the moon.
|
|
|
|
|
I have to admit, this is a new approach. Seems unlikely to succeed, even if this weren't a forum dominated by libertarians and scoff-laws of several stripes.
|
|
|
|
So far I have not seen TwinWinNerD's attack refuted.
I own 1000 BTC.
I am investing 180 BTC in my attack and sell the other 820 on the exchange. I divide them into outputs of size exactly 0.1mBTC+1satoshi over a few weeks onto several node's I control. That will be about 1.8 million tx I can spam once set up. That is more than 3 consecutive days of 6 tx/s.
Once ready, I unleash the kraken, send 10tx/s in burst mode. The queue will grow long very quickly until tx are dropped at the end of it.
Now most people will not know what is going on, but simply see their cashout from bitstamp or their transfer to a friend not show up for a looong time. Of course, the core crew here knows to just increase the mining fee a bit to jump to the front of the queue, but that's not something 90% of the users even know how to do (wild estimate).
This will cause a bit of a sell off of coins. These coins, however, don't even arrive at the exchange within a day (caught in queue / dropped). Now people panic. Price drops 20% in a day (wild estimate).
I buy BTC back, with the money I got from selling earlier. At 20% lower price, I can afford 1020 BTC.
Voila I made 20 BTC profit.
FF a week. The newst -qt is released which has a dynamic automatic fee. The BTC price reaches pre-attack levels. My 20BTC profit is now in the money as well.
Where does this attack fail? (Besides the wildly estimated numbers of course.)
There are other tricks of the protocol not yet mentioned. One is the stretchy nature of the blocksize limit. You had better hurry if you wish to test this theory, though. It won't be much longer before the "naked block" protocol is ready for prime time. Like I already said, if you've got the funds and the balls, put it to the test. If you succeed in breaking the network, so be it; it was bound to happen eventually anyway and better sooner than later. If you fail, then you will have spent a lot of money to prove something the rest of us believe. Whatever the outcome, you'll be remembered. |
|
|
|
You can outbid me because you have such an old wallet, others might read about it and increase their sending fee. BUT the majority of transactions use the formula where for every 1 kb 0.0001 Fee is applied. So all automated transactions would come to a halt and most user transactions.
Yes, of course you can cause some delays if you're willing to spend the funds. But your costs are ever increasing as the attack continues. Personally, I don't think 1800 BTC would be enough to maintain such an attack of any significance for two weeks. And we haven't even talked about the 'soft' blocksize limit rules. The blocksize can "stretch" somewhat when the fees increase significantly, which would also increase your attack vector costs or limit your effectiveness. The end result is the same.
I still think that this is a risk we have to completely solve, but it is not as severe as i thought.
Thank you for the discussion btw!
It's not something that can be completely "solved", although the developers are working on "naked" blocks, which would improve the effective throughput of the network significantly, even without increases in the blocksize limits. Because there is no way for a computer to distiguish between a spammer willing to pay the price from a group of honest users. Individual miners can add additional sorting rules as they see fit, however, so if you come up with a new one that might further limit such damage, or cost attackers more, feel free to propose it. Some will take it up, and complete compliance with the rules are not required most of the time. |
|
|
|
<sigh>
Alright, I'll explain the mechanics as best as I can remember the details. I could easily get the actual numbers wrong, but this is basicly how the system works.
The transaction queue in the bitcoin client is ordered by points, not the order of arrival. There are two ways to get points, you can buy them or wait them out. When you pay a fee, you're effectively buying enough points to reach the minimum number of points to get processed, because no transaction gets processed before it has enough points. IIRC, one satoshi = one point, and the minimu fee is the minimum number of points required to process immediately. Of course, free transactions can get processed as long as it has enough points. Any transaction that has it's YOUNGEST input transaction old enough to have enough points gets processed, at one point per block. For example, if I didn't use my wallet for several weeks, my free transaction might still end up with more points than your minimum fee transactions based upon a brand new input transaction. But in addition to that, no transaction that has not had it's inputs processed can have any points at all, regardless of the fee, because the network won't even recognize your #2 transaction until the inputs from #1 are processed. So no matter how many wallet.dat files you're using to do it, your processed transaction input are finite, and I would stil be able to get my transaction based upon a 3 week old input through before your 1 second old transaction with a fee, unless and until you were willing to increase your fee significantly. No matter how you do it, your spamming costs you an exponentially increasing amount of money to maintain, and since most users don't need to have their transactions processed in less than an hour anyway, most users wouldn't even notice your efforts.
I actually know all these points, thats why i said that you start from a single wallet with enough founds that you don't need to use any fund twice. If we need 90 BTC per day to occupy all slots, we can buy/collect 1800 BTC and just let them sit for a/couple months and then just"freeze" the network for 20 consecutive days. Most people won't have a problem with 1 hour waiting time, but if their transactions are held in limbo for 2 weeks, they WILL mind. You're still overlooking a critical point that I've mentioned three times. No matter how long you age your wallet.dat file(s), the number of independent & processed transactions in those files are finite. As soon as you run out of aged transactions to use, you are immediately dependent upon the first set of transactions being processed before your second set can even buy their way in; so you can make all your transactions in advance and hit the network all at once, and your second wave is still denpendt upon the first wave beign processed in a timely manner. And even if you succeed at that, your second wave doesn't have any age advantage anymore. You're second wave woudl require a significantly higher fee in order to trump my older transaction, more so if I choose to include a fee myself. If I'm in a hurry and see that the network is jammed, I can easily outbid your per transaction fee to get through. It's a self regulating system, yo ucan only make it cost more until you run out of funds. You can never completely deny service to other users, even for a short time. I think you don't read my posts at all. I have accounted for that. In my example we start with 1800 BTC, that is enough to send 12.000.000 Transactions WITHOUT USING A SINGLE INPUT/OUTPUT TWICE! Those 1800 BTC are enough to last for 20 consecutive days. That is MORE than a short time... Okay, but even if you have that much to blow, as soon as you begin you just drive up the price. I can still outbid your per transaction fee if I need to get something done sooner rather than later. And if you do try this, most users would learn pretty fast that the delays were due to a transaction spam attack, and either increase their fees or wait you out. Either way, this doesn't have any real effect upon the price of bitcoin. And when I say I can outbid you, I mean I know I can outbid you, personally. I actually have access to a storage wallet with ages over two years and counting. I'm sure I'm not alone. Once again, go ahead and try it. Either way, you'll be remembered for it. |
|
|
|
<sigh>
Alright, I'll explain the mechanics as best as I can remember the details. I could easily get the actual numbers wrong, but this is basicly how the system works.
The transaction queue in the bitcoin client is ordered by points, not the order of arrival. There are two ways to get points, you can buy them or wait them out. When you pay a fee, you're effectively buying enough points to reach the minimum number of points to get processed, because no transaction gets processed before it has enough points. IIRC, one satoshi = one point, and the minimu fee is the minimum number of points required to process immediately. Of course, free transactions can get processed as long as it has enough points. Any transaction that has it's YOUNGEST input transaction old enough to have enough points gets processed, at one point per block. For example, if I didn't use my wallet for several weeks, my free transaction might still end up with more points than your minimum fee transactions based upon a brand new input transaction. But in addition to that, no transaction that has not had it's inputs processed can have any points at all, regardless of the fee, because the network won't even recognize your #2 transaction until the inputs from #1 are processed. So no matter how many wallet.dat files you're using to do it, your processed transaction input are finite, and I would stil be able to get my transaction based upon a 3 week old input through before your 1 second old transaction with a fee, unless and until you were willing to increase your fee significantly. No matter how you do it, your spamming costs you an exponentially increasing amount of money to maintain, and since most users don't need to have their transactions processed in less than an hour anyway, most users wouldn't even notice your efforts.
I actually know all these points, thats why i said that you start from a single wallet with enough founds that you don't need to use any fund twice. If we need 90 BTC per day to occupy all slots, we can buy/collect 1800 BTC and just let them sit for a/couple months and then just"freeze" the network for 20 consecutive days. Most people won't have a problem with 1 hour waiting time, but if their transactions are held in limbo for 2 weeks, they WILL mind. You're still overlooking a critical point that I've mentioned three times. No matter how long you age your wallet.dat file(s), the number of independent & processed transactions in those files are finite. As soon as you run out of aged transactions to use, you are immediately dependent upon the first set of transactions being processed before your second set can even buy their way in; so you can make all your transactions in advance and hit the network all at once, and your second wave is still denpendt upon the first wave beign processed in a timely manner. And even if you succeed at that, your second wave doesn't have any age advantage anymore. You're second wave woudl require a significantly higher fee in order to trump my older transaction, more so if I choose to include a fee myself. If I'm in a hurry and see that the network is jammed, I can easily outbid your per transaction fee to get through. It's a self regulating system, yo ucan only make it cost more until you run out of funds. You can never completely deny service to other users, even for a short time. |
|
|
|
Even if this was possible what woud you do to prevent it?
Increase the max blocksize and introduce a methode to bootsstrap the blockchain, so that it doesn't bloat They are already working on both of those issues. Go help them. I am currently not capable of doing so. But back to the topic, is this following statement true? "It is possible to slow down the processing time of transactions with this attack, although it is extremly expensive and not very practicable." No it is not true. then tell me why, because the explanation from before is not enough. <sigh> Alright, I'll explain the mechanics as best as I can remember the details. I could easily get the actual numbers wrong, but this is basicly how the system works. The transaction queue in the bitcoin client is ordered by points, not the order of arrival. There are two ways to get points, you can buy them or wait them out. When you pay a fee, you're effectively buying enough points to reach the minimum number of points to get processed, because no transaction gets processed before it has enough points. IIRC, one satoshi = one point, and the minimu fee is the minimum number of points required to process immediately. Of course, free transactions can get processed as long as it has enough points. Any transaction that has it's YOUNGEST input transaction old enough to have enough points gets processed, at one point per block. For example, if I didn't use my wallet for several weeks, my free transaction might still end up with more points than your minimum fee transactions based upon a brand new input transaction. But in addition to that, no transaction that has not had it's inputs processed can have any points at all, regardless of the fee, because the network won't even recognize your #2 transaction until the inputs from #1 are processed. So no matter how many wallet.dat files you're using to do it, your processed transaction input are finite, and I would stil be able to get my transaction based upon a 3 week old input through before your 1 second old transaction with a fee, unless and until you were willing to increase your fee significantly. No matter how you do it, your spamming costs you an exponentially increasing amount of money to maintain, and since most users don't need to have their transactions processed in less than an hour anyway, most users wouldn't even notice your efforts. |
|
|
|
You say that so many have tried. How many managed to get the TPS above 10?
If you are producing 14 tps from the same wallet.dat file, it's impossible for them to not be dependent upon each other. So your first transaction must be processed before your 2nd, and so on. You don't introduce a condition that you can delay anyone but yourself, althoug you can still manage to spend fees pretty fast. You can set up a couple of nodes and with enough BTC in stock you can always send fresh satoshis + the minfee. [/quote] At some point, multiple wallet.dat files repeatedly sending each other transactions still become dependent upon one another. The same thing would happen if every user on the system were repeatedly sending each other transactions, and that is the point. The delays protect the system regardless of where the delays originate. If the delays are truely legitimate, then yes the network can get bogged down, which is why the network will favor higher fees for short term processing. If you need that kind of speed, you can pay for it. But there is no one with enough money that can screw the system over for any significant period of time. |
|
|
|
Even if this was possible what woud you do to prevent it?
Increase the max blocksize and introduce a methode to bootsstrap the blockchain, so that it doesn't bloat They are already working on both of those issues. Go help them. I am currently not capable of doing so. But back to the topic, is this following statement true? "It is possible to slow down the processing time of transactions with this attack, although it is extremly expensive and not very practicable." No it is not true. |
|
|
|
Others have tried this. I welcome you to blow all your funds on the attempt. The miners will appriciate the donation, and you will quickly learn that you can't really outrun the bitcoin network. Have fun!
Well, lets do some math on this: Current network can handle 7 TPS. Let us assume that 1 TPS is happening independent of our spam. That leaves us with 6*60*60*24 = 518400 Transactions per day Min fee is 0.0001 --> 518400*0.0001= 51,84 BTC/day Now lets say that we are a highroller that wants: - this method of attack fixed - wants to buy cheap within the panic selloff 1 day Network stillstand for ~60 BTC doesn't seem too expensive does it? It's not a problem. Spamming the network with valid transactions is not a valid attack vector. When the developers say that the network can presently handle 7 tps, they mean that is how fast the network can process them. The network doesn't have to process the 8th transaction per second, it can simply ignore it, which is what it does. It happens all of the time, in fact. If you don't add a fee, your transaction is the first to be ignored as a matter of principle. If you add a minimum fee, your transaction is the first among the fee paying transactions in the queue to be ignored in favor of higher fees. It's a bidding market, dude. If the network is under stress, the cost of a transaction being processed sooner rather than later increases, and the lower fee paying transactions have to wait for the network to catch up. If your transaction is ingored for two weeks, it disappears from the queue and you have to resend it. Furthurmore, if you send a transaction that is dependent upon another one being processed first, the second one doesn't even propagate across the network at all, because any node besides your modified client will consider it invalid until the preceeding transaction makes it into a block. Really, you can't break this thing. So many before you have tried, using values when the value of a bitcoin was still under a nickel. Your 60 BTC example isn't shit. There, are you ready to send me my 30 BTC consultation fee yet? Or do you need more? But you say it yourself, the 8th transaction per second gets ignored. If 1 of 8 transactions is a legit one, than there is a 12.5% chance that everyone that wants to send something gets ignored. If we spam 14 TPS than that increases to 50% at no additional cost for the spammer. (the ignored transactions are just reversed, no fee paid) Also @ bidding market, you can also increase the fee of the spam, this makes the attack more expensive, but in the end you can make a big profit if you are a highroller. You say that so many have tried. How many managed to get the TPS above 10? If you are producing 14 tps from the same wallet.dat file, it's impossible for them to not be dependent upon each other. So your first transaction must be processed before your 2nd, and so on. You don't introduce a condition that you can delay anyone but yourself, althoug you can still manage to spend fees pretty fast. As far how many times an attacker has been able to spam the netowrk beyond 7 tps, that has happened exactly once; and is the primary reason that the point delay system was put inot the network protocol for free transactions. I was here when it happened, and I )as a user) didn't eve notice until it was all over. |
|
|
|
Even if this was possible what woud you do to prevent it?
Increase the max blocksize and introduce a methode to bootsstrap the blockchain, so that it doesn't bloat They are already working on both of those issues. Go help them. |
|
|
|
We could do a 1000 for 1 split and put 1 BTC close in value to a dollar.
Of course, what this would do is open the floodgates for new buyers, guaranteed. That I agree, it's 100% confirmed that more people would buy if the decimal point is shifted to the right place You can only speak for yourself, although you probably are here. This argument is why I pointed out that the market has already decided how to handle it. There is nothing for us to debate, no one has any power to effect this kind of change if the users don't wish to do it themselves. The unit of display isn't decided by the code or protocol. This whole thread is like arguing how many angels can dance on the head of a pin! There is nothing that any of us can do! Even if we could all agree. If you don't like how your client displays the unit, change it. You can in your own client anytime you like. It would have zero effect on your net spending power, nor would it have any effect whatever on your ability to buy bitcoins in any fraction or number you are able. If people don't buy bitcoins because the price of a whole bitcoin is $800, why does it matter if they might buy a millibit for 80 cents? Their economic ignorance isn't a reflection on you, is it? Nor is it a reflection on Bitcoin itself. If Bitcoin fails, it won't be because a portion of the potential user pool doesn't understand the unit. True to a point, but if we just change the name of the unit on e.g. our wallet, then we will be saying e.g. 1 mBTC, right? That is a problem right there. It is no longer a "bitcoin", it is a "milibitcoin". I think we are talking about more than an adjustment in perception, now that you bring up that good point. Unlike regular money, we don't yet have the familiarity with the equivalent of say "a penny" in our Bitcoin vocabulary. And it sounds so geeky to say "milibitcoin" for Grandma! LOL But who knows, really... Perhaps we can easily make the adjustment. It is an interesting part of the experiment, eh? Having a money that increases so much in value that you have to start refering to it in thousandths or the like. Outside of the core Bitcoin community, I suspect that units will have many names across nations, cultures and languages, and I don't think there is any way to avoid that. So why try? There is no need to have an "official" unit name, people who trade across borders will make it their business to be aware of the differences in unit nomiclature and division. People who don't trade across borders don't give a shit what it's called elsewhere. Note that gold has 200+ names. EDIT: BTW, if you're willing to dig into the archives of this forum, you'll find that I'm the person who suggested that the smallest unit be called a satoshi. Yes, me, personally. I really have been here that long. The reason that I gave then was that most people chaff at using scientific names, and that (much like the faces on the US currencies) the most important historical characters tend to be on display on the smallest units of currency, so that they will be seen more often. That's why George Washington is on the $1 bill (first US president under the constitution, not the first Us president) and Ben Franklin is on the $100 bill (founding father, not a president ever). For this reason, and the fact that the names were so uncommon, I proposed that the smallest unit be called a satoshi and the smallest unit times 1000 be called a GAvin. That stuck because it was a good idea and was received well by the community at the time, not because I had any authority over the matter. |
|
|
|
Others have tried this. I welcome you to blow all your funds on the attempt. The miners will appriciate the donation, and you will quickly learn that you can't really outrun the bitcoin network. Have fun!
Well, lets do some math on this: Current network can handle 7 TPS. Let us assume that 1 TPS is happening independent of our spam. That leaves us with 6*60*60*24 = 518400 Transactions per day Min fee is 0.0001 --> 518400*0.0001= 51,84 BTC/day Now lets say that we are a highroller that wants: - this method of attack fixed - wants to buy cheap within the panic selloff 1 day Network stillstand for ~60 BTC doesn't seem too expensive does it? It's not a problem. Spamming the network with valid transactions is not a valid attack vector. When the developers say that the network can presently handle 7 tps, they mean that is how fast the network can process them. The network doesn't have to process the 8th transaction per second, it can simply ignore it, which is what it does. It happens all of the time, in fact. If you don't add a fee, your transaction is the first to be ignored as a matter of principle. If you add a minimum fee, your transaction is the first among the fee paying transactions in the queue to be ignored in favor of higher fees. It's a bidding market, dude. If the network is under stress, the cost of a transaction being processed sooner rather than later increases, and the lower fee paying transactions have to wait for the network to catch up. If your transaction is ingored for two weeks, it disappears from the queue and you have to resend it. Furthurmore, if you send a transaction that is dependent upon another one being processed first, the second one doesn't even propagate across the network at all, because any node besides your modified client will consider it invalid until the preceeding transaction makes it into a block. Really, you can't break this thing. So many before you have tried, using values when the value of a bitcoin was still under a nickel. Your 60 BTC example isn't shit. There, are you ready to send me my 30 BTC consultation fee yet? Or do you need more? |
|
|
|
If it was this easy, people would have done it already.
Where is my missconception? Would you prefer to send me half of your stash, and I'll just tell you? Or would you prefer to give it a try, blow everything you have and see the results for yourself? |
|
|
|
|
Others have tried this. I welcome you to blow all your funds on the attempt. The miners will appriciate the donation, and you will quickly learn that you can't really outrun the bitcoin network. Have fun!
|
|
|
|
Where does this nonsense come from that the base unit is the satoshi? Its is agreed upon to stick to 8 decimal places for time being (can be changed to 6 or 10 or whatever) and its called a Satoshi.
If someone wants to be cheap i am sure he can find some crappy coin on a crappy exchange.
Well, I first noticed it when I read Satoshi's white paper. I've been told by many of the developers that the satoshi is the base unit as well. Can't see any reason to call it nonsense, myself. |
|
|
|
We could do a 1000 for 1 split and put 1 BTC close in value to a dollar.
Of course, what this would do is open the floodgates for new buyers, guaranteed. That I agree, it's 100% confirmed that more people would buy if the decimal point is shifted to the right place You can only speak for yourself, although you probably are here. This argument is why I pointed out that the market has already decided how to handle it. There is nothing for us to debate, no one has any power to effect this kind of change if the users don't wish to do it themselves. The unit of display isn't decided by the code or protocol. This whole thread is like arguing how many angels can dance on the head of a pin! There is nothing that any of us can do! Even if we could all agree. If you don't like how your client displays the unit, change it. You can in your own client anytime you like. It would have zero effect on your net spending power, nor would it have any effect whatever on your ability to buy bitcoins in any fraction or number you are able. If people don't buy bitcoins because the price of a whole bitcoin is $800, why does it matter if they might buy a millibit for 80 cents? Their economic ignorance isn't a reflection on you, is it? Nor is it a reflection on Bitcoin itself. If Bitcoin fails, it won't be because a portion of the potential user pool doesn't understand the unit. |
|
|
|
they'll be promised more free stuff, and they'll vote for it.
Yes, so long as that promise appear credible. Presumedly, that leaves open the possibility that the electorate could conclude that such promises are not credible. History isn't kind in this aspect, however. |
|
|
|
|
Show Posts
