Grace period after manually closing a crowdfund

[dexX7]

I'm not a fan of tolerating or even rewarding those who try to game the system and fail, say for example a crowdsale ends at blockheight 300000 which is known by all actors but Mallory knows many people are friendly and his transaction which was sent later and finally confirms at blockheight 300005 will eventually be honored. During those additional blocks he may have gained an unfair advantage against other honest actors who honored the true deadline. If Mallory likes to do a risky play he may do so but exploiting the system should be prevented and therefore I don't see any reason to introduce a buffer or grace periode, if all information is available to everyone.

One can argue about time based events because the time resource we are rely on can fluctuate and may behave in a non-predictable manner but that's a different issue and even while this is potentially non-predictable, it's the same for all and no actor gains an unfair advantage.

And there is the case of transaction type 53: closing a crowdfund manually. A manual close is neither predictable nor is any mechanism in place to prevent abuse by the issuer. Say for example I watch incoming tokens very, very closely and spot a very large order pending unconfirmed in the mempool. Now I could broadcast a manual close transaction and with some luck the close transaction is mined in the next block but the purchase transaction doesn't make it. I may even try to delay the purchase by sending large junk transactions to fill the next block. If this works as planned, I would receive the large amount of tokens for free and basically could con buyers.

This is somewhat similar to the case where a very short payment timeframe is used on the DEX but in the later case a potential buyer has all information available to identify malicious behavior because he knows the payment timeframe before making a purchase.

But all malicious actions aside, the simple fact that a manual close is not predictable is enough reason to consider the introduction of a mechanism to make this more transparent in my opinion.

A few ideas:

• After a manual close was confirmed there may be a grace periode of n blocks in which purchases are still honored.
• Purchases which confirm within n blocks after the manual close may become invalid.

[ProphetX10]

t seems to me that this grace period thing is chasing a solution for a
problem that shouldn't exist.

From my recollection the only reason the manual close was created was
because there was no ability to create a ceiling on the number of tokens.
And in particular the ceiling on the number of tokens created by a certain
currency.

But to address your example, if someone were putting in a large order they
have the same incentive to watch the mempools and also spam transactions in
order to block the close transaction. However, the issuer does not get a
large amount for free since they actually lose money in this scenario and
risk their reputation, among other things which are not free.

The purpose of a crowd sale is to sell as much as possible, as fast as
possible.

To address the issue this grace period thing brings up we would have to
look at the root cause of why someone would have incentive to go against
their own interest and use premeditated resources (i.e., checking mempool
and spamming) to do that, and address that.

If for example a crowd sale happens faster then anticipated and the issuer
deems that the sale price was too low against his interest), the solution
would be to create a reverse auction sale type, so that the issuers
interests are clearly aligned to maximize their return.

Thanks,

Dominik Zynis
Head Evangelist
Mastercoin Foundation
Mastercoin.org http://mastercoin.org/
[email protected]
+1-415-800-4155
+34-697-41-22-01
dominik.zynis (skype)

Assistant:
Joanne [email protected]

On Wed, Apr 23, 2014 at 12:14 AM, dexX7 [email protected] wrote:

I'm not a fan of tolerating or even rewarding those who try to game the
system and fail, say for example a crowdsale ends at blockheight 300000
which is known by all actors but Mallory knows many people are friendly and
his transaction which was sent later and finally confirms at blockheight
300005 will eventually be honored. During those additional blocks he may
have gained an unfair advantage against other honest actors who honored the
true deadline. If Mallory likes to do a risky play he may do so but
exploiting the system should be prevented and therefore I don't see any
reason to introduce a buffer or grace periode, if all information is
available to everyone.

One can argue about time based events because the time resource we are
rely on can fluctuate and may behave in a non-predictable manner but that's
a different issue and even while this is potentially non-predictable, it's
the same for all and no actor gains an unfair advantage.

And there is the case of transaction type 53: closing a crowdfund
manually. A manual close is neither predictable nor is any mechanism in
place to prevent abuse by the issuer. Say for example I watch incoming
tokens very, very closely and spot a very large order pending unconfirmed
in the mempool. Now I could broadcast a manual close transaction and with
some luck the close transaction is mined in the next block but the purchase
transaction doesn't make it. I may even try to delay the purchase by
sending large junk transactions to fill the next block. If this works as
planned, I would receive the large amount of tokens for free and basically
could con buyers.

