Let me know what you think.

---BITCOIN SCALING---
-- 1 ABOUT ME--
Martin Clemens Bloch. CEO of BlochsTech and creator of an easy to use Bitcoin smart card hardware wallet.
(www. BlochsTech.com)

-- 2 GOAL--
We want to design a partial node that together with other nodes can do full validation of the chain.
By having many of such 'swarm' nodes the chain will remain secure and duplicated many times.

Because each single swarm node would only store and validate a part of the chain a CRITICAL scaling issue would be solved:
Keeping nodes diverse.

If there are many full nodes, but all of them are big companies it becomes easy for governments to target them.

If there are very few full nodes the network can easily fail.

With small swarm nodes the network could be supported entirely by a little spare capacity on users normal PCs.
Such a network might have a few full nodes, but would not require them and still the entire chain would be duplicated
and validated thousands of times.

Each time the amount of users increased the network would also gain more resources.

-- 3 WHY--
Because if the cost of running a validating node is trivial many many people will do it.

This is not a postulation; all torrent files are shared free of charge by people who are done downloading it
and have every incentive to stop sharing.

However because the cost of sharing a file a few times is trivial they - or enough of the users anyway - keep
sharing.

This is the ONLY true solution. The debates of 1mb vs. 8mb vs. XT are misleading and can never satisfy the demands for price and decentralization at the same time.
Segregated witness does absolutely nothing to solve the issue.

The lightning network is a beautiful idea, and while it has great merit it gives too much power to the payment channel operators. Larger payment channel operators can
pay greater fees than smaller ones which together with a 1mb limit means total centralization.

Bitcoin has only 3 real choices:
1. Do nothing and die/be replaced.
2. Increase the limit and accept centralization towards big miners and big node hosting companies.
This would still be much more decentralized than our central banks so I wouldn't see that as a total failure.
3. Split up validation work among multiple nodes - swarm nodes.

This example goes through how to do the 3 option assuming a standard PC with less than 1mb/s available and 1 million transactions per block - 1600 TX per second.

-- 4 TO BE VALIDATED--
1. Nothing can be withheld from a validated block.
2. Valid scripts and signatures.
3. Correct transaction fee total (coinbase).
4. No double spends.
5. Correct mining reward/mining difficulty (trivial will not discuss).
6. Block size.

-- 5 SOLUTION--
- 5.1 REQUIRED CHANGES-
TXs in blocks should be sorted by their TX hashes. Today the order is random and without any effect.

After sorting a TX hash starting with 000 may be first in the merkle tree leaf index and a hash
starting with FFF last.

This will be needed in order to easily request data from other swarm nodes. (See section 5.7)

Swarm nodes could be made without this change, but it makes data handling easier.

- 5.2 SWARM NODE CHUNKS-
Swarm nodes would break the Bitcoin transactions into chunks based on their index in the block.
For this example we will just say 512. (current block limit corresponds to about 3000 txs)

The block will thus be broken into some number of chunks with exactly 512 TXs each and one last chunk
of 1-512 transactions.

We will go through this example assuming our swarm node validates just one chunk.

Chunk sizes like this would mean we would have 1954 chunk ranges for 1 million TX per block - VISA
levels or 1600 TX/s.

A swarm node would only need 15.6 GB per year to keep up at these levels (see section 6.1).

At even higher volume bigger chunks would be better to reduce connection count, but at that market cap
it would not be a problem if running a swarm node required a single dedicated PC full time.

- 5.3 SWARM NODE SCRIPT RANGES-
In addition to chunks we will also partition data long claim script hashes.
All Bitcoin outputs are in the form of a script, the hashes of all those scripts are unique per script.

Swarm nodes would subscribe to certain ranges. So if hashes could be only 1 or 0 node A might subscribe
to the 0 hashes and node B subscribe to 1 hashes.

If node A sees a 1 hash in its chunk range 0-512 it will send it to B. If B sees a hash 0 in its chunk range
513 to 1024 it will send it to A.
B will give its signature to A that it has sent all 0 hashes - for example by A asking B "Does Tx534 and Tx567
contain all the 0 hashes outs in chunk range 513-1024 for block xyz?" and B signing that + "yes".

It can thus easily be proven later if B withheld data.
How this helps us will become clear later.

- 5.4 NO WITHHOLDING-
Our swarm node gets its chunk from the network as well as a list of the other chunks merkle hashes.

