Gaffe quand même à la technique de la lamproie 

Hi Sundance,

Very interesting paper !
I'm quite impressed by the effort done to formalize the idea in a clear and understandable manner. I'll need to read the paper again to be sure that I get it right, but I've started to play with the model, to check how much the final result is sensitive to the underlying primitive.
Note: I didn't sleep a lot last night, thus my maths and my logic could be a bit random today. I apologize in advance if there's some mistakes in what follows.

I tend to think that the notion of entropy already used by gmaxwell and andytoshi is quite handy to quantify the quality of a given tx in term of privacy. So I've used that measure.

Notations

C(tx) = number of possible combinations to link the txins and txouts of a tx

H(tx) = Entropy of the tx. We consider that all combinations have same probability (attacker has no additional information) thus we have H(tx) = log C(tx)

({vin_1,...,vin_n}, {vout_1,...,vout_m}) = transaction with n txins and m txouts where vin_i is the value of the ith txin and vout_j is the value jth txout

Case studied : the first example from your paper (inputs = [1, 2, 3]) with Coinjoin used as underlying primitive.

Hypothesis : the values of the inputs are the amounts proposed by the players but could correspond to several txos per player (which helps to increase entropy).

Scenario 1: BCM + 2 coinjoins
tx1 = ( {2,2}, {2,2} )
tx2 = ( {1,1}, {1,1} )

C(tx1) = 2   
=> H(tx1) = 1 bit
C(tx2) = 2   
=> H(tx2) = 1 bit
H(tx1 + tx2) = 2 bits

Scenario 2 : BCM + 2 coinjoins
tx3 = ( {2,2}, {1,1,1,1} )
tx4 = ( {1,1}, {1,1} )

C(tx3) = 6 * 1 = 6   
=> H(tx3) = 2.585 bits
C(tx4) = 2
=> H(tx4) = 1 bit
H(tx3 + tx4) = 3.585 bits

Scenario 3 : Naive coinjoin => A unique coinjoin with same vins and vouts as Scenario 2
tx5 = ( {1,1,2,2}, {1,1,1,1,1,1} )
C(tx5) = 6 * 5 * (4! / (2! * 2!)) = 180      
=> H(tx5) = 7.491 bits

We have a ratio H(tx3 + tx4) / H(tx5) = 47.85%
Let's try another scenario and check if we can get better results.

Scenario 4 : BCM + 2 coinjoins
tx6 = ( {1,1,1,1}, {1,1,1,1} )
tx7 = ( {1,1}, {1,1} )

C(tx6) = 4 * 3 * 2 = 24
=> H(tx6) = 4.584 bits
C(tx7) = 2
=> H(tx7) = 1 bit
H(tx6 + tx7) = 5.584 bits

Scenario 5 : Naive coinjoin => A unique coinjoin with same vins and vouts as Scenario 4
tx8 = ( {1,1,1,1,1,1}, {1,1,1,1,1,1} )
C(tx8) = 6 * 5 * 4 * 3 * 2 = 720   
=> H(tx8) = 9.491 bits

We have a ratio H(tx6 + tx7) / H(tx8) = 58.83%

I think scenario 4 is the best we can get with 2 txs. An easy solution to increase entropy would be to chain another round of coinjoins txs after the first ones. I think it would be enough to get an entropy higher than the naive coinjoin.

Now, the interesting point would be to check how it compares in term of efficiency with TierNolan Atomic cross chain which would produce very different patterns in the blockchain.

Don't know if it makes sense. Sorry if it's not the case. Anyway, keep up the good work !


EDIT:
Previous computations of combinations/entropy just try to match 1 input with 1 or n outputs.
But I guess it would be more correct to also consider input aggregates as possible combinations.
This is required if you want to make sense of txs like ( {1,1}, {1.2, 0.8} ) => C(tx)=1 and H(tx)=0

Under this form, we should have something like:
Scenario 1
C(tx1) = 3 and H(tx1) = 1.585 bit
C(tx2) = 3 and H(tx2) = 1.585 bit
H(tx1 + tx2) = 3.17 bits

Scenario 2
C(tx3) = 7 and H(tx3) = 2.807 bits
C(tx4) = 3 and H(tx4) = 1.585 bit
H(tx3 + tx4) = 4.392 bits

Scenario 3
C(tx5) = 687 and => H(tx5) = 9.424 bits (if my computations are ok)

H(tx3 + tx4) / H(tx5) = 46.6%

I'm too lazy too compute the last scenarios by hand but that form seems to confirm the first results.

