Yes, I did misplace the decimal point.  I'm really good at that.

DeathAndTaxes: I'm normally impressed with your posts, but I think you've got some details wrong.

First, RE: the orphan cost of transactions:  Decker/Wattenhofer measured 80ms for a 1K bigger block. The math to compute orphan cost is:
Plugging in 25 XBT block reward, 600 target time, 0.08 delta time, and assuming no fees (to make the math easier):

So 3.3 millies per kilobyte is the orphan cost.

Even if we assume Decker/Wattenhofer are off by a factor of two (we have made some improvements since they measured block propagation; better measurements welcome), default transaction fees (1 to 5 millies per kilobyte) are in the right ballpark to minimize orphan costs. the .1 default transaction fee does not come close to covering the orphan cost (edited: thanks foxpup).

It should be fairly easy to get about another factor of about 10-20 reduction in orphan costs. And as I said in another thread, if EVERYBODY produces larger blocks then EVERYBODY bears the increased orphan cost, and the result is better for everybody . There is a fixed number of new bitcoins to be earned, regardless of the orphan rate; everybody's share of that fixed number will be the same if everybody has a slightly higher orphan block rate. But everybody will earn more fees, and their bitcoins will be worth more because bitcoins will be more useful.

Transaction fees are likely to go up (in dollar terms) for a while, until some engineering work is done to reduce the "orphan cost" for miners to include more transactions in their blocks OR mining pools / miners collectively agree to include more transactions for the good of the whole system.

In the very short term, you can ask mining pool operators to create larger blocks. If they refuse, then switch your miners to a pool that does.

If they all create larger blocks, then we get more transactions and more orphan blocks, but the cost of those extra orphan blocks is spread across everybody mining, so everybody gets just as many bitcoins (on average) as they would with smaller blocks.

No.

By the way:

I really like your proposal, ByteCoin. I think it captures the intuitive notion of "incentivize publishing blocks immediately as the best policy".

IF all proof-of-work-valid chains are relayed (and, as I said, my intuition is that they should be) then highest-number-of-transactionseconds seems like a very good criteria for resolving ties.

Unconfirmed wallet transactions are automatically rebroadcast by bitcoind/Bitcoin-QT until they are confirmed.

A surprising number of people will trade anything that has a price.

Yes.

I am much more worried about transaction fees right now than "selfish mining". That is why I've been working on better fee estimation in the reference implementation.

I agree with Mike-- we need better measurement, and we need to make "full-match merkle block relaying" the default to drive that 80ms number way down.

Nice! Can you open source this?

Is the simulator accurately modeling how orphan blocks are (not) relayed?

It would also be useful to see total revenue, and total-revenue-expected-if-everybody-mines-honestly for both the entire network and the attacker.

I have several partly-formed thoughts.

First, on "is there REALLY a problem" -- I think Ed Felten makes a good argument that, at least in the current world of mining pools, the incentives work to prevent "selfish" mining:  https://freedom-to-tinker.com/blog/felten/bitcoin-isnt-so-broken-after-all/

Related, I think it is important to remember that the current structure and behavior of the p2p networking code is NOT part of the fundamental consensus algorithm. It is easy to change, and, as I've said in the past, I would really like to see blocks and transactions being broadcast over some completely different networking protocol.

I think there is a really interesting theoretical question that I don't know the answer to; I'll try to state it clearly:

As the p2p network is currently implemented, nodes only have a partial view of competing best-chains, because nodes only relay the first node they see at a given height.

If there are two blocks at the same height announced at approximately the same time, they propagate exponentially fast across the network in two waves, and only the nodes at the edges of where the waves meet will see both blocks.

Given that network behavior, assuming no selfish mining, there is a strong incentive to announce your block as soon as possible, because in an exponentially fast race any delay is very likely to make you lose.

There are lots of ideas for fixing selfish mining that rely on changing that behavior, and having nodes relay orphan blocks. I think it is important to remember that no matter what rules we SAY the network will follow, we can't stop individual nodes from implementing whatever rules they wish to follow; any solution that begins "If all nodes do THIS..." is not a solution.