Using this information it can determine:
1. The transactions it received are in the block and that from that chunk nothing is missing.
Otherwise the merkle root would not match.

2. Again if an entire chunk is withheld the merkle root will not match.

In this way if we had 1 million transactions per block this would only mean 62.5 kilobytes of merkle hashes
to validate.

- 5.5 NO WITHOLDING - DISHONEST NODES-
Now while this takes care of our own chunk, the other nodes we connect to could cheat.
Other swarm nodes can do two things:
1. Simply sign an invalid chunk.
2. Withhold TX data that we subscribe to from their chunk.

To limit this risk we rank all the nodes we can find for each chunk range. Each node will have an identity such
as an ECDSA-AES public key over which all communication and chunk signing occurs.

We rank their public keys by the following and in this order:
1. We permanently blacklist* nodes that have signed script ranges that turn out to be invalid.
or that have withheld** TXs from us. Ranking of nodes that have recommended a blacklisted node the
past 2 years is reduced by 95%.
2. Proof of work burn done for that specific key. (top 10 we can connect to)
3. Latency. (top 5)
4. How long we have known that node and gotten messages from it. (top 5)
5. Whether other nodes we trust "recommend" that node. (top 5)
(ie. if someone ran a node on two separate devices they would of course recommend their own nodes)

25 peers for 10^6/512 = 1953 chunk ranges with 2000 bytes of ID data each would be a fixed 100 mb cost.

Before a block would be considered valid the node would require 15 of its 25 peers per chunk to sign off on their
chunk* and at least one peer per peer type group (ie. top history, top burn, top ping and top recommends).

* Blacklisting due to invalid script range would be based on a merkle branch proof showing that a TX is being
double spent and that a node signed its script range as valid.

** Blacklisting due to withholding would be based on a signature by the dishonest node that all information
was shared even though it was not. (Chunk range includes relevant TXs 1, 2 and 3 while dishonest node signed
that 1 and 3 were the only relevant)

- 5.6 BLACKLIST REPORTS-
To validate an error report you would only have to get the offending chunk, ether to check the merkle hashes,
to check for missing data or to check invalid scripts.

To validate a double spend would only require the merkle branch of the earlier spending transaction.

If an error report turns out to be false the false reporter is blacklisted.

Error reports are accepted by the top 95% nodes by hash burn/proof of work.

This prevents cheap DDOS spam while still allowing error reports to quickly propagate through the network
from so much as a single honest node.

- 5.7 VALIDATING SCRIPTS-
To validate scripts we need the output scripts that the containing TX references in its inputs section.

When the referenced outputs are not known to the node it will request those TXs from a node known to process that
chunk range.

Since TXs are sorted by their hashes in the block and since hence each chunk will have a highest hash we can
somewhat easily keep track of which chunk a hash is in.
We do this by maintaining a table of highest chunks per block number (3.3 GB/year).

Using the table and another node we request and get the unknown TX.

If the node refuses to give the data the block validation will simply be delayed. In extreme cases
blacklisting of the withholding node is a possibility.

Once we have all input TXs we can validate the scripts and either sign our script range for the block or reject the block.

- 5.8 VALIDATING BLOCK SIZE -
To validate block sizes nodes check the size of their chunks transactions and signs off on it ie. "chunk 45 1.7 kb signed A".
All the nodes can then quickly count the 1954 sizes add them and see if it is below the limit.

If a node sees different sizes for the same chunk the offending node can be blacklisted after getting the chunk and checking its
size.

- 5.9 VALIDATING TOTAL FEES -
Same mechanism is used as for size in section 5.8.

Total fees are then also compared with the coinbase transaction.

- 5.10 CHECKING FOR DOUBLE SPENDS -
Each node will store a table indexed by script hash containing a list of unspent transaction hashes and spending TX hashes per index.
Ie. a list of tuples ordered by an script hash index.

To save hard disk space nodes will not store the full information about transactions in their script range. Instead they store what is
in their chunk range and ask for all other TX information from other nodes.

Since each swarm node processes a small subset of the blockchain bandwidth is a cheaper resource than disk space and not a big worry.
(A 1 mb/s connection can fill 31 TB of disk in a single year - our swarm nodes use only 15.6GB)

-- 6 NUMBER CRUNCHING--
- 6.1 STORAGE REQUIREMENTS PER YEAR -
These numbers are for 1,000,000 transactions per block and with each swarm node processing 512 transactions
each.
Each node will store exactly 512 transactions from its chunk range and approximately 512 transactions
from its script range per block.

