 Show Posts
|
|
Pages: « 1 2 [3] 4 »
|
|
In the future, when transactions start to compete in blocks, what algorithm(s) will/should miners use to optimally determine what transactions they should include to get maximum transaction fees while keeping the block size below 1MB?
|
|
|
|
Er... I wasn't saying that the moon was made of cheese. You said that the node's time is only used for mining blocks; it's also used in verifying blocks.
Yes, sure, thats true and not at all relevant here for the subject of the thread. Why don't you try writing out the particulars of what you're thinking in greater detail than "Collect timestamps.  . Hax!" and perhaps you'll see why? Okay. The OP linked to a page which was all about timing attacks and how nodes used their time to verify blocks, and how to skew that. Then he suggested doing it while a fork was in progress. Then you said that this was confused, and said that node times were only used in "what it puts in it's own blocks", which wasn't correct (as you just agreed), which I then pointed out. Then you said that the moon wasn't made of cheese... |
|
|
|
But what if the node isn't a miner? The node's time is used to make sure that blocks aren't more than 2 hours in the future, right? The node doesn't check the difference between the current block that it's verifying's timestamp and the immediately previous block's timestamp.
And? The moon is not made of cheese. Er... I wasn't saying that the moon was made of cheese. You said that the node's time is only used for mining blocks; it's also used in verifying blocks. |
|
|
|
A nodes time is utterly irrelevant beyond determining what it will put in its own blocks.
But what if the node isn't a miner? The node's time is used to make sure that blocks aren't more than 2 hours in the future, right? The node doesn't check the difference between the current block that it's verifying's timestamp and the immediately previous block's timestamp. |
|
|
|
This is basically a non-issue. Just interpret the timestamp as the lower 32-bits of an infinite timestamp. It "wraps around" every 138 years, and it's pretty easy to figure out how many times it's wrapped since Bitcoin was created, so it's easy to convert the stored 32-bit value, into your own 64-bit value.
+1 |
|
|
|
|
Please post more, LvM! You're making us laugh.
|
|
|
|
|
Just confirming, I can send from unspent outputs worth less than 54.3uBTC each, right? So if I've already received several transactions that were worth 54.3uBTC or less each, I can then spend those outputs?
|
|
|
|
|
No... The POW of a block is the nonce which makes the hash below the target. It's not 1/target. Maybe you mean that one in every 2^256/target nonces will be below the target?
|
|
|
|
Wouldn't it just be simpler to add the base point incrementally? Why not just start out with a private and public key, store the private one securely, then just keep on adding the base point to the public key to get new addresses.
Are you suggesting k_i=k_par+1, K_i=K_par+G ? Then the keygen isn't pseudorandom (post #62), if one privkey leaks then the entire wallet immediately leaks too, and there's no hierarchical derivation. Ah. I see. Nevermind what I said. |
|
|
|
|
Wouldn't it just be simpler to add the base point incrementally? Why not just start out with a private and public key, store the private one securely, then just keep on adding the base point to the public key to get new addresses.
|
|
|
|
|
Yes, that's mostly true.
Although, in the second one, you're not really sending it to an "address", you're putting the tx out into a script which would require 2 out 3 signatures from predefined public keys (You can't do this in the main bitcoin client). For that to be spent, either the sender and receiver, or receiver and escrow, or sender and escrow must agree.
|
|
|
|
|
rJSBTYtZDam93gUtHcUPdm14d1TMVLzApf
|
|
|
|
Thanks for the info. But it is still not clear to me. When I started with a genesis block and how does the system know there is no other existing bloackchain in the network that it needs to sync?
I'm not sure what you mean by that. There is only one blockchain (sometimes more if it's forking). The blockchain starts with the genesis block. The client will download all the subsequent blocks, then verify them, and assemble them into a blockchain. |
|
|
|
|
In Bitcoin-Qt:
Help->Debug Window->Console
|
|
|
|
Bottom line is that all the information is stored on the server side; passwords, addresses, keys.
Actually, no. The server doesn't store the password. You download the encrypted file containing the addresses and private keys and decrypt it with JavaScript when you enter in your password. The server never has the unencrypted version. |
|
|
|
|
Go into the RPC window, then do
getrawtransaction *transaction id*
then copy and paste the result into
sendrawtransaction *result from previous command*
This will rebroadcast the transaction to the network.
|
|
|
|
|
You can run as many as you want off of one computer if you have a USB splitter.
|
|
|
|
|
I don't think so. Connecting to a node normally requires that node to have port 8333 forwarded to the bitcoin client, but in Tor you generally are assigned a port >32768 which can't be used for Bitcoin. Also, setting up a tor hidden service wouldn't work because peer discovery is locked into IPv4 and IPv6 which can't be used for a tor hidden service.
|
|
|
|
|
