We don't use IRC anymore— not by default, you can manually enable it but it's off because:

*It didn't work well, most nodes it gave you were not listening
*It was a point of substantial centralization (easily shut down; operators of a single obscure network IRC could manipulate it)
*It degraded node's privacy— it announced the IPs of the majority of nodes that were not listening and thus didn't need to be made so public.
*It was frequently confused for a Botnet and was blocked by major providers several times, and resulted in nasty "you're infected" notices sent to users on a few ISPs.


In addition to dnsseeds, Bitcoin nodes have always remembered past nodes they've learned about over the network (it used to remember _all_, but thats a DOS vulnerability— now it maintains a large but finite set in a specially randomized way that makes it attack resistant).  You can also drop a textfile in the bitcoin data director "addr.txt" with a list of nodes to use, or provide nodes with the --addnode command line. There is also a hardcoded set of fallback addresses (which are updated every few releases) which it will use if all other means fail.

I don't consider this the biggest vulnerability.


Bittorrent is nowhere near 50% of internet Bandwidth anymore (Figures range from about 8%-18% and declining, depending on who you asked and what timespan their data covers). It's frequently shaped by a fair number of ISPs and there are a number companies that specialize in selling tools to manipulate bittorrent traffic.    Bitcoin would be be even worse off: The network itself is highly public and there is only one network... so you'd simply start one Bitcoin node to enumerate all the other publicly available ones.   These attacks can be resisted— see the tor bridges arms race for an example—  but it's better to let the experts in that area handle that for us and take advantage of our common needs.  Bitcoin is very tor compatible, its a good mix.

Sure you could embed Bitcoin stenography— but you'd lose the additional privacy and effort sharing that comes from sharing with groups like Tor who already work hard to get around censorship.

In Bitcoin everyone broadcasts everything which is valid.  It uses a lightweight inventory exchange to avoid sending a bunch of data redundantly. This is part of how Bitcoin, as Satoshi wrote, "takes advantage of the nature of information being easy to spread but hard to stifle". The fact that everyone passes on all the good information makes it so someone can't disrupt the system with a few misbehaving nodes.

Well why not—  if you abandon a privileged position, a reasonable thing to abandon if you're stipulating _decenteralized_, it's makes perfectly reasonable example.  If you use things like finite processing speed as examples as to why attack resistant decentralized autonomous agreement isn't possible people will just argue what IFs involving faster computers and other such spherical bovine.   Going to a more fundamental argument, even if its totally wanky makes it clear that the goal is really autonomy but its simply not achievable, and so we instead take majority ordering with eventual consistency.


I can't believe it. I completely agree with a statement of yours. I'm flabbergasted.

No it can't "be done".  You're misunderstanding what fork means in this context.  It's an independent universe.    For example, you could create a FuzzyCoin which has 84 million coins and blocks every 2.5 minutes— you could even copy the history of Bitcoin into it, so that anyone who was holding bitcoins when fuzzycoin started would be holding the same amount of FuzzyCoins.  ...  but none of the Bitcoin users/clients would know you existed.   This is what a true fork is.

And of course you can do that. Nothing can prevent you from creating an independent system.... but the Bitcoin system will not talk to your system unless your system is exactly the same rules as Bitcoin (thus being the same system), and it doesn't matter how many miners you have.

You misunderstood.

Bitcoin is not a democracy. Bitcoin is a zero trust system. Each full node is autonomous, it validates the entirety of the rules on its own— trusting only its source code (which you or anyone else can audit).  Only through autonomy can you have independence and the assurance that the majority of wolves won't vote to have you for supper.

Unfortunately, to resolve to double spending a digital cash system must have a way of agreeing what order the transactions happened in.  Its is not possible to have a decentralized antonymous system where everyone agrees on the same order of events— because the apparent temporal ordering of events depends on the relative position of the events and the observers in space— this is a consequence of relativity.  So before Bitcoin many people believed that this sort of system was fundamentally impossible.

Bitcoin solves the fundamental impossibility by relaxing the autonomy by the minimum amount necessary:  We use a majority of computational power to decide on the ordering of transactions.  But _ONLY_ the ordering. Nothing else. That one compromise makes all the rest possible.

Of course, controlling the ordering of transactions is a powerful thing— because a transactions validity depends on its order relative to possible conflicting transactions penned by the same author.   This is why it's important that the majority of the Bitcoin computing power is well distributed,  that we don't let it consolidate into the hands of a few service providers (like mining pools or exchanges).  The use of computing power makes the the system not only resistant to attack, but it makes the attacks have a clear and fairly consistent real monetary cost— so people can reason about the risks, and the economics of the system make it so that it should hopefully be more profitable to cooperate than to attack it.

