/bitcoin.org

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

Already on GitHub? Sign in to your account

The "Why" For Standard Transactions, Plus Std Tx Tweaks #436

Merged
merged 2 commits into from Jun 1, 2014

Conversation

Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
4 participants
@harding @saivann @luke-jr @instagibbs
@harding
Contributor

harding commented May 31, 2014

Based on a discussion tonight on IRC with comments from @gmaxwell,
bitcoin428, and kadoban.

  • Add a new introduction to the Standard Transaction section which
    explains the purpose behind standard transactions so readers
    understand that these aren't limitations for limitation's sake. More
    specifically, note that bug-prevention isn't the only reason for
    standard transactions---thanks to @gmaxwell for explaining the forward
    compatablity reason to me.
  • Make it clear that isStandard() only applies to loose transactions and
    that it doesn't apply to txes in blocks. Thanks to bitcoin428 for
    pointing out this source of confusion.
  • Make it cleare that a non-standard redeemScript is a script that would
    not pass isStandard(). Thanks to kadoban for pointing out the absense
    of that information.
@harding
The "Why" For Standard Transactions, Plus Std Tx Tweaks 
Based on a discussion tonight on IRC with comments from @gmaxwell,
bitcoin428, and kadoban.

* Add a new introduction to the Standard Transaction section which
  explains the purpose behind standard transactions so readers
  understand that these aren't limitations for limitation's sake. More
  specifically, note that bug-prevention isn't the only reason for
  standard transactions---thanks to @gmaxwell for explaining the forward
  compatablity reason to me.

* Make it clear that isStandard() only applies to loose transactions and
  that it doesn't apply to txes in blocks.  Thanks to bitcoin428 for
  pointing out this source of confusion.

* Make it cleare that a non-standard redeemScript is a script that would
  not pass isStandard().  Thanks to kadoban for pointing out the absense
  of that information.
This commit was signed with a verified signature.
@harding harding David A. Harding
GPG key ID: 4B29C30FF29EC4B7 Learn about signing commits
f33ea71

@saivann saivann commented on the diff May 31, 2014

View full changes
_includes/guide_transactions.md
+Non-standard transactions---those that fail the test---may be accepted
+by nodes not using the default Bitcoin Core settings. If they are
+included in blocks, they will also avoid the isStandard test and be
+processed. However, miners who produce blocks with non-standard
+transactions put their block reward at risk---if a transaction
+produces a bug, the block which includes it will likely be orphaned by
+other miners.
+
+Besides making it more difficult for someone to attack Bitcoin for
+free by broadcasting harmful transactions, the standard transaction
+test also helps prevent users from creating transactions today that
+would make adding new transaction features in the future more
+difficult. For example, as described above, each transaction includes
+a version number---if users started arbitrarily changing the version
+number, it would become useless as a tool for introducing
+backwards-incompatible features.
@saivann

saivann May 31, 2014

Contributor

@harding Not sure if s/backwards/backward/ ?

@harding

harding May 31, 2014

Contributor

@saivann I believe plural backwards is correct to agree with plural features. I base that purely on my native-speaker ear because I don't actually know what the rule for agreement is when an adverb is used in an adjective phrase.
@saivann
Contributor

saivann commented May 31, 2014

@harding This seems like very good changes. All LGTM!!
@harding
Contributor

harding commented May 31, 2014

@saivann thanks!

In the absence of critical feedback, this will be merged late May 31st UTC.

@luke-jr luke-jr and 3 others commented on an outdated diff May 31, 2014

View full outdated diff
_includes/guide_transactions.md
-0.9, the standard script types are:
+After the discovery of several dangerous bugs in early versions of
+Bitcoin, a test was added which only accepted transactions from the
+network if they had an output script which matched a small set of
+believed-to-be-safe templates and if the rest of the transaction didn't
+violate another small set of rules enforcing good network behavior. This
+is the `isStandard()` test, and transactions which pass it are called
+standard transactions.
+
+Non-standard transactions---those that fail the test---may be accepted
+by nodes not using the default Bitcoin Core settings. If they are
+included in blocks, they will also avoid the isStandard test and be
+processed. However, miners who produce blocks with non-standard
+transactions put their block reward at risk---if a transaction
+produces a bug, the block which includes it will likely be orphaned by
+other miners.
@luke-jr

