Futures in the near future!

“I wish it need not have happened in my time,” said Frodo.
“So do I,” said Gandalf, “and so do all who live to see such times. But that is not for them to decide. All we have to decide is what to do with the time that is given us.”
― J.R.R. Tolkien

Ok, what many of you have been waiting for has been the upcoming release of our “Futures”/time lock transactions and yes, they are here very soon. 
11:14:34

help futuretx send

11:14:34

futuretx send amount fromAddress toAddress maturity lockTime …
Sending amount RTM fromAddress to toAddress and locked it with maturity or lockTime variable transaction fees.
if maturity is negative, this transaction lock by lockTime.If lockTime is negative, this transaction lock by maturity.If both are negative, this transaction is locked till external condition is met.Otherwise it is unlock and spendable either maturity or lockTime whichever come later.

Arguments:
1. “amount” (Number, required) Amount of RTM to be sent
2. “fromAddress” (String, required) source address where unspent is from. it need to have enough for amount + future feee + mining fee.
3. “toAddress” (String, required) destination address
4. “maturity” (Number, required) Amount of confirmations need for this transaction to be spendable.
5. “lockTime” (Number, required) Numbner of seconds from first confirms for this transaction to be spendable.

This is in the final stages of debugging and coming very soon on the testnet.

But this was promised for Q2, we are now in Q3?

Yes, by a couple of days, but what hasn’t been made public till now is that we are managing to roll out an additional feature which was not initially planned till assets hitting mainnet significantly later on in the year. 

This additional feature is adjustable fees for special transaction types, which will turn out to be an extremely important feature keeping RTM dynamic and current should we see action on price from the release and from several other items coming up. Furthermore, having it up and running prior to assets puts us several steps ahead of where we planned to be.

Fees will be adjustable without the need for forking and can be done in tune with market conditions meaning we will never be in the situation of being too expensive to use, which is critical since we want to see real adoption.

So, yes it is a bit late but at the same time, it is so much more than what was initially promised.

Here is an example of what the actual transactions look like:

{
“txid”: “f659480e09d635c774f67ca5700c05bb727fac56d1e593a682ffee8a655e2e35”,
“version”: 3,
“type”: 7,
“size”: 200,
“locktime”: 0,
“vin”: [
{
“txid”: “2db15524a5c54a78fb439b1422100b9ad4d7e8f6b17ec1e98e5b5722801eea40”,
“vout”: 0,
“scriptSig”: {
“asm”: “”,
“hex”: “”
},
“sequence”: 4294967294
}
],
“vout”: [
{
“value”: 200.00000000,
“valueSat”: 20000000000,
“n”: 0,
“scriptPubKey”: {
“asm”: “OP_DUP OP_HASH160 96c5a451064073ed39b582f692f4d0d497c98ed6 OP_EQUALVERIFY OP_CHECKSIG”,
“hex”: “76a91496c5a451064073ed39b582f692f4d0d497c98ed688ac”,
“reqSigs”: 1,
“type”: “pubkeyhash”,
“addresses”: [
“rjKQEXdV83pp1N2gmjp4tMsoMSqqfVRJYJ”
] }
},
{
“value”: 699.99999693,
“valueSat”: 69999999693,
“n”: 1,
“scriptPubKey”: {
“asm”: “OP_DUP OP_HASH160 796a264ae4d84e96c44ce87cee48540b90e84d91 OP_EQUALVERIFY OP_CHECKSIG”,
“hex”: “76a914796a264ae4d84e96c44ce87cee48540b90e84d9188ac”,
“reqSigs”: 1,
“type”: “pubkeyhash”,
“addresses”: [
“rgeB2yFejUwbDC8RyRqcsppRNVasm87iuj”
] }
}
],
“extraPayloadSize”: 80,
“extraPayload”: “010064000000302a000000000000000000000000000000000000000000000000000000000000000000000000000000004973ec97ac7ae8a27ae988663247dd02b586ab917d448777a72c93b71969f716”,
“futureTx”: {
“version”: 1,
“maturity”: 100,
“lockTime”: 10800,
“lockOutputIndex”: 0,
“updatableByDestination”: false,
“externalPayoutAddress”: “N/A”,
“externalTxid”: “0000000000000000000000000000000000000000000000000000000000000000”,
“externalConfirmations”: 0,
“inputsHash”: “16f76919b7932ca77787447d91ab86b502dd47326688e97aa2e87aac97ec7349”
},
“hex”: “030007000140ea1e8022575b8ee9c17eb1f6e8d7d49a0b1022149b43fb784ac5a52455b12d0000000000feffffff0200c817a8040000001976a91496c5a451064073ed39b582f692f4d0d497c98ed688accd3a534c100000001976a914796a264ae4d84e96c44ce87cee48540b90e84d9188ac0000000050010064000000302a000000000000000000000000000000000000000000000000000000000000000000000000000000004973ec97ac7ae8a27ae988663247dd02b586ab917d448777a72c93b71969f716”
}

In the above sample transaction we can see 1000 RTM being spent in the following manner:

1. 200 RTM being returned to a change address
2. 699.99999693 RTM being spent as a transaction locked for 100 blocks or 10800 seconds.
3. 0.00000307 RTM being spent as a regular transaction fee
4. 100 RTM being charged as a FutureTX fee

The fee we are making adjustable is the 100 RTM FutureTX fee.

Any questions, please reach out to us on Discord or Telegram
July 1st Bigpiggy01