4741khash/s, whatever that means.
Specialized programs can be used with your GPU. You'll have much better results. |
|
|
|
|
You will gain 2.2 btc by year, in a pool (and less with difficulty increase). It helps the network a bit, but this is not significant for now, because an equivalent to the total hashing power can be obtained with botnet or amazon services for example.
|
|
|
|
But, this argument will disappear if light clients (without the whole blockchain) are more used than the current one, because light clients can't generate blocks if i remember correctly what gavin write in another thread.
Although there will be 'lightweight' clients in the future, most likely those will be on consumer devices without the capacity to support a full client. Future users of Bitcoin are as likely to have a client running on portable devices and home computers. There is no reason to expect that future users are going to prefer lightweight clients on personal computers. If Bitcoin is successful, a personal computer with a standard internet connection will not be able to download all the transaction data. These projections talk about an 8 Gbit/s link. My understanding is that only mining companies will have full nodes. - 8 Gbit/s during 1mn and nothing sent during the other 9 minuts. It's also possible to optimize the protocol somewhat. A solved block could be broadcast as only its header and merkle tree. Nodes would then check the transaction hashes against their own in-memory lists. If a block contains a transaction the node did not see for some reason, it'd then request only those transactions. For the common case of a node with good, 24/7 network connectivity, this would reduce the size of block broadcasts dramatically.
With this "small" optimisation, in the worst case, you will receive/send 2000 transaction/s from/to 50 nodes (2'000*1kB*50) per second + a list of transaction's hashes with a block "header" each 10mn (~50*2000 + ~500). So, in 10 to 100 years, you will need 1Gbps/s duplex to be a supernode, with a single optimisation. Wow, impressive :p |
|
|
|
|
Non generating nodes will be numerous. More the difficulty augments and more nodes won't generate coins, because bitcoin will ben used like a money.
Do you think each people who will use bitcoin like a money will try to generate coins if they must wait 2 years ?
Now, imagine 100'000 nodes which can generate 1 block each 2 years (a quad core is currently more efficient than that), this leads to a significant hashing power (pool), even if from an individual perspective it is useless.
But, this argument will disappear if light clients (without the whole blockchain) are more used than the current one, because light clients can't generate blocks if i remember correctly what gavin write in another thread.
|
|
|
|
Gluskab - You're probably referring to eWallets like MyBitcoin.com - you're correct that mybitcoin users can instantaneously send money to other mybitcoin users, and in the future it's likely that similar, interoperable services will arise.
I guess he spokes of private key transfer from one wallet to another => instant tranfer. |
|
|
|
An important part of a future coin selection algorithm should be the ability to spend self-generated coins (which have no history) when that is important.
This patch ( http://bitcointalk.org/index.php?topic=5333.msg77952#msg77952 ) is the first step. Next one is to add some mechanism to select from address(es). |
|
|
|
Good job ! I'm waiting for this to be in the official client. This will allow everybody (with another patch, to add possibility to select the from address) to send a transaction with the same address from and to, to prove the ownership of public addresses ( needed here for example) by sending specified amount at specified time (more decimal precision than current 2 digits would be better... But this will be for later :p). |
|
|
|
but only on a per-IP basis (and maybe also by larger IP blocks).
If your node has 50 connections and you send each transaction to only 1 node (with a modified software), you could send 50 x the limit and those 50 nodes will relay all transactions. To limit that, the limit must be low, but i don't like a low limit. If you are mybitcoin or else, a low limit will be blocking, and fees will be needed if you want instant transactions... But does fees existed for this reason too (putting a limit to free transactions) ? I see another potential problem : a relaying node will accept, for example, 500 free transactions by ip maximum. It could accept 1510 free transactions from 4 nodes (500,500,500,10) but could only transmit 500 of them to other nodes ? So, a spamming node will limit other nodes too. [edit] Thoses 10 transactions will be sent to other nodes, and then be relayed. You would be very unlucky to send your 10 transactions to the same all nodes who recevied 1500 transactions. But, this could be a way to block a lot of nodes, by sending a amount of transaction just below the limit... => same situation a now[/edit] I agree it's a better method than the current one though. |
|
|
|
Here's a mix proposal : Securing the Blockchain - Generate Coin |
|
|
|
|
A small update to remove coin generation :p
|
|
|
|
Thanks for the reference. |
|
|
|
5 nodes are currently running for testing purpose. Web - Bitcoin JS Remote by tcatm :http://188.165.57.88:10000/btc000/ to http://188.165.57.88:10000/btc004/login : btc000 to btc004 pass : pass Examples of remote bitcoind management :login : btc000 to btc004 port : 20000 to 20004 To get your bitcoins back :./bitcoind -rpcuser=btc001 -rpcpassword=pass -rpcconnect=188.165.57.88 -rpcport=20001 sendtoaddress 1L5zqFahc8Ahu9wtgJqCeJMendvD174xsG 10 error: {"code":-4,"message":"Insufficient funds"} Node infos :./bitcoind -rpcuser=btc001 -rpcpassword=pass -rpcconnect=188.165.57.88 -rpcport=20001 getinfo {
"version" : 32002,
"balance" : 0.00000000,
"blocks" : 116858,
"connections" : 8,
"proxy" : "",
"generate" : false,
"genproclimit" : -1,
"difficulty" : 68978.89245792,
"hashespersec" : 0,
"testnet" : false,
"keypoololdest" : 1301946990,
"paytxfee" : 0.00000000,
"errors" : ""
} List addresses :./bitcoind -rpcuser=btc001 -rpcpassword=pass -rpcconnect=188.165.57.88 -rpcport=20001 listreceivedbyaddress 1 true [
{
"address" : "1HdRhGaeP8rT7mL2sZrqQmh9XEwSXAGG4Z",
"account" : "Your Address",
"label" : "Your Address",
"amount" : 0.00000000,
"confirmations" : 0
},
{
"address" : "1Lcv5tmZMWDgAdhmCUXJ9KNodj4F2cqZzC",
"account" : "Your Address",
"label" : "Your Address",
"amount" : 0.00000000,
"confirmations" : 0
}
] What do you think about (except nothing is secured : http and rcp without ssl for example) ? ps : bitcoind rpc is allowed from all ip for test time only, default config blocks remote ip. |
|
|
|
It's a recurrent problem, and a first response can be found here : http://bitcointalk.org/index.php?topic=4983.0It is a full wallet encryption patch. Like said, a better (or complementary, using 2 passwords) approach would be to encrypt private keys only to allow more flexibility. But, generating new keys would cause some problems because you need the key to encrypt them, and it's not secured to keep the key in memory. So deeper modifications of the bitcoin client are needed. |
|
|
|
|
My browser does not seem to be compatible :p
|
|
|
|
|
Endpoint => server
Encryption key => wallet password
Make a visual separation between server fields and wallet fields
|
|
|
|
|
So, no real interest for now i guess, even from merchants ?
|
|
|
|
|
I had a different error, with g++ 4.4 (default g++ on debian testing), but with g++ 4.3 (like written in the doc) it compiled without problem, with gaivin git repo.
|
|
|
|
|
Show Posts
