WIth a US bank, you can use cash, check to pay someone without incurring any fees. If you use a debit card, you pay 21 cents in fees. A federal law limits debit card fees to 21 cents in the U.S.

That is the closest comparable to bitcoin in the U.S. because credit card fees are due to the fact that credit card spending is a loan. When you buy something with a credit card, you are spending money you don't have. At the end of the month, you have the option to pay or to roll the balance to the next month. If you pay the credit card off every month, you have no fees. The vendor getting your money does pay a fee, you just don't see it. Since things are generally priced the same whether you pay by cash, check, debit card or credit card, as a consumer it is usually best to buy with a credit card because you can dispute the transaction easily if there is a problem. And you can get cash back rewards with a lot of cards, making using a credit card the cheapest option to purchase something.

Buying something with a credit card that has a cash back option is by far the cheapest option for consumers buying online. The transaction cost is negative for the consumer.

Transferring money internationally by wire can be expensive.I only use wire transfers for amounts above $50,000 because the fee can be $30 or so. When I transfer money internationally, I usually use Transferwise. It has a flat $3 fee for transfer under $300. That includes the conversion into the receiving parties local currency with the rate locked for 24 hours at the mid market day rate. So, you aren't just getting the transfer, the receiver is getting local currency. To transfer bitcoin using local currency, you'd need to buy buycoin and the receiver would need to sell bitcoin. Both sides incur an exchange fee and the transfer fee is on top of that.

Bitcoin is good for illegal transactions like the current ransomware attack. The illegal transaction market is a decent sized market and people don't care about fees very much.

Some proponents say "look at Venezuela" and talk about currency inflation as a reason bitcoin will eventually become popular as a currency. People don't use currency as a store of value. How many people own paper dollars as an investment? None. People own assets, the dollar is a means of exchange. It is what things are priced in. When the "value of the dollar" goes down, it means other asset prices have gone up compared to the dollar. Venezuela is not having issues because the value of the Bolivar is going to hell. The value of the Bolivar is going to hell because the country has fallen apart and all assets in Venezuela, including the Bolivar, are becoming worthless as a result.

The best proxy for bitcoin is public stock in a company that has no income, no assets and that pays no dividends. It is not a currency, it is an asset that can be bought or sold, only to someone else. Like a stock, you can transfer the stock to someone else through a broker (miner) and you will incur a transaction fee to do so.

I am not saying this is a good or bad thing or what it means for the future.

Basically. But the bitcoin community actually supports him pretending to be "Nakamoto" because it is a good distraction.

And if you spend more than a half hour researching it, it is pretty clear who the main Nakamoto was. He's the one who deleted the web pages back when bitcoin was released talking about it. Unfortunately, you can't delete history completely once published to the interwebs.

To revisit this idea:

https://news.bitcoin.com/theymos-bitcoins-satoshi-destroyed/

The comment I would make is that the only ones who need to agree to do this are the miners and they would directly benefit from it. It would delay them having to be paid via transaction fees alone, thus keeping the network stable.

I would change the approach described in the article by having the miners perform the operation. They could modify the chain to remove the coins and then keep mining away. As the miners are now concentrated in China, just a handful of miners would have to agree to do this. You don't need any change to code and there is no way for them to be prevented from doing it if they agree since hashing power overrules everything else.

I don't think it would set a precedent for other coins since this is just to protect the ecosystem and the miners. Attempting to do it in the code would never work as there are too many people who are required to agree to do it that way. Agreement between the majority hashing-power miners would be much easier. I'm sure it will be an issue visited when the coin limit date starts getting closer but it would be nice for them to start discussion now.

Regarding this statement:

"4) More fees collected by miners on each block
unknown effect, What if the fees per TX half and the amount of TX's doubles? The amount of collected fees would remain the same in this case. "

If blocks stayed under 1MB there would be no change in fees even with 2MB block support. The statement makes it sounds like changing the system to support 2MB blocks would cause miner transaction fees to increase regardless of the actual size of the block.

I'll explain Danny's answer in a different way. What he stated was that the times in the cells in the original table weren't representative of the data set described.

He then gave an example of rolling 4 dice and how the average time is affected when the players are halved in that game. To further explain his answer, I created a program to generate the same type of data franky generated in the original post but with actual data from the 4 dice game Danny described. The Go program to generate the data is here so you can play with it if you want. You can just press Run to run the program and see the data:

https://play.golang.org/p/piIbg8DLv3

The program has 20 players (shown by row) throwing 4 dice at a time until they get all 1s. Each player does this 25 times (shown by column) and the number of rounds it took them to roll all 1s is displayed in each cell (if you cut and paste it into a spreadsheet).

After cutting and pasting it into a spreadsheet, here is what the result looks like:

http://s23.postimg.org/jvpcsrn8q/20players.jpg

I then highlighted the winning round (lowest number of rounds to get four 1s) in each column in green.