The state currencies of democratic nations is theoretically democratic money, unhappiness of the current state of affairs is part of the motivation behind Bitcoin. Democracy is not a good method of making decisions— it's often just the least bad option.  But Bitcoin is something stronger than democracy, ... though not quite as strong as the laws of nature.

Of course— the rules of the system can be changed, but it requires basically everyone to agree to the change because the old system and change system won't talk to each other, it's basically like replacing Bitcoin with something else.   This has actually happened, for example, there was once a bug in the rules of the system where the values of transactions could overflow and someone exploited the bug to create a billion bitcoins for himself.  People noticed this right away and published a fixed version of bitcoin which rejected the block containing that transaction and all blocks after it... and everyone applied the fix, because it was obviously in everyone's interest except the attacker's, and life went on.

But if people are afraid of e.g. the supply of Bitcoin being changed they really shouldn't be.  Yes, almost all the Bitcoin users could switch to some fork of bitcoin that had different rules— but with the same effort they could just switch to paypal.  There is always the risk that someone will use something else. But Bitcoin itself isn't subject to petty majority rule.


(I wrote basically the same thing at https://bitcointalk.org/index.php?topic=61922.msg723476#msg723476  too ... couldn't find it at first because the only quote I could think of from it is all over the internet now )

Then I arrange a bunch of transactions under that key and unbalance your tree. Updates become O(N). Yuck.   (And bumping zombie threads? double yuck!)

Technical attacks are the ones you should lose the least sleep over.   Attacking Bitcoin by making it unlawful and thus driving it underground, thus making it mostly worthless (as even outlaws have little use for outlaw money) is a prerequisite for that kind of technical attack...   If the technical attacks come without the legal attacks then lawsuits— by all the people harmed by the conspicuous unlawful attacks on the computer system their businesses depend on— will fly and be successful.

The kind of conspicuous resource expenditure bitcoin's Proof-Of-Work system requires for security means that outlawing Bitcoin would be rather devastating.  The solution to this risk is to grow Bitcoin. If many people use it and like it and recognize it as legitimate it will not be possible to outlaw it it— at least in the more free parts of the world.

That said—  the Bitcoin protocol itself is utterly trivial to block.  But it doesn't have to be hard to block: It runs fine over tor and the tor support is improving all the time.  Tor itself is becoming harder to block, and blocking tor has collateral damage.   The Bitcoin developers currently have the view that anti-blocking is not a goal for us, we'd rather leave that to the experts working with Tor but fortunately we benefit from their efforts too.

Will the next person who gets stuck please get in touch with me via PM.  Peter thinks he fixed a dangling get stuck bug (https://github.com/bitcoin/bitcoin/pull/1196), but unfortunately its hard to reproduce the problem.   If you could cleanly shut down and make a copy of your bitcoin director then we could give you a fixed binary to test.

Can you bring up the about dialog and tell us exactly what version it shows?

The network is almost a randomly wired graphs. Nodes make 8 outbound connections (unless modified, a few people run modified nodes). Nodes will take up to 125 connections by default (unless the user has configured it otherwise). Nodes will not make outbound connections to two hosts with addresses in the same /16 (in order to make it harder to DOS attack by spinning up large numbers of nodes from a single network, though this is fairly weak protection).

Only a small fraction of nodes accept inbound connections, though it's impossible to know the exact fraction as non-listening nodes are invisible unless one happens to connect to you. (Of course, they still relay data between the listening nodes they connect to)

(And FWIW, I believe the figures on http://bitcoinstatus.rowit.co.uk/  are not especially accurate— but at least they're something)

The amount of time it takes to broadcast a block depends on how long the node takes to validate it, so its hardware dependent.  The logs on my nodes indicate that it's deeply subsecond, but I don't have high enough time resolution to tell you more than that.  Obvious network latency gets added on top of validation, but since a significant portion of the nodes are clustered in Europe and the Americas there isn't a ton of additional network latency.

Miners always attempt to extend the first received longest chain. If another chain becomes longer they'll attempt to extend it instead.  Your use of the word 'abort' concerns me: Mining is memoryless, each attempt is independent.

From this information and a few guesses about the things we can't answer you could arrive at some figures for your questions.

You are confusing this thread with your thread. Is this confusion intentional?

What you're talking about is getting people to replace their Bitcoin software with software the validates some other rules.  This is totally orthogonal to attacks involving large amounts of hash power.


They have _all_ been 'beneficial' to their users in that by participating in them you're one of a much smaller set of miners, and thus getting a far larger percentage of the total produced coin than in Bitcoin. This is more extreme in some chains than others— for example LQC had block rewards starting at 1000 coins and then  dropping 4% every 1000 blocks or so, while Litecoin has payout's much more similar to Bitcoin but a single person could pretty easily be 1% of litecoin's total hashrate.



I have intentionally not responded to your thread because other clueful people have responded and you just keep continuing the boring debate. Please don't spread it to other threads.

Thanks for providing (2).  You did not provide that before.  The attack you're suggesting doesn't work.

Difficulty adjustments require 2016 blocks and can only change the difficulty by a factor of 4 per cycle of 2016 blocks.  Your DOS attack, if effective, would slow down block creation while in effect but it would not substantially change the computational power required to rewrite any of the existing chain.

(It's perhaps also worth pointing out that pools are constantly under DOS attack— and many have have been successful DOSed before without much impact, most miners now autoswitch to backup pools... — and the rise of p2pool closes that particular issue ::shrugs:: )

What mission. You need to speak completely and concretely. Give the series of steps that will be performed and what the harms or profits are.

Otherwise you're just waving your arms, spreading FUD, and really just forcing the people trying to correct your FUD to spend the time inventing hypothetical attacks which you might mean but haven't even invested enough time or thought into to come up on your own.

Anonymity and privacy are two different but somewhat related things.   Banks are very private in a conventional sense.  Bitcoin (and MAVEPAY as described) can not have that kind of privacy— but what bitcoin does is uses weak pseudo-anonymity to provide the privacy that was lost.

This is fairly effective—  although it's not strong enough by itself to hide my activities from concerted attackers it can successfully prevent awkward questions from snoopy inlaws who are angry about you buying contraception when they want grandchildren— and in Bitcoin as as designed it's largely free, and the account level historical summarization that the related design precludes could only shrink the stored data by some constant factor.

I don't particularly think that anonymity is all that important a property, but I think that privacy certainly is — perhaps you can come up with some clever way to regain some privacy in your system.

Greetings.

So you want to make some money?

Well— people on IRC have been circulating links to https://ragecoin.appspot.com/  (there is also a thread here about it: https://bitcointalk.org/index.php?topic=63081.0 )

The site has two substantial security vulnerabilities.  One potentially in the sites favor, one in the users favor.

The site is totally anonymously run, so I can't report the vulnerabilities to the site: Their loss, your gain. My IRC logs strongly indicate that the site run by "Joric" but he outright denies this.  I also reported the vulnerabilities to him but he's clueless and just argued with me. Then again, he also denies running another site which I think mostly exists to part fools and their money (brainwallet) and which I have pretty much conclusive proof that he runs.  Danger will Robinson Danger.

In any case here we go:

The site sends you a cryptographic commitment to the next spin... E.g.  it tells you "57b12eb121a742b1cd0454408d1b38ec"  then you deposit funds and spin .... then it tells you MD5("0,1,0:W6Wv4t3x")  with the 0,1,0 being the slot positions you just got, and you can then see that this matches the commitment so that the site didn't change what it was going to spin for you based on your deposits.

There are two problems with this, first the one potentially against your favor:  The site is doing nothing to prove that its RNG used to come up with the spins is fair.  E.g. it may be the case that it will _never_ produce results with big winnings, thus giving lower payout than advertised and screwing over the player.    This could trivially be avoided using the pick-and-split cryptography I came up with for bitjack21: The server commits to a random value,  the user provides a random value (by default based on JS RNG, but modifiable)— the draw is based on the hash of the committed random (not the commitment itself) and the user random.  Thus proving that the site's RNG is unbiased.

The next is the one is in your favor, or at least in the favor of hackers with gpu farms:   The secret salt values, the part after the : in the value its committing to, only have log2(62^8) = 47 bits of entropy.   You could construct a rainbow table of all values that start with 0,0,0:.  Then you keep spinning until it gives you a "next hash" which is in your table. You know that hand will give you a 256x winning.  Bet like hell on that one.    If you want you can build a larger table that has additional winning combinations in it so you don't have to respin as much. Alternatively, you don't even have to cover all the 0,0,0 values... even a 'small' table will let you win if you don't mind spinning a whole bunch of times.

Building a table for all values for a single spin result is the same computational complexity as building an md5 rainbow table for 8character passwords from the A-Za-z0-9 set, and many such tables (and larger) already exist... so the computational work is high, but totally doable.   If anyone does this… I want a cut of your winnings. (PM for deposit address, thanks!)

(Also, since you don't need to know the full preimage of the hash you could save a ton of space with some small chance of incorrect results by simply using a very large bloom filter: Figuring out the size needed in order to maximize profitability is an exercise left for the reader)

Keep in mind that this is a glaringly obvious vulnerability.  The operator of the site may have expected someone to figure this out, build the table, then drop 1000 BTC on a 0,0,0 win, and if you do that they may just vanish with the funds.   A lot of scams are powered by making you think you're the one scamming them.


In any case, enjoy and keep safe!


Edit: I dropped this in the speculation subforum because while gambing may be gambling, compromising a gambling site is a lot more like speculation than a lot of things people here consider speculation plus the site I'm talking about was previously discussed in this forum. Another cute thing: my vanity address probably took more computation than rainbow table for a single slot value would take.

The paper would be a lot more readable if it didn't constantly make factually incorrect statements about Bitcoin, it makes it somewhat irritating to read.

Some examples,  (though there are a great many— I think, in fact, the majority of the comments about the bitcoin system are arguably incorrect or misleading— including things as simple and factual as transaction sizes)


This is incorrect, and you could have verified in just a couple minutes that an overwhelming super-majority of transactions pay _no fee at all_ right now.

Though fees are one mechanism bitcoin uses for anti-dos— resulting in a _reusable proof of work_ system which is arguably superior to any one-shot POW system, at least so long as mining is creating substantial amounts of coin,  Bitcoin also uses coin-immobility-time as an anti-dos mechanism— and the effectiveness of this is why most txn don't carry fees.


I'm not even sure how you're making this error.  It simply isn't true.  Transactions must spend a previously existing transaction, and they exhaust it in the process thus making duplicates of that transaction invalid. Nodes do remember transactions they've already forwarded to peers to avoid excessive rapid retransmission, but there is no protocol requirement of this and the storage is purely in memory not eternal.

Perhaps it would be better in the future to describe your system without constant incorrect references to the Bitcoin system.

[I don't mean to be entirely negative—  the PoW-Chain-staggered-commitments as signatures is quite clever.  I'm not convinced as to it's use in currency systems, especially since ecdsa signatures (esp with the proper curve selected and bulk validation) are not that much slower, nor are lamport signatures that much bigger... but it's still a neat idea]

You are entering the wrong password.   There was (now fixed in GIT but not in any released version) a somewhat tricky bug where a small fraction of incorrect passwords caused a crash rather than the wrong password notice.

The log message of "secret must be 32 bytes" is a very strong and clear indication of this.

Unfortunately this behavior seems to convince the afflicted user that they actually have the right password, making it unlikely that they'll keep trying and get the right not.

Here is the related pull request: https://github.com/bitcoin/bitcoin/pull/1039

It's enormously less hacky.   It doesn't waste coins, it doesn't increase the size of the blockchain ... not by one byte... even if it were committing to trillions of documents per minute.   So it can actually scale to be widely used, if it did so it wouldn't risk breaking bitcoin in the process.

But I do know the generation scheme:  Ask a human to generate a secure password.

This is something humans are not good at and so they are prone to doing things like ... picking passwords with a repeated character (or, alternatively completely avoiding repeated characters). For example, here are some of the cracked mtgox passwords (all except the Us were using the more secure freebsd crypt scheme): uuuuuuuuu, ggggggggggg, 999999999q, qqqqqq123, 111111111a, 999999999, 88888888, 99999999.

Uniformly probable uncertain length between 1-33 adds only 5 bits of entropy to the repeated character model.   Meaning that if you're already doing "every character repeated" (which is obviously a useful model which cracking tools already include) searching all of those lengths only increases your workfactor by 32.

I agree too—

Though I would point out here that at some point in the future we may find that we need to upgrade cryptosystems for security reasons... and that if we don't _eventually_ deny the spending of coins sent to the old insecure system then we could well find that enormous deposits of zombie coins suddenly appear due to cracking and that their rapid unexpected introduction into the economy is very much not what anyone signed up for and could be disruptive.   So it would make sense to sunset insecure transactions.

Someone arguing for regular long-horizon sun-setting, instead of just a one time event, might have a lot more success arguing it at that time.  In particular, it would be much less bad if you know _in advance_ that you will have to heart beat your coins once a decade, then it would be to find out later that cryptosystem breaks mean you'll have to do it.