Bitcoin Forum
December 03, 2016, 03:46:04 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3]  All
  Print  
Author Topic: Necessary protocol improvement; dissent on future mining configuration  (Read 5705 times)
ChloeST
Newbie
*
Offline Offline

Activity: 11


View Profile
May 27, 2011, 12:45:38 PM
 #41

How can the cost of transactions become arbitarily high? Mining is a competitive enterprise right now. There is a option in the client to select a maximum processing fee, doesnt this communicate to transaction processors how much they can make by securing your transaction? If clients pay less than it costs to secure the transaction, the transaction is not processed. But if the processor is too greedy and doesn't accept low fees, he will be driven out of the processing market by a processor who is willing to accept the lower fee. The key is that the software is open and free, so the market for processing is huge, and there will always be competition.

Bitcoin has many tangible benefits for its users in comparision to regular finance: anonymity, security, universal acceptance (eventually). The value transfered to processors is well worth the benefits to the client, or clients would not use the system. Some value MUST be transfered to processors, because processing takes energy to undertake, and energy is not free in any sense.

The a question posed is "how many miners do we want?", the answer is we don't want ANY "pro miners".

Currently there are people heavily invested in mining: "pro miners". This group is an anomaly, almost a cancer that has grown on the system. Will these "pro miners" shut down and dissapear once their business becomes anything less than lucrative? For sure. Will bitcoin transactions slow to a crawl? Eventually they will. Will the curency devaluate relative to dollars? Eventually it will. But the currency will always have non-zero value due to its scarcity and it is and always will be traded for other goods/currencies. We can sit back and watch the variance while the system takes time to mature and become a well distributed system where the only miners and payment processors are the users themselves.
1480779964
Hero Member
*
Offline Offline

Posts: 1480779964

View Profile Personal Message (Offline)

Ignore
1480779964
Reply with quote  #2

1480779964
Report to moderator
1480779964
Hero Member
*
Offline Offline

Posts: 1480779964

View Profile Personal Message (Offline)

Ignore
1480779964
Reply with quote  #2

1480779964
Report to moderator
1480779964
Hero Member
*
Offline Offline

Posts: 1480779964

View Profile Personal Message (Offline)

Ignore
1480779964
Reply with quote  #2

1480779964
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480779964
Hero Member
*
Offline Offline

Posts: 1480779964

View Profile Personal Message (Offline)

Ignore
1480779964
Reply with quote  #2

1480779964
Report to moderator
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
May 27, 2011, 12:53:02 PM
 #42

For family and friends you don't even need to broadcast the transaction at all. That's not the problem. The problem is scaling it up.

The argument goes like this. If the cost of including a transaction is X (a small figure), why would anyone attach a fee higher than X + 0.00000001? Miners would include those transactions anyway unless there is some artificial minimum fee or scalability limit stopping them. Yet if all the fees are very low, there won't be much real mining done. The problem is that in the current model you're paying for block inclusion, not actually security.

You can say, well, attach a bigger fee if you need more security. It'll pay for mining on the current block and then future blocks too. More fees == more hashes of work piled on your transaction. But, you can't really pay for the security you need yourself. If you receive a payment for 1000 BTC in return for some goods which cost you 500 BTC, then guy paying you can easily spend 900 BTC to reverse the transaction (100 BTC profit for him), you can't spend anywhere near that much. In a 1-on-1 race the merchant always loses. The chain only works if everyone reinforces everyone elses security. Then the issue becomes, if there are a bunch of people paying for lots of mining to be done on some blocks, I can just pay whatever the minimum is to get into a block and benefit from the free work. The extra hard blocks paid for by others protect my transactions just as well as theirs.

So this is the argument as to why it won't work. Now, it's a theoretical argument, mind you. The free rider problem exists for copyrighted works too ... why would I pay for a {video,game,book,album} when I can download it for free? People do anyway. Relying on altruism and honesty isn't going to convince many people however.

asdf
Hero Member
*****
Offline Offline

Activity: 527


View Profile
May 28, 2011, 02:03:48 AM
 #43

The argument goes like this. If the cost of including a transaction is X (a small figure), why would anyone attach a fee higher than X + 0.00000001? Miners would include those transactions anyway unless there is some artificial minimum fee or scalability limit stopping them. Yet if all the fees are very low, there won't be much real mining done. The problem is that in the current model you're paying for block inclusion, not actually security.

