Another question: I see that now the client recommends a transaction fee of 0,01 per KB. That's quite an increase compared to the prior "recommended fee", which was 0,0005 if I my memory is not failing. What do you think about this? Personally I will set up the client that way, I like miners getting fair rewards for processing transactions.
Now a "n00b" question: is there a quick way to calculate how many kb will have your transaction?
|
|
|
I want to see concrete numbers: How many bits per second in transfer and how many transaction verifications per second can an average computer do?
Keep in mind that if I count the average in my household, the average PC has ~3 cores with ~2 GHz, ~6 GB RAM and about 2 TB of HDD space. In other areas of the world that might not even be reality in 5 years...
I'm sorry but I'm a non-technical user. Anyhow, it's not hard to see what is the "average computer". Just check the specs of a 5 years old Vaio, Apple laptop, personal-use computer. Of course that many people in Africa could not run a super note due to specs/network limitation. But the whole point of this is to prevent super companies being the only players able to run a full node. Something that can run in a standard, 5 years old, "personal use" computer by Dell, Apple, Sony Vaio, etc. would be definitely OK. If you want me to be more specific: I would say that right now we would be looking at an Intel Core 2 2GH, 2GB RAM and 250MB of HDD space.
|
|
|
Running well on Mac OS X 10.8.2 but the context menu entries when right-clicking on the Dock-item are gone for whatever reason.
Same thing here. If you click on "close window", then you are unable to open it again. You close the window, you have to quit the client and restart. In the old version, if you closed the window you could open it again just right clicking on the Dock-item and selecting "send bitcoins", "receive bitcoins" or whatever you wished to do.
|
|
|
Smaller blocks = more difficult to get your transaction verified = higher fees to get your transaction on a block. Smaller blocks = more difficult to get your transaction verified = frustrated users = lower adoption = possible failure of the currency Exponential growth in block size = impossibility for average users to run a full node = bitcoin becomes a centralized system where mining supercompanies set their own rules, ala "central bank" = FAIL If you want superfast, near free transaction you have credit cards, or paypal-like services. Or ripple, or systems built on top of Bitcoin. Bitcoin's value is in its decentralized nature. That's what attracted most of us. It's a secure and decentralized p2p system, and because of this it's an extremely clever store of value. Kill the decentralized nature and you will kill bitcoin. I don't disagree with you. Given your thoughts on the matter though, I do however wonder what you would consider to be the "correct" blocksize? Is 1MB too big? Should we limit it to 500kB to increase decentralization? How about 5MB? Would that be ok? How do we determine the "correct" blocksize right now, and how do we adjust the "correct" blocksize for changes in technology in the future? I would like a blocksize that allows the average user, with an average connection and an average computer (let's say 5 years old "personal computer") to run a full node. I know this a non-technical, vague statement. But I think that we should work out a technical solution to achieve that.
|
|
|
I want a blocksize that allows the average user, with an average connection and an average computer (let's say 5 years old computer) to run a full node. Could you please clarify this a bit more? How does a user with a 5 year old computer and an "average" (what is "average"?) connection benefit the network by operating a full node? How will "average" computers and connections look in 20 years? Average users being able to run full nodes means average users being able to verify and sign. Means average users being able to prevent that a few super-nodes change the rules at their own will. In 20 years "average computers" and "average connections" will grow. The rule is simple: for me too big is what an average computer cannot handle. What about an "average connection"? If you cannot run a full node through Tor, then it's not good. Don't forget that btc could be attacked by governments and other factual powers.
|
|
|
I want a blocksize that allows the average user, with an average connection and an average computer (let's say 5 years old computer) to run a full node.
The magic of bitcoin is its decentralized nature: make it possible only to super-companies to run full nodes, and you will have a new central bank... And bitcoin will die.
|
|
|
Smaller blocks = more difficult to get your transaction verified = higher fees to get your transaction on a block. Smaller blocks = more difficult to get your transaction verified = frustrated users = lower adoption = possible failure of the currency Exponential growth in block size = impossibility for average users to run a full node = bitcoin becomes a centralized system where mining supercompanies set their own rules, ala "central bank" = FAIL If you want superfast, near free transaction you have credit cards, or paypal-like services. Or ripple, or systems built on top of Bitcoin. Bitcoin's value is in its decentralized nature. That's what attracted most of us. It's a secure and decentralized p2p system, and because of this it's an extremely clever store of value. Kill the decentralized nature and you will kill bitcoin.
|
|
|
Thanks Hazek. Brilliant post. We, the users, want to be able to run full nodes. That's bitcoin, and that's why we are in.
|
|
|
Both MtGox and SatoshiDice stand to lose if the block size is increased. MtGox because it will raise their costs (higher transaction fees). SatoshiDice because they could not accept low value bets.
I think you are mistaken. The fees go up (making low value bets impossible) if the block size is NOT increased. Your understanding of this appears to be backwards, and you may wnat to look into it a bit more. (or else I'm completely confused) You are right, Danny. Smaller blocks = more difficult to get your transaction verified = higher fees to get your transaction on a block. Quite simple even for non-techies like me
|
|
|
https://mtgox.com/press_release_20130220.htmlTOKYO, JAPAN - February 20, 2013 - Due to the increasing number of new Mt.Gox users who have been applying for verification status, we have been experiencing some delays in reviewing everyone's applications within the last few weeks. Please accept our deepest apologies regarding this matter. Also, to put an end to this delay, we would like to announce that we have three new staff in training, to work alongside our working team of four, and scheduled to be deployed on the 2nd week of March. Once again, please accept our deepest apologies on this delay as we are working hard on handling this issue as fast as possible. Regards Mt.Gox Co. Ltd Team. Media Contacts press@mtgox.com I see that you just added a handy "position in verification queue". Nice, that should avoid users asking about where they are standing at. Anyhow I'm in position 320 after a full week. I did not move any position during this morning, hope that moves fast. It's really a problem to be willing to enter such a volatile market and having to wait for more than a week to start trading.
|
|
|
Please don't forget that what attracted most of us the users is the decentralized nature of bitcoin. We want a secure p2p network that serves as a store of value.
I feel your pain - managing the blockchain with increasing transactions per second will be a pain - but the top priority should always be avoiding centralization.
|
|
|
Title says it all maybe, but to elaborate (and very sorry if this has been answered, couldn't find it explicitly mentioned anywhere).
I want to setup Armory as follows: 1. Offline wallet on Ubuntu LiveCD (USB-stick). 2. Online wallet on my Windows 7 installation.
I will switch between offline and online wallet using the same PC.
Will the wallet created from the Ubuntu LiveCD-environment work effortlessly with my Armory Windows installation?
I have the same setup, but with MacOSX as an online environment instead of Windows 7. It works effortlessly and smooth.
|
|
|
Entonces me recomendais mejor invertir ahora en un sistema GPU, ? Una grafica de unos 150 euros cuanto tiempo tarda en rentabilizarse?
A parte no voy a negar que me viene bien comprar una grafica... ya que ando con la grafica del micro I5... osea un intel graphics de mierda.. xDDD
Lo bueno que la grafica la puedo sacar por mayorista y sin pagar iva gracias a la empresa donde trabajo a media jornada... por lo que puedo coger una mejor al mismo precio al salirme mas barato que en tienda.
Un saludo
Con GPU no vas a sacar nada. Menos aún cuando ASICminer ponga en marcha los 20TH que tiene previsto, y aún menos cuando lleguen los Avalon y los BFL (si es que estos llegan algún día). Ya que buscas rentabilidad, te recomiendo que estés atento a cuando se anuncie la segunda generación de ASICs. En ese momento decide si quieres hacer un pre-order, o si prefieres comprar una participación de alguna empresa tipo ASICminer que te de confianza.
|
|
|
La idea sería buena si se hubiera planteado en Agosto del año pasado. Cualquier player nuevo se ha quedado fuera. Los verdaderos triunfadores son los afortunados y escasos poseedores de los pocos ASICs de Avalon que se han entregado, y los que compraron acciones de ASICminer, que ya está hasheando desde el 14 de Febrero. Las estimaciones recientes son que, con la dificultad actual y casi sin competencia por los retrasos de Avalon y sobre todo BFL, ASICminer está minando aprox. 500 BTC al día. Los inversores recuperarán los 0.1BTC que se gastaron por acción antes de llegar a Marzo.
Si preguntas a BFL por un pedido puesto hoy te dirán que el envío (que no entrega) está previsto para Junio. Y nadie te asegura que cumplan las fechas, ya que no han cumplido ni una sola hasta ahora.
En resumen: comprar un equipo ahora es arriesgarte a recibirlo cuando la dificultad sea tan alta como para sacar poquísimos BTC/mes. Si el precio del BTC sube a 100€, quizás compense. Pero es una apuesta arriesgada, yo no lo haría mirando la rentabilidad. Sí lo haría si tuviera pasta de sobra y quisiera colaborar por la estabilidad de la red y de paso sacarme unos satoshis, pero teniendo claro que hay un muchas posibilidades de que ni siquiera puedas recuperar la inversión.
|
|
|
I'm sure a lot of cold storage coins came out and went to avalon.
that pretty much equals selling. No.
|
|
|
wachtwoord, dude, I gave you the link to official Tails description on how to use Truecrypt, how can I unambiguify it more? Except if you are using some software called TrueScrypt, I can`t help then, lol Also I won`t teach you how to use Truecrypt itself, I`ll leave it to very good documentation and Mr. Google I suggest you to install Tails with its built-in installer to USB and configure Persistent volume with built-in configure tool. It is easier and more "official way" than Truecrypt in Tails. Come on N.Z., go a little easy on the linux-n00b I remember those days... lots of confusing command line arguments, figuring out how to re-add windows to my grub menu, the dreadful "kernel panic"... great fun! If I get some time, I might try the Tails thing, too. Maybe I can write up a more-specific instructions. I think having an 'offline" setup that doesn't require separate hardware is a nice alternative. Specific instructions for Tails or UPR would be great. Or even better, a downloadable ISO including armory for a Tails / UPR livecd. The only inconvenience in Tails is the difficulty in creating an USB with persistence that will boot on macs. I found a workaround using one CD with refit + Tails USB 1 made with Unetbootin + Tails USB 2 made with the Live USB Installer inside Tails. The system will boot with the CD + USB 1, but the OS will run in USB 2, with persistence (don't ask me why). If you use only refit + USB 2 Tails will not boot on a mac. It's not the best way, but at least works.
|
|
|
Imagine I create an offline wallet with a Linux LiveCD. I print a paper backup (or save an encrypted copy of the PDF), and I send all my savings to the addresses in that wallet.
In 10 years I need to access my funds. Imagine that Armory was discontinued, I don't have any copy of the old Armory I used to produce the paper backup, and I only have the piece of paper with me. Can I import that wallet to the standard Bitcoin-Qt? Is any way to retrieve the private keys in the Armory wallet using the paper backup, but without using Armory?
You have to know the algorithm that was used to recreate the keychain from the data on the paper backup. This has been the same ever since the very first release of Armory, and it's not complicated. Brainwallet.org has the algorithm implemented in javascript. Even when I update Armory to the new wallets, it will still have support for the old ones. I find it difficult to believe that even in 20 years, it would be impossible to find any copy of Armory that ever existed. Information persistence on the internet is pretty good. If you are still concerned about it, it you can write down the algorithm yourself. It will fit in the corner of the piece of paper. Or you could print off the piece of code, which is a bit more verbose, but will still fit on one piece of paper: SecureBinaryData CryptoECDSA::ComputeChainedPrivateKey( SecureBinaryData const & binPrivKey, SecureBinaryData const & chainCode, SecureBinaryData binPubKey) {
if( binPubKey.getSize()==0 ) binPubKey = ComputePublicKey(binPrivKey);
// Adding extra entropy to chaincode by xor'ing with hash256 of pubkey BinaryData chainMod = binPubKey.getHash256(); BinaryData chainOrig = chainCode.getRawCopy(); BinaryData chainXor(32); // XOR hash of pub key and chain code for(uint8_t i=0; i<8; i++) { uint8_t offset = 4*i; *(uint32_t*)(chainXor.getPtr()+offset) = *(uint32_t*)( chainMod.getPtr()+offset) ^ *(uint32_t*)(chainOrig.getPtr()+offset); }
// Hard-code the order of the group static SecureBinaryData SECP256K1_ORDER_BE = SecureBinaryData().CreateFromHex( "fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141"); CryptoPP::Integer chaincode, origPrivExp, ecOrder; // A chaincode.Decode(chainXor.getPtr(), chainXor.getSize(), UNSIGNED); // B origPrivExp.Decode(binPrivKey.getPtr(), binPrivKey.getSize(), UNSIGNED); // C ecOrder.Decode(SECP256K1_ORDER_BE.getPtr(), SECP256K1_ORDER_BE.getSize(), UNSIGNED);
// A*B mod C will get us a new private key exponent CryptoPP::Integer newPrivExponent = a_times_b_mod_c(chaincode, origPrivExp, ecOrder);
// Convert new private exponent to big-endian binary string SecureBinaryData newPrivData(32); newPrivExponent.Encode(newPrivData.getPtr(), newPrivData.getSize(), UNSIGNED); return newPrivData; }
That function is how to get from one private key n to private key n+1. The only other thing you need to know is how the "easy-type-base64" alphabet maps to hex: NORMALCHARS = '0123 4567 89ab cdef' EASY16CHARS = 'asdf ghjk wert uion'
The mapping was chosen to make slightly obfuscate the data, but also because it's easier to type than raw hex (most people don't touch-type numbers well). Thanks for your prompt reply. New wallets on the way? Could you point me where I can find some info about these new wallets? Thanks
|
|
|
Imagine I create an offline wallet with a Linux LiveCD. I print a paper backup (or save an encrypted copy of the PDF), and I send all my savings to the addresses in that wallet.
In 10 years I need to access my funds. Imagine that Armory was discontinued, I don't have any copy of the old Armory I used to produce the paper backup, and I only have the piece of paper with me. Can I import that wallet to the standard Bitcoin-Qt? Is any way to retrieve the private keys in the Armory wallet using the paper backup, but without using Armory?
|
|
|
I like the UPR solution. Just a question: where I can find all the necessary packages to install Armory offline in UPR?
|
|
|
so, how do they keep the chargebacks low? By limiting the amount one can deposit, not having instant withdraw. Honest/longterm customers can enjoy higher limits building a steady amount of "no-risk" transactions. This is it.
|
|
|
|