New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ZCA­004 - Decrease in huge­ reorg security margin #1387

Closed
nathan-at-least opened this Issue Sep 13, 2016 · 6 comments

Comments

Projects
None yet
4 participants
@nathan-at-least
Copy link
Contributor

nathan-at-least commented Sep 13, 2016

No description provided.

@nathan-at-least nathan-at-least changed the title ZCA­004 - Decrease in huge­reorg security margin ZCA­004 - Decrease in huge­ reorg security margin Sep 13, 2016

@str4d

This comment has been minimized.

Copy link
Contributor

str4d commented Sep 13, 2016

The longest Bitcoin reorg I know of was this six-hour one in 2012.

@nathan-at-least

This comment has been minimized.

Copy link
Contributor Author

nathan-at-least commented Sep 13, 2016

We had a discussion about this just now. There are some subtle user-facing impacts here:

Reorg-Triggered Invalidation: We already have a similar issue whenever re-orgs invalidate JoinSplit anchors, in which case the user experience is transaction reversal where funds are 'returned to original senders' at the reorg point. In the additional case that reorg > coinbase maturity, not only do some of the funds get returned to senders, but some 'evaporate' (although other miners have received a similar amount of funds). In some cases, such as the reversion of a single step of JS xfer, a friendly business may reissue a transfer to make some prior economic trade whole. In the case of longer chains, it's much less clear. I don't see the coinbase maturity making much of a difference compared to the invalidation of JoinSplits.

Wallclock Time as Security Parameter: The maturity level should not only be measured in blocks, because the wall-clock time has two crucial features:

  • opportunity cost: if the wallclock time is X hours, this is X hours of opportunity cost to a malicious miner. An attack of X hours needs to be compared to the next best alternative which may be unrelated to how many blocks fit into X hours. Eg: a large RAM farm does protein folding for money. Diverting those resources for an attack for X hours is independent of blocks-per-time.
  • community reaction time: if an anomaly is detected and the community reacts, if they can do so during the maturity interval, they can prevent widespread (non-young-anchor JoinSplit) txn invalidation.

Again, because JoinSplit invalidation exists, this complicates the utility of the coinbase maturity for me.

@nathan-at-least nathan-at-least added this to the 1.0.0-rc1 milestone Sep 13, 2016

@nathan-at-least

This comment has been minimized.

Copy link
Contributor Author

nathan-at-least commented Sep 13, 2016

I've put this in the rc1 release, even though I'm uncertain about it's priority. I'm at least certain that many items in Beta 2 are higher priority.

@bitcartel

This comment has been minimized.

Copy link
Contributor

bitcartel commented Oct 6, 2016

Document this as we did not change coinbase maturity in beta 2.

@arcalinea arcalinea added the has PR label Oct 11, 2016

zkbot pushed a commit that referenced this issue Oct 14, 2016

zkbot
Auto merge of #1499 - arcalinea:document-coinbase-maturity-security, …
…r=bitcartel

Note that Coinbase maturity interval does not protect JoinSplits

Changed wording of Block Chain Reorganization section in security-warnings.md to note that we did not change Coinbase maturity #1387, but that this also does not protect JoinSplits from becoming invalidated in the case of a block chain reorg #953
@str4d

This comment has been minimized.

Copy link
Contributor

str4d commented Oct 17, 2016

@nathan-at-least was this issue satisfied by #1499 or is there more to do?

@nathan-at-least

This comment has been minimized.

Copy link
Contributor Author

nathan-at-least commented Oct 17, 2016

Documentation in #1499 is sufficient for this purpose.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment