search

OmniLayer / spec

Omni Protocol Specification (formerly Mastercoin)
The Unlicense
341 stars 116 forks source link

Add crowdsale start time #151

Open marv-engine opened 10 years ago

marv-engine commented 10 years ago

Originally posted as https://github.com/mastercoin-MSC/Master_Protocol_Product_Requirements/issues/4

dexX7 commented 10 years ago

If this is going to happen, please include not only block time, but also block height as an option.

dexX7 commented 10 years ago

May be worth to mention: Bitcoin itself has an option to create transactions which are only valid after a specific and time/block height has passed. This means I could create a "create crowdsale transaction" which can be mined only after block 300k, but not before.

The only downside: the transaction is actually not "on the network" but rather "not accepted before this timestamp/block height" and probably need to be re-broadcasted once they are considered as valid.

taariq commented 10 years ago

Hey dexX7. Which option is this to which you are referring? I¹m not sure I know it.

marv-engine commented 10 years ago

I envisioned using a date/time value as we use for the crowdsale deadline. So the crowdsale could be advertised as starting on 15-May-2014 0930 UTC. Can that be reliably and predictably enforced given how the blockchain handles time?

marv-engine commented 10 years ago

Are investors going to be more sensitive to time variations for a crowdsale start compared to the deadline? I expect so.

dexX7 commented 10 years ago

marv, I think the question about time variations completely relates to the circumstances of the crowdsale. In the case there is immense demand and not much supply the start is more imporant, because users may fear to be not fast enough to get some of the tokens before they are sold out. But what I also saw several times on btct.co for example: there is an IPO and a larger amount to collect. The first 70-85 % are sold very, very slowly, because no one wants to be the one who wants to wait with locked coins, but once a critical point was reached things accelerated and from one second to the other everyone who waited wants to get it and eventually may be the one who missed the opertunity. Such incidends were lead to a price spike right after the end (or after it sold out in these cases). -- I'm not sure, if my observations are representative in any way though.

Hey taariq, I was referring to the transaction property "nLockTime". It's basically a field which tells miners (and nodes?): "do not include this transaction in a block, if the time defined by nLockTime is in the future". But as mentioned, this is not the same as "I send a transaction now which will confirm 100 blocks later", but rather "I create a transaction now that can't be mined (and maybe not even broadcasted) in the periode of the next 100 blocks".

However, this can be used for more complex things. An example: I prepare a transaction which sends 10 BTC to you, but I don't yet send it. You create a transaction based on mine which sends those 10 BTC back to me, but not earlier than 100 blocks in the future. You sign this transaction and hand it over to me. After I confirmed the transaction is indeed valid which you send back to me, I'm going to actually send the 10 BTC. -- So what's the implication of this? If you don't spend those 10 BTC in the next 100 blocks, I would be able to revert the payment! Hope this makes sense. :)

While this doesn't sound very useful (at least for me at the moment), this is extremely powerful, if combined with multisigs: say, we create a 2-of-2 multisig address instead and because I don't completely trust what you are up to, we agree that you agree to sign (with me) a transaction which sends 10 BTC from that 2-of-2 multisig address back to me - not earlier than 200 blocks in the future for example. After this is done, I have a guarantee: I can be 100 % sure to get my coins back in 200 blocks, if we don't spend them together and in consensus, because you alone are unable to sign the 2-of-2 transaction yourself - so it's either: me or we both.

More really interesting applications: http://bitcoindev.us.to/en/developer-guide#term-micropayment-channel https://en.bitcoin.it/wiki/Contracts (just to give you some more input for the case you are interested =D)

zynis commented 10 years ago

A few comments

  1. nlocktime is not actually implemented as far as I am aware within the network, i.e., the tx are not relayed at all. Not sure why we would use this here.
  2. if this is done then one cannot under any circumstances allow someone to pick a valid time that is prior to the current time in a bitcoin block when the tx is accepted, otherwise one can start creating transactions that rewrite historical balances in the future by turning potentially invalid tx into valid tx, and vice versa.
dexX7 commented 10 years ago

Implemented it is, but initially it was intended to be used in combination with sequence numbers such that "not yet ready" are in the mempool and can be replaced, if a similar transaction with a higher sequence number was found. This was appearingly a DOS vector. And as mentioned: now it's simply "if the time is in the future, don't include this transaction in a block". In the case you chose a time which is in the past, it's similar as if you send a transaction without nLockTime: "it can be mined immediately".

Sorry for the lengthy responses, this was actually only a sidenote anyway to mention it. :)

dacoinminster commented 10 years ago

It's very easy for the issuer to control when the crowdsale starts by advertising beforehand the date and website (but not the address) then sending a message to start the crowdsale, then advertising the address. This is what maidsafe did, and I don't think a protocol variable for determining the start time in advance adds very much, especially considering the possibility of the block time being off by as much as an hour.

Consequently, I think we should not do this.