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.

It's quite easy (two lines changed or so) to modify pool software to accept 'difficulty 0' shares, and a regular cpu miner to consider every attempt a winner.. by doing this you can produce rates enormously faster than any asic.  If you're board its only a few more lines changed to fork testnet or bitcoin and mine a bunch of fake blocks to test the whole system. 

There may be some burps in practice but you can certainly get some reasonable testing in.

Same as Bitcoin.

If someone has a prerelease ASIC miner at 60GH it should only take 5 HR or so to push testnet3 to the halving if using a little time warping. I think this would be a fun test and I'd be glad to help with it.

Which is how you can tell that I have been paid all the bitcoins:  https://people.xiph.org/~greg/21mbtc.png

The blockchain itself doesn't lie, but websites with blockchain in their name aren't the blockchain. They're websites and they can lie and have lied in the past.

Seriously, depending on some centralized services is not a good idea. Every Bitcoin client itself has an independent view of the blockchain.  Does the transaction in question have a bunch of confirmations (e.g. on the order of 6 per hour since you made it)? if so — it's settled.  If the far end says they don't see it then something is broken there or you paid the wrong address, or they're scamming you.

What kind of major business expenses pay themselves back— passively no less!— in just a year?   Perhaps 7%/wk is more to your liking? Those tastes are catered to in other parts of the forum.

There are major risks in mining— including the risk that all that fancy hardware could be worthless before it arrives due to a loss of interest in Bitcoin, security flaws, legal attacks, etc. Or things like breakthrough optimizations for SHA256^2 allowing massive speedups on equal process or someone somehow doing a major run a vastly better process... just to name a few.

Meanwhile y'all have been ordering devices without concrete specs (including BFL customers— a substantial amount of pre-ordering happened when they were saying nothing about power at all!) which makes concrete reasoning about returns impossible if uncertainty about the future difficulty and exchange rate hadn't already made it impossible.

And after that, you're worried about some months difference in payback timeframes for some estimates?  Suicidal.  I hope no one has put money into these asic preorders that they can't afford to lose.

If Inaba tells me the figures but not in public then I can collect.  I'll only charge 50%, how about it Inaba?