Topic: 90 minutes for 1 block... (Read 7104 times)

Actually not. Most of The United States is rural with big cities helping to even out the cost. A lot of rural areas can't even get broadband internet. I often see postings showing smaller countries having better/faster internet because they have a smaller area to cover which costs less to build out.

Edit: Oh never mind. That is what you meant.

Yeah yeah, you also have many more capita per sq mile to help pay for the infrastructure costs. 

In Munich I have 100mbps for some 40€/month

Maybe the barriers to do a full node will decrease but the incentive to do so decreases just as well. With a Bitcoin Spinner style (Mike Hearn(?) suggested to have full nodes do the book keeping for the connected thin clients with variable anonymity towards that full node by querying a superset of the own keys at this and other nodes. Such a solution would have all the privacy and security the average user might want at a fraction of the costs of running a full node.

It's Comcast, and the charge is $115/month if I remember correctly.

50mbps!?  What ISP are you using and how many arms and legs are they charging you for that!?

right now I pay ~$50 for 24mbps

if only i had FIOS in my location

I disagree.  Bitcoin blockchain growth will be linear while technological innovation and progress will be exponential.  At some point, the Bitcoin block chain will be no bigger deal than a simple word document.

1MB (max block size) * 6 * 24 * 365 = 53GB.  That's the maximum growth of the blockchain per year.  We already have 3 TB HDD's, so those'll last for 56 years.  And in 56 years, we should theoretically have 268 exabyte HDD's, which would last, for all intents and purposes with regards to Bitcoin, indefinitely.

And if you want to talk about bandwidth, it's the same story.  I now have 50mbps cable service available to my residence.  5 years ago, I only had 12mbps available.  10 years ago, I only had 768kbps dsl available.  So bandwidth is basically following Moore's law as well.  In 5 more years, I should have 300mbps service, etc, while the bandwidth requirements of Bitcoin will remain the same, at 53GB/year (or 13kbps).

… until pruning comes along and I'm very very sure it will. storing all the information about addresses with 0$atoshi in them is just waste of disk space.

… also "tens of thousands of computers forever" could be disputed. Bet in 5 years from now, full nodes will be down to less than 10k either because bitcoin became obsolete or too high traffic for most people.

I find this issue a little bit similar to when businesses destroy perfectly good (over)stock, and then people complain that they should have given it away instead.

But giving it away decreases the perceived value of the remaining stock.

If miners give away the same service for free, what incentive is that for people to pay tx fees?

There is a hard-coded block size limit. There is often many blocks worth of transactions waiting to be included in a block, even now.

Miners are the gatekeeper to the blockchain, they generally use the standard inclusion rules of Bitcoin, but can also modify the Bitcoin client to prioritize or limit transactions. Every single transaction that is included in a block is going to be stored on tens of thousands of computers forever; transactions use many more resources than simply a millisecond of a miner's time. Bitcoin fee and priority rules currently only discourage the spammiest of spam transactions from being sent, which is why you still see things like the hundreds of thousands of .00000001 BTC payments that satoshidice has sent in the past several months.

See, this is what I don't get?  How fucking hard is it seriously for a pool to include all transactions?  I mean is it THAT intensive that at a certain point they just have to drop all lower paying ones or something?  Isn't a block like a couple kilobytes and formed by running a couple milliseconds of hashes?  I bet my desktop could make a 10,000 transaction block in under a second let alone a pool's web server.  This whole include or exclude system makes absolutely zero sense.

Interesting point. I agree.

Still, with MBRs as I suggest none of that matters; block size would be irrelevant to propagation. You get rid of the network effect which is where the latency builds.

Assuming a constant hashrate:
-The probability that a block won't be found after 10 minutes is 50%, or .5.
-The probability that a block won't be found after 20 minutes is .5 * .5 = .5 ^ 2 = 25%.
-The probability that a block won't be found after 90 minutes is .00195, 0.2%, indicating 1-in-512 blocks can be expected to take 90 minutes or more (averaging about one in four days with long-term sampling)
-The probability that a block won't be found after one day of mining is .5 ^ 144 = 0.000000000000000000000000000000000000000005%

The term "rounds" is only used in pools to describe the periods between their block finds and the work/reward evaluation time.

Being able to alter the target difficulty based on included transactions (theory omitted from quote) is unacceptable; a miner could just pad his own valueless transactions in a block up to the maximum block size; everybody would be making 500K blocks and bloating the blockchain with faster-than-expected blocks.

The system now is perfect: miners have a financial incentive to include as many fee-paying transactions as possible, and a disincentive to include free transactions (as a larger block increases the risk of an orphaned block by making block propagation time longer). This keeps cruft out of the blockchain.  

Block propagation times are currently roughly proportional to block size, so it's actually an incentive to mine smaller blocks. I know Luke-Jr has limited the number of transactions he puts into his pool's blocks for exactly this reason. The interesting part is that for a given transaction rate, the average block size is going to be roughly proportional to the time between blocks - so you can have a faster block rate with smaller blocks, or a slower block rate with bigger ones, and in theory they should converge roughly the same.

+1

I don't know how Goat has managed to avoid a scammer tag... really he should be permabanned. 

And no, we shouldn't just "ignore" him  but as a community make sure new members learn about him so they can steer clear of having anything to do with him.

We are using the current version of Bitcoin the community agrees is Bitcoin. That doesn't mean it's the same as it always was.

For example, my understanding is that early on a software issue allowed someone to generate a transaction giving their address millions of valid coins. The bug was patched and code was added to ignore the block with that transaction as well as all subsequent blocks after it. This change required everybody to upgrade - users, merchants, and miners - which everyone did and life went on. So we are not using that original Bitcoin, but something else we still call Bitcoin using some of the blockchain from that early version.

If you make a change incompatible with the blockchain, like changing the number of coins scheduled to be created then those coins (like Litecoin or others) will be rejected by the network. Of course, Litecoin is really still just Bitcoin, just another version.

If it was Bitcoin before the hard fork change in Spring that allowed multi-signature transactions (pay-to-script?), and it is no longer Bitcoin because of that change... what is it that we are using now?

No, that's not true. Confirmation simply let's you know a certain amount of computational work went into the block with your transaction, and the more confirmations you have the less likely it is that block will turn out to be invalid. Regardless of how fast the block is found you can have extremely large amounts of computational power necessary to have found it.

In other words, if Litcoin's network was already the same size as Bitcoin's network, and assuming there was no problem with invalid blocks due to network latency, then 1 Litcoin confirmation would be about equal to 1 Bitcoin confirmation.

Yes, you can. I'm working on a post that explains that in fact.

Bitcoin is set. If you make changes to it then it's no longer Bitcoin. It is something else.

What do you mean bisection of the hash rate? Difficulty is adjusted automatically so block creation moves toward the target regardless of hash rate. I think you meant bisection of miners, which would make more sense. But even that is problematic. How do you split miners mining coins into two halves? Mining, like Bitcoin, is decentralized.


Now multi-minute propagation is interesting, and something I hadn't considered for Bitcoin or Litecoin, so I can see your point. Invalid blocks do result currently with Bitcoin from latency of miners learning of found blocks elsewhere due to the network effect.

This problem should worsen as Bitcoin adoption grows and the network expands. So this could conceivably be a problem for Bitcoin, Litecoin, or any cryptocurrency with a block creation around 10 minutes or less on average. Mining invalid blocks is a waste of resources for miners, which would be a disincentive where there is supposed to be incentive. Frequently occurring invalid blocks also complicates trust in confirmations.

However, I think there is a simple solution. It's in everyone's best interest to know of a valid found block as soon as possible. This way work can start on the next block with minimal wasted resources for no reward. While it's not called for in the protocol I think there can be developed what I'd call mining block references or MBRs. This is simply one or more online resources (nodes or sites) where miners can report and check for found blocks. Since all miners (or a significant number anyway) would reference only a few nodes, polling say every few seconds, communication of found blocks could be near instantaneous regardless of network size.

The network effect exists now because Bitcoin is designed to be decentralized. However, smart centralization of some aspects, especially non-critical functions like this can be beneficial. Note this doesn't change the protocol. It's just a reference on top of how things already work. Satoshi's white paper says "When a node finds a proof-of-work, it broadcasts the block to all nodes." It doesn't say how to broadcast that information to all nodes. I think optimization of that is easily accomplished with MBRs.