Hi there,

I've just pushed a new version (r0.0.3) of the python library on github:
- Fixed a problem with urlparse in python 2.7
- Cleaned package structure
- Created a setup script for clean installation (setuptools)

I've also setup a demo server with 2 python demos (authentications with mainnet addresses):
- BitId authentication demo : http://vps90685.ovh.net:8080/
- BitId 2FA demo : http://vps90685.ovh.net:8081/

EDIT:
BitId authentication demo with testnet addresses: http://vps90685.ovh.net:8084/

Ce n'est pas vraiment une blockchain mais un système de stockage distribué appelé Distributed Hash Table.
Contrairement à la blockchain, tout le monde n'a pas toutes les données stockées sur sa machine mais juste une partie.
Si j'ai bien compris, ce système servira à stocker les fiches produits et les contrats en cours de négociation.

Pour la partie contrats, ça s'appuie sur le concept de Ricardian Contracts déjà utilisé par Open Transactions.
Le concept est assez intéressant car il permet tout un tas de déclinaisons (achat à prix fixe, enchères, marchandage, émission de parts).

L'intégrité des données est assurée par un système de signature.
Je crois qu'ils veulent également mettre en place un système de gestion de la réputation (WoT).

Une prez d'introduction qui explique tout ça

Pour les amateurs de python il y a aussi l'excellente librairie pybitcointools
Pour les amateurs de .NET il y a NBitcoin

 
C'est con mais ça m'a vraiment fait rire

I don't think it's completely true. There was an interesting concept discussed in the past : a miner network backbone (direct connection between big mining pools used to propagate blocks, clients connect directly to mining pools).

The concept is interesting and I guess that such a network could work. But it has a major drawback : the network becomes more centralized with less redundancy in the architecture. As a consequence, attacking such a network would become easier. I guess a better solution is a miner backbone cohabiting with full nodes which provide redundancy and a better resilience of the network.

So, as stated by CJYP, even if mining becomes more and more centralized, full nodes remain very important for the security of the network. Their role is different but not less important.

Hi wbaw,

I fear I can't agree with you on that point. OpenID is not just an example used by NameID. It's a core component of its concept. That's clearly stated in the FAQ and on the homepage

If you remove OpenID from NameID, it's no longer NameID.


Agree. NameId uses a principle of digital signature like BitID, Bitcoin and many systems before. But it isn't the core value of NameID. The true value of NameID is that it integrates Namecoin and OpenID.


Agree !

Tell me if I'm wrong but I feel that your main interest is not in OpenID but in being able to use a Namecoin ID to sign in.
For now, BitId only supports bitcoin address format (1....) but it would be easy to extend this behaviour to manage additional formats like Namecoin addresses (N...) or SIN addresses.

I think that supporting different address formats is a natural evolution of BitID because there's legit use cases for people wanting to sign in with a unique public identity managed by Namecoin or by a SIN. That sounds to me like a natural complement to the existing behaviour allowing to sign in with bitcoin addresses or "ephemeral ids" (when you want to keep some privacy).

I don't know if Eric and others devs share this vision but if you're interested by the addition of Namecoin ids in BitId, I encourage you to open an issue on github. I'll be pleased to support your request !

People like to say that nobody should reinvent the wheel and that one should support the existence of standard protocols. That's without any doubt a good engineering principle. I agree with that. The problem is that it's a pure technical vision of things which doesn't take into account incentives provided by a technology. As far as I know, Eric never claimed that he had invented a new authentication schema. He has come up with a damn simple protocol and a nice implementation which offer strong incentives to integrate this schema in consumers product (wallets, websites, ...).

It's not a secret that our digital life is filled of kinks (see "Motivation" chapter in this document) even if:
- technologies allowing "anonymous" authentication with public/private keys exist for decades
- PGP exists for decades
- SQRL exists for almost one year

After its announcement, in less than 3 months:
- BitId is supported by different languages and platforms (cms, wikis, ...) thanks to independant devs who spent a little time to develop libs and plugins
- some people (who are not devs) start to offer bounties to have bitid integrated in their favorite tools
- BitId has started to been integrated in "consumer products" (dark wallet, mycelium)
- BitPay has open sourced its own version of a similar schema after announcements by dark wallet and mycelium

This was made possible because BitId offers strong incentives to developers:
- it's easy and fast to integrate in existing products
- it relies on the crypto stack already used by bitcoin
- efforts done to secure the coins also secure the authentication keys
- security can be easily reviewed
- It's an open protocol. Everybody is welcome to participate

