Bitcoin Forum
June 03, 2024, 05:15:54 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 [147] 148 149 150 151 »
2921  Bitcoin / Bitcoin Technical Support / Re: Is this a possible attack or am I missing something? on: September 05, 2011, 08:29:48 PM
This is a possible attack, but not in the way you suggest. You can DOS the nodes connected only to you, reject their blocks, and reject their txs. In theory, it should also be possible to fake tx to them (double-spend) and not broadcast it over the network, but this is very dangerous since you must keep them in quarentine until the coins are confirmed to be spent into your other wallet. (and you don't know if they are in quarentine or not).

This attack is very dangerous, and costly since many IPs in different blocks (bitcoin allows only one connection per block) needs to be purchaced. To avoid this attack, remain well-connected, keep a peers file on your computer and do not rely on IRC too much.
2922  Economy / Economics / Re: Falling Price To save Bitcoin on: September 04, 2011, 11:46:25 PM
MtGox likely has more than 2 million. (most of that might be reserve, though).

Most of it is not owned by them at all. Being an exchange they keep large amounts of all involved currencies for the customers Wink
If they decided to sell it all, few people would even bother to withdraw Smiley.
2923  Economy / Economics / Re: Falling Price To save Bitcoin on: September 04, 2011, 06:46:23 PM
MtGox likely has more than 2 million. (most of that might be reserve, though).
2924  Alternate cryptocurrencies / Altcoin Discussion / Re: [2BTC BOUNTY] New useless scammy blockchains on: September 04, 2011, 05:52:47 PM
Looks like I was not that wrong after all
In all fairness, it wasn't a double-spend attack. It did kill solidcoin (as well as ignite a licence change), though.
2925  Other / Beginners & Help / Re: More blocks/hour please on: September 04, 2011, 05:51:00 PM
Quote from: drlee
=Since they charge a 5% fee, any attempt to double-spend is unprofitable if the chance of getting 6 confirmations (I assume this is when the laundry sends the coins) in a row (or 7 blocks) falls below 5%. So in this case, bitcoinlaundry wouldn't care about how long or short blocks are (to a certain extent).

Why wouldn't they care? How many blocks bitcoinlaundry would need to wait to get the odds of an attacker getting that many confirmations in a row, below 5%, would be proportional to how short/long the blocks are.


No no, you see. The chance of double-spending this way REQUIRES the attacker to confirm invalid transactions! If more non-attacker blocks appeared than attacker blocks, the attack is now over. There is no reason to care about the block time if the attacker used that attack.
2926  Bitcoin / Development & Technical Discussion / Re: Bitcoin client took BTC. on: September 04, 2011, 02:01:42 AM
Linking you to this thread: https://bitcointalk.org/index.php?topic=30191.0. Please upgrade to the current github version to avoid this issue.
(edit: 0.3.25 is confusing)

I cannot find 0.3.25.

https://github.com/bitcoin/bitcoin/downloads
The 0.4rc1 is what I mean.

oic. cool, thanks, so 0.4rc1 fixes this problem that you know of?
Yes, this is the commit introducing this bug: https://github.com/bitcoin/bitcoin/commit/a6b211596323a8f2de20f8ab97e38969bece30fb#diff-7
And this is the commit fixing it: https://github.com/bitcoin/bitcoin/commit/a7dd11c6dadeb17cf5444dd29f3a63d80ef4b159
I'm guessing I gotta compile this Huh
Yeah, unfortunately.
2927  Bitcoin / Development & Technical Discussion / Re: Bitcoin client took BTC. on: September 04, 2011, 01:40:38 AM
Linking you to this thread: https://bitcointalk.org/index.php?topic=30191.0. Please upgrade to the current github version to avoid this issue.
(edit: 0.3.25 is confusing)

I cannot find 0.3.25.

https://github.com/bitcoin/bitcoin/downloads
The 0.4rc1 is what I mean.
2928  Other / Beginners & Help / Re: More blocks/hour please on: September 04, 2011, 01:40:02 AM
Hmmm OK. So 10 seconds won't work. What about trimming that time down a little bit?

The whole point of waiting for 6 confirmations is to wait for an hour's worth of blocks to be hashed out.  If you had 1 block a minute you'd want to wait for 60 confirmations.  6 confirmations isn't just some magical number that never changes based on the target block rate being shorter or longer.
Not nessesarily, it could also be reducing the chance to double-spend by a major holder to unprofitable. For example, assume someone is trying to attack http://bitcoinlaundry.com/. Since they charge a 5% fee, any attempt to double-spend is unprofitable if the chance of getting 6 confirmations (I assume this is when the laundry sends the coins) in a row (or 7 blocks) falls below 5%. So in this case, bitcoinlaundry wouldn't care about how long or short blocks are (to a certain extent).

As satoshi detailed in his whitepaper, the issue is network latency. It takes around 3 seconds for a block to spread around the entire network, and this is only 0.5% of the 10-minute block time. Cancer node attack is possible if this percentage rises. In 10-second blocks, this is 30% of the block time, so the attacker can broadcast a tx and a confirming block(s) to a certain group of nodes, and not to others. A fork is now very likely in this time so long as the attacker only broadcasts his own blocks only to that certain group of nodes. Once the other blockchain catches up, the attacker could either have lost nothing but some cpu time or fees, or have pulled off a successful double spend.

Satoshi believed 10 minutes to be this magic number. There is no proof that this is the best number, and only one attack maybe due to short block times (the myBitcoin incident) has been reported, but that attack could possibly just as well be pulled off with a standard 2-blocks-in-a-row (deepbit or btcguild or slush, for example, certainly had the capability, even though evidence suggest it isn't them). It is likely that ten minutes is too long, but we still don't know if anything else is better.
2929  Bitcoin / Development & Technical Discussion / Re: Bitcoin client took BTC. on: September 04, 2011, 01:20:57 AM
Linking you to this thread: https://bitcointalk.org/index.php?topic=30191.0. Please upgrade to the current github version to avoid this issue.
(edit: I meant 0.4.0rc1 is confusing)
2930  Bitcoin / Development & Technical Discussion / Re: Bitcoin client took BTC. on: September 04, 2011, 01:14:43 AM
What version? Older versions sent anything less than one bitcent away as a fee. ("bitdust").
2931  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCEMENT] Ixcoin 0.3.24.2 SECOND mandatory update released on: September 01, 2011, 11:40:15 PM
I'm still seeing 115+ Ixcoin clients on Freenode's #ixcoin channel and only ~47 on LFNet #ixcoinxx channels, so I'm guessing they still haven't switched over. Once these switch over to the new client, the block count will increment more rapidly.

Nasakioto, it looks like ixCoin is finally "out in the wild". Why? The creator no longer has the ability to change the rules!  Cheesy
2932  Economy / Speculation / Re: $/BTC Time Series Analysis on: September 01, 2011, 01:42:24 AM
I place the IQR for Thursday at $7.79 to $8.55. I am not yet convinced that the $8.00-$8.10 support level is ready to be broken, although the trend for the next few days seems to be down.

*image*
Price fell below $8, and is still dropping. It definately looks like it's tending down. When do you expect it to return?
2933  Other / Archival / Re: delete on: September 01, 2011, 01:33:03 AM
You might be correct that varience has a near-zero effect for lower-confirmation transactions, but still remember that shorter block times give less varience.
Shorter block times means the attacker can make more attempts.

So someone with 49% has a near-zero, close enough to zero, chance. The actual probability of getting 7 blocks in a row is less than 0.6% for a 49% holder. The actual probability is smaller, because you aren't rolling an infinite amount of dies.
Think it can't happen? I had to search long and hard to find a real example. I had to go all the way back to...today.

Bitcoin network right now: 12.224 Thash/s
Deepbit network right now: 5282 Gh/s

How many block can deepbit get in a row with 43% hashpower? Blocks 143334 - 143341 are deepbit blocks. Deepbit just solved 8 blocks in a row with only 43% hashpower. I'm sure if someone analyzed the blockchain we'd find even longer runs of deepbit-only blocks.

Variance = someone with <51% can successfully attack the blockchain.
Faster block target speeds = more chances to attack = weaker security.
And? This means deepbit must be CONSTANTLY trying to double-spend. It would be wasting a lot of money doing that! Faster block target speeds = less varience, and more oppertunities also means more money lost for the attacker. It's a waste of time faking blocks - better just fork the blockchain (which is a problem for faster-time blocks, since more natural forks for the attacker to "cancer node" exploit are possible.)
2934  Other / Archival / Re: delete on: September 01, 2011, 12:03:08 AM
You might be correct that varience has a near-zero effect for lower-confirmation transactions, but still remember that shorter block times give less varience. So someone with 49% has a near-zero, close enough to zero, chance. The actual probability of getting 7 blocks in a row is less than 0.6% for a 49% holder. The actual probability is smaller, because you aren't rolling an infinite amount of dies.

Someone computed what the actual odds were. Even for a 60% holder it was a small fraction of a percent. But it wasn't zero for below-51%.

So it isn't that you can't create a longer chain, it's that it's extremely unlikely any attempt to do so would succeed, and even if you have 75% of the power the variance is much higher than I think you're assuming: look at the luck charts of large pools if you want proof of that.
A 60% holder can, however, use a stronger attack - simply fork the entire blockchain. A 49% holder, trying to do that, will not be able to sustain it for long. Varience is higher when difficulty is higher, however, so this is hardly an argument FOR bitcoin.
2935  Other / Archival / Re: delete on: August 31, 2011, 11:55:20 PM
As can 49%, 40%, 20%, etc., they just have zero chance of succeeding.
Fixed it for ya
You seem to misunderstand now cryptocurrencies work. Read over http://en.wikipedia.org/wiki/Variance and come back when you understand it.
Variance has nothing to do with it.  You can't create the longest chain if you have less hashing power than the rest of the network.  It's one of the most basic concepts of the current design of crypto-currencies actually.
*facepalm*
Yeah real useful response thanks.

Here's a more useful one:

Variance means that even with less than 51% of the hashing power you have a chance, albeit a smaller one, to disrupt the chain. For example, a bunch of people freaked out some weeks ago because the Bitcoin chain managed to get... I think it was like 3 blocks in a 10 second period? People also often freak if there's the occasional hour between blocks, but this has happened MANY times without a drop in hashing power.

Think of it this way: Take, say, a d12 for roll playing, and assume you and several players are sitting at a table, and to "win" the game you have to roll a 1. The average chance of you rolling a 1 is going to be 1 in 12, but...

You could roll that 1 result twice in a row, or, you could get 24 rolls in a row... that come up with a different number. In a large enough sample set, with a truly balanced die to roll, it'll just about always be "even" among the different numbers, but if you're looking at just a few rolls in a row...

If you play many games with dice, cards, etc, it only takes a moment of pondering that before you can realize that if you were to roll that die 12 times, it's quite possible for you to _NOT_ get each number exactly one time.

Now imagine the block chain lottery as rolling a die with 115792089237316195423570985008687907853269984665640564039457584007913129639936 sides... (Someone correct me if I'm remembering wrong and it's not a 256 bit hash in use, please.)
You might be correct that varience has a near-zero effect for lower-confirmation transactions, but still remember that shorter block times give less varience. So someone with 49% has a near-zero, close enough to zero, chance. The actual probability of getting 7 blocks in a row is less than 0.6% for a 49% holder. The actual probability is smaller, because you aren't rolling an infinite amount of dies.
2936  Economy / Marketplace / Re: 14 good reasons for bidding "bitcoins.com" on: August 31, 2011, 11:38:26 PM
We'll see soon enough!  "Powered by Mt. Gox"
 - http://bitcoins.com
Mt. Gox was outdone by bitcoin.com: Powered by Tradehill. They're probably facepalming right now.
2937  Other / Archival / Re: delete on: August 31, 2011, 11:32:46 PM
As can 49%, 40%, 20%, etc., they just have zero chance of succeeding.
Fixed it for ya
You seem to misunderstand now cryptocurrencies work. Read over http://en.wikipedia.org/wiki/Variance and come back when you understand it.
Variance has nothing to do with it.  You can't create the longest chain if you have less hashing power than the rest of the network.  It's one of the most basic concepts of the current design of crypto-currencies actually.
*facepalm*
Unfortunately, it's correct that varience has nothing to do with it. In fact, varience is lower with shorter blocks because of the lower difficulty.
2938  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCE] SolidCoin - new and improved block chain. Secure from pools on: August 31, 2011, 08:12:13 PM
Very interesting how the 6 month BTC chart looks very similar to the 6 day SC chart......

