Show Posts
|
Pages: [1] 2 »
|
Have any been created that are open source?
|
|
|
Would the profitability of it change?
|
|
|
EDIT: Idk why I didn't just post in that other thread about this.
|
|
|
What are some security concerns of a node which only saves transactions that involve itself?
Other than the obvious of being unable to verify transactions, and relying on them being buried a few blocks deep before "accepting" them. What other attacks would such a node be vulnerable to, and what are possible ways to defend against them?
Right now the node I'm running saves headers, coinbase, and tx involving itself. What am I vulnerable to?
|
|
|
Because I'm sure we're all aware that due to the nature of random number generators, and implementations, the more widespread the adoption of Bitcoin, the more likely it is that we will see key collisions.
Are we even sure that ECDSA even has an unbiased distribution?
|
|
|
Are there any ethical concerns with an exchange using their balances to mix coins? Since the tainted coins would be returned to customers when they withdraw?
|
|
|
Such as it was downloading the wrong chain, and suddenly the chain ends?
Like if 2-3 blocks back was suddenly marked as orphaned, how would the qt client understand this had happened?
|
|
|
We need to move away from the mindset that zero confirmation transactions are safe.
Miners will eventually start to prioritize what to include by the fee it gives them, which is exactly what they should be doing. Even if that were to nullify another unconfirmed transaction, the one which gives the most to the network (miners) is the one that should be included.
|
|
|
Why was it raised from 256kb (12.79GB per year max) to the current 1MB block limit at 51GB per year?
Only 4010 blocks have been over 256kb so far... And blocks are usually under 200kb.
|
|
|
Can't the client just download and parse the entire blockchain removing the unspent outputs as they get spent?
I don't understand why it hasn't already been implemented, I imagine it would be immensely useful for miners who don't want to foot the entire 10GB blockchain, and just want the probably .5GB block header + unspent output that would be the result of the parsing.
|
|
|
Other than the initial blocks with only the coinbase, do any blocks even have the luxury of having all their transactions being spent by now?
|
|
|
I'm looking at the thing that creates the coinbase transaction, and I'm not quite sure how to insert arbitrary data like ASICMiner does to tag their blocks.
Could somebody offer their insight?
|
|
|
This issue was brought up in a reddit thread. And now I'm genuinely curious, the person I was talking to about it seems to feel that the major mining players could collude to exclude the attacker, and that would be an acceptable course of action.
I on the other hand feel that any action that shows how easily it is for the network to censor blocks would actually be more detrimental to the network than the attacker is (the attacker would only hold the majority power for a short span of time as ASIC hardware producers would most likely use their production capabilities to roll out more "legitimate" hash power) I believe that a 51% attack can only be resolved by increasing the legitimate network hashrate, not by excluding blocks.
Thoughts?
|
|
|
When miners are mining and producing block hashes, what is the average value of those hashes?
Since SHA256 is supposed to be uniform distribution the average should tend towards 2^255, right?
|
|
|
I lost power the other day while my bitcoind was running, and I went to start it again and it was unable to read the blocks. I'm currently in the process of redownloading the blockchain.
Has anybody else had this issue?
|
|
|
Does anybody know if they are explicitly double SHA256, or if they simply run the SHA256 twice. This is important because it also denotes their usefulness outside of Bitcoin.
|
|
|
It seems like every time I check blockchain.info there are groups of blocks found within 30 minute blocks, and then there are times when it takes 30 minutes for a block to be found. While it still averages (according to blockchain.info) to be under 10 minutes per block, it certainly isn't that consistent.
And will this variance just get worse as the difficulty rises?
|
|
|
Why would Satoshi (group or indiv.) use 32 bit timestamps which would overflow before the last coin was designed to be minted?
The fix is simple, just up it to 64bit unsigned integers to represent the date.
|
|
|
|