At the end, the important point is not which protocol is used but the fact that people can experiment by themselves that digital life is not doomed to be a perpetual privacy leak. And the more people experiment this reality, the more developers will be incentivized to expand BitId or integrate others protocols like SQRL in their products.

IMHO, the most important strength of BitId is that it provides the needed incentive to initiate the "avalanche".

On the technical side, here are a few points:

• internet is full of people who like to criticize ideas. Critics are good and necessary. But always ask them this simple question : did you read specifications, source code of the thing you criticize ?
• all things which can be done by SQRL can be done by BitId
• BitId is versatile:
  
  • you can generate keys for each website/system you want to sign and get "anonymous" authentication
  • you could use future systems like SINs which establish your online identity and sign in with this unique identity
  • as proposed by some people in this thread, you could link authentication rights with some bitcoin address used for a transaction or owning some coins. Basically, your authentication rights are linked to a proof of stake or a proof of payment. Definitely something which can't be achieved with SQRL

La notion de puissance de calcul est absente du PoS, contrairement au PoW. L'idée générale du PoS est que plus un utilisateur a de coins plus il a de chances de pouvoir émettre un bloc.

Certaines implémentations vont fonctionner sur un modèle de tirage au sort du prochain utilisateur pouvant émettre le bloc (si son ordinateur est connecté au réseau).

D'autres vont plutôt mettre en concurrence les utilisateurs en s'appuyant sur la notion de coinage (valeur obtenue en multipliant le montant d'un Txo non dépensé par le nombre de jours écoulés depuis la "réception" de ce Txo). L'idée est que la personne qui va émettre un bloc en PoS va devoir réaliser une transaction vers elle même d'une partie de ses coins telle que le coinage soit supérieur à une valeur donnée (un peu l'équivalent de la target/difficulté dans le PoW). En réalisant cette transaction, l'utilisateur possède toujours autant de coins mais a par contre remis à zéro la partie âge du coinage, ce qui va le pénaliser pour l'émission des prochains blocs. C'est plutôt malin.

La notion de puissance de calcul n'interviendra pas (ou quasiment pas) dans la réussite d'une attaque contre du PoS. Une des critiques les plus pertinentes que j'ai lues à propos de la sécurité du PoS est la suivante:

La sécurité d'un système repose plus sur le coût extrêmement élevé d'une attaque que sur l'infaillibilité du système (illusoire).

Dans le cas du PoW, un acteur malveillant peut tenter une attaque mais si elle échoue il va perdre de l'argent (le coût de l'électricité consommée). Tout l'enjeu du système PoW est de faire en sorte que les gains associés à un comportement honnête restent toujours plus élevés que les gains moyens d'une attaque (en tenant compte de la probabilité d'échec de l'attaque).

Dans le cas du PoS, une tentative d'attaque qui échoue ne fait rien perdre à son auteur. Il ne perd pas ses coins et je ne suis même pas sur qu'il perde l'ancienneté de ses coins. Bref, une tentative d'attaque ratée n'a pas d'impact financier sur l'attaquant. Les comportements "déviants" ne sont pas punis.

Quoi qu'il en soit, je trouve intéressant qu'il y ait des altcoins fonctionnant en PoS. C'est le seul moyen de vraiment tester le système et de détecter ses forces et faiblesses.

EDIT: Deux lectures intéressantes pour approfondir le sujet du PoS:
- le Whitepaper Peercoin (mix PoW/PoS)
- un article de V.Buterin sur les forces/faiblesses du PoS et de possibles améliorations

C'est clair que le design visuel et l'UX sont souvent les parents pauvres des projets open source. Ce serait bien que ça change un jour et que les designers soient un peu plus présents sur ce type de projet. En ce qui concerne Open Bazaar, faisons leur pour l'instant crédit du fait qu'ils sont en plein développement et pas du tout au stade de livrer des versions utilisables par Mr et Mme Toutlemonde.
Après, s'ils ne sont pas trop c..., ils devraient se douter que leurs utilisateurs ne sont pas des devs avertis et packageront un truc simple à installer pour tout le monde. Le fait est que quand on regarde le projet, ça répond quasi-exactement au besoin de l'OP et je pense qu'ils sont nombreux à attendre une telle solution. Imaginez le potentiel ne serait ce que pour les gens qui veulent vider leur grenier ou leur cave...

Voici un excellent blog avec un post expliquant le mining, les pools de minage, .... C'est illustré avec du code python, notamment pour l'algo de mining.

