Author

Topic: Would there be a way to put a lock time on all successive transactions? (Read 677 times)

legendary
Activity: 3598
Merit: 2386
Viva Ut Vivas
Just looking at creating a colored coin that would represent equity shares in a company. One way to comply with SEC regulations is if shares of a company can only be sold after 1 year. And any sale of that share beyond that also needs to be held a year.
Since you're looking broader than just Bitcoin: Byteball offers regulated assets:
Quote
Regulated assets
Regulated institutions can issue assets that are compatible with KYC/AML requirements. Every transfer of such asset is to be cosigned by the issuer, and if there is anything that contradicts the regulations, the issuer won't cosign.
You can probably set up a bot to handle sales-requests (but I can't tell you how exactly).

No, you can't do that with Bitcoin. Once the funds are spent, they have nothing to do with their past transactions anymore. When you make a transaction, you can specify whatever the rules of unlocking those funds you want, as long as you can unlock them.

If it is possible in your implementation, you can simply specify that all the transactions have to use nLockTime with a month of delay, otherwise those coins are effectively burned, or uncolored.

That makes sense. They have value due to some external definition not by having value itself.

Either way, this is likely not the road we would take but it needs to be checked off the list. The SEC sucks balls.
sr. member
Activity: 490
Merit: 389
Do not trust the government
Just looking at creating a colored coin that would represent equity shares in a company. One way to comply with SEC regulations is if shares of a company can only be sold after 1 year. And any sale of that share beyond that also needs to be held a year.
Since you're looking broader than just Bitcoin: Byteball offers regulated assets:
Quote
Regulated assets
Regulated institutions can issue assets that are compatible with KYC/AML requirements. Every transfer of such asset is to be cosigned by the issuer, and if there is anything that contradicts the regulations, the issuer won't cosign.
You can probably set up a bot to handle sales-requests (but I can't tell you how exactly).

No, you can't do that with Bitcoin. Once the funds are spent, they have nothing to do with their past transactions anymore. When you make a transaction, you can specify whatever the rules of unlocking those funds you want, as long as you can unlock them.

If it is possible in your implementation, you can simply specify that all the transactions have to use nLockTime with a month of delay, otherwise those coins are effectively burned, or uncolored.
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
Just looking at creating a colored coin that would represent equity shares in a company. One way to comply with SEC regulations is if shares of a company can only be sold after 1 year. And any sale of that share beyond that also needs to be held a year.
Since you're looking broader than just Bitcoin: Byteball offers regulated assets:
Quote
Regulated assets
Regulated institutions can issue assets that are compatible with KYC/AML requirements. Every transfer of such asset is to be cosigned by the issuer, and if there is anything that contradicts the regulations, the issuer won't cosign.
You can probably set up a bot to handle sales-requests (but I can't tell you how exactly).
legendary
Activity: 3598
Merit: 2386
Viva Ut Vivas
e.g.
1.  2 bitcoins to address 1XYZ which is locked for 1 month
2. then after that month, whomever controls 1XYZ sends to two different addresses,  1ZYX and 1WXY which should also be locked for another month no matter who has the private keys to 1ZYX and 1WXY?
3. Then  1ZYX and 1WXY send elsewhere and those transactions are locked for a month worth of blocks?
4. Does this continue infinitely or does it stop after some number of transactions?
etc

I don't believe that you could encumber future transactions that all originate from a single root as bitcoin is now under the scenario above.  Perhaps you could do so with some type of payment channel, but if you can give an example of what you are trying to accomplish, perhaps that would help determine a method to do so.

Just looking at creating a colored coin that would represent equity shares in a company. One way to comply with SEC regulations is if shares of a company can only be sold after 1 year. And any sale of that share beyond that also needs to be held a year. We are looking at all SEC options which all have varying degrees of limitations in place. I was just vetting whether or not the 1 year delay route was possible via Bitcoin. It might be possible with ETH but I'll let our ETH guys look into that.
legendary
Activity: 4256
Merit: 1313
I know that you can already set a lock time which allows you to set the future block for which a transaction has to wait until to be confirmed, but would there be a way to specify locking any transaction after that by a set amount of blocks?

Like I send 2 bitcoins to address 1XYZ which is locked for 1 month (a certain amount of blocks). Then once 1XYZ has access to the funds they send to two different addresses, 1ZYX and 1WXY but they both have the same delay of 1 month. And those transactions also have a delay and so on and so on...


I ask this as I am trying to figure out a programatic way of conforming to some certain SEC regulations for something. We are still flushing some things out but I just want to know if this path is possible.

So you are asking if you can encumber all or some number of future transactions that follow the initial one with a delay?  (It doesn't seem like the previous answers were talking about more than locking the 1st transaction).

e.g.
1.  2 bitcoins to address 1XYZ which is locked for 1 month
2. then after that month, whomever controls 1XYZ sends to two different addresses,  1ZYX and 1WXY which should also be locked for another month no matter who has the private keys to 1ZYX and 1WXY?
3. Then  1ZYX and 1WXY send elsewhere and those transactions are locked for a month worth of blocks?
4. Does this continue infinitely or does it stop after some number of transactions?
etc

I don't believe that you could encumber future transactions that all originate from a single root as bitcoin is now under the scenario above.  Perhaps you could do so with some type of payment channel, but if you can give an example of what you are trying to accomplish, perhaps that would help determine a method to do so.

staff
Activity: 3458
Merit: 6793
Just writing some code
It sounds like what you want to use is OP_CHECKSEQUENCEVERIFY which is specified in BIPs 68 and 112. Using this requires using P2SH and it allows you to say "this output can only be spent after X amount of time/blocks".
hero member
Activity: 935
Merit: 1002
You can lock a transaction by both the time and certain block. You however will not be able to broadcast those transactions until the lock time has passed.
Check https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki for more information.
legendary
Activity: 3598
Merit: 2386
Viva Ut Vivas
I know that you can already set a lock time which allows you to set the future block for which a transaction has to wait until to be confirmed, but would there be a way to specify locking any transaction after that by a set amount of blocks?

Like I send 2 bitcoins to address 1XYZ which is locked for 1 month (a certain amount of blocks). Then once 1XYZ has access to the funds they send to two different addresses, 1ZYX and 1WXY but they both have the same delay of 1 month. And those transactions also have a delay and so on and so on...


I ask this as I am trying to figure out a programatic way of conforming to some certain SEC regulations for something. We are still flushing some things out but I just want to know if this path is possible.
Jump to: