Bitcoin Forum
June 22, 2024, 11:05:30 AM *
News: Voting for pizza day contest
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 [257] 258 259 260 »
5121  Bitcoin / Bitcoin Discussion / Re: Bitcoin-Qt / bitcoind version 0.8.0 released on: February 21, 2013, 04:06:23 PM
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?
5122  Bitcoin / Bitcoin Discussion / Re: Max Block Size Limit: the community view [Vote - results in 14 days] on: February 21, 2013, 03:18:18 PM
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.
5123  Bitcoin / Bitcoin Discussion / Re: Bitcoin-Qt / bitcoind version 0.8.0 released on: February 21, 2013, 03:06:18 PM
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.
5124  Bitcoin / Bitcoin Discussion / Re: The block limit will be raised. There are just no ifs or buts... on: February 21, 2013, 02:20:44 PM
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.
5125  Bitcoin / Bitcoin Discussion / Re: Max Block Size Limit: the community view [Vote - results in 14 days] on: February 21, 2013, 02:15:26 PM
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.
5126  Bitcoin / Bitcoin Discussion / Re: Max Block Size Limit: the community view [Vote - results in 14 days] on: February 21, 2013, 02:03:20 PM
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.
5127  Bitcoin / Bitcoin Discussion / Re: The block limit will be raised. There are just no ifs or buts... on: February 21, 2013, 01:55:48 PM
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.
5128  Bitcoin / Bitcoin Discussion / Re: Why the Bitcoin rules can't change (reading time ~5min) on: February 21, 2013, 01:48:09 PM
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.
5129  Bitcoin / Bitcoin Discussion / Re: The block limit will be raised. There are just no ifs or buts... on: February 21, 2013, 01:38:53 PM
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 Wink
5130  Economy / Service Announcements / Re: [ANN] Mt.Gox account verification delays and solutions on: February 21, 2013, 12:31:48 PM
https://mtgox.com/press_release_20130220.html

TOKYO, 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.
5131  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 21, 2013, 09:24:05 AM
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.
5132  Bitcoin / Armory / Re: Ubuntu LiveCD (offline wallet) + Win7 (online wallet) = no problem? on: February 20, 2013, 12:44:13 PM
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.
5133  Local / Español (Spanish) / Re: Busco personas de madrid que quieran invertir en un Asic mejor. on: February 20, 2013, 09:49:56 AM
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.
5134  Local / Español (Spanish) / Re: Busco personas de madrid que quieran invertir en un Asic mejor. on: February 20, 2013, 09:47:05 AM
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.
5135  Economy / Speculation / Re: Wall Observer - MtGoxUSD wall movement tracker on: February 20, 2013, 07:38:33 AM
I'm sure a lot of cold storage coins came out and went to avalon.

that pretty much equals selling.

No.
5136  Bitcoin / Armory / Re: Armory - Using Tails for secure Armory use on a single physical machine on: February 19, 2013, 09:00:16 AM
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 Smiley 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 Smiley   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.
5137  Bitcoin / Armory / Re: Importing Armory paper wallet backup without Armory on: February 18, 2013, 01:13:26 PM
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:

Code:
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:

Code:
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
5138  Bitcoin / Armory / Importing Armory paper wallet backup without Armory on: February 18, 2013, 11:07:42 AM
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?
5139  Bitcoin / Armory / Re: Creating an Armory USB drive for offline usage: which Linux distro? on: February 18, 2013, 11:04:04 AM
I like the UPR solution. Just a question: where I can find all the necessary packages to install Armory offline in UPR?
5140  Economy / Service Discussion / Re: Why doesn't Paypal shut down Virwox? on: February 15, 2013, 08:09:28 PM
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.
Pages: « 1 ... 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 [257] 258 259 260 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!