We do NOT store script range TXs, only chunk range. Storing script range data would cost almost 30 gb/yr. Instead we store only a table of TX hashes in our script range
and the TX hashes of their spending transactions.
When needed we fetch the script range from our peers which means extra bandwidth usage. This however is not a problem as our yearly bandwidth usage tracking a small subset
of the blockchain is quite low.

8.9 gb for chunk transactions (avg. 330 bytes/tx * 512 * 6 * 24 * 365).
3.4 gb for spending TX hashes ((32 tx hash + 32 * 3 avg. outputs spending TX hashes) * 512 * 52560 blocks/year script range spending TX hashes.)
(log2(10^6 TXs)*32 = 640 bytes extra per TX in merkle branch information)
3.2 gb for TX hash to block and chunk indexing. (1954 highest chunk hashes in sorted order * 32 bytes per hash * 52560 blocks/year)
~0.1 gb for blacklisting and node reputation information (+~1gb fixed one time cost).

Connection usage will likely be up to 10 times this amount (mostly polling for unknown outputs) so 156 gb per year
or 0.005 mb/s - plenty to spare there.

While the nodes will need many other nodes they need not be connected at all times. Nodes can be notified or
polled at need and then the connection closed again.

In other words a normal PC with a 100$ 1TB HD using negligible broadband could run a swarm node and help run
the Bitcoin network at 1600 TPS for 32(!) years and only use half the disk.

It would only take 1954 of such computers to equate one full node - so a small group of enthusiasts could run the
entire Bitcoin network at VISA levels even if all else failed.

- 6.1 ESTIMATED FULL COPIES AT 1600 TPS -
At such a market cap it would be fair to assume that only a few big companies and miners would be running normal full
nodes while a much larger assortment of smaller companies and individuals would be running swarm nodes.

If there are 2 million bitcoiners today and a resulting 6000 full nodes - that today require about the same as a
swarm node would at 1600 TPS - we can try to extrapolate.
At VISA levels one would expect something like 0,7 billion users and if the ratio holds 0.5-2 million swarm nodes.

At 1600 TPS this would equate 255-1023 full copies of the blockchain hosted in a very diverse, robust and decentralized
way.

-- 7 QUICK SUMMARY--
- 7.1 WHAT SWARM NODES SIGN/VALIDATE -
1. Script validity of script range and chunk range.
2. No withholding claims for chunks.
3. No double spends in script range (based on no withholding signatures by other nodes).
4. Chunk size and total fees.

- 7.2 SWARM NODES ARE DIVIDED BY -
1. Chunk ranges.
2. Script ranges.

- 7.3 HOW TO DO IT -
A first version could be done where all nodes trust each other. This would eliminate the need for blacklists and other code dealing with
trust of peers.

This could then be added later at leisure.

Right now the two cheapest hardware wallets are the Ledger HW1 and the BlochsTech Bitcoin card at 15 and 20 EUR respectively.

However what would you consider cheap? At what price would you get one (either/other)?

Do you think dedicated devices help Bitcoin usability and security or are apps and SMS services the way forward?

It is my pleasure to announce that I have a working Bitcoin card for sale.

It was developed based on a thread on this very forum and now it is a reality.

It is:
- An open source platform/app and protocol.
- Very very user friendly.
- Cheap, 20 EUR.
- Secure for the everyday Bitcoiner.
- The perfect gift for people you want to introduce to using Bitcoin.

You can read more in my FAQ.

Picture time (its not just a graphic the real product is ready for sale, tested and has already shipped to some individuals):




You can get one at my website: BlochsTech.com

Questions are welcome.

If you do a couple of coinjoin transactions and you require that you will be the mixer in one of them, won't your anonymity be perfect?

Normally the mixer would know who was who and you would only have anonymity towards the public - but if you do the mixing only you will know where the money went.

Is this already how it works or would this be an improvement?

[I]

Hi.

I am the "technical speaker" for the Danish Bitcoin Foundation. I am also currently programming my own project directly interfacing with the Bitcoin protocol.

This is my proposed solution to 51% attacks, centralization issues, selfish mining and any such. This simple solution takes care of them all.
Someone could do this very quickly and I am willing to personally pledge 2000$ towards it.

The reason I don't do it is that I'm already swamped with two "public good" Bitcoin projects, a full time job and a family.