Pour des aspects plus théoriques, le wiki bitcoin est une mine mais c'est parfois bien caché. Quelques pages intéressantes: présentation générale du mining, les notions de target et de difficulté, proof of work, hashcash, ...)

Je sens que ce thread a besoin d'une once de légèreté


Gaffe quand même à la bulle sur le hamstercoin. Ca risque de pas être joli joli si elle explose.

C'est bien des headers de 80 bytes (notez qu'en hex cela donne 160 digits soit 0x11111111111111111111111111111111111111111111111111111111111111111111111111111 1111111111111111111111111111111111111111111111111111111111111111111111111111111 1111)


C'est bien ça


C'est à la discrétion du mineur. En théorie le mineur agit sur le champ nonce pour faire varier le hash et trouver la solution.
En pratique, je crois que certains mineurs font également parfois varier la date lorsque les variations sur le nonce n'ont pas produit de hash "gagnant".
Les contrôles de validité effectués par les autres noeuds du réseau sur le timestamp du block sont assez souples (problème d'un référentiel temps commun dans un système distribué):
Donc ça laisse pas mal de marge au mineur pour choisir la valeur du champs !


Je ne suis pas expert en crypto mais je dirais que Bitcoin utilise bien un algo SHA256 standard avec 64 tours.

Si la mise en place du site peut encore attendre quelques mois, je pense qu'Open Bazaar pourrait être une solution toute indiquée.

Cool !

Si le coin est destiné à rester dans un petit groupe de gens de confiance, la suggestion de SuperRésistant est effectivement excellente:
- Avec du proof of stake, seules les personnes qui ont déjà des coins peuvent émettre des blocs => limite le risque qu'une personne extérieure attaque le coin.
- le PoS nécessite moins de calculs que le PoW (donc coute moins cher en électricité).

Cela étant, même avec du PoS, la remarque concernant la nécessité d'avoir des fees sur les transactions tient toujours. Même si cela requiert moins de calculs, il faut qu'un minimum de participants laissent leur ordinateur tourner 24/7 pour que de nouveaux blocs soient émis et que le système perdure. Ca consomme quand même de l'électricité, donc il faut qu'il y ait une récompense à la clé pour les motiver à continuer. Comme tous les coins ont été préminés, cette récompense ne pourra venir que des fees associés aux transactions émises.

Il y a plusieurs variantes de PoS (Nxt, PeerCoin, ...) voire des mixes PoS/PoW. A toi de voir ce qui correspond le mieux à ton besoin.
Après l'idée est la même: récupérer les sources d'un coin utilisant du PoS et les modifier pour que 80M soient émis dans le bloc initial et que les blocs suivants aient une récompense de 0.

Je pense que c'est techniquement possible. L'idée est simple : Il faudrait par exemple partir du code de bitcoin et modifier les règles de récompense des blocs de manière à ce que le premier bloc (genesis bloc) ait une récompense de 80M coins et que tous les autres blocs aient une récompense de 0 coin. De fait, la monnaie sera démarrée avec une adresse qui a 80M de coins à répartir plus tard. Miner le premier bloc ne devrait pas être trop long, la difficulté initiale étant basse.

Mais la technique n'est qu'une partie du problème. La monnaie n'est viable que si elle est sécurisée par une puissance de calcul suffisante du côté des mineurs pour la validation des transactions. Hors le minage coute de l'argent et s'il n'est pas payé par les récompenses associées aux blocs, il ne reste plus que les fees attachés aux transactions pour payer les mineurs. D'ou le risque de se retrouver avec un altcoin très peu sécurisé ou imposant des fees très élevés.

Après tout est question de contexte. Un altcoin qui est utilisé dans un petit cercle d'amis a peu de chances de se faire attaquer. Par contre, un altcoin qui a beaucoup de visibilité et n'est pas sécurisé par une puissance de minage suffisante est généralement destiné à disparaitre dans les atroces souffrances liées au supplice de l'écartèlement (plus communément appelé "fork" dans la communauté).  

AuroraCoin est un bon exemple de ce funeste destin.

Seems to me that the payment protocol solves this problem. The merchant should look for tx(s) received in Payment messages, not for stealth payments.

You're right but there's an important difference between NameId and BitID:

• NameID relies on OpenID which is a nice system but requires a third-party (the identity provider) to let you authenticate.
• With BitID, no third-party is required. It's just your wallet and the website.

Both systems have their strengths and their weaknesses. It's a matter of choice.