did anybody here noticed that?
Yep, see the SC/bitcent parity thread in Speculation. Apparently it's "a faster, edgier coin".
2939  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCE] SolidCoin - new and improved block chain. Secure from pools on: August 31, 2011, 08:03:47 PM
I agree with dree12.

Can anyone explain how merged mining would NOT drop the price down to 0?


The price won't drop to 0 if the coins are useful
So yes you're right, the proce will drop to 0
Bitcoin are also not "useful". If we added 10M bitcoin to the economy today, price WILL drop to zero.
Do you understand the concept of "50 coins per block"? Why are you talking about adding 10M coins??
Merged mining = rapid increase of coins mined until price decreases to near-worthless. This is because to maximize profit, the entire bitcoin network will mine solidcoin until the difficulty reaches 0.3x bitcoin difficulty, when it will balence itself out. This is nowhere near close to happening, and solidcoin will slow down the difficulty increase, which means that you will add in effect more than the size of the current economy.
2940  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCE] SolidCoin - new and improved block chain. Secure from pools on: August 31, 2011, 07:46:04 PM
I agree with dree12.

Can anyone explain how merged mining would NOT drop the price down to 0?

*just opinion and speculation* This would essentially make SC and BTC nearly identical at least to an uneducated consumer as this breaks one of the nicer to see features ie. the difficulty algorithm ... from then on it would be a race for adoption (SC's speed enhancement to transactions gives it a plus here and BTC's current level of adoption gives it a plus here) and once the whole "green address" concept takes off it could hurt SC's speed effect but likely both would add the support but SC probably more natively... since that would then be mostly negated it's a race for pure fiat value.  At the moment (But changes tomorrow with Ruxum) to get SC you have to go through BTC but once they are both trading directly to fiat it will be the one that is more ideal to investors/speculators currently with no major mishaps SC is favorable here, but BTC already has a head start and with a few million less total coins SC has a slight value advantage, but this is negated somewhat because SC users have learned from the BTC mishaps that caused thousands if not more coins to be lost or those really early people who were just "playing" with BTC and have just left dead wallets so that advantage may be somewhat negated as well.

Merged mining between these currencies will likely result in a "battle royale" where one will eventually come out on top plummeting the other to nothingness... SC has the advantages of lessons learned, BTC has the advantages of head start so it could be interesting ... on the flip side if one or the other does not participate in merged mining that one would cease to exist rapidly because I can't see a case where miners wouldn't participate in merged mining to maximize profits among the several cryptocurrencies.
The issue with this is that Bitcoin is not affected, but solidcoin is. It's a one-way path:

I find block that only meets BTC difficulty. I get BTC and SC.
I find block that only meets SC difficulty. I only get SC.
More solidcoin are produced than bitcoin - until SC difficulty * 3.333 becomes higher than BTC difficulty
Then, merged miners would produce 3 times more pure-solidcoin blocks than bitcoin-blocks, and then you have the competition

If price remains constant, before the stablization, 30% more coins will be mined preety much constantly (until solidcoin difficulty becomes comparable to bitcoin difficulty), dropping the price by more and more every day. Solidcoin difficulty adjustment CANNOT keep up with a 30% increase in hashing power until difficulty stablizes, causing supply to grow until price decreases. The time it takes to reach near-zero is dependent on the amount of buyers.
Pages: « 1 ... 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 [147] 148 149 150 151 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!