Dev Meeting Transcript (January 21, 2022)

[4:00 PM] kinkajou (SegWit Clique): Hello

[4:00 PM] LSJI07 – BWS: Hi 🙂

[4:01 PM] BadGuyTy: Lets go!

[4:01 PM] BadGuyTy: Super excited about the stuff being built on the chain!

[4:03 PM] BadGuyTy: One thing I would like to talk about is change control. In the raw transactions there is no way to control the change as you can with the regular RPC's

[4:05 PM] BadGuyTy: basically with a transferwithmessage I can specify the recipient the rvn change and the asset change. These can be all the same address and it works. This is not possible with raw transactions and thus not possible with p2sh

[4:11 PM] BadGuyTy: I can see the raw change being resolved 2 ways.

1. Through the use of fundrawtransaction and being able to specify the source utxo, the change, and the asset change.

2. Through adding p2sh specific RPC's that allow for needed arguments like the keys to sign with and the script used

[4:15 PM] Hans_Schmidt: Not sure what you mean by that- if you create a raw transaction then use raven-qt to sign and send, you have total control over every input and output. So you can create outputs which send back to yourself all the change in addition to the outputs which send to other people. Just make sure that the total specified outputs equals the total specified inputs.

[4:18 PM] BadGuyTy: The issue is the squawker protocol. In order to keep a user known you have to send from and back to the same address. The outputs are defined using json and so you can't define the same address three times once for the asset to flag the type of message, once for the asset change, and once for the rvn change.

[4:19 PM] BadGuyTy: The current implementation could work if the json accepted multiple functions for the same address. Currently it takes the first

[4:22 PM] BadGuyTy: so the output defined like such could work if it iterated over the json object