That applies to the behavior we have now about not relaying orphan blocks, too, of course. The interesting theoretical question I'm pondering:  does the security of the Bitcoin system depend on the relaying behavior, or on how ties are resolved in block races?

My intuition is that we SHOULD be relaying all orphan blocks, and should let each node decide how to resolve races, but before we talk about how to resolve races I think we should consider the incentives that arise from the current relaying behavior.

+1

This is the kind of analysis that I think we need more of before jumping to the conclusion that there is actually a problem that needs to be fixed. I'm not claiming that HorseRider is correct, but his logic looks plausible and I tend to listen harder to reasonable people who say things like "please check whether my logic is right".

See:
  http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf


You can calculate the "orphan cost" of including an extra 1kilobyte of transactions in your block from that, which gives a floor on reasonable transaction fees.

RE: can we decrease that delay:  sure, up to a point. But across-the-world network latency gives a physical limit.
See, for example:
  http://www.verizonenterprise.com/about/network/latency/

Which "bitcoin client" ?

The client-side of Multibit and electrum should have no problem handling that transaction volume.  Only the transactions relevant to your wallet are sent to your machine when you are running those clients.

The reference implementation can't handle that transaction volume today, but I 100% guarantee that version 11.11 which I 100% guarantee will be released on November 11'th, 2022 will be able to handle that transaction volume.

I feel obliged to insert my standard disclaimer:  Bitcoin is an experiment in progress.  Only invest time or money that you can afford to lose, there is still a chance the experiment may fail for some reason we don't forsee.  Past results are no guarantee blah blah blah.

That said, I'm more confident than ever that the network will be able to scale up and remain decentralized.

No; miners have a natural incentive to want to be closely connected to as many other miners as possible (to reduce orphan costs).

RE: Evaluating sybil resistance: I would still like to see blocks and transactions being broadcast over another completely different networking protocol, either peer-to-peer or not. More diversity so we're not relying on the one p2p network would be great, and, depending on how it was implemented, might automatically bring sybil resistance.

No. If their anonymous credential scheme is successful (and I hope it is!), then the payment protocol should be extended to use it. The payment protocol is quite carefully designed so that replacing the public key infrastructure system is easy.

Mmm.  Maybe.

That sounds a lot like the alternative local currency movement-- create a local currency that somehow expresses the local community's values.

I'm probably just a too-logical, cold-hearted geek, but building community around a currency doesn't strike a chord with me. To me, community is about people, and a currency is just a tool for transactions. I guess an analogy would be a bunch of carpenters who build a community around some Extra Special brand of nails that they create and trade amongst themselves.

You're right, I apologize. I just added libbitcoin to that list.

RE: bitcoin-security mailing list:  bottom line is I don't trust you. I think you have made irresponsible decisions in the past, and I don't trust that you would handle sensitive security issues responsibly.  Happily there have been approximately zero cross-implementation security issues in the last six months, so it is more of a theoretical issue that you're not on the list....

RE: foundation phone call:  I personally agree that fundraising for a vaporware wallet is less newsworthy than a 9 million dollar reputable VC investment.

RE: libbitcoin: when there is significant software using it and it has been "battle tested" a bit I'd be happy to mention it. But last I heard even Intersango was not using it because it was too slow/immature.

Don't do that; spamming is evil.


RE: hyper-complexity of the multi-coin paradigm:

uhhh...  Were you a postmodern lit major in college?


I've got a pretty simple, but I think fairly accurate, view of money/wealth.

I believe you can't create wealth just by printing money.  You can create the illusion of wealth (and I imagine some Keynesians would argue the illusion is enough to lubricate the economy and somehow increase productivity and growth and wealth; lets set aside that argument).

You can create wealth by making it easier for people to transact (and money is the world's best invention for doing that, barter is terribly inefficient).

I'm still stuck on how y'all think altcoins create wealth. I don't see any of them being any easier to transact than Bitcoin.

Please don't say "official client" -- there is no "official."

"Reference implementation" is more accurate.

Lack of SPV mode in the reference implementation is mostly due to lack of testing / code review resources.