Search content
Sort by
Showing 20 of 86 results by gim
Idéalement tu as créé une branche séparée pour ton commit et tu peux utiliser le bouton "Fork queue" pour tenir master à jour
Je crois pas que ce soit humainement possible d'utiliser le "Fork queue" de github sur un projet comme Bitcoin. Où alors je veux bien que tu m'expliques comment ^^
Rien de tel qu'un bon vieux "git pull" a mon avis.
"Casser" une fonction de hachage h revient à l'une ou l'autre des possibilités:1/ inventer un algo permettant de retrouver x à partir de h(x).2/[...]
Juste pour préciser, trouver un algo qui inverse le hash c'est pas dur (l'espace de départ étant récursivement énumérable).
Trouver un algo qui permet de trouver un résultat en moins d'une vie (même aidé d'un gros ordinateur), ça c'est plus dur.
Je suis inculte en crypto, mais c'est bien possible que pour certains hashs il y ait des résultats sur la complexité minimale d'une solution pour 1/. Ça ne vaut certainement pas la peine d'essayer dans le cas général. Quelqu'un connaît des références?
lis ça : http://econoclaste.org.free.fr/dotclear/index.php/?2011/03/08/1773-le-mythe-de-l-obsolescence-programmee
tu vera que ce n'est pas un si bon doc que ca
tu vera que ce n'est pas un si bon doc que ca
Je me suis arrêté de lire à la moité, ce texte est complètement vide.
Ce qui ne fait que confirmer l'aveuglement de l'auteur.
J'essaye même pas d'y trouver une logique.
Il met en gras une évidence, et réfute on ne sait quoi par l'absurde avec un argument qui ne tient pas la route.
Dans le paragraphe suivant il remet en doute l'évidence... Tout cela n'a aucun sens.
Code:
0 addresses found from DNS seeds
For the live connection, this list is not empty (it has 48 addresses). If I operate on the assumption that the live connection was NEVER able to connect to IRC, then it got that seed list from somewhere.
There is no DNS seeding available for the testnet work. Current options are IRC connection or using static --addnodes.
I've resurrected the original pull request.
This should reduce disk access. Please tell us whether this helps or not.
This should reduce disk access. Please tell us whether this helps or not.
only thing is the tests won't run, am i doing something wrong?
Quote
(.text+0x20): undefined reference to `main'
Same here, there's some '#define BOOST_TEST_DYN_LINK' missing.
But, anyway, there are just two boring tests available for now.
So, be patient
I wanted to share some thoughts about how Webcoin is going to handle DWs.
Nice! We need this everywhere.Wallet's private data is 1 Random number, all the rest can be derived from it.
De bonnes boites de conserve bien orienté pour faire du wifi longue portée 
Oui ça marche très bien 
Right, so I spend to that "revoked" address using an ewallet provider and the coins don't come back to me.
E-wallet providers should check that transactions are validated anyway. So, I'm sure they can bear with that.(For now, everything is "standard" on the real network)
Let's say the FSF's bitcoin private key has just been compromised.
Current funds available at this address will probably be stolen, but that's not the problem discussed here.
Of course FSF will change wallet and public address... but donations to the old public address will keep on.
(Some people have stored the old address in their Address Book, some others will find the old FSF address on bitcoin wiki, etc...)
So, the FSF would also like to revoke their old public address, because they don't wan't to play the "who will spend new credits first" game with the thieves.
The problem is that there is no revocation procedure available in Bitcoin.
Do you think such a feature would be useful?
---
"Half-baked" implementation proposal:
A special revocation transaction containing public keys (and signed with associated private keys) that can be included in a block. Miners understand those transactions and are forced to reject any following transaction that could be unlocked by those keypairs. (Note: this work only for standard tx)
Current funds available at this address will probably be stolen, but that's not the problem discussed here.
Of course FSF will change wallet and public address... but donations to the old public address will keep on.
(Some people have stored the old address in their Address Book, some others will find the old FSF address on bitcoin wiki, etc...)
So, the FSF would also like to revoke their old public address, because they don't wan't to play the "who will spend new credits first" game with the thieves.
The problem is that there is no revocation procedure available in Bitcoin.
Do you think such a feature would be useful?
---
"Half-baked" implementation proposal:
A special revocation transaction containing public keys (and signed with associated private keys) that can be included in a block. Miners understand those transactions and are forced to reject any following transaction that could be unlocked by those keypairs. (Note: this work only for standard tx)
debian, canonical, microsoft etc...
Tu veux vraiment que je te donnes tous les noms de fabricants d'OS ?
Tu veux vraiment que je te donnes tous les noms de fabricants d'OS ?
Non, tous ces gens n'ont jamais accepté de prendre la moindre responsabilité.
Faute d'autorités compétentes pour l'assumer, les utilisateurs sont entièrement à charge de la sécurité de leur système.
Je vais citer le passage en majuscule qui existe (sous une forme ou sous une autre) dans les licences de ces OS...
Quote from: GPL
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL AND COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL AND COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
Edit: Je cherchais depuis quand ce thread est parti en vrille, mais en fait c'est depuis qu'il a été placé dans la section "Hors-sujet"...
D'ailleurs, si le sujet c'est Bitcoin, la moitié des threads qui sont ici ne sont pas (ou n'étaient pas) hors-sujet. Peut-être qu'il faudrait le renommer en "Expression libre" ou quelque chose dans le genre.
Les responsables qui définissent nos systèmes de sécurité d'aujourd'hui sont juste de gros incompétents.
Ah, il y a des responsables ?
Sur qui il faut tapper ?
)Allow scripting in Bitcoin, so that they can share ownership of the coins with their previous owners for a while.
They can decide later what to do with the remaining coins.
(It would be fantastic if this kind of operation was offered in the client.
Mistakes could be reverted safely and anonymously.
Of course this requires that the coins are from a standard address.)
They can decide later what to do with the remaining coins.
(It would be fantastic if this kind of operation was offered in the client.
Mistakes could be reverted safely and anonymously.
Of course this requires that the coins are from a standard address.)
I've thought about this as well. Simply force the '.' in the middle and regard it as two fields, one right aligned and the other left-aligned. Pressing the '.' while in the first field will jump to the second field.
I'm going to implement this and see whether it is useful.
Best thing to do IMHO. Great!I'm going to implement this and see whether it is useful.
(changez vos mots de passe !)
Oui ! Si vous avez utilisé votre mot de passe MtGox sur d'autres sites, changez le immédiatement !Pour info, les échanges vont rester gelés quelques temps sur MtGox, le temps d'inverser les opérations illégitimes.
Britcoin ferme temporairement pour protéger leurs utilisateurs.
Les autres plate-formes de trading voient leur activité augmenter assez rapidement, et le cours des bitcoins reste raisonnable sur ces échanges.