Layman's terms
1. Establish a way mining pools can document they made a block - pool IDs.
2. Let individual full nodes add or remove pool IDs to/from a "trust list".
3. A full node will not relay untrusted/unknown blocks  for ~1 hour IF 40% of the past 100 blocks were from unknown/untrusted pool IDs/ +50% from one single trusted ID.
4. A full node will not accept blocks if 99% of past 100 blocks were from unknown/untrusted pool IDs.
(exact percentages do not matter that much)

What it will do
Basically as the network is now it wouldn't do anything. Everything would be fine.

Once ~10% of full nodes upgrade miners would have an incentive to ID their blocks - simply for faster block propagation.

IF the network however came under attack such as:
A Many targeted double spends by a corrupt pool.
B Selfish mining escalation.
C No transactions in blocks.

THEN the solution would elegantly force the attacker to include at least some few blocks that could not be rolled back by the attacker and that contained transactions.
If the attacker DID not allow for other's blocks the attackers blocks would simply be ignored.

Once a "trusted" block was found the attacker can work on that and again make 99 blocks, so this is NOT a white/black list solution.

Ok so there's a catch right? It's a hard fork? Slow? Bullshit extra chains? Exotic crypto? Tatiana coin infusion? (no offense Tatiana)
No, none of the above.
There are literally ZERO drawbacks.

Technical detail
1. The protocol allows for a coinbase transaction script to have arbitrary data.
2. We can use this to let pools sign blocks with an "ID".
3. A pool would sign say the hashes of non coinbase transactions with their ID (w. SECP256k1).
4. Put the signature bytes in the coinbase transaction script.
5. This should be easy to put and read in blocks.
6. Only the pool has the PRIVATE_ID_KEY and the contents of the block are now signed.
7. The ID_PUBKEY can then be used as an ID.
8. No changes in protocol, zip, nada. Just an optional check for certain data.
9. Add the largest 20 pools to the trust list and no one ever has to talk about 51% again.
10. Its totally organic too, anyone can start a new pool and create an ID for themselves. Even botnets are still in, they just can't take over.

What it would really do:
Skeptic: I heard Bitcoin is under attack and will die?
You: Naw that can't happen because miners would then kill the coin and then... bla bla bla incentives... maybe ... bla bla bla and besides tree chains could fix it.... bla bla.
Skeptic: Huh?

--> To this -->

Skeptic: I heard Bitcoin is under attack and will die?
You: Nodes would reject that and kill it because all blocks would come from like the same dude.
Skeptic: Ah ok... is it still a ponzi though?

[However I have some questions I hope someone knows a resource for or the answer to:]

I have poured over the available information I could find such as:

https://en.bitcoin.it/wiki/File:Bitcoin_OpCheckSig_InDetail.png
https://en.bitcoin.it/wiki/Protocol_specification#tx
https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer
https://en.bitcoin.it/wiki/Protocol_specification#Signatures
https://en.bitcoin.it/wiki/Transactions#Pay-to-PubkeyHash

Aswell as mathematical descriptions of how ESDSA works:
http://kakaroto.homelinux.net/2012/01/how-the-ecdsa-algorithm-works/

However I have some questions I hope someone knows a resource for or the answer to:
1. In the linked picture what is "script part 4"?
2. Is it correct that script part 1 is R and S concatenated and compressed with DER encoding?
3. Is script part 2 the pub key?
4. If yes, is the  pubkey also DER encoded?
5. Where is the implied script part 3?
6. Can OP_CODESEPARATOR be left out entirely without invalidating the script?
7. Basically what is the byte-wise format of the claim script, this is my own educated guess:
START: DER(RS){approx. 70 bytes} VARINT_PUBKEY_LENGTH pubkeybytes{32 bytes, x coordinate of Qa} :END

(The out script would not be repeated when claiming, but is seen here:
OP_DUP OP_HASH160 VARINT_PUSH_BYTES PUSHEDBYTES{hash160 of Qa/address} OP_EQUALVERIFY OP_CHECKSIG )


A good exact and in-depth explanation of DER encoding would also be nice.

What I mean exactly is that right now Bitcoin has 8 decimals going from 1 bitcoins to 1 satoshis or 0.000 0001 bitcoins.

In the future especially, for nano-payments between automatic software using payment tunnels, we will likely add more decimals.

My question is: If a client or device made a mistake today and say sent 0.1 satoshis (assuming this was NOT treated as dust/ignored) which would happen:
(or more realistic maybe: 1.000 0000 1 btc)

