|
Stealth addresses are only one part of the "privacy pack", helping to protect privacy of the payee (ability to get a public address without address reuse).
On the other hand, privacy of the payer is protected by no address reuse (but most wallets already manage a new address for every change) and by Coinjoin transactions which decrease linkability between inputs and outputs of the tx.
Seems to me that one-time change address can be generated randomly or in HD fashion without requiring an additional tx but I don't know which path was selected by DW.
|
|
|
|
I like this idea. Providing a financial incentive seems a good way to increase adoption of privacy tools and transform dormant bitcoins in active money. Moreover, some coinjoin txs (like the example in your post) provide a low entropy and it's really easy to link outputs. By transferring a fee from taker to maker, the tx becomes more similar to a regular tx in term of entropy and you can't link outputs with 100% certainty. The "downside" is that these txs still have a specific signature (#outputs >=4) different from the most usual txs (#outputs = 2). Just a detail: Don't think your proposal will "solve" the third point from your post. Having more makers is nice but it won't remove attackers. And some could argue that your proposal will just help to fund them  |
|
|
|
En détournant (un peu) ta pensée, je dirais que tu viens de trouver un super use case pour coinhouse : les couples infidèles. Bitcoin est l'alibi parfait. Il n'y a juste qu'à attendre le prochain mtgox pour expliquer à sa moitié pourquoi l'argent placé a disparu. Coinhouse devrait définitivement monter un partenariat avec Gleeden ! Je savais bien que cette idée avait du potentiel !  |
|
|
|
Vous en connaissez des mineurs de Bitcoin en France ?
Non ça n'existe plus.
L'expérience a été tentée dans la Bresse mais ça a échoué. Ces fucking poules sont vraiment trop connes.  |
|
|
|
I would say that the first required step is to reach bitcoin 1.0 |
|
|
|
Ok, now I know exactly what the HTTP request from Onchain looks like (which works against the BitID demo). No wonder I couldn't get it to work. The phone app doesn't use Json at all, but does a full webform post.
Interesting. I thought that all wallets were using json format to send these parameters but it's true that it's not a requirement made by the protocol. This is what I was asking for in the spec as a sample: POST http://dev.swarmops.com/Security/BitId.aspx HTTP/1.0 Content-Length: 272 Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip Host: dev.swarmops.com User-Agent: android-async-http/1.4.4 ( http://loopj.com/android-async-http) signature=H2ooalc68rfcS%2FnEIrrCH2zUKYvjIuj%2Bp9DoQoVVkW39R3wVfNnbO7Pmd4UdkNf6FpQ%2FUGV3pfm4vrE9541za%2Fg%3D&uri=bitid%3A%2F%2Fdev.swarmops.com%2FSecurity%2FBitId.aspx%3Fx%3D4b593383a4674b83b31d066e0e87e60f8d1c1df565f568f%26u%3D1&address=14fRQCbR62EGzjPQks9XRAVRiqWhftn3dA If you have some time, send me a PM with your comments/fixes about the draft in my previous post. I'll gather everything and send it to Eric to get something on github. And here I was trying to interpret Json and wonder why the server did absolutely nothing...  Arfff. I know this feeling when you spend time looking for the causes of a bug and finally notice that you didn't look at the right causes. I fear it's the curse of all developers. By the way, it's great that you work on this integration of BitId with C#. It's a great platform and I expect we see more .NET bitcoin projects thanks to efforts like yours or NBitcoin. |
|
|
|
Sorry for the late answer. Was musing in the french subforum Does it have to be this (partial) URI, or is it just a header describing this section? That's unclear. I have been using a different URI, as I'm using the [WebMethod] feature of Asp.Net that lets you embed a Json-callable function on any page.
The uris "/callback" can be something else. The client should only rely on what it has received in the bitid_uri. I think we've all followed a kind of implicit norm by reusing the same "/callback" uri but the protocol does not state any such rule. EDIT: Here is an example of a different callback uri used in my 2FA demo (uses a "/tfa_activation_callback" uri) Parameters:
uri : string - required - bitid uri used as the challenge
signature : string - required - signature of the bitid uri
address : string - required - address used for authentication
Can we lock down that the parameters come IN THIS ORDER? That's not explicitly written, and some implementations (like C# which I'm using) are or can be order-sensitive, even with parameter names supplied. Ooops. That sounds like a more serious issue. On its side, BitID protocol does not state any specific order for the parameters. Main problem is that such a rule would have a direct impact for wallets developers. Thus, I think it's better if Eric answers this point. I may be wrong but to my knowledge, there's no notion of order in json. A lib forcing an order for json content seems to me like a bad implementation of json. |
|
|
|
je participe un peu à mon niveau au dev de supernet, et je peux dire que les choses avancent vite et que supernet sera en release bien avant les sidechains.
Il y a des gens brillants qui participent, mais il est vrai que c'est jl777 porte le projet et qu'en effet cela peut porter préjudice en cas d'empêchement de sa part.
Yep. Je n'ai pas trop de doutes que supernet sortira avant les sidechains. C'est bien si l'effort de dev se répartit sur plusieurs personnes et s'il y a des backups de personnes. Il n'y a pas de raison pour que jl777 fonde un fusible mais la centralisation des connaissances sur une personne n'est jamais bonne pour un projet. En fait, on parle ici de programmes OpenSource avec de la monnaie virtuelle.
James ne risque pas grand chose, au pire de payer une amende mais dès que SuperNET est sorti, ce n'est plus dépendant d'une seule personne.
C'est comme de décider que Bitcoin était illégal... ça changerait rien car on peut rien faire contre. Ce serait encore plus ridicule de dire que la répartition des BTC est illégale parce que le minage est cadré par la loi : c'est ridicule.
Et bien un ICO/IPO etc. sur les systèmes cryptos, c'est la même chose. Les états peuvent gueuler et peuvent ennuyer les gens par des amendes mais ils peuvent rien arrêter. Ca échappe de leur contrôle.
jl777 est anonyme et il sait bien pourquoi. C'est pour qu'on ne l'emmerde pas. Pour le reste, les états ne peuvent pas grand chose contre ses projets qui lui survivrons dès qu'ils seront prêt à être lancés.
Je sais tout ça. Je dis juste que dans ce genre de situation, le régulateur aime bien faire quelques exemples (ce qui en général ne sert à rien...) et que ce serait dommage que ça tombe sur un projet comme supernet (avant qu'il soit lancé). Un développeur qui a l'IRS sur le dos ça n'a pas la même productivité qu'un développeur serein. Mais j'avais effectivement cru comprendre que jl777 protégeait sa tranquilité et c'est tant mieux! Au cas où ça en aurait l'air, je précise que je ne suis pas venu troller le thread supernet, bien au contraire.  J'essaie juste d'analyser lucidement les + et les - en terme d'investissement et le même exercice pourrait être fait pour les sidechains (sauf qu'ils sont déjà financés). De leur côté, ils ne doivent pas risquer grand chose avec l'IRS mais je leur prédis quelques frictions à venir avec la communauté bitcoin en terme de soupçons de conflits d'intérêts (bitcoin / blockstream). Je ne suis pas certain que ce soit une position plus confortable. |
|
|
|
Here's my notes, written while working on the python library. Hope it helps. /callbackRequest sent by the browser or the wallet as a response to a challenge Request can be sent in two formats: json or html form Request Http method: POST Parameters: uri : string - required - bitid uri used as the challenge signature : string - required - signature of the bitid uri address : string - required - address used for authentication Headers: Content-Type : string - required = "application/json" if request sent by a wallet, otherwise server should assume a manual signing submitted via an html form (see demo) Response Process completed Response format: address : string - required - address used for authentication nonce : string - required - session id associated to the authentication Http code: 200 Process failed Response format: message : string - required(?) - message describing the error Http codes / messages: Invalid adress Http code : 401 message : Address is invalid or not legal Address is valid but not associated to an existing account Http code : 401 message : Address is invalid or not legal Invalid BitId uri Http code : 401 message : BitID URI is invalid or not legal Invalid signature Http code : 401 message : Signature is incorrect Illegal nonce Http code : 401 message : NONCE is illegal Expired nonce Http code : 401 message : NONCE has expired Server error (pb with db, ...) Http code : 500 message :  Misc error (specific to implementations by websites) Http code : 401 message : [...] /authRequest sent by the browser to check if authentication has succeeded Request Http method: GET Parameters: None Headers Cookie: stores the session id Response Process completed Response format: auth : int - required - 1 if authentication successfully completed, otherwise 0 Http code: 200 |
|
|
|
C'est qui Boussac?
Voici un lien vers le meetup qui aura lieu le 11 Décembre. Je ne sais pas comment ça évoluera mais c'est sur que les sidechains sont un facteur à prendre en compte. Mon humble et rudimentaire vision concernant supernet: Points positifs - Les sidechains confirment la vision de supernet de créer un réseau de cryptos
- Supernet parait fonctionner sur un modèle plus agile. Apporter des modifications à Bitcoin prend du temps, les développeurs sont très prudents et obtenir un consensus sur une évolution peut être très long.
Points négatifs - La valeur de chaque réseau dépendra du nombre et de la qualité des altchains membres. Les sidechains pourraient bénéficier de la prédominance de bitcoin (visibilité, capitalisation, ...) pour attirer plus facilement les nouvelles altchains dans leur écosystème.
- L'équipe blockstream regroupe un nombre impressionant de devs et cryptos reconnus dans la communauté. Jl777 a l'air brillant mais semble un peu isolé par rapport à l'"armada" blockstream. Ca peut avoir ses avantages mais ça a aussi ses risques (je ne suis pas certain que supernet survivrait à un burnout de jl777)
- Blockstream a reçu un financement de 15M$ provenant d'investisseurs. Supernet a été financé par une ICO au statut légal incertain. Je ne sais pas quelle est la localisation géographique de jl777 mais j'espère pour lui que ce n'est pas les US car la SEC commence à montrer ses dents
|
|
|
|
Théorie et pratiqueIl y a la théorie et la pratique. C'est bien beau de faire des calculs de probabilité (théorie) mais quid des évènements externes qui peuvent arriver à tout moment et faire basculer le cours du bitcoin (pratique) ?... une whale qui dump par exemple, un exchange qui ferme, un énième scandale, etc. Amen ! Il y a quelques mois, des chercheurs de Princeton publient un article expliquant pourquoi selon eux, Facebook va rentrer dans une phase de déclin. S'appuyant sur les stats de recherche Google, ils constatent que les recherche concernant Facebook commencent à suivre un pattern identique à celui de MySpace qui a disparu il y a quelques années. Problème: ils ne tiennent pas comptent du fait que l'usage d'internet s'est largement répandu dans la société, que tout le monde connait Facebook et que surtout une majorité de gens passent désormais par leur smartphone pour l'utiliser. Conséquence : quelques jours plus tard les data scientists de Facebook publient un post bien marrant, expliquant pourquoi les chercheurs de Princeton sont des cons. Morale: tout modèle a ses limites |
|
|
|
|
Je ne pense pas que Baakewolf envisage des activités répréhensibles au point d'avoir besoin d'un vrai anonymat mais au cas ou, voici quelques compléments.
Crypto note ne fournit pas un vrai anonymat au sens cryptographique du terme.
Les principes mis en oeuvre sont en fait similaires à ceux d'autres cryptos (ou wallets tels que darkwallet) :
- stealth addresses pour masquer le destinataire
- mixing pour créer une explosion combinatoire compliquant l'analyse du graphe des transactions.
Crypto note se démarque des autres par les technos utilisées (ring signatures) et l'inclusion de ces principes au niveau du protocole.
En fait, il "industrialise" un modèle qui est encore artisanal (voire inexistant) dans la plupart des autres cryptos.
Avec Zerocoin, on entre carrément dans une autre division avec du véritable anonymat.
Par contre, il demeure pas mal de difficultés à lever pour en faire une devise utilisable (perfs, scalabilité, problème de l'initialisation, ...).
Le système est tellement anonyme qu'il serait impossible d'être certain que ceux qui ont initialisé la devise ne sont pas en mesure de frauder. C'est un poil embarrassant.
@Baakewolf :
Honnêtement, je ne m'embêterai pas trop avec ça. Comme pour le cash, il est probable que chacun d'entre nous se retrouvera un jour ou l'autre avec des coins "blanchis". Ca ne nous transforme pas pour autant en criminels.
Selon moi, le plus important en cas de contrôle est de pouvoir expliquer comment les coins ont été acquis (avoir une preuve de retrait de cash, ...).
|
|
|
|
|
@superresistant:
100% d'accord sur le fait que la localisation joue un rôle important (avantages naturels, coût de l'électricité, ...)
Merci du rappel sur le refroidissement, c'est un truc que j'ai lu 1000 fois mais que j'ai tendance à oublier.
@perl:
Yep. C'est exactement le type de raisonnement que j'avais en tête.
|
|
|
|
Cette influence est négligeable par rapport :
- Au marché du hardware : ratio hashrate/FIAT à l'achat
- A la date à laquelle on commence à miner
- Au coût du minage : énergie + hébergement
C'est simple, un coût de minage nul rend n'importe quel matériel profitable à l'infini (ou du moins jusqu'à ce que le Bitcoin vaille zéro).
Où alors, un matériel de dernière génération livré avant les autres est extrêmement profitable alors que livré en retard, il ne l'est plus.
Intéressant ! J'imagine que les coûts d'électricité et d'hébergement sont majoritairement payés en fiat. Or ces coûts exprimés en fiat sont relativement "constants" si on les compare aux évolutions du cours btc/fiat. Si les mineurs utilisent une partie des btc minés pour financer leur coûts immédiats (la théorie selon laquelle les mineurs sont un des facteurs expliquant la pression à la baisse sur le cours) alors le cours a une influence directe sur le comportement des mineurs qui raisonnent en terme de profitabilité. Mais comme tu le disais, si un mineur n'est plus rentable il revend son matériel et le hashrate est juste redéployé ailleurs, ou il pourra être exploité de manière profitable. |
|
|
|
|
Merci pour ces éléments. Très instructif !
@superresistant:
100% d'accord sur l'importance de la profitabilité du minage et le fait que les traders se foutent surement royalement des courbes de hashrate.
Concernant l'impact du hashrate sur la valeur de la devise, j'ai quand même toujours un doute. Si les mineurs venaient à basculer massivement et durablement leur hashrate vers une autre crypto (parce qu'elle est plus rentable, parce qu'elle semble plus viable que bitcoin, ...) j'ai du mal à croire que cela n'aurait aucun impact sur la valeur de bitcoin. Mais bon, je peux me tromper.
@Madmat:
L'analyse de sgbett est vraiment intéressante. J'aime beaucoup son idée que nous sommes dans un période de cycles alternant une bascule entre investissements dans le mining et investissement dans la monnaie et que c'est notamment lié au fait que les gens raisonnent encore en fiat (bon en même temps il paient leur note d'électricité en fiat...).
|
|
|
|
I intend to implement this as a 2FA sign-on in Swarmops over the next two weeks. I've never seen _anything_ matching its ease of use. Is there redistributable server-side code somewhere I can use as a template? My platform is ASP.Net and C#. I would rather not reimplement crypto code, but I am happy to change its syntax keywords from another implementation language. Cheers, Rick (Swarmops: https://github.com/Swarmops/Swarmops) Hi Falkvinge, There's no server-side code written in C# yet but it would be really great if someone can achieve that. WRT crypto code, there's a great bitcoin library written in C# : NBitcoinI'm almost sure that you can get all the crypto code required by BitId (basically the verification of ECDSA signatures) from this library. You may contact Nicolas Dorier (maintener of NBitcoin) to check if you can reuse parts of his code and where to find the relevant code. WRT BitId code, implementing server-side code is quite straightforward. There's several implementations in different languages : - Ruby (original code) - Python- JS- PHPI hope it helps. Do not hesitate if you need more details about the protocol. Thumbs up here too.
You're welcome |
|
|
|
Ça marche dans un sens mais pas dans l'autre donc ce n'est pas une corrélation.
Le mining et le trading sont deux mondes séparés qui s'ignorent complètement.
Pour être plus précis, ma question ne porte pas sur les fluctuations de la valeur à court terme (il y a trop de facteurs qui peuvent influer) mais sur les tendances à long terme. Jusqu'à maintenant, je m'étais peu intéressé aux détails du modèle économique du minage. Les récentes discussions sur la taille des blocs m'ont incité à regarder ça plus en détail. D'où ma question... Je veux bien croire qu'au jour le jour, le hashrate n'est pas un facteur de décision pour les traders mais j'ai du mal à croire que le hashrate n'a aucune influence sur la valeur de bitcoin. Mais qu'adviendrait il de cette valeur si les mineurs décidaient de basculer durablement 50% du hashrate sur une autre crypto ? |
|
|
|
|
Je suis d'accord avec Gobitcoin. Utiliser un service de mixing n'est pas interdit pas la loi.
Après, il y a le contexte.
Si le mixing des coins était partie intégrante du protocole, ce serait totalement transparent.
Dans la mesure ou il s'agit d'une fonction additionnelle utilisée par une minorité de bitcoiners, passer des coins dans un mixer, s'ils proviennent ou doivent aller vers un service appliquant les textes d'AML/KYC, c'est un peu comme allumer une grosse ampoule rouge au dessus de sa tête.
A mon sens, c'est un vrai problème car le niveau d'anonymat de bitcoin est très surévalué et il y a vraiment besoin de services améliorant la confidentialité des transactions.
|
|
|
|
Il voulait dire que l'augmentation du hashrate signifiait une augmentation de la sécurisation du réseau et donc une monté du prix.
C'est faux puisque c'est la distribution du hashrate qui augmente la sécurisation du réseau, si le hashrate monte du fait de la concurrence entre un petite nombre de très gros mineurs, le réseau ne devient pas plus sécurisé, au contraire.
Au temps pour moi ! Ma question était imprécise. En fait, ma question n'est pas sur la sécurisation du réseau (distribution du hashrate) mais sur l'aspect économique du mining et la valeur du hashrate. Mon raisonnement est que si la valeur du coin augmente, à hashrate constant, miner devient plus rentable. Il y a donc une incentive à investir plus dans le mining (d'où augmentation du hashrate). De là ma question sur la forme que prend la relation entre les deux. |
|
|
|
I've just reread the whitepaper and I wonder what is the impact of SPV on fungibility in sidechains. Since pegged sidechains may carry assets from many chains, and cannot make assumptions about the security of these chains, it is important that different assets are not interchangeable (except by an explicit trade). Otherwise a malicious user may execute a theft by creating a worthless chain with a worthless asset, move such an asset to a sidechain, and exchange it for something else. To combat this, sidechains must effectively treat assets from separate parent chains as separate asset types. |
|
|
|
|
Show Posts
