Sur une transaction coinhouse il y a deux types de coûts :
- les frais prélevés par l'établissement de paiement pour traiter la transaction VISA ou Mastercard, qui sont à la charge du marchand (de l'ordre de 1.5%)
- les frais coinhouse pour convertir les bitcoins en euros et émettre une carte de paiement, qui sont à la charge de l'utilisateur (de l'ordre de 6%)
Je ne prends pas en compte les coûts liés à l'acquisition de bitcoins, car il faut partir du principe que l'utilisateur en a déjà et que son problème est de savoir comment les dépenser, pas comment les acheter.
Ces coûts ne se recoupent pas.
Ce salaud de Satoshi avait raison, les intermédiaires de confiance coutent chers en fees  Pour être honnête, je crains que l'idée de devoir payer plus cher pour avoir le droit de régler en bitcoins ne remporte pas un franc succès auprès des bitcoiners, surtout si ce surcout doit majoritairement profiter à une banque... C'est vraiment dommage car il y a un vrai besoin à remplir en attendant que le paiement direct en bitcoin se démocratise. Quoi qu'il en soit, c'est vraiment bien de voir des solutions apparaître pour addresser ce genre de problématique et j'ai envie de croire que c'est un service qui trouvera son créneau (produits "rares" non payables en bitcoins, produits peu couteux, ...). Et merci pour la transparence sur le détail des fees ! |
|
|
|
|
Au risque d'être celui qui pose la question qui "fache", une autre question concernant les fees.
Les fees pour un paiement via coinhouse se décomposent ils comme suit:
- les fees payés par le commerçant pour le paiement par carte bleu,
- les fees coinhouse,
- les fees de transfert bitcoin
ou y a t'il une fusion de certains fees ?
|
|
|
|
Je refuse les tracasseries administratives.
C'est de la phobie administrative ? Ca sent de futurs problèmes de conformité tout ça. En même temps, c'est bien connu: "Problème de conformité n'est pas fraude" (proverbe de Saone et Loire) |
|
|
|
Dark Wallet supports BitID ? Do you have a link I can look at.
They do, since their last release ( alpha 5) |
|
|
|
Not sure. It's working now, that's the main thing.  Sure. Anyway, it's really great that you've integrated Bitid in the wallet ! Unfortunately, I don't own an android smartphone, so I won't be able to check your android app against futures version of the library but if your web web wallet manages bitid, I'll add it to my list of test platforms with Dark Wallet. Keep up the good work ! Laurent |
|
|
|
I've just done a quick check with the values sent in your previous post. At library level all tests (bitid uri, address, signature) are ok. I guess the problem is with the app demo or with the server. The /callback POST request has a mimetype header set to "application/json" ? EDIT : Ooops. Cross-post Cool ! What was the problem ? |
|
|
|
Hi onchain ! Sorry for the late answer (was out of office). Started POST "/callback" for 192.168.178.39 at 2014-09-11 12:07:05 +0200
{"signature"=>"ICmRRZees1ERGP0zFRpjlzNA60e3b9GYAwScGbpqe7Lnek6ulUwTB3VXkWkH1ZbaPirEf60EKrWGAXE0BqMSETI=", "uri"=>"bitid://192.168.178.29:3000/callback?x=463eb9f064a4173f&u=1", "address"=>"1PmcrixixGKzSyL6NbNcSzjHGLSsgb7dfa"} Regarding the structure of your request, everything seems ok. I assume the values are those used with the rails demo and that you had different uri, signature & address for your test with the python demo. That's right ? May you check the value of the field "message" in the json returned by the server ? It should give us a first hint about the problem. |
|
|
|
Pour chaque transaction nous générons une carte virtuelle dynamique à usage unique. C'est effectivement un peu comme une payweb card, sauf que nous utilisons une API bancaire dédiée robuste et scalable.
Ok ! |
|
|
|
|
Par curiosité technique (et si ce n'est pas un secret industriel): vous utilisez une payweb card pour le règlement en euros. C'est bien ça ?
|
|
|
|
Je pense qu'il y a causalité mais dans autre sens.
Le cours monte donc les gens informent
Je suis assez d'accord avec l'idée de l'investissement opportuniste: cours à la hausse => plus de couverture dans les média et meilleure visibilité => plus de gens se renseignent => nouveaux investisseurs => bulle La situation ces derniers mois est différente: le cours est à la baisse/stable mais avec une couverture média de plus en plus mainstream et positive. Ca devrait être intéressant d'observer si la tendance se confirme dans Google Trends et comment ça se traduit en terme de cours. |
|
|
|
Peut être la fin de la baisse avec un début de remontée du terme "bitcoin" dans Google Trends.  Pour ceux qui ne voient pas bien le rapport, la théorie est que chaque bulle est alimentée par l'arrivée de nouveaux bitcoiners. Or qui dit nouveau venu dit recherche d'informations => plus de recherches dans google => hausse dans google trends La théorie vaut ce qu'elle vaut mais il faut avouer qu'il y a quelques similarités dans les pics des courbes google trends et capitalisation bitcoin. Après comme disait l'autre: corrélation n'est pas causation. |
|
|
|
Allez hop, à mon tour pour une petite salve ! 1) Titre bien racoleur, pour ne pas dire putassier à souhait... J'adore !  2) Cet article parle d'une inculpation de Mark Karpeles après plainte d'un ancien employeur. Là ou ça devient marrant, c'est quand on sait la réputation qui colle aux basques de la dite victime (voir ici). Donc ce que dit cet article c'est que M.K. est accusé d'avoir escroqué un type lui-même suspecté d'être un escroc notoire. Je doute que le journaliste du Monde ait fait ses due diligences au point de fouiller les recoins du net pour vérifier les antécédents de la dite "victime" et c'est fort dommage. Dans un article dont l'axiome est qu'un "passé trouble" est porteur de sens pour appréhender des évènements récents, la moindre des choses est d'appliquer la même règle à tous les acteurs du "drame". Simple affaire d'honnêteté intellectuelle et journalistique. 3) A quoi ça sert qu'Hugo se fasse chier à écrire Les Misérables si 150 ans après la logique est toujours la même: coupable un jour, coupable toujours. Si on m'avait dit qu'un jour je prendrai la défense de Mark Karpeles, je l'aurais pas cru...  |
|
|
|
The intent was that mixes have a one-to-one correspondence to simple cycles. So, examples 1a and 1b induce two mixes, while 1c three mixes.
After thinking over the threat model, I'm tending to agree more with laurentmt's point, and my answer to your question is this:
Combining node-distjoint cycles of the same amount is not only a viable variation, but also has the advantage of larger anonymity size for that mix. Supposing the mix amount is equal, if I were to weigh the pros of a large single trxn versus that of two with a significant time difference, I'd favor the larger trxn.
Anyway, I think BVM cycling/splitting phase remains highly valuable (even for coinjoin) considering your objective to come up with a scalable solution. Indeed, the "problem" of coinjoin is that it's subjected to 2 antagonist constraints: 1 - more players involved in the tx (more txins & txouts) is desirable for better privacy. 2 - txs are subjected to technical constraints (max number of txins & txouts) and organizational constraints (it's more likely that the signature of a coinjoin tx will fail if there's a lot of participants -1 rogue participant is enough-). These points make less participants quite desirable. BCM cycling phase (or a variant) may be an adequate solution to "locally" maximize entropy and cope with (2) at the same time. Thus in the case of coinjoin, may be this phase can be tweaked to produces subgraphs instead of simple cycles. These subgraphs should be as close as possible of a given pattern (with defined # txins & txouts). Note : I don't know the best target values for # txins & txouts but I'm quite confident that people from the community are able to define them. Open question : Is it desirable to introduce specific behaviours in BCM depending on the underlying primitive ? WRT (1), chained coinjoins seem a straightforward solution (and already implemented in Darkcoin ) Imho, it shouldn't be managed by BCM but by wallets which call multiple iterations of BCM according to rules defined by the wallet. I think it's the solution implemented by Darkcoin wallets allowing users to select the number of iterations. Main reasons I see for this: - I don't think anybody has come up with an objective criteria defining what is the right number of iterations / desirable entropy (surely depending on the threat model as you pointed out) - I may be wrong but this "chained txs" schema seems to me quite specific to coinjoin. Not sure others primitives have the same requirement. laurentmt, this will help in the entropy analysis somewhat. Being that the # of cycles of the same flow amount is also a random variable, the size of the combined cycle is still too a RV.
It makes me think that it would be nice to have some stats from the blockchain about distributions of this kind of things. Added into my todo list. EDIT: Removed assertion about how the cycling phase works. Seems wrong. |
|
|
|
Silentgwad a bien fait de vous "allumer" En terme d'image, c'est carrément le jour et la nuit par rapport à la version précédente et ça donne beaucoup plus envie d'essayer le système. Bonne continuation ! |
|
|
|
beau boulot. bon j'ai quand même un peu de mal avec l'anglais sur certains détails mais j'ai compris le principal.
En parlant d'anglais, si vous voyez des trucs incorrects n'hésitez pas à me les indiquer. Je corrigerai. De même, si vous avez des idées d'arguments de vente à ajouter. N'hésitez pas ! un mot sur la démo:
lorsqu'on est d'accord sur le prix qu'on soit vendeur ou acheteur il serait pratique d'avoir un bouton (accept the offer) pour préremplir le champ "price" dans l'envoi du dernier message au lieu de devoir copier/coller sous peine de se tromper.
Très bonne remarque. C'est effectivement un des cas (l'acheteur propose un prix qui est accepté par le vendeur et l'acheteur doit réenvoyer une transaction de paiement) où le protocole impose une redondance qui nuit à l'UX. De mon côté j'avais songé à une solution encore plus radicale: si la wallet de l'acheteur reçoit un message qui confirme le dernier prix proposé, elle réenvoie automatiquement la transaction de confirmation. Cela étant je n'ai pas voulu l'implémenter dans la démo pour 2 raisons: - il y a des cas où cette confirmation automatique peut poser problème (cas d'un acheteur négociant en parallèle le "même" produit avec plusieurs acheteurs). - je voulais que la démo (et son UX) ne cache rien du fonctionnement du protocole, Si je devais implémenter le protocole dans une vraie wallet, je pense que l'UX serait totalement différente avec le formulaire et l'historique de négo sur une seule page au lieu de 2 onglets et la solution que tu proposes pour le cas de la confirmation par l'acheteur. |
|
|
|
Bonjour à tous, Je viens de pousser sur Github les sources et les specs du projet de protocole de marchandage proposé au hackathon de Juin à la Maison du Bitcoin. Depuis le hackathon, j'ai cleané le code et complété les specs. Ca ne rend pas du tout justice au travail fait par Thibault sur l'UI de la démo mais ça a nettement amélioré la librairie. De plus une démo est en ligne pour tester le protocole. Elle simule une online wallet permettant de négocier avec un vendeur qui est un bot minimaliste (négociant au hasard). Les specs et les codes sources sont sur GitHub: |
|
|
|
Chained CoinJoins... now that's exciting! I hope this can open possibilities for chaining.
Yep. It's the idea of a n-stage switching network proposed by gmaxwell in his first post about Coinjoin. It aims to mix inputs for a high number of players (and keep entropy provided by number of participants) while coping with transaction size limits. |
|
|
|
I definitely agree with you that there's possible improvements in term of UX. On the technical side, I don't think this mechanism should be implemented at the level of bitcoin protocol. (1) As suggested by prezbo, I guess the schema would be a public referential (like namecoin) with a bitcoin address (or a stealth address for better privacy). At UX level, it would require that : (2) wallets interface with this referential to translate a name in an address (3) there's an easy way to manage your profile Current state: (1) already exists (3) some solutions have appeared (like onename.io) The missing step is (2) which depends on wallets developers. I'm confident that it will happen sooner or later because it sounds like a legit feature. |
|
|
|
Sure I see where you're going with that, laurentmt. And agreed that entropy is less for BCM/Join than for native Joins, # of players being equal.
Yup. I suck at poker ! That said, BCM is intended to make it easier to mix against larger, more diverse sets of players, and the number of mix participants is a random variable 100% agree about the value of BCM as a decentralized solution to address scalability and heterogeneity of inputs. so one could argue that the entropy comparison should be a probabilistic calculation where the expected # of players for a Join in BCM is equal to the # of players in the native join. Some txns in BCM will have fewer, some will have more.
To be honest, I don't feel comfortable with a probabilistic calculation. I tend to think that all measures of anonymity should be done on specific instances of mix(es) and not on averaged or probabilistic mix(es). This is the only way for users to be sure of their level of anonymity. Note that this remark also worths for my use of entropy which is a measure at tx level. For perfect coinjoins (all inputs with same value, all outputs with same value) this measure is ok. But for coinjoins with different input/output values, the degree of anonymity is not the same for all players and we should have a more local measure (at txout level). Work in progress... Entropy analysis does cover the combinatorial dimension of semantic security, assuming the adversary knows all information known to any participant until the Join. Still, there are a few other dimension that I think should be taken into account.
100% agree If we're willing to allow consideration for the common case (1) separately from the worst case (3), then with (1) BCM has something that native doesn't: the times in which the transactions occur can vary, so much so that other mix transactions can be interspersed in between transactions of this mix. There can be other non-mix transactions that look like mix transactions as well.
Definitely one of the strengths of BCM. Interspersed txs could be a solution to increase entropy of coinjoin mixes. [Note: In my previous post, I suggested to chain coinjoin txs to increase entropy. It can help but it doesn't work for all cases (like a coinjoin tx with only 2 inputs and 2 outputs)] |
|
|
|
Hi there, The Bargaining Protocol is one of my toy projects, initially proposed at a bitcoin hackathon organized at La Maison du Bitcoin. To be honest, the main goal of this project was to provide an excuse to hack code implying a bunch of bitcoin concepts (creation/validation of transactions, retrieving data from the blockchain, payment protocol, chain of signatures, ...). But the pitch was a bit more elaborated: The Payment Protocol (BIP70) has been proposed to offer a better UX and better security on the payment process. Beyond being a payment solution, the Payment Protocol also perfectly matches with a trade model based on fixed prices. But trade models are strongly linked to cultures. Considering that Bitcoin is a global currency, it shouldn't be limited by cultural bias. It should embrace cultural diversity by promoting different models. The Bargaining Protocol aims to transpose such an alternative model (based on prices negotiation) into the cryptocurrencies world.  This protocol should be a modern digital version of the bargaining process allowing: - provable negotiations: messages form a chain of signatures which ensures that the terms of the negotiation can't be forged
- trust-free negotiations: at every step, the seller is assured that the buyer owns the funds to cover the pledge
Because of its digital nature, the protocol should also help to build advanced use cases: - asynchronous bargaining: launch a negotiation, make a pause, complete later
- 1-to-N bargainings: a buyer (seller) can run multiple concurrent negotiations with multiple sellers (buyers)
Foreseen use cases: - human-to-human negotiations : online bazaars, ...
- computer-to-computer negotiations : automated negotiation of resources (on-demand cloud service provisions), dynamic negotiation strategies (A.I.)
- human-to-computer negotiations : automated negotiation for e-merchants (travel retail, hotels, cars renting, ...), negotiation assistant for consumers, ...
For the record: - the protocol takes inspiration in the Monotonic Concession Protocol from Games Theory (with some modifications: proposals are not simultaneous but sequential, more permissive stop conditions, ...)
- the protocol is a generalization of the Payment Protocol. Take the Bargaining Protocol. Remove the negotiation phase. Et voilà ! You've got the Payment Protocol (almost)
After the hackathon, I've spent some time to polish the code (i.e. rewrite the code), write draft specifications and release the whole thing on github: If you feel in mood for bargaining with a computer, try this DEMO which simulates an online wallet allowing to bargain with a seller (aka "MyStupidBot"). All comments, critics or suggestions are welcome. Kudos to @thibaultj who gave me a hand to build the first version of the demo during the hackathon. |
|
|
|
|
Show Posts
