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.

FWIW, BFL wrote me to say:  "Mesarah has nothing to do with BFL and I would appreciate it if such a connection wasn't implied by the moderators of bitcointalk",  and thats a request I think is completely reasonable.

For all I know MeSarah is some kind of crazy counter-agent that is maximally obnoxious in BFL's apparent favor just to make BFL look bad.  Then again, I have to say I also would have had the opinion about Inaba's posts in the last month, so take my crazy conspiracy theory guesswork for what it is: Not terribly reliable.

Frankly, the kind of trouble I've seen people cause is the sort that comes only from seeing the misfortune of others, of creating argument and drama, and not from promoting one interest or another. Chaos has no affiliation but its own.

In general we should judge participants in our community by their own actions and not by those of their sometimes unfortunate supporters.  I've certainly had my share of moments cringing at some of the agreement I've received.

Yes. And its been moved out of the thread. STOP AMPLIFYING IT.

Funny, I didn't mention which trolls I was talking about or who might be paying them.  I'm glad you could help people with your opinions on the subject.


You are very thoroughly confused about the law. But hey, feel free to send me the contact information for your attorney.  Mine wouldn't mind having a word with yours.


Please provide hyperlinks. Note, I have not authorized and do not authorize public duplication of my writing. If you wish to make private copies for whatever purpose be my guest.

And as I previously directed— I would remove your posts if you continued to repeat the same material and I have done so, as promised... but your post was too funny to delete completely.

I'm now removing further "MeSarah"'s posts from this thread and wll remove them generally anywhere in the mining subform at least so long as they keep repeating the same things. As it stands these repetitive posts off-topic and over the top and I'm reasonably convinced that no one here is interested in hearing more of them.

Let me know if I've made a mistake. Alternatively, if whomever is paying these trolls wants to send me a substantial kickback I _may_ be persuaded to look away and allow the insanity to continue: 136H7e7oHYtddM9iPNLG8ZGDqZvme2ogUn  

Also— I _strongly_ recommend using the ignore button when you see people that are constantly idiots, dishonest, or otherwise abusive. You can still view the posts if you must for context. Ignore is like a distributed ban and the text turns yellow as more people do it, signaling to other people that the community considers that person to be a waste of time or worse.

Or they are honorable people who value the trust and respect gained from not breaching confidentiality for some minor prize even absent a formal contract.

Currently P2pool is simpler to run than solo mining, though this is an artifact of ~no larger miners except Luke bothering to submit patches to  full node software for mining scalability.

Your opposition to long term real decentralization in Bitcoin is well established at this point.  I think as a community we need to start speaking up emphatically against these positions. I hope you will not take it personally when I do, because I have great respect for you no matter how much I disagree with you on this subject.

If Bitcoin were only to have 1000 distinct non-trivial mining entities then I believe Bitcoin would be worse than pointless.  With so few entities having a veto over the validity of transactions it would be substantially more centralized than any of the largely existing widely used currencies— as there are are far more bank like entities than that for any major currency, and unlike bitcoin other currencies have cash transactions which are more reversal resistant. The cost and complexity of bitcoin is not justified if it doesn't provide a solid advantage over highly trust centric (semi-)centralized systems like the USD.

From a technical perspective: If you were only to have 1000 entities the Bitcoin consensus algorithm is fundamentally wrong:  The stochastic POW chain consensus provides slow and unpredictable eventual consensus. A consensus of 1000 entities can be accomplished far more inexpensively, rapidly, and reliably by identify them and using a majority vote with digital signatures. There are places for systems with this kind of security property, and they are the sorts of things OpenTransactions seek to create (potentially ones with much better scalability than the broadcast based Bitcoin system).

It would certainly be nice if there existed a global, thoroughly distributed, cheaply validated, medium of exchange which could enable trade between distinct scalable and fast confirming federated systems... but it won't be so if Bitcoin tries to become everything to everyone with forcing users through services providers and limiting miners to those who can handle gigabits of bandwidth for multigigabyte blocks.

Fast provably strong confirmations are not something the Bitcoin consensus algorithm can do without sacrificing the things that make Bitcoin worth having and we shouldn't be afraid to admit this.

Please don't downplay the finney attack.

It's a non-issue in this case because— as mentioned— they can just cancel the service if the payment doesn't go through. This would let them get instant turnon and security against all kinds of attack. For the purpose of this thread it's really the end of the discussion.

