There are enormous speedups happening right now which might stem some of the alarming movement to centralized clients... but to really close the gap the software will need to be able to be instantly usable and sync in the background, and thats going to take more work.

We're development resource constrained all around and especially testing constrained.  Getting more of the geekier parts of the community running nodes with the bleeding edge code (including testnet and secondary nodes; to keep their real funds off the experimental software) and teaching them how to beat it up and produce good bug reports would help the software mature faster and help get the improvements into the hands of new users.

Those reports make no sense at all— each process has its own address space. It's not possible to even _attempt_ to modify another process without invoking a bunch of OS calls to get access to the other processes space (of course, bitcoin has no code to do any of that). Unfortunately those reports also include no details so I have no idea what behavior its mistaking.

Are you sure you don't have some kind of infection on that system?

Who are you (and most of the other people in this thread) to tell other people how to run a chat channel which they use and contribute to and you do not?

There are understaffed food kitchens in your community. How come you've got over a thousand posts here?

Hm. This picking the causes that other people should be fighting thing is fun.

Or a court of public opinion.  Some of the positions people adopt on these forms, and less often on IRC, are rather alarming to outright despicable.  While I hold the view that people have a right to have opinions which are widely (and rationally considered!) despicable my own freedom demands that I not be forced to associate with them.  If there is to be free speech a community also needs to have the freedom to exclude and choose their associations lest they all be made worthless by a competition of the loudest shock artists.   Sometimes I hesitate to mention Bitcoin to people because I'm, frankly, embarrassed that I might be associated with some of the people here.

The ultimate arbiter of the rightness of keeping someone in a channel or excluding them is the users of the channel and no one else has any business having an opinion. I'm especially disappointed to see the hysteria in this thread— mostly from people who do not use the channel, do not contribute to development, and may not even have a clue what IRC even is...   Why is it that so many seem to have so much time to rant and rave in this thread but yet cant find the time to spin up a prerelease copy of bitcoin and file some bug reports?

It's no big deal to accept only one confirmation transactions so long as you don't allow withdraws of derived funds until after the payment confirms.

(there is still some exposure where someone double spends their input only when they would have lost— but a gambling site may consider that an acceptable risk)

The frequent invocations of RedHat upthread are weird and misplaced.  _I_ did the initial BE testing for Jeff. Lots of people have access to BE systems and pretty much anyone who wants to can have access to one (for a couple bucks on ebay if nothing else).  ... but nothing Jeff is doing makes handling the endlessness hard as directly evidenced by the fact that he got it running fine on BE without using one.  Your 'solution' of pushing unions everywhere for that is an odd one and I'm happy to not work on your codebase.

Now that you've made your numerous complaints would you please cut it out? The tangent is going nowhere. If you want bitcoin software written to your particular, and somewhat odd, specifications feel free to do so yourself or to pay someone to do so.

uh No. The miner can search for hashMerkleRoot values to get particular ones.

Only if you think profits and losses are the same thing.

E.g. one thing returns $10/mo, another option returns $5/mo. Now add a $6 cost to both sides.  Nor can you say that if one or the other was the winner ignoring the constant cost it would still be still be a winner with it as they don't have initial upfront costs.

Personally, for infinite duration things I like to convert constant future operating costs to unfront costs:  $10/mo in today's value forever costs you roughly $3000 (assuming 4% post-tax/inflation return).  Though mining isn't infinite duration and the long term trend of energy costs certainly seems to be upwards.

Warning: Irrational exuberance detected.

Why the heck would you expect that a "maximum estimate" established for 3/4th of the hash power would still hold?

Um. Because it's utterly trivial to do it I expect a lot of people don't talk about it much.

Fedora removes ECC support from OpenSSL because OpenSSL doesn't distinguish the stuff that no one argues isn't covered by valid patents and the stuff that no one argues is patented. RedHat's response was just to disable it all and let god sort it out.  So you need OpenSSL recompiled with the removed ECDSA re-added.  Once you have this it works like anywhere else (e.g. you need the suitable dependencies and development headers).

I've maintained suitable RPMs for my own usage for some time: https://people.xiph.org/~greg/openssl/

Nor is it welcome under mining.  Take your attack crap to the cesspool where it belongs.

