Bitcoin Forum
April 23, 2014, 09:16:47 AM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 ... 365
141  Bitcoin / Bitcoin Discussion / Re: Broadcasting the Blockchain on: February 04, 2014, 03:25:42 PM
However, a hotspot in space couldn't coordinate timesharing of all the hotspots in it's radio shadow even if it were possible for it to hear them.

You know more about it than I do, but perhaps this is relevant:

Quote
The signal on the ground will be fairly weak, in order to not interfere with local networks.  At this time, we're shooting for receive sensitivity of about -90dBm.

Quote
Correct, in all likelihood the noise floor in modern urban areas will be too dense. As much as we would like everyone to use Outernet, it's really meant for people who would otherwise not have access to information.

http://www.reddit.com/r/technology/comments/1wqgmh/outernet_wifi_for_the_world_from_outer_space/cf4nshr

Actually, now that I look, someone also asked this question on their forum.  The response seems dubious:

https://discuss.outernet.is/t/can-2-4ghz-even-penetrate-the-atmosphere-efficiently/34


Well, it's either misinformed or deliberately false.  I've had my kids look at this site and another site (waterstep.org) to compare the tech claims of one charity asking for money compared to another, and we've largely come to the conclusion that this outer.in site is a scam designed to illicit donations from well intended.  As my son noted, the first clue is the "for free" claim.  That can never happen.  While it might be free to receive, there would still need be advertisments and such.  And it's not false that low earth orbit sats have used the S band, but that particular section of the S band is where the attenuation from water is greatest.

EDIT:  By "that particular" section of the S band, I mean the sliver of unlicensed bandwidth that B/G wifi occupies.  The S band is very wide, but only that portion is unlicensed, and because it's an ISM band (Insustrial, Scientific & Medical) that is used primarily for purposes besides communication.  There are other ISM bands, but none that are so wide as the one that B/G wifi (and Bluetooth, and several other short range techs) utilizes.  It's that wide because microwave ovens (in particular) use that band due to the fact that the high attenuation of radio waves by hydrogen is useful for heating with radio waves, and microwaves are so paowerful that they produce a lot of 'splatter'.  Until wifi came out, it was largely believed that  the band was useless for communications due to both the high attenuation and the likelyhood of interfereance from microwaves.  Wifi protocols are designed with the likelyhood of occasional interference in mind, however.  So is Bluetooth.  The rest of the S band experiences attentuation due to water in much the same way that radio does in general, in that the higher the frequency the greater the attenuation from water.  Both the US and Russia have massive ultra-low-frequency transmitters, with enormouse power ratings, in order to communicate with submerged submarines via morse code.  There are ham radio geeks called "lowfers" who try to communicate in this range as well, but it's hard to do anything when the wavelength of the signal is hundreds of kilometers long.  So while there are useful frequencies outside of the wifi band on the S band, they generally require more power for the same task than a lower frequency band such as the L band, and less than higher frequency bands such as the K band.  So most of the S band is particularly good for a low power downlink to consumer class receivers, just not within the B/G wifi band.
142  Other / Politics & Society / Re: Opposition to ObamaCare now 2:1 among the uninsured on: February 03, 2014, 11:06:00 PM

Your tax penalty (shared responsibility fee) for not having insurance is paid on your taxes at the end of the year. If your taxable income is below 133% of the FPL you are exempt from this tax.
<snip>

Why not just pay the small amount it takes to get insurance? It will be cheaper to have it, than to pay the tax. You pay a small % and the government pays the rest..


You answered your own question right out of the gate.  The vast majority of the uninsured are uninsured because they don't have reliable employment to produce such a taxable income.  That is not to say that most of these people don't actually have an income, just not a taxable one.  It's actually not very difficult for a young, single person to make a good living if they don't have a problem with the kind of work that doesn't tend to produce a W2 form with your own name on it.  That kind of work also makes it easier to qualify for government aid at the same time, but to a 20 something hustler with no known medical issues, paying any kind of premium has always been a non-starter.  That's why they didn't bother before.

