There's only one thing you actually need to worry about - block validation, which is explained here. I disagree. The core validation is a description of the rules for validating transactions. This would include the script language and the rules for the encryption. What is the core problem that bitcoin solves? The distributed consensus problem. There have been chains of hashes and chains of digital signatures before. What makes bitcoin different is that it is timestamping these digital messages, and protecting those timestamps against being reversed. The currency aspect of bitcoin is simply a layer on top of the distributed timestamping service. namecoin is an example of a non-currency use of distributed timestamping. Thus, validation of blocks and transactions is important, but in a way misses (and ignores in testing) the part about bitcoin that makes bitcoin work. |
|
|
|
lol, what a small world, I live in wake county
My dad owns 4 houses in wake county and if you provided more information I'm sure he would look into this
Send a PM, and I'll be happy to provide any additional information needed. |
|
|
|
Satoshi also intended the subsidy-free, fee-only future to support bitcoin. He did not describe fancy assurance contracts and infinite block sizes; he cleared indicated that fees would be driven in part by competition for space in the next block.
Unlimited block sizes are also a radical position quite outside whatever was envisioned by the system's creator -- who cleared did think that far ahead. Appeal to authority: Satoshi didn't mention assurance contracts therefore they can not be part of the economics of the network Strawman argument: The absence of a specific protocol-defined limit implies infinite block sizes. False premise: A specific protocol-defined block size limit is required to generate fee revenue. Gathering data does not imply blindly following the data's source. Fully understanding the intent of the system's designer WRT fees is a very valuable data point in making a decision on block size limits. |
|
|
|
I have 0.7.0-beta. How will this affect me?
From what I understand, it looks like my client wouldn't recognize v2 blocks.
Older clients will recognize v2 blocks just fine. This is largely a mining issue. |
|
|
|
|
+1 thanks for being responsible and responsive about this issue.
BTC Guild is currently my favorite ASIC mining pool, because it is the most stable and has the most features.
Just switched to Eligius (2nd favorite) until hash rate gets down a bit.
It sounds odd, but: if BTC Guild hash rate comes down, I will definitely switch back.
Great website UI and very reliable service.
|
|
|
|
* jgarzik votes for a fixed minimum difficulty which is out of reach of most CPU miners, as well as eliminating getwork. GBT or stratum only. But just an opinion.  Looking forward to the control panel. |
|
|
|
The problem is current client/relay/miner software has no automation to evaluate what is actually happening in the blockchain so users are forced to manually set tx fees. This must be improved. Let the Bitcoin marketplace decide minimum tx fees. Not developers with fixed-guess recommendations. And certainly not with fixed default settings in the software.
+1.000001 The developers agree with you. Where is the code submission? Pull requests to do this are welcome. |
|
|
|
|
+1 to the private UDP broadcast idea.
Further, there has been talk off and on (by myself, and others) about a "backbone network" where Big Players privately and directly interconnect, for reasons similar to this.
|
|
|
|
I don't agree with the idea that keeping the 1mb limit is conservative. It's actually a highly radical position. The original vision for Bitcoin was that it supports everyone who wants to use it, that's why the very first discussion of it ever was about scalability and Satoshi answered back with calculations based on VISA traffic levels. The only reason the limit is there at all was to avoid anyone mining huge blocks "before the community was ready for it", in his words, so it was only meant to be temporary.
You continue to repeat this -- but it is only half the story. Satoshi also intended the subsidy-free, fee-only future to support bitcoin. He did not describe fancy assurance contracts and infinite block sizes; he cleared indicated that fees would be driven in part by competition for space in the next block. Unlimited block sizes are also a radical position quite outside whatever was envisioned by the system's creator -- who cleared did think that far ahead. |
|
|
|
How can one enable to light / client mode in bitcoind referenced in issue #7?
Lightweight client mode is called Simplified Payment Verification (SPV) mode. It was never completed by Satoshi, nor anyone since. It is a bit lower priority, with bitcoinj and other clients supporting SPV mode. |
|
|
|
|
It is ludicrous to demand that anyone who loses value X be repaid at value X*10.
Look at the exchange rate on the day of the hack, and return debt based on that.
|
|
|
|
|
Good stuff!
You might want to add extra safeguards when it comes to input/output selection, to make sure that a user does not accidentally create a transaction with 94 BTC in fees (this happened recently). This depends on your user interface of choice, but a manual sanity check for "inputs - outputs > 1 BTC" or something could probably save users much money and grief.
That is the danger and power of raw transaction APIs. They give you enough roof to hang yourself.
|
|
|
|
It's worth reviewing the many threads on this subject, that have come before Any completely automated metric is potentially abused by miners to run up fees. |
|
|
|
|
Last night, it took seven blocks and 90 minutes before my ~6 BTC transaction was confirmed. Zero fees attached to the transaction.
There is definitely a wait, if the transaction does not include fees.
|
|
|
|
Nobody knows you are mining, even without Tor, as your behaviour is indistinguishable from any other node.
Not true. Sites already track the first node relaying a particular block. Targeted observation (wiretap) makes the activity even more transparent, when you find a block. |
|
|
|
We are concerning about that Avalons will sky high share diff to high. Share diff is raised, when shares are showing to fast in chain.
Maybe allow Avalon (or another high power devices) users to set share diff as high as they want?
There is an argument for multiple pools... an Avalon/ASIC pool, a GPU-and-smaller pool, etc. |
|
|
|
|
Increased hash rate == increased network security.
Also, litecoin is certainly not at all immune to ASIC.
|
|
|
|
|
display_short is the shortened display value.
|
|
|
|
|
Show Posts