That page is pretty embarrassing.   There is absolutely no mention of the fundamental flaw in PoS consensus which none of your proposals have addressed:  As of yet none of the proof of stake proposals are workable because there is nothing at stake!   If someone is PoS mining it is in their best interest to attempt to concurrently build an honest chain as well as all possible attack forks just in case one of them happens to win.  Under most schemes this is the profit maximizing move, in all I've seen so far its at least neutral.  Mining an attack under PoW actually involves _spending_ something and taking the risk other miners will extend it. PoW works because your work is at stake so even a very small amount of honest miners make mercenary rational miners behave honestly too.

Moreover, I don't see why you argue here that it better aligns incentives. Parties can't mine PoW without having a validating node (or face the extreme risk other miners will toss them off on forks).  All it does is redistribute control, which might be useful— if not for the fact that it makes attacking more attractive for selfish participants.   I was hopeful of these techniques but as of yet I don't see how any can be workable.

No.   The size of the txout set is much more important than the size of the historic chain. Old transaction data is only needed to bootstrap new nodes with zero trust. The txout set needs random access queries in order to do live validation in real time.

Use the argument -tor=ip:port  to set the tor proxy and you'll only use tor to connect to hidden service nodes. See doc/Tor.txt included with the software for more information.

I really hope we don't end up with a large amount of perpetual txout bloat because that kind of thinking.  Perhaps there should be some kind of "send all my private keys to charity" button that sends them to someone who can sweep them up.

I don't agree with Mike. Bitcoin is not a democracy— at least not a majority voting one. It's not a system that is predicated on a "vote", it's a system predicated on autonomous validation and it would not be trustworthy if it were predicated on relaying based voting as sibyl attacks would undermine it. The only "voting" in bitcoin is the computational vote on the ordering of transactions, which we don't know how to resolve absent a vote, and a non-mining node doesn't actively participate in that (though they do passively participate in that by forwarding only valid blocks— which is essential but rather indirect).

A non-listening node contributes through the basic services of honestly relaying transactions and blocks, but it also contributes to the security of the system by making sure that any violations of the system rules are ignored as effectively as possible.  They do this even when they are not providing listening services so that Mike's SPV clients can externalize their cost of running their own validation... though it is obviously much more valuable when a node provides this service to nodes which lack the validation.  The existence of many relaying full nodes, regardless of if they listen, is one of the reasons that the "red balloons" attack (where miners selfishly fail to relay txn with good fees) is not a practical issue and also doesn't depend on the relaying nodes listening. Another way they help is by improving privacy for other nodes by relaying transactions and thus further obscuring their origins.

An extra point to add is that a node especially contributes when it is better maintained than the average node— because it can increase the speed and reliability of transaction and block relaying network wide. E.g. because the average node is on some slow spinning disk, a fast node which stays up with current software, and runs on a SSD or ramdisk can contribute quite a bit. Faster relaying makes forks less likely which makes zero and one confirmation transactions more safe for those foolish enough to use them. A node can also contribute better when it's crossing transports— e.g. talking to nodes on IPv6, and talking on Tor (and maybe listening, as it's possible to listen on tor even for some nodes that don't listen generally) as there are far fewer nodes on the other transports.

Can you tell me why you've added "several dozen" addnodes?  I'm asking because I want to know if there is some documentation I need to get updated that is causing people to think that they need to do this.

Validating the existing chain is _NOT_ proof that it implements it correctly.   To be correct all implementations must accept AND reject the same things.  Most possible things are not in the chains because, if for no other reason, most possible things are rejected.

Grau, Please confirm that you understand this. It's very important.

People seem to be frequently confused because they misunderstand blockchain.info. Let me spell this out:

There is no realistic way to know for sure who created a block. Even when pools put their name into the block itself (as some do) that doesn't stop someone else from putting the same string in.

Blockchain.info displays the origin of blocks by _guessing_ based on some simple rules on text in the coinbase and  which node first handed them the block.

If they are connected to an especially fast and well connected relay they will falsely report it as being the 'source' of many blocks.  This doesn't mean that this relay is a big miner, or that they're attacking the network, or anything like that. An example of this is the Swiss node at 82.130.102.160 but there have been a number of similar misattribution addresses in the past.

People freaking out over these misconceptions will now be shot. Please take a note of it.