But the finney attack is not terribly uneconomical now that there are services where you can buy hashpower from dimwitted greedy miners for small premiums over their value.  The finney attack is also not the only relevant concern for 0/confirmed:  conflicted transactions are not broadcast (and simply broadcasting them has serious DOS risks) so there may be a substantial portion of the network that prefers a conflicting transaction and yet you won't hear about it.  Moreover, AFAIK no existing node software does anything _useful_ even if it does hear a conflict such as expose it to the user. Again, in this kind of case it doesn't matter, but I strongly disagree with downplaying it generally.

It doesn't really.

The expectation of solo mining is the same as pooled mining. If you'd like to split off and try to mine a conflicting transaction you can and you won't lose any coin on average— you'll even gain if the conflict has higher fees.

It's not a guarantee because the inclusion isn't fixed like it its when a transaction is actually mined, a miner could stop at any point.  Perhaps you could imagine some kind of system for discouraging that, but it would need a consensus mechanism... and would have to force all miners to mine the same txns (or at least no conflicts)

P2Pool now does this— miners exposing what they're working on in p2pool shares with no enforcement— however.

I did— but no need to be a smartass about it— especially since you're drawing the wrong conclusion.

The existence of this rainbow table _proves_ the feasibility of brute-forcing that entire space for a single salt. I _happened_ to have a rainbow table, but for the point I was making I might have well said that I brute-forced a single password of that size on my GPU farm.

So sure, the salt means the attacker couldn't lower their costs through precomputation, but if you have high value data (e.g. a bitcoin private key they _know_ has a lot of funds assigned to it) then they really could search such a large space unless you had a quite costly KDF.

And I agree in combination your advice is good, I'd just prefer that you hadn't repeated the 8 characters == good myth, which is terrible advice in isolation as it's normally applied.

This is generally a known behaviour. What happens is that you are doing the initial block download forward, and then a new block happens on the network and you try to connect it (backwards) to your chain... so you start pulling  and pulling and before you make it all the way back there is a new block on the network.. and you sweep over them.

IIRC it's not actually downloading them twice, but they show up in invs and you note you already have them and don't getdata them.
 

You're saying a number of good things mixed with absolutely terrible things. I have exhaustive 12 character (alphanumspace) md5 rainbow tables sitting on a disk here.

With a fast KDF you need a fair bit more to be sufficiently strong.  And you certainly can't count on a user constructed string being sufficiently random really at any length.  People can't reason about entropy, and they can't reason about attackers that can do a billion attempts per second per gpu and have powerful statistical models.

I didn't mean to discourage your work, I was just suggesting extreme caution because there are many subtle features which are hard to test and must be exact.

Diversity is good and may help discover issues.  But as Gavin was saying and as I like to point out: The most dangerous kind of failure in bitcoin isn't an implementation bug— any blockchain validation inconsistencies in widely deployed implementations are significantly worse than pretty much anything other than a full private key leak or remote root exploit... and are even harder to avoid.

There are many useful 'test' cases in the mainnet chain and in the testnet chain, but those only test valid blocks. Bugs that accept thing which should be rejected wouldn't be found by those.  Matt has been working on a test feeder tool as part of his effort to make full node support for bitcoinj which is very promising. There are also tests included with the reference software. There needs to be more of them.

Just some poorly documented behavior, if you'll note there is no explicit mention of SIGHASH_ALL in the script code; SIGHASH_ALL is what you get when it isn't the other things.

If you implemented based on material in the wiki I would be concerned about the correctness of your implementation unless compared very carefully with the reference code and tested thoroughly because of the many possible sources of little quirks like this.

Why do you assume those nodes are isolated? They are assuredly not— the software makes some effort to form topology-diverse connectivity and beyond that the network is randomly wired.

The overwhelming majority of nodes are 'secret'.  Nodes which do not accept incoming connections never have their addresses visible except to the nodes they directly connect.  Non-listening still function as complete nodes relaying transactions and blocks even though they aren't directly observable.

There are also a fair number of nodes which connect over Tor, and a number of nodes which are only inbound reachable as tor hidden services.

The bitcoin distributed algorithm is also not married to the peer to peer protocol, it's perfectly reasonable to link nodes via alternative means— e.g. bulk transferring blockchains (via https, scp, torrent, etc) is fairly widely done. People could even ship around transaction steganographically embedded in cat pictures. (and I've seen transactions being transported via IRC and pastebin).

You could certainly make measurements of the public stuff and infer some likely things about the hidden connectivity by things like transaction propagation times... but you can't reliably measure much of it.