don't know wether this is know, but just discovered a bug in the amount entry field. to reproduce. - enter 1.456
- hit cursor left 3 times
- enter "123"
- see "0.145623" instead of the expected "0.123456"
The cursor is always put to the end of the text after entering something. Same for "fee" textbox. I just wanted to say this. It's very annoying and can lead to sending wrong quantities. Using Ubuntu 12.04 64 bits.
|
|
|
¿Es posible que tengas un troyano keylogger o algo por el estilo?
En cualquier caso te recomiendo un yubikey. A mi me dieron uno gratis en marzo por la creciente cantidad de robos. Con un yubikey (o cualquier otro método de autenticación de 2 factores) no pueden entrar a tu cuenta ni aunque tu ordenador esté comprometido. Es un pincho USB que simula ser un teclado y genera una clave de un solo uso al pulsar su botón.
|
|
|
Hello! My fromaddr/changeaddr feature I added in february no longer works. Here's a patch: diff --git a/electrum b/electrum index d927860..0c9c234 100755 --- a/electrum +++ b/electrum @@ -439,10 +439,12 @@ if __name__ == '__main__': else: keypair = from_addr from_addr = keypair.split(':')[0] - if not wallet.import_key(keypair,password): - print_error("Error: Invalid key pair") - exit(1) - wallet.history[from_addr] = interface.retrieve_history(from_addr) + wallet.import_key(keypair,password) + + wallet.interface.get_history(from_addr) + print "Waiting for history (warning: this won't timeout)" + while not from_addr in wallet.history: + sleep(0.1) wallet.update_tx_history() change_addr = from_addr
Is the wallet saved automatically now? If I hit ctrl+C while waiting for the history it seems it's saved...
|
|
|
The "alt-chain" term confuses people. It's more like a "sub-chain" of the main blockchain. It doesn't generate any coins at all, and it's a temporal fix until the majority of miners support it.
|
|
|
Hola, yo uso Linux y sólo he usado cgminer.
|
|
|
My tree structure guarantees that you can not only get any TxOut, but you can get all TxOuts for a given address/script and have no doubts that it's correct. I always saw that a separate issue/feature of my proposal (i.e. not necessary for starting and deploying an implementation), also making things simpler. Sometimes (actually most of the time) you just need to know an output hasn't been spent. If you need the balance and someone gives you a list of outputs, you can be sure those outputs are unspent; the only thing remaining is knowing if *all* the outputs are given to you. That's easy to solve. I'm thinking of several solutions that doesn't require full nodes to build and verify the tree. For example having a separate tree, address-based instead of chain-based, which just stores the number of unspent outputs (removing the key if the value is 0). Initially, though, we can just query several nodes to give us the count of unspent outputs and trust the majority.
|
|
|
About rolling out new features and avoiding block chain splits, what we need is a good automatic system to automatically and democratically add any feature. Just like the implementation schedule of p2sh but being more like my proposal: time-flexible, with an additional temporal sub-chain, and for any feature. It may be difficult and problematic to code it only for one feature, but IMHO it's worth it if it's a generic implementation-deprecation system for determining the validity of blocks.
|
|
|
You are discussing two issues that IMHO it's already resolved in my proposal or a followup:
Efficient tree update: The update functions only recalculates the hashes affected by the changes of each block. Those changes can be reversed, as long as the block is valid (i.e. there's no double spends), therefore it will be easy to roll-back in case of getting orphaned blocks.
Where to save the roots: In my proposal I explain how to roll it out in the coinbase of the existing chain, but nullifying the risk of a chain split by rejecting blocks with invalid root only when there are more than 55% of valid roots in a specific time span.
For extra security (and this is what isn't originally in my proposal), the root should be accompanied by a hash of the previous+current valid roots, effectively making a secure blockchain from day one. But after it's deployed widely, it will be unnecessary, as we'll know miners will reject blocks with invalid roots. Miners won't reject blocks without roots. Blocks with valid root but without this blockchain-ish hash won't be rejected either (so we can drop this hash when it's not longer necessary).
In this way, creating a separate chain is just a temporal fix for something that will be in the main chain some day.
|
|
|
I always send payments as donations. My new bank has a drop-down list for selecting the purpose of the wire, and I select "unregistered donation" there.
I donate money, people donate me bitcoins. Sometimes it's the opposite.
If the sender of the money issues a chargeback, you lose the money, but that's the purpose of bitcoin.de ratings. Better to lose small amounts than have an account frozen. I can't wait to have ratings at bitmarket.eu.
|
|
|
the one I provided may have too much noise and include broken links
I've been checking the links in the wiki for the past 4-5 hours. I've removed all broken links, and some e-shops which don't have bitcoin as payment option has been marked as such. Web design in most links is AWFUL (even in the design section). It was difficult to check all links without wanting to rip my eyes off. Also it's very poorly categorized. I've put a warning in sites with autoplay music or sound. Now the problem is the noise. There are too many sites that aren't of interest of almost anybody but happen to accept bitcoin donations. I've found some gems, though. I didn't know uploaded.to (which I use sometimes since megaupload was shut down) could be payed in bitcoins. One musician that I used to listen several years ago also accepts bitcoin (paniq, part of the demoscene group farbrausch).
|
|
|
The only vulnerability known to ECDSA are timing attacks (measuring how long it takes to generate a key). Bitcoin does not suffer of this because it always generates a pool of keys instead of a single one and there's no way of knowing how long it took (at least with the implementations I've seen).
|
|
|
Deberían desfijar este hilo, hace ya tiempo que pasó lo de MtGox y mejoraron mucho la seguridad. A mi ya me robaron, mi error fue tener la misma contraseña en casi todos los sitios,
Eso sí que debería estar fijo: Nunca jamás uséis la misma contraseña en todos los sitios. Os recomiendo esto, que os genera una contraseña diferente a partir de una contraseña maestra: OplopPor ejemplo, para obtener mi contraseña para entrar a este foro, voy a Oplop, pongo "bitcointalk" en el primer recuadro, mi contraseña maestra en el segundo y obtengo algo como esto: uAv9hzjv Ese sitio web es javascript (no se envía nada al servidor) y está el código para bajar, así como versiones para móviles.
|
|
|
People really need to stop using these centeralised services nad start using stuff like bitcoin-otc
Bitcoin-otc is too hard to use for most users. The best non-centralized exchanges I know are http://bitcoin.de and http://bitmarket.eu (used mostly by europeans like me).
|
|
|
I think the best client is Electrum. It's simple, easy, fast and best of all: it's very easy for me to modify the code to suit my needs. I've modified it to send transactions from any address I want just by having the private key, sending the change to the same address and without needing to import it.
After Electrum, the best one is blockchain.info, I agree. I suggest piuk to add a bigger button for entering the wallet. Each time I want to enter I find a bit difficult to find wallet, then login. Also, when you type the pseudonym in the login field and go to the password field, the login field should change automatically instead me needing to press the button, waiting and then type the password.
Edit: I agree with BitcoinSpinner also being great! I've done half of my transactions to date with it!
Edit 2: My 100th post! Woo!
|
|
|
Also, one can never buy all bitcoins in existence and a market will be always there, even if there's only one bitcoin remaining.
|
|
|
Sorry again! I did send the refund with no fees and it took forever.
|
|
|
edit: version 0.39b fixes a bug in the wallet creation procedure
What bug? Now the code is prettier but it doesn't work. I've added 3 lines and made a pull request. Edit: updated pull request with two fixes.
|
|
|
|