add outcomes

-define outcomes section
-outline format

69.md

@@ -2,43 +2,26 @@
 
 A poll note is a nostr event type (kind 6969) for conducting valuation polls. A poll presents two or more voting options, each represented by a unique zappable bolt11 address. Voters may participate in polls by zapping one or more chosen option(s). Poll results may be blinded, until after users have voted. Polls may specify a closing time, after which results should be unblinded, closed to new votes, and considered final.
 
-Votes may be tallied either by total valuation or by count. To avoid ambiguity of outcome, the tally method MUST be specified by the poller upon creation of the poll. Once closed, the option with either the highest total associated value (sats) or the most votes (counts) should be treated as the winning option, and the distribution of votes considered respresentative of the combined opinion of its participants.
-
 ## Purpose
 
-The purpose of poll notes is to solicit qualitative public opinion polls by requiring voters pay to participate. By quantitatively tying vote counts and amounts to real satoshi valuations, nostr polls should provide superior signal compared with other free polling models. Imposing real monetary costs on participants should also discourage attempts at fraudulent result manipulation, by automated or other means. 
+The purpose of poll notes is to conduct quantitative public opinion polls over nostr by requiring voters pay to participate. By tying vote amounts and counts to real satoshi valuations, nostr polls should provide superior signal compared with other free polling models. Imposing real monetary costs on participants should also discourage attempts at fraudulent result manipulation, by automated or other means.
 
-Strict adherence to the requirements of this NIP should allow for more robust and formal means of assessing consensus of opinion on a poll's content. However, until this outline is further refined and proven robust, polls should not be considered authoritative nor binding.
+## Poll format
 
-## Poll format (RFC)
+A poll is a self-contained nostr event which MUST have a primary description along with a predefined number (2..n) of voting options. Each voting option also MUST contain its own secondary description along with an associated bolt11 address, used to tally corresponding vote amounts and counts. A poll should specify a primary tally method ('value' or 'count') and a closing time. It may also include a consensus threshold percentage.
 
-A poll is a self-contained event, containing a predefined number of voting options.
+## Poll outcomes
 
-#### Self-contained poll event
+Votes may be tallied either by value or by count. To avoid ambiguity of a winning outcome, a primary tally method SHOULD be specified as either 'value' or 'count'. If a closing time is specified, after it is passed, a poll should be unblinded publicly and MUST be treated as closed (additional votes must not be tallied). Once closed, depending upon the specified tally method, the option associated with either the most satoshis (value) or the most votes (counts) MUST be accepted as the winning option; while the distribution percentages across all vote options MUST be considered respresentative of the distribution of opinion amongst participants.
 
-* Pros:
-    * likely results in better UX by providing compact, widget-style notes immediately recognizable as unique poll type
-    * promotes more uniform implementation across clients
-* Cons:
-    * increased poll event complexity, owing to internally nested voting options (each necessarily containing their own zap requirements)
-    * potentially increased difficulty of client implementation
+Additionally, if a consensus threshold percentage is specified, and any single option's associated value (or vote count) percentage of the poll's total value (or vote count, respectively) exceeds the consensus threshold, then consensus MUST be considered attained.
 
-#### Single parent poll event with linked child voting option events
-
-* Pros:
-    * better alignment with existing event (specifically zap) structures
-    * potential for backward compatibility with clients uncompliant with polling events, i.e. non-compliant clients could handle poll event chains same as existing threads
-    * possibly simplifies implementation by clients?
-* Cons:
-    * introduces possibility for fragmentation of polls, e.g. separation or loss of child voting options
-    * increased potential for non-uniform implementation of polling UI/UX across clients
+Strict adherence to these requirements should enable a formal means of quantitatively assessing the distribution of opinion regarding a poll's content amongst poll participants, determining a winning outcome, and possibly acheiving consensus. However, until this protocol is further tested, refined, and proven robust, polls should probably not be considered authoritative nor binding.
 
 ## TODO
 
-* define basic polling features
-* define basic polling format
-* outline polling NIP
-* publish RFC to nostr dev community
+* define standardized polling format
+* publish RFC to nostr devs and community
 * implement polls in 1 relay
 * implement polls in 2 clients
 * send pull request to nostr-protocol/NIPs