1. TX is invalid and simply ignored/could NEVER be in a valid block?
2. TX is valid, amount below satoshis/"rounding error" becomes a miners fee?
3. Amount is lost, goes through as a 0 btc TX (or 1.000 0000 in realistic example).
4. Something else?

Thanks in advance.

Why:
I'm programming a device, similar to say a Trezor, that cannot be reprogrammed later and cannot access the internet on its own.
The device could trust information about decimal places from an untrusted source, but I am just wondering if this could backfire.

Does anyone know of something like Bitaddress.org, but for AES?

I want to be able to download it as a HTML file and put it on my offline "Bitcoin banking computer".

It should encode, decode and take input and a key (so I can encode private keys).


I am immensely inspired by the fact that SO FAR DPR has been in FBI custody for months and had had all his possessions confiscated and STILL they don't have his money.
That is so fucking powerful.

Im already safe against hacking and theft (I think) but if I could be safe from the police too...

EDIT: I found this - http://lazarsoft.info/crypter.html
And it seems to work as I want, but I can't seem to get any of the online AES tools to actually work together, they all give different results from the same key/input.

So the way I understand it so far MasterCoin was created by sending BTC to a certain address:
https://blockchain.info/address/1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P

Using Mastercoin also involves sending (a small amount of) BTC to this address.

A KEY feature seems to be that in this way the core developers are well funded and can expand the MasterCoin software ecosystem.


... sooo if a hacker gets this ONE exodus address won't mastercoins be worthless in sort time?

1. Bitcoin is a currency, payment network and a protocol.
2. Stealing bitcoins is theft of property.
3. Accepting bitcoins and not in any way delivering the agreed service is fraud and/or theft.
4. Much as losses due to fiat inflation are not tax-deductible, Bitcoin gains shall be tax-exempt.
5. Using or running Bitcoin mixing services is a privacy feature of Bitcoin and shall not be regarded as money laundering as there could be legal reasons for participating in such.
6. Using Bitcoin for activities illegal in a country shall remain illegal, but using Bitcoin itself shall not be considered illegal.
7. Bitcoins belonging to foreign citizens shall not be illicitly confiscated under local laws, but returned to the jurisdiction of the owners or to the owners themselves.
8. If a service is in some way storing customers bitcoins, they shall loudly declare that the customers funds are trusted with them completely - unless the company documents it has the funds claimed with for example a public company account or government approval.
9. Customer funds stored by a Bitcoin related service shall belong to the depositing customers before any other creditors - unless otherwise clearly agreed to by the customer.


... not a snowballs chance in hell

http://www.youtube.com/watch?v=EtKCDFPYXbs

So first many months ago I upload my passport and a phone bill. They deny that because the bill is electronic, so I just went within their limits.

Ok, but NOW they wont let me withdraw ANY money at all, so I sent my payslip addressed to my name and scanned in physical form and I have had no answer even acknowledging they received something.

Horrible service and I am seriously considering paying more at localbitcoins or anything else next time - then at least my money is not locked forever.

How are these guys so much better than MtGox again?

So for those who thinks this is a stupid question: The normal address format for Bitcoin addresses puts a hash/checksum of the hashed public key at the end - this means you can tell if someone say mistyped their address as the checksum will not fit.

My question is can you send money to an address with an invalid checksum? (as in will the main Bitcoin clients allow such blocks, relay the TXs and so on)

If it IS possible my second question is why?
.. and my third is which clients and online exchanges are known to check the checksum?

It seems to want 2 args for the importprivkey function, functions are given as func(arg0,arg1...) and the old import command is gone.
I think the 2 args are wallet-name and the key in some format in that order... but where do I find the wallet name?

Mostly for Danish people, but: We now have a Danish Bitcoin Foundation.

https://bitcointalk.org/index.php?topic=281021.0
http://www.danskbitcoinforening.dk/

Hej allesammen.

Så går vi officielt i luften - Dansk Bitcoin Forening er nu en realitet:
www.danskbitcoinforening.dk
eller nemmere:  
www.Bitcoin.dk
Facebook-side:
https://www.facebook.com/groups/369428839849165/

Vores formål er at tilføre værdi til Danmark gennem Bitcoin. Vi mener at Bitcoin er fremtidens betalingsmiddel og vi vil derfor hjælpe danskerne med at lære om Bitcoin, mødes om Bitcoin og bruge Bitcoin.

De personer, der allerede har hørt om os har taget super godt imod os - hvilket de skal have tak for - men vi vil virkelig gerne høre jeres andres ideer til, hvad vi skal lave også.

Vi er ikke ligesom DATA der prøver at fremstå som en autoritet over Bitcoin eller The Bitcoin Foundation, der har taget store beløb for medlemsskab og brugt dem på lobbyister.

Helt konkret vil vi hjælpe med at arrangere meetups, open source arbejde, vejlede og/eller anbefale nystartede Bitcoin firmaer samt informere danskerne om Bitcoin.

Hvad forventer I jer af Dansk Bitcoin Forening?

[2200$]

I need a smart card terminal application for Android.

There are four more or less independent tasks in this:

- Use NFC from Android application to communicate +
- Get the BasicCard java lib to work on android and use the NFC code to communicate with a basic card smart card from ZC. 2200$
- Interface with Electrum and send TX data. 0$
- Interface with Electrum and get TX data for the card to later sign in specified format. 0$

In addition to the monetary award you are allowed to do what ever you want with the code including releasing your own terminal program for your own profit.

Requirements:
- I must get all the code including rights to do as I please with it.
- You get paid the specified amount once a task is done.  
- You must let me know before you start, I don't want to pay 5 different people for the same work.

If you are interested let me know what task you will be working on as I am also looking for interested parties elsewhere. Also I have more detailed information about each task and files I can give you.

Contact me by email or forum PM:
Realpra1@hotmail.com

I loved the story: "Bitcoin saves the people"

.. but it just doesn't match the realities:

1. Argentina has less node activity than New Zealand and is about as bad as Africa and the rest of South America.
2. Of the 5 largest transactions I checked none were from Argentina.
3. Argentina has 25-50% the transactions it should have to match the US in txs per capita and about the same as some countries 5-6 times smaller.

Now my theory is this:
Those countries that need Bitcoin the MOST will get it the LATEST.
I think this is the same as a kid falling behind in the school: Even if a new better teacher comes along the student is so far behind it handicaps him in following the improved teaching and he gains the least.

Same with Argentina; they have bad government and banking which makes them poor and have bad computer/internet coverage (66% compared to 97% of say Denmark) - which combined makes it difficult to learn about, buy and use Bitcoin.


Already based on the stats we have now I think we can say that by and large the "Western world" holds and will hold for a time the vast majority of all Bitcoin - even though their financial systems are superior and cheaper compared to the rest of the worlds.

With a lot of second wave investors being big shots like the Winkelwoss twins, I think we can also say that Bitcoin will not lead to a major redistribution of wealth in terms of type of and location of the people holding the wealth.

[actually works]

People say, including one of my close friends, that Bitcoin will never be used and accepted by normal people and businesses if it is illegal.

Well that might be true enough, but consider this: What would the value of Bitcoin be if it was used "only" by everyone sick of the current system in the world? If it was "only" used by small to medium sized pioneering businesses in the world?

I think more than 1 billion $ market cap would be a safe bet.


This is when you must realize that all this regulation stuff is going to fall flat on its face. Sure price will dip in coming months, maybe like in 2011 down to around 30$ (twice the pre-run-up value as in 2011 where it was 1->2$ ignoring the bubble in between). Maybe some people will even become very pessimistic about Bitcoin as after 2011.

But then (~1. Jan 2014) something is going to happen:
1. People will realize how easy it is to exchange Bitcoins. We will have more sellers on sites like localbitcoins and new smaller exchanges.
2. If need be, how easy it is to hide - send to a few addresses and even without coin-mixing a long trial would be necessary to link you to all those transactions - on larger scale making regulation unenforceable.
3. That regulation is not doom - big players will do it, normal people will ignore it and some areas or countries will have none.

(Think about it; today it actually works when a company says "Golly gee all my profit was on the Cayman isles, no tax for you!" a near childish lie - what chance do they have with Bitcoin?)


After this stage (~1. Jan 2015), with the new BTC products and software also out by then making things easy, Bitcoin will reach mainstream at least one or two places in the world (new bubble anyway) (some would say it already has in Kreutzberg and Argentina).

In ~2017 Bitcoin will be boring and simply another money we use (though not the only one) - even a small country jumping on the wagon will not be enough to see those x10 price spikes any more.

Saw it in the train today, maybe 200.000 other Danish as well.

Mostly about Silk Road, but mentioned Bitcoin 3 times, mostly as "100% untraceable" and what you pay with on SR.