CAP-0033 Fixes after Protocol Meeting 6/4 (#631)

* Fix two small issues with CAP-33

* Add discussion of sponsoring account creation

core/cap-0033.md

@@ -141,7 +141,7 @@ struct ClaimableBalanceEntry
 ```c++
 struct LedgerEntryExtensionV1
 {
-    SponsorshipDescriptor sponsorship;
+    SponsorshipDescriptor* sponsorship;
 
     union switch (int v)
     {
@@ -177,6 +177,15 @@ enum OperationType
     UPDATE_SPONSORSHIP = 16
 };
 
+enum AccountMergeResultCode
+{
+    // ... ACCOUNT_MERGE_SUCCESS, ..., ACCOUNT_MERGE_SEQNUM_TOO_FAR unchanged ...
+    ACCOUNT_MERGE_DEST_FULL = -6,       // can't add source balance to
+                                        // destination balance
+    ACCOUNT_MERGE_IS_SPONSOR = -7       // can't merge account that is
+                                        // sponsoring future reserves
+};
+
 struct SponsorFutureReservesOp
 {
     AccountID sponsoredID;
@@ -498,6 +507,11 @@ Succeed with UPDATE_SPONSORSHIP_SUCCESS
 CAP-0023, except that `createdBy` and `reserve` are everywhere replaced by
 `sponsoringID` and `reserve` in the `LedgerEntry` extension.
 
+#### AccountMergeOp
+`AccountMergeOp` will fail with `ACCOUNT_MERGE_IS_SPONSOR` if attempting to
+merge an account that is-sponsoring-future-reserves-for another account. This
+guarantees that the sponsoring account always exists.
+
 #### Other Operations
 Other operations will need updated semantics in order to behave correctly with
 this proposal. Specifically, changes will be required to handle sponsorship
@@ -535,6 +549,25 @@ can afford the reserve itself. That is part of the contract of the sponsorship
 relation, and if you didn't want revocation to occur then you shouldn't have
 accepted the sponsorship in the first place.
 
+### Sequence Number Utilization and Sponsoring Account Creation
+A typical use case for sponsorship is an enterprise sponsoring the reserves for
+customers. Because sponsorship requires signatures from both the sponsoring
+account and the sponsored account, this requires multi-signature coordination.
+But an enterprise may be coordinating many such signatures at once. Each
+coordination requires a sequence number. When sponsoring sub-entries such as
+signers and trust lines, it is possible to use the customer's sequence number.
+But sponsoring account creation requires the enterprise to provide the sequence
+number. This will likely require a pool of channel accounts, which is a source
+of complexity.
+
+Despite the complexity that will be required for large-scale creation of
+sponsored accounts, we still believe that this approach is justified by its many
+benefits. Furthermore, the need for channel accounts during multi-signature
+coordination is an area in which the Stellar protocol can be generally improved.
+Already there are discussions of ideas which may mitigate some of these issues
+such as David Mazieres' proposal for Authenticated Operations, which can be found
+at https://groups.google.com/forum/#!msg/stellar-dev/zpO0Eppn8ks/e1ULbV_lAgAJ.
+
 ### Example: Sponsoring Account Creation
 In this example, we demonstrate how an account can be sponsored upon creation.
 Let `S` be the sponsoring account, `C` be the creating account, and `A` the