You're just making shit up, the vast majority?? I don't have insurance and way above the FPL level.. No one was talking about the FPL level.. What you quoted was talking about the fee that comes along when you don't get insurance.. not being to poor to get it and not getting a fine.

For sure, the only rational discussion would be based on the individual self-optimizing for his own economic welfare and that of his family.

But my earlier comment pretty much stands:  Who would buy insurance with a ridiculous deductible, when alternately they could pay the penalty (let's not call it a "fee" or a "shared responsibility fee", PLEASE no sugar coating shit here) ...

and have no deductible?

My point was that the fee was meaningless to those for whom the law was targeted to attract; namely the young, healty and uninsured that are needed to pay premiums to subsidize the older and less helathy with pre-existing conditions.  The young and healty are the majority of the uninsured Americans that this bill was aimed at, that much is fact.  But if you were young, healthy and officially unemployed (but had an unofficial form of income) what value would you see in paying any premium at all, if you didn't see such value before this, and the law specificly exempts you from the penalty because you don't pay taxes?  You could argue that such officially unemployed young with non-taxable incomes is the minority, but the statisics on System D economies says otherwise.
143  Economy / Service Discussion / Re: Time to go on a spending spree at Overstock! on: February 03, 2014, 05:47:30 PM
I've found that paying with bitcoin to overstock.com isn't cheap.  The value converter in my Mycelium client consistantly quotes the bitcoin price about 10% higher than what Overstock says it is. 
144  Other / Politics & Society / Re: Opposition to ObamaCare now 2:1 among the uninsured on: February 03, 2014, 05:26:23 PM

Your tax penalty (shared responsibility fee) for not having insurance is paid on your taxes at the end of the year. If your taxable income is below 133% of the FPL you are exempt from this tax.
<snip>

Why not just pay the small amount it takes to get insurance? It will be cheaper to have it, than to pay the tax. You pay a small % and the government pays the rest..


You answered your own question right out of the gate.  The vast majority of the uninsured are uninsured because they don't have reliable employment to produce such a taxable income.  That is not to say that most of these people don't actually have an income, just not a taxable one.  It's actually not very difficult for a young, single person to make a good living if they don't have a problem with the kind of work that doesn't tend to produce a W2 form with your own name on it.  That kind of work also makes it easier to qualify for government aid at the same time, but to a 20 something hustler with no known medical issues, paying any kind of premium has always been a non-starter.  That's why they didn't bother before.
145  Bitcoin / Bitcoin Discussion / Re: Broadcasting the Blockchain on: February 03, 2014, 05:15:22 PM
After checking my own shortwave receiver, which I believe to be fairly representative of the kinds of reciever available most of the world around, is tunable between 19,990 and 30,000 khz using it's third (final) SW band setting.  This encompasses the international shortwave bands of 15 meters (18,90019,020 kHz) 13 meters (21,45021,850 kHz) and 11 meters (25,60026,100 kHz).  All three of these bands are pretty much useless for international broadcasters because it's rare for the critical frequency to spike that high, at least not reliablely enough for a broadcaster to use.  For this reason, 11 meters is a common citizen's band in many countries and 13 meters is a regional AM band in Pacific Asia.  Wikipedia says that 15 meters is rarely utilized, and may be reallocated to DRM broadcasters in the future.

Perfect.

What needs to be done is that someone in a country that is signatory to the communications treaties needs to get a broadcasting license from their country to broadcast in the 15 meter band.  The United States is notoriously unlikely to approve such a broadcasting license, so it'd be better for someone in another country to attempt it.  I might still attempt it, but I'm not going to pursue it if it requires a $10K broadcasting fee, obviously.  The sats would still have to be aware of all licensed broadcasters in this band, and avoid them whenever possible.  I'm pretty sure that this is also a ham band, but not one that I've ever known any hams to use, as local hams use 2 meters and 70 cm while distance hams use 20, 40 and 80 meters.

A modified AM shortwave receiver could simply involve an audio output jack wired to the audio input jack of a computer sound card, with an accompaning app that can fit on a small usb drive and instructions for locating the right frequency and capturing the data stream.
146  Bitcoin / Bitcoin Discussion / Re: Broadcasting the Blockchain on: February 03, 2014, 04:47:43 PM
Looks like someone is going to attempt this:

https://www.outernet.is/

Quote
By leveraging datacasting technology over a low-cost satellite constellation, Outernet is able to bypass censorship, ensure privacy, and offer a universally-accessible information service at no cost to global citizens. It's the modern version of shortwave radio, or BitTorrent from space.

Unfortunately, I can see some very real technical and legal issues with trying to do this as described.

First off, Wifi is possible in only two bands.  Since the higher N band is very new, and many smartphones still don't support it, I'm going to assume that the older B,G band is what they plan to use.  But there was a technical reason that this band was chosen at the time of development; namely that the B,G band was license free worldwide.  But why was that, since such license free technologies didn't really exist before Wifi itself?  Because the B,G band is the resonate frequency of hydrogen.  Thus, energy transmitted in this band is heavily attenuated by any water or hydrocarbons found in it's path, and was considered useless for distance communications.  This is still true, and has much to do with why Wifi is so poor at clear range.  It's also why this band is shared by every retail microwave that I know of, since food is pretty much all hydrocarbons and water.  While there wouldn't likely be much risk of hydrocarbons in the line of sight from low earth orbit, there would be much water.  On average, the Earth's atmosphere has enough water from space to sea level to equate to a 32 foot deep dive under the ocean's surface.  The amount of power that would be required to push through this and be receivable by common wifi hardware on the Earth's surface would be rediculous.

Second, there are also sound techincal reasons as to why wifi multicasting is not commonly used.  Mostly because wifi is a time-sharing technology that (generally) permits more than one unrelated connection to coexist on the same channel.  This is permitted because normal mode wifi requires that the hotspot 'listen' to it's own channel several times per second for other broadcasters trying to share the channel space.  This doesn't always work well, but it does work more often than most people realize.  However, a hotspot in space couldn't coordinate timesharing of all the hotspots in it's radio shadow even if it were possible for it to hear them.  In this case, the sat based signal would effectively 'jam' the chosen channel across the whole of it's radio shadow, and also be a violation of international communications treaties as a result.

Third, the licesne free broadcasting nature of the B,G band is limited to 'terrestrial' transmitters, and therefore doesn't apply to satillites at all.  A new treaty would be required to even permit such a license, since every country has max transmitter powers in the B,G band that would be WAY below what a sat would require.

While using the new N band would reduce the power requirements considerablely, the other two issues would still apply.  Perhaps a lower frequency license free band would work with modified FM band recievers, but I can't see a way around the international communications treaties regarding this.  Perhaps a broadcast stream that can switch around frequencies in the higher frequency shortwave bands would work, but the sat would have to be able to respond to the reflectivity of the ionosphere and changes in the critical frequency.  Most Shortwave broadcasters have to stay below the critical frequency so that their Earth bound transmitters can reflect their signal off of the F layer of the ionosphere, but what about a broadcaster in teh shortwave bands that deliberately stays above the critical frequency so that his signal is not reflected back into space?  Regardless, the data throughput woudl be low due to a narrow usable bandwidth and a particularly 'noisey' radio environment in those bands.
147  Economy / Economics / Re: When to "move the decimal points" ? on: February 01, 2014, 09:17:48 PM
It's not for display.

why would someone set a constant MAX_MONEY = 21000000 * COIN; for display purposes? The display would never go past that so it would be useless to set that constant just to control display.

So in fact, the BTC value is set in code.

The transaction fee per kB is also set in the code. That doesn't mean that it can't be changed.

COIN is used in various places in the code to make BTC amounts easier for programmers to read. MAX_MONEY = 21000000 * COIN is the same as MAX_MONEY = 2100000000000000. Except in a small amount of code very close to the UI, all Bitcoin values in the code are stored as integer satoshi amounts. (MAX_MONEY is used in transaction verification, but its unit is not BTC.)

In general, changing the code equals changing the rules. Hey, I thought we were done with centralised regulation. Think about it, a miner gets 25 BTC today, which is a fixed portion of the total amount of 21 million BTC (2 100 000 000 000 000 units). Bitcoin is fine as it is; the only minor problem is defining a nice and catchy pricing notation. By definition (design) 1 BTC is 1/21 millionth of the total amount, because of the mining strategy (50, 25, 12.5, and so on).
It will be very confusing/misleading/deceiving if you/they change the already familiar symbol BTC, or its abbreviation BTC, for something else than 1 BTC; i.e. 1/21 millionth of its totality.

Some of the code impliments the protocol; within exists rules that cannot be broken, and others that are more flexible within constraints.  All the rest of the code within a given client is there for users' ease, and can be modified without problems.  How the client displays the stored value is of the latter type, for the protocol doesn't specify a display unit and isn't even aware of one besides the satoshi, and not even by that name.  There are many aspects of the system that are like this.  This is not an example of centralization.
148  Economy / Goods / Re: Like Beef Jerky? (Buy Jerky For Coin) on: February 01, 2014, 05:01:43 AM
Love Deer meat and Jerky. But would not Condone killing Deer for profit. Necessity is one thing Profit is another.

Huh You don't think shooting a deer to eat it is profit?
149  Economy / Economics / Re: When to "move the decimal points" ? on: February 01, 2014, 04:53:33 AM
Quote from: Its About Sharing

So, as thms said (or rather discovered  Grin), 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?

Code:
static const int64_t COIN = 100000000;
static const int64_t CENT = 1000000;

and then in bitcoin / src / core.h we see this:

Code:
static const int64_t MAX_MONEY = 21000000 * COIN;

Taht's just the display code.
150  Other / Alternate cryptocurrencies / Re: What altcoins are going to the moon? on: February 01, 2014, 12:35:55 AM
I doubt any of the altcoins ever get above the 13th floor, much less the moon.
151  Other / Beginners & Help / Re: Federal Bitcoin Inspector on: February 01, 2014, 12:27:19 AM
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.
152  Bitcoin / Bitcoin Discussion / Re: Possible Guide on how to "disable" the bitcoin network(?) on: February 01, 2014, 12:22:01 AM
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.
153  Bitcoin / Bitcoin Discussion / Re: Guide on how to "disable" the bitcoin network on: February 01, 2014, 12:14:30 AM

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.

Quote


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.
154  Bitcoin / Bitcoin Discussion / Re: Guide on how to "disable" the bitcoin network on: January 31, 2014, 11:39:00 PM

<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.
155  Bitcoin / Bitcoin Discussion / Re: Guide on how to "disable" the bitcoin network on: January 31, 2014, 11:26:50 PM

<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.
156  Bitcoin / Bitcoin Discussion / Re: Guide on how to "disable" the bitcoin network on: January 31, 2014, 11:07:07 PM
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.
157  Bitcoin / Bitcoin Discussion / Re: Guide on how to "disable" the bitcoin network on: January 31, 2014, 10:42:41 PM

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.
158  Bitcoin / Bitcoin Discussion / Re: Guide on how to "disable" the bitcoin network on: January 31, 2014, 10:39:28 PM
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.
159  Bitcoin / Bitcoin Discussion / Re: Guide on how to "disable" the bitcoin network on: January 31, 2014, 10:36:01 PM
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.
160  Bitcoin / Bitcoin Discussion / Re: Guide on how to "disable" the bitcoin network on: January 31, 2014, 10:34:05 PM
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.
Pages: 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 ... 365
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!