Obviously I agree— but beyond that— look at the volume of coins moved every day on the markets and on the blockchain.  Are people here really suggesting that there is that much economic activity coming from scams and obscure black market websites? That seems crazy to me.

Not implying this is the case AT ALL, but wouldn't it be epic if it turned out that the mining circuit was acausal logic implemented by arranging the gates in a closed time like curve that allow the system to only attempt solutions which are valid and thus actually achieving infinite speed. ... but then Butterfly labs couldn't productize that because it would make bitcoin worthless, so instead they rate-limit it to realistic speeds in order to maximize their sales. Again, I'm not even suggesting this is the case, I just let my mind wander.

Except for thw whole "doesn't make sense at all because no one makes a terabit/sec sha256 chip" part, right?

Especially since many of the same people in this thread are completely willing to write off FPGA products like the x6500 which are using the _same_ FPGA as some other products because they aren't yet claiming the higher performance numbers that they should be able to achieve but have not yet (because of time spent working on building boards to ship to customers, instead of on promoting more vaporware).

If BFL demoed a FPGA running at a fraction of the speed and using a lot more power, I'm pretty sure many of you would say that was more evidence that it was a scam. Worse for them, they'd probably alert their competition to identity of their supplier (and the non-scamness of their business). So it goes either way.

This controversy is fantastic marketing. We're all watching for the drama— and a lot of people will buy buy buy when there is any evidence of it being real, even less evidence than they'd demand had we not had this little adventure. This all sounds like a reasonable enough approach, scam product or real :-/

Thats a gibberish number. It is like saying that one mile per hour is equal to 14.285 pounds (because some car that weighs 2000 lbs can go 140 MPH).

There are no floating point operations involved in the calculation of a bitcoin hash. None at all. 0 FLOPS.

Ngzhang says above that there are about 1300 32-bit operations (in one bitcoin hash) which sounds about right. So one 1GH/s would be equal to 1,300,000,000,000 operations per second.

If you're looking to, e.g. compare bitcoin's speed with various supercomputers you can just figure out how fast the supercomputer could mine.  For example, one of the top machines is the Jaguar supercomputer which uses fairly standard opteron cores. I think my fairly boring rough numbers put it at about 522 GH/s.  (pshaw, who says CPU mining is useless? )

No, people have pointed this out _many times before_, including in this thread, I'm sure.

1MH/s ~= 1 GBit/sec of SHA256 hashing.  There is no commercial application for a mining-speed SHA256 engine.

This isn't really fair.   And the tree-rewards system is interesting on its own merit, even if it never turns out to be something useful for bitcoin.  Complaining about this is kinda like complaining that double-geometric payout schemes for mining pools are pointless because there are non-score based ways around the problems proportional pools have.

Greetings.

Forwarding and processing transactions in litecoin competes with CPU power that could be better used for mining.

Rather than disallowing free transactions entirely, this patch simply corrects the metric to better match the currently relatively stationary behavior of litecoin: To be free 100 LTC of input must sit around 576 blocks (4x the 144 value from bitcoin).   Otherwise, a fee of 1 LTC applies, pretty reasonable considering the exchange rates.

If people want binaries, let me know for what platforms you want them. Cheers!

diff --git a/src/main.h b/src/main.h
index 5783d67..468f11e 100644
--- a/src/main.h
+++ b/src/main.h
@@ -33,8 +33,8 @@ static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;
 static const int MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;
 static const int64 COIN = 100000000;
 static const int64 CENT = 1000000;
-static const int64 MIN_TX_FEE = 50000;
-static const int64 MIN_RELAY_TX_FEE = 10000;
+static const int64 MIN_TX_FEE = 100000000;
+static const int64 MIN_RELAY_TX_FEE = 100000000;
 static const int64 MAX_MONEY = 84000000 * COIN; // Litecoin: maximum of 840k coins
 inline bool MoneyRange(int64 nValue) { return (nValue >= 0 && nValue <= MAX_MONEY); }
 static const int COINBASE_MATURITY = 100;
@@ -527,7 +527,7 @@ public:
     {
         // Large (in bytes) low-priority (new, small-coin) transactions
         // need a fee.
-        return dPriority > COIN * 144 / 250;
+        return dPriority > 100 * COIN * 576 / 250;
     }
 
     int64 GetMinFee(unsigned int nBlockSize=1, bool fAllowFree=true, bool fForRelay=false) const

The P2P protocol
^^^

Meaning the current one, with its weaknesses to insufficient diversity.  You can have other network topologies (which can be "peer to peer" or otherwise) and reduce/eliminate the particular weaknesses... differents set of tradeoffs, ones which would make sense in different environments.  We can freely change the networking protocol without breaking bitcoin, because even a single node that speaks both would bridge them.


