I think the mnemonic algorithm is kind of weird (using quartets of bytes??) I suggest we use the full 2000 english words list with a complete base2000 encoding: any reason for doing that? Well, 2000 is an easier number to remember and that's the number of words in the wikitionary page anyway. Other wise you have to remember that 1626 is the lowest number n such as n**3 > 256**4 or something. That's a bit odd. But that doesn't change the final number of words in the mnemonic anyway, so I guess it does not matter much. However, I recently thought about using /usr/share/dict/words, which is -at least in french-, about 136,000 words long. This reduces the number of final words to height (for a 128 bit keys), which might be a significative improvment. |
|
|
|
Ahh I had the http and git address mixed up. Silly of me. Works fine now. Thanks. |
|
|
|
|
This is by far the longest last word I've ever seen.
|
|
|
|
I think the mnemonic algorithm is kind of weird (using quartets of bytes??) I suggest we use the full 2000 english words list with a complete base2000 encoding: def mn_encode( number ):
return [words[number],] if number < n else [words[number%n],] + mn_encode( number/n + number%n )
def mn_decode( wlist ):
r = words.index(wlist[0])
return r + n*(mn_decode(wlist[1:]) - r ) if len(wlist[1:])>0 else r
Well, the good thing is that anyone can do his own recipe with his client, as the server is not supposed to be aware of the particular encoding, right? |
|
|
|
Publish to CPAN?
Yeah I will eventually but I don't know CPAN much and I don't have a regular internet access so it might take some time. |
|
|
|
I know you guys you all like Python and do plenty of bitcoin-related stuff in this language and that's cool. But for people like me who are much more script lovers, a complete Perl bitcoin library would be great. So, while I was translating ThomasV's Electrum client, I happened to had written such a library. I think it is already awesome, so I think it worth publishing it. You can see the main POD in html here. The tgz is thereIn a nutshell, you can do stuffs such as: use Bitcoin qw(BTC);
printf "you owe me %d%s.\n", 10, BTC;
use Bitcoin::Address;
my $addr = new Bitcoin::Address '1DxH3bjYeCKbSKvVEsXQUBjsTcxagmWjHy'; # this does checksum verif
use Bitcoin::PrivateKey;
my $key = new Bitcoin::PrivateKey; # generates a random private key
print $key->address; # prints the corresponding bitcoin address
|
|
|
|
Some people have trouble understanding that i'ts easy to use an anonymous system in nominative mode and not the other way around.
The same people usually do not undestand either that we can have trusted third parties in a decentralized system (escrow, hosted wallets etc) but that we cannot turn a centralized banking system in a decentralized network like bitcoin.
Exactly. I had trouble phrasing it correctly but you nailed it. |
|
|
|
There are many virtues to decentralization, but reducing operating costs and improving performance (assuming equal costs) are not really among them. Some things appear to do so, but only because they are externalizing costs (e.g. shifting costs onto the most expensive last mile ISP paths, which is only 'cheaper' due to unsustainable all you can eat pricing, resulting in blocking/rate limiting, or hosting things on stolen resources).
Well, Terabytes of data are exchanged every day in P2P file exchange systems, and yet I have never heard of any donation campaign for them. Wikipedia costs a fair amount to operate, but only because it's so widely used. It comes down to something less than $0.05/yr per monthly visitor (actually more like, 0.02 but wikimedia is spending more than strictly necessary in order to develop new software and increase Wikipedia's usage around the world). The challenge for Wikimedia is that most of their visitors don't donate at all, and payment processing overheads would make operating on 400 million 5 cent payments still insufficient.
First, I want to say that I love Wikipedia. I contribute on the french site, I donated about 10EUR few years ago as I think it is the best thing that came up from Internet. However, I will NEVER ever donate anything again. Because there are two many things I don't like with this project. For instance, there are several Wikipedia editing rules I just don't agree with. That's one problem with centralization: you must agree with the whole package or go away. If you don't agree with one part, you can't use the whole thing. I also don't consider storing pictures to be important for an encyclopedy. And yet I assume this is one of the big cost for wikimedia. So I may accept to donate to "wikipedia", but certainly not to "wikimedia". Unfortunately, the wikipedia project is not separable from the wikimedia project. I use to argue that decentralizing Wikipedia (while retaining the property of having a single coherent website people could browse, rather than e.g. a forest of never updated forks, preserving user privacy, etc)
What is wrong with diversity??? There is no reason why there should be a *single* encyclopedic wiki. An encyclopedy could have a "editorial line". There would be nothing wrong with that. On the contrary. In Eric Raymond's metaphor, Wikipedia moves much more toward a "Cathedral" than a "Bazaar". And that's the main thing I don't like with this project. ... was actually impossible, but the bitcoin distributed algorithm disproves that. That said, many people complain about the time it takes to sync a full bitcoin node, it would be far worse with 400 gigabytes of article history and 12 TB of image data. So even ignoring the fact that it would cost more in total to operate it's not easy, and the required technology simply hasn't been built.
Yeah that why I think we should not fund old technologies with charity, so that people can have an incentive to imagine better technology. Of course, you can go to download.wikimedia.org, and pull a static dump and serve it up via a CGI and people do, but that isn't the same as decentralizing the sites* it's not getting the hundreds of updates per second, it's not providing a single, coherent, usable, and reliable view of the site. The prior attempts (for which there have been many) have all been laughable.
reliable: ok usable: ok coherent: ok single: WTF?  I'm sure if some bitcoiner wanted to build the technology to enable this they could find many patrons in the bitcoin and Wikipedia communities to sponsor their work. Sadly, it seems that on this subject most people are all talk.
Wait a bit. Some people will create a decentralized collaborative encyclopedy. But it sure won't help if people continue to support and fund wikimedia. |
|
|
|
|
Why do they need money in the first place?
I mean, it seems to me that they don't do any effort to decentralize the whole thing, so that computing and storage essources would be provided by users.
Somehow, I think it might be a good thing if the Wikimedia fundation could go bankroute. After all, the encyclopedy would not vanish. It's free so anyone could save it by just downloading it (I have a copy on my laptop with a CGI script to consult it and it works fine).
Once Wikimedia goes down, it would be a big incentive for other organizations to continue the project with other, fresh ideas.
|
|
|
|
Bonjoru, ca fait longtemps que je suis sur le forum en "lurker". Quelqu'un peut m'expliquer pkoi je ne peux pas poster sur les autres forums ?  Je crois qu'un minimum de posts a été exigé avant de pouvoir poster sur d'autres forums que ceux consacrés aux newbies. |
|
|
|
As I am translating the client, I have a few comments/suggestions: - Shouldn't the wallet store its own version number? Otherwise we'll need to guess it when we recover an old wallet. - It would be nice if a standard data format such as JSON was used to communicate with the server - The 'for_change' thing in 'create_new_address' is a bit odd. I suggest considering the created address to be 'for change' when no password is provided. - In the wallet, addresses should be stored in a dictionnary, not an array. Pretty much everything should be stored in a dictionnary anyway. We don't need sequential access, except maybe for the change_addresses index. - There is way too many Object Orientation in the code, imho. Objects are useful when instanciation is needed. Otherwise packages or modules are just fine. Other ideas I may forget may be seen in my repo: http://github.com/grondilu/Perlectrum in Bitcoin/Electrum/Client.pm |
|
|
|
Bonjours à tous je viens de découvrir l'existence de cette monnaie,je ne comprends pas encore comment l'utiliser et l'obtenir mais ce moyen d'échange me parait prometteur.
J'espère en comprendre le fonctionnement et les possibilités d'usage par le biais de ce forum.
Bonjour et bienvenu. Pour comprendre comment fonctionne bitcoin, amha le mieux est encore et toujours de lire et relire le papier de Satoshi en personne: http://bitcoin.org/bitcoin.pdf |
|
|
|
The more I think about it, the more I think this stuff is really good. For at least two reasons: 1. It separates the client code from the server code, making two clearly distinct applications. What is good about this is that it gives much less possibility for a troyan to be harmful in the server code. 2. This idea of generating keys deterministically from a seed that can be memorized is just a great idea. The official bitcoin client should propose something like this as an option. I'd like to nominate ThomasV for a Satoshi award or something  Anyway, I have a question. I don't quite understand this random number generation algorithm (the "randrange_from_seed_trytryagain"). It seems overly complicated to me. If I must pick a random number from 0 to n, where n < 2**256, I would just do this: x = randrange(0, 256) for i in range(32 + 4): x = 256*x + rand(0, 256) return x % n Maybe there is something I miss mathematically here, but basically why can't I pick a number from 0 to p where p is fairly larger than 2**256 (say, 256**4 times), and then take the remainder modulo n? |
|
|
|
Damn, developping a client in Perl is much more difficult than I thought, but I really want to do it as I am not comfortable with python code. I had made a mistake creating the repo (I wrote Perlelectrum for the name instead of Perlectrum). It's now corrected (I guess): http://github.com/grondilu/PerlectrumAny other Perl adepts here? If so, please help. |
|
|
|
And again right after that...
The public key serves as an address to which Bitcoins can be sent,"
(the address contains a hash of the public key, and a checksum of that hash, but not the public key itself, which is not disclosed until funds are sent away from that address. I'm sure someone will correct me if I wrong here.)
Well, the public key is used to make the hash, which is encoded in Base58 to make the address, so in a sense the public key serves as an address. When the guy says "the public key serves as an address", it does not necessarly mean litterraly. |
|
|
|
Bonjour, J’ai voulu tester bitcoin avec un collègue, l’ayant installer depuis quelques temps déjà j’ai pu récupérer 0.0005 bitcoin par le robinet. J’ai voulu donc envoyer 0.001 bitcoin à mon collègue et j’ai eu le message suivant : « cette transaction est au delà de la limite de taille. Vous pouvez tout de même l’envoyer moyennant des frais de 0.0005, qui ira au noeud gérant votre transaction, et qui aidera à soutenir le réseau. Acceptez vous de payer ces frais ? » CF image http://www.2aa.be/2011/bitcoin3.JPG Je pensais que le service était gratuit ? La gratuité existe-t elle vraiment ? Y a-t-il un tarif des transactions. Merci Cordialement Il existe un montant minimal pour les transactions, et ce afin de résister à une attaque par inondation du réseau. Il n'y a pas si longtemps cette limite était fixée à 0.01. Il n'y a pas de "tarif" des frais de transactions. Les frais sont entièrement déterminés par ce qu'exigent les mineurs. En pratique, il y aura toujours des mineurs qui acceptent de traiter les transactions gratuitement (puisqu'ils empochent de toute façon toujours la génération). Mais ça prend forcément plus de temps. Si tu veux "tester" bitcoin, le mieux c'est d'utiliser le réseau de test, s'il est encore en service (je suppose que oui). |
|
|
|
Je le sens bien ce projet: https://bitcointalk.org/index.php?topic=50936.0Pour moi c'est idéal vu que je n'ai pas de connexion régulière au net. Mais même dans un ordre général je trouve que c'est une bonne idée de séparer d'une part la gestion du portefeuille de clef et la signature des transaction, et d'autre part la gestion du nœud du réseau (traitement des blocs). Un projet à suivre attentivement amha. |
|
|
|
|
Show Posts
