Nothing is sent though port 9332.
OK. It's simple a matter of waiting 'till "Got block..." messages finish.  |
|
|
|
Nothing is sent though port 9332. I've launched locally p2pool, bitcoind (0.3.23) and cpuminer (I know it is useless; just to test p2pool). p2pool and bitcoind inter-communicate well. Miner ("cpuminer") doesn't get in touch with p2pool. minerd -a cryptopp_asm32 -t 1 --syslog --url http://127.0.0.1:9332 --userpass dummy:dummy &
And the answer: Jun 27 11:12:30 anarres cpuminer[32184]: 1 miner threads started, using SHA256 'cryptopp_asm32' algorithm.
Jun 27 11:12:59 anarres cpuminer[32184]: HTTP request failed: couldn't connect to host
Jun 27 11:12:59 anarres cpuminer[32184]: json_rpc_call failed, retry after 30 seconds
Any clues? |
|
|
|
Soon, I'll try the process described in this thread, in a Debian box with an onboard nvidia card (not suitable for mining) on which a HD5570 card will be plugged.
Pray for me...
Success! I installed the card without problems, and after this, I followed these instructions (with a bit of problems... phoenix does not work) Now I'm mining! Next step: refine the process. |
|
|
|
|
Advice for Debian users:
1) the package "fglrx" does not exist. Instead, use "fglrx-driver" and assorted automatic list of packages.
2) Installation of fglrx-driver will uninstall all packages linked to privative nvidia drivers. So, nvidia and ATI-radeon can not coexist, if you want for both the privative libs and drivers. This is a known bug, with no solution (I can't provide links now, but search into bugs.debian.org).
Soon, I'll try the process described in this thread, in a Debian box with an onboard nvidia card (not suitable for mining) on which a HD5570 card will be plugged.
Pray for me...
|
|
|
|
I completely agree with you, but this will only be posible when the bitcoin exchange price stabilizes a bit.
Price stability will not matter at all. When BTC-market provide enough services & commodities, people can stop calculating tax rates... except those who receive there usual incomes in $, €, etc  I quoted my own message by mistake an I don't know how to delete it. Moderator can wipe this one. |
|
|
|
I completely agree with you, but this will only be posible when the bitcoin exchange price stabilizes a bit.
Price stability will not matter at all. When BTC-market provide enough services & commodities, people can stop calculating tax rates... except those who receive there usual incomes in $, €, etc |
|
|
|
I'm Debian user who soon will install a decent Radeon GPU on pci-e plug. My board has also a slum old Nvidia builted in. So, I'm curious how to manage both GPUs. I don't have the expertise you need. Anyway, I guess this is something related to xorg.conf. Search in forums "xorg.conf". P.S. look at this: http://forum.bitcoin.org/index.php?topic=17833.0 |
|
|
|
Thanks a lot for your feedback! I want to know, how to configure my host computer (Debian) in which I run bitcoin, to be reached externally.
As you didn't provide much information I'll just list all the possible errors in your method. - Bitcoin isn't running as a server/daemon
- You're using the wrong port when trying to connect (maybe try default port 8333?)
No. It's ok. Locally, I can "telnet" and "http" to localhost:8332 (with nonsense result, but it proves the daemon is listening). - You're trying to reach the server from outside the local network and haven't configured NAT and/or firewall exceptions in the router
The server has public address, with no NAT device. Perhaps I should take a peek to "iptables", but I think ports over 1024 are visible by default... - bitcoin.conf file uses whitelisting of IPs or is forbidding remote access
Only rcpuser and rcppassword are on bitcoin.conf. But this is worth to investigate: the options in bitcoin.conf I'll quickly go to the wiki to dig out the matter. Thanks again! |
|
|
|
After the last wallet steal, there is a strong recommendation to protect wallet.dat from trojans. I think one of the worst weakness of the actual development of bitcoin, is the mixing of client and server/daemon activities. AFAIK, the daemon does not need anyway the file "wallet.dat". So, I propose to separate both programs definitively. "Bitcoind" should have the data (except "wallet.dat") in ~.bitcoind directory. And "bitcoin" should have its own, let's say, ~.bitcoin directory with encrypted "wallet.dat". If the user has an active "bitcoind" daemon, "bitcoin" searches in ~.bitcoind the data for RCP-connection to the daemon. Eventually, "bitcoin" can connect to a remote "bitcoind" and then the program should ask for data connection, which eventually can also be hosted on ~.bitcoin. |
|
|
|
I see. Thanks for the tip. When SHA3 started, I was thinking around algorithm based on EC. But I finally I gave up. The problem with EC-hashing is the message splitting in blocks. If the message is one-block only, the EC is unfeasible. But if not, you must merge the different blocks some way. And EC has a "wonderful" property: A=a·Q, B=b·Q; (A+B)=(a+b)·QSo, it is not easy to merge the resulting EC-products in some non trivial way. Finally, the strength of the algorithm lies on the merging mechanism, not in EC itself. As far as I read, this attack points to this fact. My proposal targets an eventual inverse mapping (even if partial) weakness of SHA256, so EC is done almost at end, with only one block, result of previous hash. BTW, tt is possible to redefine h0 and h1 to discourage searching of collisions. |
|
|
|
I know, it is much more critical the scenario where elliptic curve (EC) fails, but EC is somehow safe. The insecurity of EC does not depend on smart cryptanalysis, but in advances on mathematics and/or quantum computing.
Cryptanalysis _is_ advances on mathematics. Uhmm... yes, may be. I mean "advance in mathematics" the kind of things that are shown with Theorems (see the capital...), such as the factorization of composite numbers. The kind of mathematics that are used in hash breaking are statistics and sometimes theorems (with no capital). I think a qualitative difference still stands.
It's also worth noting that EC based hashes were rejected as part of SHA3 (e.g. ECOH).
I guess because of the high consumption of computing resources (anyway, citation is needed, I agree). I come back to Satoshi's comment. Changing the hash function in the future looks mandatory. I'm sorry but, from his comment: - we probably don't need to worry before several decades. Optimistic prediction. May be true or not. Better to think the worst case. - we will have technical solutions to circumvent the problem.
I want to contribute to these solutions. Hardly the Achilles' heel.
(Check the wiki page on Weaknesses, it's listed there and you can see it's definitely not a top concern).
Energy better be used to tackle other shortcomings.
I don't agree this is not a big concern. ECDSA will break with quantum computing. SHA won't. I'd think ECDSA is the bigger risk.
Quantum computing is far to be technically functional. Similar situation as nuclear fussion: the theory and the technological environment is ready since decades, but the definitive solution is still far away. |
|
|
|
1. Uno de los modos para ganar bitcoins es el obtener un hash mediante computación matemática. Disculpad si la definición no es exacta. Mi duda con respecto a este sistema es, que según he leído, existe un límite de 21 millones de bitcoins posibles a generar. Que pasa si alguien usa un Ordenador Cuántico y en menos de 2 días obtiene todos los bitcoins que faltan?
Si alguien construye un ordenador cuántico de verdad, que funcione... entonces olvídate de bitcoin y de otras muchas cosas. Los bitcoins se generan a razón de 50 BTC por certificado de transacción. El sistema está configurado para generar ~6 certificados por hora. Si a lo largo de la generación de 2106 certificados se ve que esa tasa ha aumentado (porque alguien ha reventado el algoritmo de hash, por ejemplo), entonces la siguiente tanda de 2106 certificados costará más computación.
2. Si el sistema se basa en obtener bitcoins mediante computación, es una desventaja absolutamente clara para aquellos que tienen menos dinero para obtener ordenadores que generen hashes y ganar bitcoins. El sistema en principio beneficia más a los ricos.
La obtención de bitcoins mediante la generación de certificados supone un aliciente a los nodos para se dediquen a generarlos. Si no... ¿quién lo haría? Recuerda que bitcoin no es un sistema de loterías. Es una moneda para intercambiar mercancias y servicios. El uso de bitcoins favorece a todos, pobres y ricos, porque se salta la necesidad de un sistema centralizado de emisión de monedas y de costosas transferencias. Es cierto que la previsión era que en los primeros tiempos la moneda fuera inflacionaria (esto es, que tuviera cada vez menos valor) hasta que hubiera suficientes en circulación para permitir el comercio fluido (a partir de entonces se haría deflacionaria). Esa previsión se ha roto en el sentido de que la moneda está adquiriendo ya mismo valor, a pesar de que el comercio con ella es minúsculo. Y eso está favoreciendo marginalmente a los que tienen equipos más potentes... que los han comprado en dólares. Si en el futuro el valor de cambio BTC/dólar cae, entonces no está tan claro que "los ricos" hayan sido favorecidos. 3. En cuanto a la rentabilidad para obtener bitcoins, me gustaría saber realmente con un equipo normal, (CPU con 4-6 nucleos). aproximadamente si es rentable el ponerlo a trabajar en un pool de mineros o si el gasto generado por la electricidad y consumo es mayor y por tanto no es rentable. Como se puede saber?
Consulta la wiki de bitcoin al respecto (no tengo el enlace a mano). En general, te recomendaría que usaras la tarjeta gráfica para acuñar/minar BTCs. Si no la tienes, usa tu CPU aunque sea para ir probando. En cualquier caso, yo me olvidaría de considerar el acuñado/minado de BTC como un negocio. |
|
|
|
It is well known that Achilles' heel of bitcoin is the hash function: sooner or later it will be successful attacked and someone will got decisive advantage on mining because of (partially) feasible inverse mapping: hash -> block header. Really? I don't think so. Let's say an attack is found. It's only beneficial as long as it remains a secret. That's why the hash change should be done not too late, regardless the actual hashing breakdown state-of-art.
Once it is out in the wild, everyone uses it and the difficulty essentially just increases by whatever factor.
I come back to Satoshi's comment. Changing the hash function in the future looks mandatory. |
|
|
|
It is well known that Achilles' heel of bitcoin is the hash function: sooner or later it will be successful attacked and someone will got decisive advantage on mining because of (partially) feasible inverse mapping: hash -> block header. I know, it is much more critical the scenario where elliptic curve (EC) fails, but EC is somehow safe. The insecurity of EC does not depend on smart cryptanalysis, but in advances on mathematics and/or quantum computing. Indeed, Satoshi recognize this fact and proposed transition to eventual SHA3 in the future. In the linked post, Satoshi mentions the possibility that the breakdown comes suddenly. So I propose an ordered transition to a new hash scheme for block validation in about 4~5 years. I have a concrete proposal about this new scheme, that relays its strength on the elliptic curve mathematics. Let's see it. First, we must have a traditional non trivial hash function, that yields 256 bit output. Let's take SHA256. So, the process is: 1) h0 = SHA256(block header) 2) h1 = SHA256(h0); actually, h1 is the output to be compared with the target in order to validate the block. 3) m = h1 mod n, where n is the prime order of the curve. 4) Now an EC product is performed: R = m·Q, where Q is the fixed point in the curve. 5) r = Rx*p + Ry, where (Rx,Ry) are the coordinates of point R and p is the prime generator of the field 6) h2 = SHA256(r)7) h3 = h2 XOR h0. The process outputs h3 as the 256-bit hash to be compared with the difficulty-tuned 256-bit target. The strength of the process lies on the impossibility of back-mapping R -> m, in the same manner the strength of an EC-signed transaction does. It really does not matter whether SHA256 is broken or not, because the security is trusted to EC. The counterpart is the computation overhead: an EC-product could cost roughly 1000 times more than a hash computation. But... in the context of mining, does it really matter? The system should take care of this hashing change, thus the difficulty level should be decreased accordingly. The miners will work as hardly as before. Comments are welcome. |
|
|
|
I mean, if the mining card can be used at the same time as the running video card.
You may have to tune the miner frame-lag setting "up" to allow more processing for video, if you're doing things like watching movies or playing games while mining. This setting would vary depending on what miner software you're using. On momchil's miner this would be set with "-f 90" or so. OK, thanks. Sure I'll come back to the forums when I purchase a GPU. |
|
|
|
Gracias nuevamente. Si llego a tener exito te voy a mandar unos bitcoins. Finalmente esperemos que el Tio Sam no detenga al Bitcoin.
Que es lo que pueden hacer? Técnicamente... poco. Las redes P2P es lo que tienen ;-) Pueden acosar a los puntos centralizados del sistema (como este mismo site "bitcoin.org", por eso es muy necesario ir creando otros nodos de información) pero el mecanismo subyacente de funcionamiento es muy difícil de frenar. Y si lo hacen, siempre tendremos freenet. Económicamente, no puede prohibir usar bitcoins porque... no se están usando. Nadie paga impuestos ni multas con bitcoins ¿verdad? Y desde el punto de vista del liberalismo económico (que tanto gusta en Yankilandia) tú no puedes impedir que un comerciante acepte como moneda de cambio lo que le de la gana... vamos, como si quiere trocar unos patines por una clase de inglés. Sí pueden acosar a sitios como mtGox, donde se realiza el intercambio de divisas confiando en que si interrumpes la convertibilidad la moneda pierda valor. Eso es lo único que pueden hacer. |
|
|
|
Minar en el sentido tradicional de la forma de conseguir oro(Sig 1)
El significado 2 también es apropiado. Sugiero que para mantener congruencia nos peguemos a "minar".
En realidad el debate que he lanzado no era tanto en relación al término que deberíamos usar en este foro, sino en la información a otros medios hispano-hablantes. Particularmente, si tengo que explicarle esto a un periodista español, él/ella entendería antes la metáfora mediante el concepto "acuñar" que mediante "minar". |
|
|
|
Yes.
 |
|
|
|
|
Perhaps it is a dumb question but... can I use the actual video card for mining? I mean, if the mining card can be used at the same time as the running video card.
TIA
|
|
|
|
|
Show Posts