Yes.   Though since you can't tell if a peer is silently dropping your messages you can't really use it as a "last option".

Addnode connects once and makes no further effort to keep the link up, beyond the fact that the address will be a recently connected address in the pool of addresses that your node knows. Keepnode attempts to keep the link up.

Come on—  Someone who executes trades at odds with their own beliefs in the valuation of the good in order to trigger software or psychological bugs in the other people on the exchange is a manipulator.  They are fairly called a manipulator rather than an honest trader not primarily because they trade on N-th order effects but because they _reduce*_ the efficiency of the market rather than increase it.


*(you can argue that they increase it long term by hardening the counterparties to these attacks— but the hardening wouldn't be required if the manipulators didn't exist, and the induced inefficiency today is very real while the increase in long term efficiency is more speculative)

Setting up p2p links with nodes you don't expect to screw you over, web of trust style, is _not_ centralized.  There are many ways to have decenteralized communication and "take TCP connections from everyone, connect out to eight others, forward everything you hear that validates... tell new neighbors about every other neighbor you've heard of"  is only one of them.

It's a good thing, because by your metric bitcoin would be "centeralized" now because people do have explicitly configured peerings.

The rest of your post is a strawman. The trust relationship between banks is not at all isomorphic to simply having a minimum fraction of peers which you trust not to black hole you and which you can safely prioritize without risk of DOS attack.

What do you mean by "bitcoin"?   The bitcoin distributed consensus algorithm?  The bitcoin currency formed by it?   Or the current version of the client software we happen to be using today?

In a world where there were only a few hundred full nodes we wouldn't be using the current software— we'd be using some evolved version of it.   The bitcoin distributed consensus algorithm and the bitcoin currency can function fine in that world, the current software as is— not so much.

The P2P protocol is simply not essential to bitcoin. Bitcoin can run over just about any transport, and there are already people communicating bitcoin across things which are not the P2P protocol. (e.g. compressed blockchain dumps, json messages, etc). As bitcoin grows and evolves many different transports will coexist (and no one could stop them from existing, even if we wanted to)

To make node software for the world with a few hundred nodes you'd want do to things like explicitly configure sets of 'known not-completely evil peers' with cryptographic authentication like the freenet darknet.  This kills cancer-nodes, confines DDOS and hostaging, prevent null routing and fragmentation, etc. And its pretty easy to maintain in a world with a few hundred nodes. You can even fully mesh the main nodes to each other.    

While I don't think "a few hundred nodes" is a desirable (or plausible) outcome, we're already getting some of the features needed for that hypothetical universe (see the 'keepnode' pull request) because the attacks you've described are not impossible enough for high value targets in our current diverse network but are made much more difficult with a little sprinkling of some pairwise semi-trust (because they're all mostly broken by 'have at least one honest peer'). No amount of P2P network diversity helps you if your ISP is evil and isolates your node onto a fake network... but a couple of authenticated peers elsewhere on the network kills that attack dead.

Show your math.

Yup.  Often providing payment perverts incentives too.  forwarding txn is so damn cheap that lots of people will do it for 'free' (just the compensation of helping the network overall).... once you start paying people won't forward txn that have too many hops for them to get paid on anymore.

Another thing not discussed in the embodiment of the payment chain.   Here is how it would have to work:

Today you construct SIGN_A(TX()) and that gets flooded. Under this system you'd have to instead construct   SIGN_A(TX()+PEER_X)  for each of your X peers. Then, peer B for example would construct   SIGN_B(SIGN_A(TX()+PEER_B)+PEER_C)  .. and C would construct SIGN_C(SIGN_B(SIGN_A(TX()+PEER_B)+PEER_C)+PEER_D)  ... and so on.  So each hop would now require $HOPS expensive signature validations, plus an expensive signing operation per next-hop peer, and would also add ~130 bytes of data (the next public key and a signature).  Just two hops would easily more than double the computational and storage cost of the transaction.

It's a neat area of research, but I'm doubtful that its actually applicable to bitcoin.

In the less than 120 case he's not "out them"— they simply never transferred into his control and he never could not have made someone else think they were on their way.

Contrast to a transaction with older coins— in a split the transaction could fall out of the chain, but the nodes would immediately put the transaction back in. Absent a specific effort to respend the same inputs in the split (which would require having awareness and access to the split) this will always be successful.  Basically for the coinbase every split deep enough to cover it is as bad as the worst case in the regular transaction case.

But relaying for the sake of relaying doesn't really provide much value to the network besides providing more open ports— which are dirt cheap resources.

It would not increase the strength of the bitcoin distributed algorithm an ounce— that strength arises from validating the chain (which even offline clients will do when they come back online) and mining new blocks, not from flooding transactions.