Thank you for so eloquently stating the problem. A solution I brought up in another thread goes like this (http://forum.bitcoin.org/index.php?topic=6284.msg134662):

Change the fee structure to pay 50% of fee proceeds to the block solver and 50% to the solver of the next block. This way, fees will approach 2 times the cost of including a transaction. So half the fees cover the cost of transaction inclusion and the other half goes to securing the network.

I didn't get a very positive response in the other thread, but as I can see how well you understand the issue, I would love your feedback on this proposal. Thank you.
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
May 28, 2011, 10:06:01 AM
 #44

Your proposal means changing the voting rules (ie a global upgrade). At that point it doesn't seem much different to just setting a minimum fee, except that it adjusts slightly depending on how efficient the nodes are at verifying transactions.

There are several solutions that "solve" the problem like setting min fees, keeping inflation, etc. The question is, what solution allows Bitcoin to reach its full potential without restricting it to particular risk classes?
asdf
Hero Member
*****
Offline Offline

Activity: 527


View Profile
May 29, 2011, 01:23:33 AM
 #45

Your proposal means changing the voting rules (ie a global upgrade). At that point it doesn't seem much different to just setting a minimum fee, except that it adjusts slightly depending on how efficient the nodes are at verifying transactions.

Well, that's a pretty important difference, isn't it?

There are several solutions that "solve" the problem like setting min fees, keeping inflation, etc. The question is, what solution allows Bitcoin to reach its full potential without restricting it to particular risk classes?

min fees and constant inflation have problems. My solution is market based and scales with increased usage and change in electricity costs and the value of bitcoin. Which is exactly what we want. It ensures a sustainable market for mining, absent block rewards, and it's very simple to implement.

Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
May 30, 2011, 11:16:13 AM
 #46

Yeah, I think your proposal is better than some of the simpler solutions out there.

My point is that pegging the security level to some arbitrary value (and yours is still arbitrary as it's linked to something unrelated, verification cost) means either we'll exclude micropayments or Bitcoin will become uncompetitive with wire transfers for large, high risk transactions. It'd be nice to find a solution that makes Bitcoin suitable for everyone, and fortunately there are many years and even decades to find such a solution.
asdf
Hero Member
*****
Offline Offline

Activity: 527


View Profile
June 02, 2011, 02:33:52 AM
 #47

Yeah, I think your proposal is better than some of the simpler solutions out there.

My point is that pegging the security level to some arbitrary value (and yours is still arbitrary as it's linked to something unrelated, verification cost) means either we'll exclude micropayments or Bitcoin will become uncompetitive with wire transfers for large, high risk transactions. It'd be nice to find a solution that makes Bitcoin suitable for everyone, and fortunately there are many years and even decades to find such a solution.

Well it doesn't really peg fees to anything. Fees will naturally approach the cost of including a transaction, which means miners will have no margin. I'm merely proposing a simple change which will result in fees naturally approaching double the cost of inclusion.

I don't think doubling the natural fee equilibrium will eliminate micropayments.
Stefan Thomas
Full Member
***
Offline Offline

Activity: 235


AKA: Justmoon


View Profile WWW
June 05, 2011, 03:05:01 PM
 #48

I don't think doubling the natural fee equilibrium will eliminate micropayments.

I don't think doubling the natural fee will be anywhere near enough to create the necessary hashing rate. My guess for a sensible hashing budget to ensure security would be somewhere around two hundred times the transaction fees. Remember, we are assuming a world where transaction fees are no longer dictated by the client developers. They would be much lower than what they are now - an ECDSA verification does not cost 0.005 BTC, not even close.

The point is, arbitrary rules like this will result in hashing revenue that is too high (wasting money, electricity, etc.) or too low.

There are lots of impossible to predict factors such as the likelihood of government intervention that algorithms can't predict or incorporate. Therefore they will need changing from time to time. Miners will seek to influence this process. Gavin might be all idealistic now, but opinions change, invitations to exclusive sporting events get made, you know how it is. Certainly a little bit higher security wouldn't hurt, would it? There have been some double spends recently, haven't there? I mean we're not talking about a major change here, we'll just tweak this knob a little. See? This wasn't so bad was it!

I'm not sure if the lobbying of Bitcoin developers can be prevented in the long run, but in the short run let's at least not give ourselves outright control over miner income.

I'll use the rest of this post to explain why I think that users will be able to solve this problem quite efficiently themselves, without developers having to intervene at all.


transactions have wildly varying tolerances to risk.

This is exactly why I suggested an insurance model. It covers these differences - if you are a merchant who has a low rate of double spends because your customers are all very honest, you can get lower insurance premiums. If you're sending money to grandma, you don't need to pay insurance at all.


The problem with a single chain is it sets a single speed and security level for everyone

Sorry, but you're looking at it backwards. The security is additive. The chain security is the sum of what everyone using it is willing to spend on security. So if you send money to your grandma using Bitcoin and you don't get insurance, you don't contribute to the security level, but you don't detract from it either. (Note that even if you don't pay insurance you still carry the cost of hashing, because you still carry the risk of your transaction not getting confirmed. In other words, you benefit from insurance company's attempts at improving security. But, the risk you carry is a cost worth roughly1 what you would've paid for insurance so it's not like you're leeching of of anybody or whatever.)

If someone transfers billions of dollars worth of coins at a time where Bitcoin's security is fairly low, he will have to pay high premiums. The insurance firm will try and figure out if it's better to raise the hashing rate or just shoulder a higher risk of an attack happening. If the risk is too great for whatever reason to use Bitcoin for such a transfer, the premium will be prohibitive and the transfer won't take place. If you think that's a bad thing and you advocate some minimum fee or other artificial way of raising the hashing level - what you're essentially advocating is my grandma and me subsidizing other people who do other kinds of transactions. Personally I think all types of transactions will be easily insurable in practice, but who knows. It's better to have a system where some extreme edge case transactions are too risky and uninsurable than a system where everyone else has to carry the cost for the riskiest transactions.

In a world with Bitcoin transaction insurance, the amount of money available for hashing at any given time is the total amount of money being transferred with insurance. In the short run, insurance companies will be willing to spend up to 100% of a transaction's amount in order to get it confirmed. For example they may do a contract with a render farm or super computing center to provide extra hashing in case of a large-scale surprise attack. They will contract with each other to coordinate such efforts - because that means lower risk from large attacks and that means lower costs.

A long-term attack like a government trying to shut Bitcoin down would cause them to raise premiums and at that point it's a matter of who is willing to spend more money overall: the global Bitcoin user base or the attacker. However, "more hashing" is not always the best defense. Imagine the US government attacking Bitcoin. Insurance companies could hire lobbying firms to stop that practice. They could advertise to get public support. They could help mobilize and fund Bitcoin's grassroots supporters and stakeholders.

In the event of a private company like a competing payment processor attacking Bitcoin, they might seek help from law enforcement. Hashing for the purpose of blocking all transactions or otherwise interfering with Bitcoin would likely be considered criminal hacking in most countries. Even if legal prosecution doesn't succeed, such practices if exposed would do tremendous damage to a company's image. So if you can find out who recently bought ten thousand high performance graphics cards, they would be in a lot of trouble.

Insurance is the tried and true way of dealing with risk. Whether it's a Bitcoin transaction or a money truck, if you want to be covered in case it doesn't make it, get insured. And the nice thing with Bitcoin is that money in transfer can't actually be stolen, only stopped/reversed. So Bitcoin transfers between trusted parties at least will be a lot cheaper to insure than any money truck.

And once again, I'm not advocating for doing anything. All I'm saying is that Satoshi's design will hold up as is. Regulation of the hashing level does not have to and SHOULD NOT be included in the protocol. Because doing so would be much less flexible and fair than letting people create suitable institutions themselves.



1 Reality is a bit messy - the person getting insurance would pay a little bit more than the pure risk due to administrative overhead. But as the existance of other insurance companies proves, people are willing to pay that little bit extra in order to have certainty. It is likely that many transactions, if not most, would be insured. Convenience goes a long way.

Twitter: @justmoon
PGP: D16E 7B04 42B9 F02E 0660  C094 C947 3700 A4B0 8BF3
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!