This is somewhat similar to the case where a very short payment timeframe
is used on the DEX but in the later case a potential buyer has all
information available to identify malicious behavior because he knows the
payment timeframe before making a purchase.

But all malicious actions aside, the simple fact that a manual close is
not predictable is enough reason to consider the introduction of a
mechanism to make this more transparent in my opinion.

A few ideas:

After a manual close was confirmed there may be a grace periode of n
blocks in which purchases are still honored.

Purchases which confirm within n blocks after the manual close may
become invalid.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/132
.

[dexX7]

Very good points.The example was chosen to think about edge cases and the example of filling blocks with junk transactions was probably a bit extreme.

I do agree that a pre-defined ceiling would be nice and probably would have solved the problem MaidSafe experienced, but there may still be use cases to justify a manual close.

[dacoinminster]

If you are investing in a crowdfund, you already have to trust the issuer.
I'm not sure the fact that the issuer could (maybe) defraud people by
closing early is something we should think about. If the issuer is
untrustworthy, people shouldn't invest.

On Tue, Apr 22, 2014 at 3:14 PM, dexX7 [email protected] wrote:

I'm not a fan of tolerating or even rewarding those who try to game the
system and fail, say for example a crowdsale ends at blockheight 300000
which is known by all actors but Mallory knows many people are friendly and
his transaction which was sent later and finally confirms at blockheight
300005 will eventually be honored. During those additional blocks he may
have gained an unfair advantage against other honest actors who honored the
true deadline. If Mallory likes to do a risky play he may do so but
exploiting the system should be prevented and therefore I don't see any
reason to introduce a buffer or grace periode, if all information is
available to everyone.

One can argue about time based events because the time resource we are
rely on can fluctuate and may behave in a non-predictable manner but that's
a different issue and even while this is potentially non-predictable, it's
the same for all and no actor gains an unfair advantage.

And there is the case of transaction type 53: closing a crowdfund
manually. A manual close is neither predictable nor is any mechanism in
place to prevent abuse by the issuer. Say for example I watch incoming
tokens very, very closely and spot a very large order pending unconfirmed
in the mempool. Now I could broadcast a manual close transaction and with
some luck the close transaction is mined in the next block but the purchase
transaction doesn't make it. I may even try to delay the purchase by
sending large junk transactions to fill the next block. If this works as
planned, I would receive the large amount of tokens for free and basically
could con buyers.

This is somewhat similar to the case where a very short payment timeframe
is used on the DEX but in the later case a potential buyer has all
information available to identify malicious behavior because he knows the
payment timeframe before making a purchase.

But all malicious actions aside, the simple fact that a manual close is
not predictable is enough reason to consider the introduction of a
mechanism to make this more transparent in my opinion.

A few ideas:

After a manual close was confirmed there may be a grace periode of n
blocks in which purchases are still honored.

Purchases which confirm within n blocks after the manual close may
become invalid.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/132
.

[dexX7]

That's almost a different topic. I may ask: why do we need to accept a sell offer before sending Bitcoin? To prevent unfavorable situations where an offer was already filled and the coins are credited to the receiver without getting anything back. This here is similar imho.

[dacoinminster]

Sell order is different because the seller is anonymous. Doing refunds breaks MSC consensus on older implementations, which I am reluctant to do.

I'm closing this for now (I'm closing LOTS of issues today). Feel free to reopen for further discussion if desired.

[dexX7]

@dacoinminster: I'd like to reopen this issue, because a similar situation is introduced by version 1 of transaction 51 where terms of a crowdsale can be adjusted.

[dacoinminster]

Re-opening this issue means (I think) that we would actually be contemplating creating an "investment send", which was the original way this was supposed to work, but was abandoned due to time constraints. A positive side effect was that old clients still tracked MSC sent for investments correctly, and did not lose MSC consensus.

I'm not opposed to discussing this more if you want to reopen, but I consider this extremely low priority.