Bitcoin Forum
December 11, 2016, 12:20:08 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]  All
  Print  
Author Topic: Post-inflation security  (Read 4501 times)
WNS
Jr. Member
*
Offline Offline

Activity: 39


View Profile
May 18, 2011, 01:55:43 PM
 #21

In the long run, block size will NOT be the bottleneck, so it will NOT determine the marginal cost of a transaction.

The bottleneck is, and I believe will continue to be, the number of ECDSA signature verifications a miner can perform per second.  Each miner (or mining pool operator) will have a transaction processing capacity of N transactions per second.

If there are more than N transactions per second going across the network, then the smart miners will select the most profitable N for inclusion in their blocks and drop the least profitable.

Okay I totally don't understand. If the block size is not a limit then why would anybody drop a tx that they had already paid the ECDSA price for?

16goksYouT6FofaaPMXBDgYC8oYsXkjdtk
1481458808
Hero Member
*
Offline Offline

Posts: 1481458808

View Profile Personal Message (Offline)

Ignore
1481458808
Reply with quote  #2

1481458808
Report to moderator
1481458808
Hero Member
*
Offline Offline

Posts: 1481458808

View Profile Personal Message (Offline)

Ignore
1481458808
Reply with quote  #2

1481458808
Report to moderator
1481458808
Hero Member
*
Offline Offline

Posts: 1481458808

View Profile Personal Message (Offline)

Ignore
1481458808
Reply with quote  #2

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

Posts: 1481458808

View Profile Personal Message (Offline)

Ignore
1481458808
Reply with quote  #2

1481458808
Report to moderator
1481458808
Hero Member
*
Offline Offline

Posts: 1481458808

View Profile Personal Message (Offline)

Ignore
1481458808
Reply with quote  #2

1481458808
Report to moderator
1481458808
Hero Member
*
Offline Offline

Posts: 1481458808

View Profile Personal Message (Offline)

Ignore
1481458808
Reply with quote  #2

1481458808
Report to moderator
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
May 18, 2011, 03:00:13 PM
 #22

Okay I totally don't understand. If the block size is not a limit then why would anybody drop a tx that they had already paid the ECDSA price for?

They haven't paid the ECDSA price.  The decision is "I know how big this transaction, how many OP_CHECKSIG opcodes I'll have to compute to verify it, and how much transaction fees it pays.  Should I do the work of verifying it or should I just ignore it?"


@ribuck:  yes, the UI would be much simpler, but internally the client needs a model of what the miners are accepting.  Maybe a really simple internal model will work if the UI is really simple...

How often do you get the chance to work on a potentially world-changing project?
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
May 18, 2011, 03:56:00 PM
 #23

Yes, that sets the minimum fee at the cost of processing and verifying the transaction. It doesn't set any particular level of mining though.

How much work is enough? I think that can only be found by lowering the security of the network until we start seeing transactions be reversed by botnets and such, at that point people (or insurance companies) will start paying more fees in order to reduce or eliminate the reversals.

Perhaps we need to be thinking in terms of minimum fee for acceptance (ie, the cost of processing the transaction) and the additional security fee for mining. Gavins proposal of looking at average fees makes a lot of sense for discovering what the current cost of processing a tx is, if nobody is paying big fees for work done. If the average is being distorted by transactions moving millions of BTC around then you might end up paying more than the actual cost of processing transactions.
Stefan Thomas
Full Member
***
Offline Offline

Activity: 235


AKA: Justmoon


View Profile WWW
May 19, 2011, 08:02:22 AM
 #24

Some points I'd like to add to the discussion:

Fees are always paid by the recipient (even though it might seem the other way around)

The only party directly interested in the success of the transfer is the recipient. The sender is only willing to pay a fee on behalf of the recipient. The sender gains nothing from coins disappearing from his wallet, however the recipient needs the transfer to be successful in order to take definitive custody of the coins transferred.

Even in cases where it seems like the sender pays the fee voluntarily he's still only acting on behalf of the recipient. So if I send money to my grandma and she says "don't include a fee," but I do, it's because I'm acting altruistically in the interest of my grandma.

Therefore it provides a clearer picture to look at transaction costs from the perspective of the recipient.

Cost function

Gavin's formula captures the normal situation perfectly. But [mike] correctly points out that there is another cost, currently hidden (because it is very, very near zero at the moment).

So extending Gavin's formula with the risks, we get:

cost = f(txn, B, P) + txamount * (1-P) + txamount * PA

PA ... Probability of a successful attempt by s.b. to overtake the block chain for the purpose of rejecting/delaying at least this transaction.

Or, in other words, the total cost of a transaction is
- the fee paid, plus
- the risk of it not being included because the fee is too low, plus
- the risk of it not being included because the block chain has been overtaken.

That means that if f() is continuous we can actually find an optimal P for any given txn and B. (In the formulas I use myself, I actually use t for time, however B is Bitcoin's representation of time, so it's just a different unit essentially.)

At the moment PA is very, very small. This is because seigniorage provides an added incentive to mine, leading to much, much higher hash rates.

As minting is phased out, the hashing rate will come down, and PA will rise. At some point it will start to be noticeable either as a risk by observant users or because an attack has actually taken place.

In terms of the P2P client... For now it seems reasonable to assume that PA is for all intents and purposes zero. And if we can indeed figure out a good approximation function for f(), we should be able to calculate the recommended fee based solely on txn and B. Note that an optimal P will likely be fairly close to 1, because we're counting the tx not getting confirmed at the requested time as a total loss (which is an exaggeration). But it allows us to ask the user "How fast do you want this to get confirmed?" and it will almost always get confirmed at least by that time.

In terms of future solutions... I expect insurance providers to crop up very soon. Even with PA = 0, they can still provide a useful service by offering t < 10min, something the P2P client can't offer. As soon as PA starts rising that will simply become another selling point for them.


Disclaimer: I actually suck at math, so feel free to point out any errors in my formulas/reasoning. Smiley

Twitter: @justmoon
PGP: D16E 7B04 42B9 F02E 0660  C094 C947 3700 A4B0 8BF3
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2100



View Profile
May 19, 2011, 09:54:32 AM
 #25

[mike]:

Quote
How much work is enough? I think that can only be found by lowering the security of the network until we start seeing transactions be reversed by botnets and such, at that point people (or insurance companies) will start paying more fees in order to reduce or eliminate the reversals.

There are other attacks they may require more security than double-spends. It is going to be really hard to answer the "How much is enough?" question until there is a systemic, existential threat presenting itself and we can measure the size of it .... or ?

John Tobey
Hero Member
*****
Offline Offline

Activity: 481



View Profile WWW
May 20, 2011, 05:33:29 PM
 #26

Some of us seem worried about how payers will know what size fee to offer.

I don't understand the problem.  Payers can effectively expedite a slow transaction by submitting a similar one with a larger fee while the first tx languishes unprocessed.  To guard against double-receipt (the flip side of the double-spend problem) the wallet software must simply:

  • make the transactions mutually incompatible by having them share inputs
  • use inputs that are unlikely to receive BTC (such as hidden change addresses), (edit: not needed; inputs on the wire reference earlier transactions, not addresses) and
  • prepare to handle the possible outcomes: tx 1 accepted, tx 2 accepted, or both languish.

As Gavin eloquently explained, miners will have different and evolving cost structures and preferences.  For a given received tx, a miner will have an algorithm by which to:

  • drop it and treat it as spam or DoS attack (block the sending node, sue the sender)
  • just drop it
  • keep it for possible later processing, or
  • include it in the current block

and either relay or not relay it.

The result will be a "fee curve" of cost over expected processing time for a given tx size.  People will invent ways to compute the curve, if nothing else, then by periodic experiment, and the curve will be generally published as a guide to payment software.

I hope this alleviates the worry.

Can a change to the best-chain criteria protect against 51% to 90+% attacks without a hard fork?
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
May 22, 2011, 08:19:20 AM
 #27

Replacing transactions like that isn't possible today. Making it possible would be, to quote Satoshi, "easier said than implemented".
John Tobey
Hero Member
*****
Offline Offline

Activity: 481



View Profile WWW
May 22, 2011, 12:11:28 PM
 #28

Replacing transactions like that isn't possible today. Making it possible would be, to quote Satoshi, "easier said than implemented".

You mean it's not implemented in the software, right?  As far as the protocol is concerned, I believe it is possible.  Yes, it would present an accounting challenge for the current wallet model.

Can a change to the best-chain criteria protect against 51% to 90+% attacks without a hard fork?
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
May 22, 2011, 02:05:07 PM
 #29

Right, it's not implemented in the software. It's tricky because the codebase assumes you aren't trying to double spend.

Regardless, I don't think it's necessary. "Guessing" the right fee level like this is going to be very slow. There are better ways.
John Tobey
Hero Member
*****
Offline Offline

Activity: 481



View Profile WWW
May 22, 2011, 04:05:47 PM
 #30

Right, it's not implemented in the software. It's tricky because the codebase assumes you aren't trying to double spend.

Regardless, I don't think it's necessary. "Guessing" the right fee level like this is going to be very slow. There are better ways.

Better ways for end users, sure, like your idea (if I remember) of servicers who, for a fee, would guarantee an acceptance time and assume the associated risk.  I see nothing wrong with that.

I worry, though, about worse ways being proposed, such as changing the block payout policy, which amounts to messing with monetary policy.

Double-spending as a strategy to speed payment already exists, in a sense.  It is implicit in the protocol.  I wouldn't be surprised if someone has already tried it (using wallet backups or custom software).  I would be surprised if it never becomes an at least occasional standard practice.

Can a change to the best-chain criteria protect against 51% to 90+% attacks without a hard fork?
Pages: « 1 [2]  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!