The average of all the lowest rounds in that table is 58.84.

I then took just the first 10 rows from the spreadsheet:

http://s15.postimg.org/5ihhpq0rd/10players.jpg
 
And highlighted the new winning rounds in yellow. The average of all those lowest rounds is 114.56 which is just about double the previous average.

You should be able to take any 10 rows from the original 20 rows and get similar results, the average will be around double even in this small set.

This is another way of looking at Danny's explanation.

Danny, I liked your explanation so much I figured I'd take a couple minutes to code it up so others can play with it. I wrote it in Go so you can just run the code online. You can change the number of players to see how it affects the winning round.

There's only two things to look out for. One is that Google won't allow too many iterations. If you set NUM_TOTAL_GAMES too large, it will complain it is taking too long. Also, if you run the program and then run it again without modifying anything, the answer won't change because Google just gives you the same answer as the last time if the code isn't changed. You need to change a variable or something to get it to actually run the program again.

You will see your math matches up with the output which is what would be expected.

https://play.golang.org/p/uoWEBnjMss

That was a very well written and clear post. Your math is correct and my previous conclusion was wrong.

Yes, it is important which miners drop out, that is why I stated:

"But with a reasonable number of miners and assuming the 50% of miners who may drop out isn't just the group of fastest miners, even half the miners dropping out would not change the time it takes to solve blocks in any dramatic way."

Even if you are talking about losing 50% of the hash rate, the math still doesn't work. You can't say you lose half the hash rate and that causes the time it takes to solve blocks to double. The impact depends on the distribution of miners, the rate at which they can solve blocks individually and which one of them would drop out. Nothing that I wrote was in error.

The original post in this thread was reasonable enough (though light on hard math ) and gave more real world example numbers.

In terms of franky's reworded proposal (not his proposal, I know):

the reward halving is a reduction in income. so lets unnaturally halve the difficulty to double the income (blocks average 5 minutes for 2 weeks) thus not impacting miners profits. and then let the natural difficulty adjustments increase by 10% every 2 weeks. giving pools a delayed and slower reduction of income over 10 weeks, instead of an instant drop overnight

That is a much better way of explaining things. That proposal would increase miner payouts at a very fundamental level during reward halving. Any  increase in miner rewards is born by users in the end and if they are willing to increase miner payouts during that point in time, then it would seem that increasing mining payouts could be considered whenever there was a perceived issue that might impact miner profits. And if that is true, continuing to halve rewards or even holding to a 21MM cap would seem questionable if the thought is that the system can't support itself on transaction fees alone.

Luke Jr stated: "For example, if 50% of miners dropped off the network, blocks would be every 20 minutes on average...". The link to his statement online is my previous post above.


If you have a 1000 sided die and 10 players, the odds of (at least) one rolling a 1 on the first try is:

1 - ((999/1000)^10) = ~0.9955%

it is not 1/100 which is equal to 1%.

Consider you had a 3 sided die and 2 players, what are the odds that at least one throws a 1 on the first try? The answer is: 1 - ((2/3)^2)

To understand this, let's look at the possible combinations:

[player 1's throw, player 2's throw]

[1, 1] [1, 2] [1, 3] [2, 1] [2, 2] [2, 3] [3, 1] [3, 2] [3, 3]

in 5 cases, at least one of the players threw a 1. There are 9 possible combinations of results. So, there is a 5/9 chance of a player throwing a 1 on the first throw which is not 2/3 (that would be 4/9) and 1 - ((2/3)^2) = 5/9

I don't know how a blockchain tx id is proof of anything. A seller could just say it was not their address. How do you prove it was theirs? Anyone can create a bitcoin address, there is no requirement to show legal ID or anything else. Bitcoin has zero proof of actual underlying physical identify of the sender or the receiver of a bitcoin transaction.

I could start a website selling gold myself. A buyer comes in, I create a new address and tell them to send their bitcoins. They send the bitcoins. I tell them I never received the bitcoins and it wasn't my address.

Now, go to court to try and prove that the address way my address. You can't. You may have an email chain that says something. But I would have an email chain that had a different address in it, I'd just modify the email.

How are you going to prove I received your bitcoins?

Who gives a fuck about other people and their problems?

LOL

franky's comment is:

"luke Jr wants to do a hard fork to drop the difficulty because he WRONGLY thinks blocks will take longer to mine due to events of the reward halving."

which I would assume is in reference to lukejr's comment here:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012489.html

where he states:

"For example, if 50% of miners dropped off the network, blocks would be every 20 minutes on average and contain double the transactions they presently do."

Solving blocks is a game of chance. The network attempts to adjust difficultly so blocks can be solved in a certain amount of time (10 minutes). However, blocks can be solved earlier or later than the 10 minute target since it is a game of chance. A miner runs through nonces and other things making different blocks trying to find one with a hash value that has a certain number of leading zeros. You are trying to find one before everyone else does.