I think it would be a _severe_ mistake to make the current crap P2P topology economically essential to the system.  The current p2p behavior is an artifact of the network bootstrapping behavior and we'd likely be better off with something else— fortunately the transport network is irrelevant distributed algorithm so we can have different transports (even many different transports being used at once)... though this wouldn't be true if there was some crazy incentive system baked into the transport.

Though we are for the moment stuck with the existing topology and we have, in the past, run short on listening nodes— If you want to create an incentive to have more of them— it's pretty simple. Run a lottery:  At random when a node gives you a transaction (perhaps a test transaction you originated someplace else in the network) give that node an IP transaction donation.  This can be run as a donation funded thing like the faucet— or better, miners can use the lottery to reward nodes for forwarding them TXN fee carrying transactions.  .. and this can be done without changing anything internal to bitcoin.

However I don't see _any_ evidence that an improvement in this area currently required. Moreover, if someone actually cared to improve things they should start by fixing UPNP so it doesn't time out shortly after startup. We'd probably get a significant boost in listening nodes that way.

Block generations which are lost in a chain split (e.g. due to a network partitioning event) can _never_ be recovered, even assuming a complete lack of bad intent. Moreover, it's "coins from thin air" — the burden on the economy from not being able to spend a coin the instant that it's generated is pretty insignificant... thus favoring bigger numbers.

The actual limit is 100, but the client uses a somewhat higher number because if you're ahead of your peers on the chain and you use it right at 100 your txn will drop.   In the common situation where you have many inputs to choose from the benefit of being able to choose the 'barely viable' one is small.

Would 200 or 90 have worked just as well? They'd give a little more or less security against a particular failure mode, in exchange for slower or faster access to newly created coins, but bother of those would probably be okay. But as a chain validation rules they have to be identical across the network, so there must actually be a number. No number is perfect, and people will have different preferences.



No, you've misunderstood the time-warp bug. The difficulty is not too high or too low as a result. The size of the window is correct.  The issue is that the sequence of windows spans from block to block without overlap, which means that one _gap_ (not one block) is excluded.

You received may other detailed and thought out arguments here and your dismissal of them out of hand is incredibly disrespectful to the people who took the time to response to this obvious non-starter proposal.   That said, you're right.  That is the response and for a damn good reason.

The only reason bitcoin isn't inferior to the numerous other 'currencies' out there is because the rules of the core system— good or bad— are mostly nonvolatile.

Sometimes this results in weaknesses, maybe even ones which could be corrected but not for the inability for grand wizards to continue to tweak the rules,  but at least you can plan for and engineer around those weaknesses without the risk that BitFed Chair Kano is going to dish out another Great Plan.

This means that changes need to be well justified and be mostly free of negative side effects— even to people who prioritize costs/benefits quite differently from you.  Certainly there are things that can pass the test— but twiddling with block times or difficulty calculations ... probably not.

Some of these things, like the inter-block time, are just trade-offs— there are a broad range of values which are all members of the pareto frontier (though I think 2 minute blocks are probably fast enough to actually be outside the range of good trade-offs for the reason given here)  and any different value will be worse for enough of the users (without being _better_ for many more of them) that you'll not over come the well justified bias against change. (Well justified because changes undermine confidence in the stability of the system and simply because changes have serious costs)

You also encounter this kind of stop-screwing-with-shit response because there is simply a constant stream of people who think it would be great to leave their mark on bitcoin by twiddling this @#$@ inconsequential parameter or that @#$@# inconsequential parameter.  While doing to they distract people from real development work and cast a cloud of doubt over the stability of the system for people who don't know enough to know that these proposals will go nowhere. Sometimes people do this in order to promote "alternatives" whos increased adoption will be greatly profitable for them.  Whatever the motivations— honest, selfish, or otherwise— it all gets old really fast.

I started this thread because I thought it looked like an obvious scam (certainly in the initial form which had a lot less information that now) and I was concerned because of I knew people were sending them funds and I thought a little sunshine would help people keep safe.

All that said, I think you're taking a much stronger position than is currently justified by the facts. Perhaps you're right, hell if I know.  But if you're so sure, the thing to do is to join in the betting, not spread speculation and slander.

The needs for mining are so out of wack with other sha256 engine uses... 1MH/s ~= 1 Gbit/sec of sha256 that the idea of using an engine used for something else seems implausible.

Grey market ("fell off truck") FPGAs? More plausible... but their power figures don't really support FPGAs unless perhaps a batch of 22nm FPGAs "fell off a truck".

SASIC is basically plausable and the upfront costs aren't that crazy. Of course, you'd want to keep it as private as long as possible— because anyone else could go and do it too once you've proven the demand. The work is not trivial but it's not a moat either.