luke-jr May 31, 2014

Contributor

This sounds a bit FUD-like. Miners (and nodes even) should be encouraged to decide their own policies, not dissuaded by unknown scares that probably don't exist (or they would have been exploited a long time ago!)

@saivann

saivann May 31, 2014

Contributor

@luke-jr I'm not sure I understand; aren't the standard transactions used to avoid bugs? Isn't it an additional risk for miners to accept non-standard transactions, especially supposing that such transactions are much less common?

@harding

harding May 31, 2014

Contributor

@luke-jr how about I revise that final sentence to:

However, miners who produce blocks with non-standard transactions put their block reward at risk if a transaction produces a bug, the block which includes it will likely be orphaned by other miners.

That way we don't say that non-standard is bad, only that buggy transactions are bad. (Which is obvious, but the consequence of losing the block reward is not obvious.)

@luke-jr

luke-jr May 31, 2014

Contributor

That was the original reason for them, but there hasn't been any evidence surfaced that there are presently any such bugs, despite having now 3 years of opportunity to use them with Eligius. Obviously one cannot rule out an increased risk, but it is not a risk that should be considered notable.

@instagibbs

instagibbs May 31, 2014

Contributor

I don't think the main concern is that non-standard transactions will cause them to get orphaned if there's a bug, it's that theoretically the script could cause DoS.

Orphaned blocks by a rouge miner aren't the problem; it's systematic crashing of the network(especially in the Bitcoin Core monoculture we currently have).

For now only a few pools(1?) accept those types of transactions, making it hard to flood the network with some theoretical extremely expensive script.

@luke-jr

luke-jr May 31, 2014

Contributor

Also note that testnet miners by default also miner non-standard transactions, and we haven't seen any exploits on testnet either (where there is no legal liability).

@harding

harding May 31, 2014

Contributor

This guide is for developers, not miners, so I will remove this contentious sentence.

If the issue comes up again in IRC and readers ask why peers don't process non-standard txes from the network but do process non-standard txes from blocks, I will open a separate issue or PR and @ mention everyone participating in this debate.

Thank you @luke-jr, @instagibbs, and @saivann for your feedback.

@saivann

saivann May 31, 2014

Contributor

@harding Thanks!

@luke-jr luke-jr and 1 other commented on an outdated diff May 31, 2014

View full outdated diff
_includes/guide_transactions.md
@@ -378,14 +403,19 @@ accept, broadcast, nor mine your transaction. When you try to broadcast
your transaction to a peer running the default settings, you will
receive an error.
-Unfortunately, if you create a non-standard redeemScript, hash it, and use the hash
+Unfortunately, if you create a redeemScript, hash it, and use the hash
@luke-jr

luke-jr May 31, 2014

Contributor

Maybe off-topic on this PR since it was already there, but "Unfortunately" is making an unnecessary value judgement here. This is a double-edged sword, not merely negative. It allows users to accept non-standard transactions as payments without risking lesser security by miners avoiding them.

@harding

harding May 31, 2014

Contributor

@luke-jr that's a fair point. I'll revise out "unfortunately" and add in a note about how it could be useful (but keep the basic warning intact). Thanks!
@harding
Standard Tx Modifications 
* Remove contentious sentence about mining non-standard txes possibly
  creating orphaned blocks and loss of block reward.  Suggested by
  @luke-jr (thanks!)

* Remove unnecessary value judgement ("unfortunately") against
  non-standard redeemScripts. Mention that they can be used deliberately
  by someone who wants to easily receive payment to a non-standard
  output script. Suggested by @luke-jr (thanks!)
This commit was signed with a verified signature.
@harding harding David A. Harding
GPG key ID: 4B29C30FF29EC4B7 Learn about signing commits
b55fae9
@harding
Contributor

harding commented May 31, 2014

Commit b55fae9 addresses @luke-jr's feedback. (Thanks!)

If no further critical feedback is received, I plan to merge this around 12:00 UTC June 1st, about 24 hours after the last critical feedback was received.

@harding harding merged commit b55fae9 into bitcoin-dot-org:master Jun 1, 2014

@harding harding deleted the harding:standardtxes branch Jun 10, 2014

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