The process it the same as players throwing dice and trying to get a certain number first. So, let's look at that game of chance instead of block solving.

Consider 20 players in a game trying to throwing single dice where they keep throwing dice until they get a 6. When one gets a 6, he wins and can publish his win and everyone starts over. Let's assume that it takes 5 seconds for a player to throw their die and see the result.

What are the odds a player will get a 6 in the first 5 seconds (first roll)?

1 - ((5/6)^20) = ~97%

Now, let's say we lose half the players. What are the odds a player will get a 6 in the first 5 seconds (first roll)?

1 - ((5/6)^10) = ~84%

As we get fewer players, it will take longer, on average for a player to roll a 6 in a given amount of time.

However, halving the number of players does not double the amount of time it takes to roll a 6 on average when you have a reasonable number of players.

Luke's post is incorrect in stating that blocks would take double the time, 20 minutes on average, to solve if 50% of the miners dropped off the network immediately.

It is true that miners dropping off the network does increase the time, on average, it takes to solve blocks without any change in difficultly. But with a reasonable number of miners and assuming the 50% of miners who may drop out isn't just the group of fastest miners, even half the miners dropping out would not change the time it takes to solve blocks in any dramatic way.

The size of the block doesn't matter but you can start solving for an empty block before you can start solving for a block with transactions.

Described in the thread referenced above:

Why do some pools do that? Is there an advantage?

Time.  Get the details of the last block mined, immediately start mining for the next - at this point 'empty' - block (and your chance at the block subsidy).  Then while things are busily mining away, build new headers that do include transactions, and at the next opportune moment start mining on that. It's just a small sliver of time, but against an otherwise equal opponent, collecting transactions by default would be a losing strategy in the long run.

From their site, if paying with bitcoin:

All Bitcoin Orders Receive a 4% Discount Relative to Credit Card/PayPal Pricing

If paying with paper check:

All Paper Check Orders Receive a 4% Discount Relative to Credit Card/PayPal Pricing

If paying with bank wire:

All Bank Wire Orders Receive a 4% Discount Relative to Credit Card/PayPal Pricing


So, the "discount" is only a discount against credit card/paypal not against other methods of payment. I've never bought precious metals with anything but a bank wire. As a side note, bank wire is currently not available for them for some reason. I need legal confirmation that the money arrived. When using bitcoin, how do I prove the bitcoins were received by them? Unlike a bank wire, I'm not sure how well the court system would deal with hash addresses if there was any issue. And, as a final comment, I get bank wire transfers for free so I would pay zero to buy using a wire where I would pay a small transaction fee to use bitcoin. The cheapest methods to purchase are paper check (zero fee) and wire transfer (if you can get zero cost wire transfers).

So, every seller needs to run their own server connected to the Internet 24/7? Is that correct?

So, if it does decrease the effective TPS rate, at some point is it an effective limit on the blocksize as well? Or is the effect of empty blocks constant with respect to blocksize? If it does effectively limit the blocksize, what is the limit?

That is all made clear in the thread I referred to above [ correction: thread other poster referred to]. I suggest you read the full thread if you haven't. One of the arguments for mining empty blocks is to prevent double-spend. But the argument is specious and the real reason seems to be miners trying to gain advantage for themselves.

My question stands: Does allowing empty blocks effectively put an real-world limit on the blocksize?

The statement I made, "According to this.. the recommenced transaction fee", is not false. The quote is a direct quote from the article, you can search for it in the coindesk link provided. If you are saying that you believe the article written by coindesk is false or that the data presented by 21.co is false, you should say that instead.

Now that the attack is over, the transaction cost has returned to normal. However, during the attack that appears to have been the accurate cost of processing a "expedient transaction" on the network. If one would have accepted a 13 hour delay for a reasonable number of confirmations, one could have used a standard fee, as stated in the article.

According to this:

http://www.coindesk.com/bitcoin-capacity-nightmare-fees-reality/

The recommended transaction fee from "21.co" for an "expedient transaction" is about $1

"For more expedient transaction times, 21's service recommends a fee of 0.0023 BTC, or about 97 cents, a 2,200% increase from the default fee."

The stackexchange links didn't have much information but the discussion in the bitcointalk mining group had a decent discussion and a lot of data. Thank you for posting it, I hadn't seen it before. There are a few discussions on reddit about it but for the most part, it didn't seem there was any consensus on how it affected the network.

My question still is.. don't zero transaction blocks effectively limit the blocksize?

For example, I would guess you couldn't have a blocksize of 100MB as large miners would publish zero transaction blocks, maybe even multiple zero sized blocks, to orphan other miner's work while they work on making a longer chain. When the block transaction time gets long enough, it seems like the system would break down. And that orphaned work decreases the hashing rate of the entire network. So, these types of transactions seem to artificially cap the total number of transactions and thus the "effective blocksize"?

Or do zero transaction blocks cause a decrease of the effective hashing power of the network that is constant against increases in blocksize?