Search content
Sort by

Showing 4 of 4 results by synctext
Post
Topic
Board Bitcoin Discussion
Re: Why is it so hard to regulate Bitcoin?
by
synctext
on 25/06/2014, 20:13:12 UTC
There seems to be only two options: 1) allow bitcoin complete freedom 2) make it illegal to accept bitcoin as payment. The second option seems more likely at the moment, be the first is still possible
I think that the option 3) is also possible. The bitcoin will stay as a "parallel" currency "as it is" but with the certain regulation/limitation of its use. Like it is already in some countries, where bitcoin payments are acceptabile in parallel with other currencies and is used by the companies with a solid reputation.

Indeed, Bitcoin is most likely parallel currency for a while.

I'm one of the authors of the paper mentioned in that Wired article (http://arxiv.org/abs/1406.5440).
Clearly the Bitcoin community rejected our proposal, it took even 9 hours for my pull request to be closed.

That's fine, I love Bitcoin. The key question is now how could millions of normal people start getting into Bitcoin?
Bitcoin ATM machine's legal in EU and US require photo-ID registration.
So #2, Bitcoin without a photo ID registration is illegal today in EU+US.

Option #3 means only tech savy people will get into it. It poses insurmountably high barriers for large-scale uptake.
Post
Topic
Board Development & Technical Discussion
Re: implementation of a redlisting mechanism
by
synctext
on 25/06/2014, 15:53:45 UTC
Won't this just force users to start using P2SH instead of addresses?
You are very correct; that should be considered future work... For this initial implementation we focused on addresses.
Post
Topic
Board Development & Technical Discussion
Re: implementation of a redlisting mechanism
by
synctext
on 25/06/2014, 14:55:37 UTC
Who is the ultimate authority that manages what is redlisted? Since Bitcoin is a consensus network if everyone isn't using the same redlist it will lead to many forks.
That is decided by the majority. Every miner can select what to redlist.
This is thus a very generic mechanism, where countries could issue redlists and miners can opt to follow them (or not).
If there is no consensus the majority simply wins. Forks are short lived, limited by the Switching threshold.
This proposed mechanism is designed to give up if it sees that it is creating a fork after, for instance, 3 rounds.

This has gotten some initial press coverage, with more details:
http://www.wired.co.uk/news/archive/2014-06/25/regulating-bitcoin
Post
Topic
Board Development & Technical Discussion
Topic OP
implementation of a redlisting mechanism
by
synctext
on 25/06/2014, 11:03:59 UTC
We created the first implementation of a fully decentralised redlisting mechanism:
https://github.com/bitcoin/bitcoin/pull/4412

We would love to hear your opinion on this. (We are obviously aware of the design ideas of Mr Hearn)


Full documentation of the redlist mechanism: http://arxiv.org/abs/1406.5440

The implementation 1 is split into several parts:
1) retrieval, updating and building of the redlist in memory
2) checking of new transactions by the miner against the redlist, to prevent them from ending up in a block.
Because the redlist is implemented as a hashset, the amortized runtime for this check is O(1). If it sees a transaction that contains redlisted keys it simply does not process it into a block.
3) checking of new blocks against the redlist and forking the blockchain if necessary to keep the blockchain clean

Switching threshold
This code identifies transactions that are tainted. It also gives up after a given threshold. This architecture maintains the Bitcoin principle that the past cannot be undone. If it will find itself in the situation in which the non-redlisted branch is too far ahead with regard to the current tip (the branch height difference has surpassed the switching threshold). It will have no other choice but to give up its effort to uphold the redlist.

End-to-End System Test
See here for the private, difficulty 1 testnet in a box. https://github.com/DistributedRegulation/testnet
The master branch is meant for bitcoind v0.8.0. Check the tags for other bitcoind versions (You must have bitcoind installed on your system and in the path).
The purpose of our tests is to verify both the correctness of our redlisting mechanism and the branching behaviour of a network populated by both the reference and the redlist version of the Bitcoin client. The test consists of a sequence of 5 steps, each involving the mining of a block containing a single transaction. In this environment, nodes W and R are the only miners, while A and B are simply used as transaction endpoints.

There are many outspoken opponents of redlisting in the Bitcoin community. They present a few important arguments against the introduction of redlisting:
• it introduces a central component, namely the regulatory organ, into the decentralized nature of the Bitcoin system.
• redlisting (or tainting) coins would be subject to abuse.
• tying a public key to an individual is technically impossible, making redlisting tricky.
We recognize all of these problems. However, we are of opinion that none of these arguments are strong enough to reject redlisting as a regulatory measure.

We will not further pursue this matter. We regret not having the time to further make enhancements to this pull request. Please pick this up if you want. The code is yours now and do with it as you please. Delft University of Technology gives the Bitcoin community full usage of this open source contribution. We hope the cryptocurrency dream comes true. -peace j