address: { transferwithmessage: { asset, amount}, transfer: {asset: amount, asset(RVN): amount}

[4:26 PM] Hans_Schmidt: This doesn't sound like a problem with core.

I'm not familiar with squawker or the json, but from the perspective of the core transaction, you can create an address for your RVN change and an address for your asset change, and then just explicitly send any change to them so that the software doesn't have any change left that it needs to deal with.

[4:28 PM] BadGuyTy: correct the issue I have is with a regular address and rpc's I can do this but I can't with the raw transactions because it dosen't fully consume the json objects.

[4:29 PM] BadGuyTy: let me put it another way say I want to transfer 4 assets to the same address. I would need 4 separate transactions to do this with raw transactions whe it should be able to be done in one.

[4:31 PM] BadGuyTy: or even if I want to send rvn and an asset it would require two separate transactions. When you try to combine raw transactions that have overlapping output addresses it also drops all but one of those outputs.

[4:32 PM] BadGuyTy: which is consistent with the json behavior I am seeing.

[4:33 PM] BadGuyTy: This will really be important for things like minable assets as you would have to send each mined asset to a different address or have multiple transactions

[4:35 PM] BadGuyTy: I get that this is a super edge case of trying to do things with raven-qt but its currently possible in rpc calls so it should also be possible to do with raw transactions which you need to do p2sh

[4:37 PM] BadGuyTy: you actually NEED this for p2sh as you could only spend the utxo's in that address once and send the change somewhere else where the others in that p2sh address can't have access to it till after it is sent back

[4:38 PM] kinkajou (SegWit Clique): is it a consensus change? doesnt seem like it would be. have you submitted a PR?

[4:39 PM] kinkajou (SegWit Clique): or made an issue perhaps?

[4:39 PM] BadGuyTy: I am not good with c++ but if thats what it will take I guess I will have to do that

[4:39 PM] BadGuyTy: I have made an issue

[4:39 PM] fdov: Hello.

[4:39 PM] Hans_Schmidt: Using your own custom-written software, you can compose any protocol-legal bit-string with as many outputs and inputs and IPFS addresses as you want, including sending things like change back to yourself. As long as that bit-string represents a valid serialized transaction, you can then use the core software to sign and send using "signrawtransaction" and "sendrawtransaction". As long as all the RVN and assets in inputs all get sent to outputs in the same total quantities, the transaction can as many inputs and outputs as your want. It did this when creating P2SH transactions to do cross-chain atomic swaps between RVN testnet and BTC testnet.

[4:40 PM] Hans_Schmidt: Core doesn't limit you.

[4:40 PM] fdov: Core, or bitcoin does not allow multiple outputs to the same address, with createrawtransaction

[4:40 PM] fdov: https://github.com/bitcoin/bitcoin/issues/23877 – https://bitcointalk.org/index.php?topic=150473.0

[4:41 PM] fdov: Most people think it is stupid, because you should just add up the numbers and make it one.

[4:41 PM] BadGuyTy: well the issue we are running into here is you can't send both assets and rvn

[4:42 PM] BadGuyTy: let alone splitting a utxo into two

[4:43 PM] Hans_Schmidt: So is that the issue- that you need to send RVN and asset to the same address in a single transaction?

[4:44 PM] BadGuyTy: partially I would also like to send two sets of assets and rvn in the same transaction.

[4:44 PM] fdov: You can't send assets, asset change, and rvn change to the same address.

[4:44 PM] BadGuyTy: you can with the RPC transferwithmessage

[4:44 PM] fdov: yes, but you can't with createrawtransaction

[4:45 PM] BadGuyTy: I understand. I'm looking to fix that

[4:46 PM] BadGuyTy: if create raw transaction would consume a multi part json it would work. so a transfer with message as well as a transfer.

[4:46 PM] fdov: For your use case it might be worth it. Most others should not reuse addresses like that.

[4:47 PM] fdov: BadGuyTy You can create the transaction, but it will be rejected.

[4:47 PM] Hans_Schmidt: Why not create the custom serialized transaction doing anything legal that you want and then just "signrawtransaction" and "sendrawtransaction"?

[4:47 PM] BadGuyTy: oh I get that I am completely an odd ball but with p2sh are you going to have to create a new address each time you use that address?

[4:48 PM] BadGuyTy: oh I guess with a typical p2sh you could just send the change back to the address

[4:49 PM] BadGuyTy: I guess thats the route I might have to take. I really didn't want to get that deep in the weeds with all this.

[4:51 PM] BadGuyTy: writing your own transactions sounds about as fun as my senior project to write a working compiler and a vm to display the asm in.

[4:51 PM] fdov: It will throw here: https://github.com/fdoving/Ravencoin/blob/2553b93e5ee3df44d4ee0996bb037bf693207399/src/rpc/rawtransaction.cpp#L681

[4:52 PM] neil: It's not that hard, I'm working on a C# class that will do the lot including signing right now, won't be completed for a while though – also not touching p2sh at this stage

[4:54 PM] kinkajou (SegWit Clique): I'm very impressed by and appreciative of all the work our core devs are putting in. I see some PRs have been reviewed and approved. Thanks fdov and Hans_Schmidt !

Any ideas as to when we might expect a release?

[4:55 PM] neil: I will fully document my c# efforts once it's ready – making this kind of thing trivial

[4:55 PM] Hans_Schmidt: Doing it from scratch is painful. But using a library like python-ravencoinlib definitely helps and lets you do it in python.

[4:56 PM] BadGuyTy: well that makes me more hopeful didn't know there was that library

[4:57 PM] BadGuyTy: ok I got to run to pick up the kids for school but thanks for helping me find a route forward

[4:58 PM] Hans_Schmidt: I have processed all but 2 PRs. Overall, the quality was very good. Just a few need fixing and some debate. We need to decide on which PRs to include in release.

[4:58 PM] Hans_Schmidt: And we need to get community agreement on what % approval by miners we will require for activation

[5:00 PM] LSJI07 – BWS: I thought 80 percent was selected along with the longer lockin window.

[5:01 PM] LSJI07 – BWS: Higher as anticipated a fairly uncontentious fork for p2sh.

[5:02 PM] LSJI07 – BWS: UNcontentious. 🤣

[5:02 PM] Hans_Schmidt: Thanks fdov for all your work generating those PRs

[5:03 PM] fdov: Thank you for finding my mistakes 🙂

[5:06 PM] Hans_Schmidt: Any other opinions on what % approval by miners we will require for activation?

[5:07 PM] Hans_Schmidt: Or how we decide whether we have collected enough feedback to make a decision?

[5:10 PM] fdov: I think about 80% should be good. If it doesn't activate on the first try, there is always a new epoch.

[5:11 PM] Hans_Schmidt: I am happy with 80% if that is the community agreement.

[5:11 PM] fdov: I don't recall what we decided last time? – i think we have concluded on this at some point earlier too.

[5:13 PM] LSJI07 – BWS: Tron supported 80 percent plus.

[5:13 PM] LSJI07 – BWS: https://discord.com/channels/429127343165145089/482289959261175838/906281965374824468

[5:14 PM] fdov: About the open PRs, I think the security related ones should be top priority. Not all are exploitable. But it does not look good to make a release with known open CVE-issues, when simple fixes are available.

[5:15 PM] LSJI07 – BWS: It could be tricky to get but IMO we definitely have community agreement to adopt the changes at 80%. Perhaps not the first epoch but there are multiple opportunities.

[5:16 PM] Hans_Schmidt: Yes, that decision is easy, especially since those PRs were all straight copies from bitcoin and therefore carry very little risk by us including them.

[5:20 PM] LSJI07 – BWS: We dont need a rapid fork. We need a secure fork with community support. If it takes time so be it. The more eyes on the code during this process the better!

[5:21 PM] LSJI07 – BWS: Appreciate the reviews and work done!

[5:22 PM] Hans_Schmidt: As soon as we decide which PRs to include, we need to distribute new binaries for wide-spread testing including full sync-from-zero tests.

[5:25 PM] Hans_Schmidt: I'm going to drop off for now. See y'all next time. Stay safe and healthy!

[5:25 PM] fdov: Bye.

[5:26 PM] fdov: We could try to do a SIG-meeting or something deciding the PRs at some point. Once they are selected and merged to develop I can build rc1 binaries.

[5:29 PM] BadGuyTy: Once again guys thanks