Atomic swaps using cut and choose

[jl777]

Pardon. Reading the header with SWAP and then parsing the story I finally understand you try to achieve just an "easy" crypto ccy SPOT trade (Even more correct a same day forward) by executing one of the "easiest" smart contract and already struggle with that?

Why not trying some betting stuff? (Sorry, just caspering around a bit  )
I really want to know and see such easy stuff working before more complex things should be developed, savely....

How about some 2factor like mechano?

The reason it isnt easy is that there are two independent blockchains.

If using just one blockchain, things become much easier

James

[TPTB_need_war]

An attacker with infinite resources that doesnt care about monetary losses...

I claim that such an attacker can bring any network to a standstill. So defending against this is not a high priority in the beginning.

But this is not a symmetric analogy.

An attacker may only want to (discretely) jam decentralized exchanges, not (boisterously) bring the entire internet crashing down.

I like the simple approach where the fee (insurance) is prepaid before each trade. The fee is tagged with the orderid of the recipient of the offer, not the initiator of the trade. This means that a papercut attack cannot be done proactively, but only if somebody else initiates a trade with the attacker.

So, that means a reputation system will be effective as trading with newbie accounts will carry some small risk that they are a papercut attacker who set a trap.

By linking the fee to the orderid of the one that posted the bid/ask, that means the papercut attack only delays as the fee that was paid is still valid for completing the atomic swap with a real peer. The attacker cant reuse the fee paid, so this is assymetric in a good way.

Granted the victim will be out a fee if their bid expires without the trade being completed. We are talking about 0.13% in the event of an attack, so most of the time not even worth going through a claim process.

But maybe an active trader over time will accumulate a bunch of such failed fees, and I think if there was some sort of automated claim process for this, it solves the practical issues of this theoretical problem.

Before you start complaining that requires trust that this process will be honored, my response is that if this attack scenario remains hypothetical, then it is not an issue. If it does happen and the fees paid for failed swaps are not refunded, then that will damage the reputation of InstantDEX and so there is strong incentive to keep the customer's happy. Keep in mind it is the 0.13% fees that are lost due to an attacker that doesnt care about losing money and just wants to jam things. Typically non-economically viable attacks are not a big priority to solve. But I dont want there to be any obstacles to using InstantDEX, so I will commit to refund the fees paid for atomic swaps that dont complete, as long as the txfees needed to send out the refunds are less than 10% of the refund.

As opposed to having 100% of your capital at risk when you use centralized exchanges.

James

Sounds like InstantDEX would have an incentive to attack the victim since victim won't bother to apply for 0.13% refund, so victim will try again and thus pay 0.26% fees.

If you refund, then attacker has no cost of jamming, or do you have a way to identify which party was the attacker? How can you differentiate a glitch/slowness in the network from a true jamming attack. What if the attacker DDoS attacks the victim and victim can complete the protocol.

An attacker can build reputation before attacking, by trading with himself, i.e. reputation can be Sybil attacked.

Sorry I have thought deeply and there is no solution for decentralized exchange. Although I love it ideologically and I was very positive on you doing it, I unfortunately have to conclude that is not viable and should be abandoned. I am trying to help you not waste time on deadends. I invested my effort precisely because I wanted to help you.

[bitcoin-esperanto]

continuing from https://bitcointalk.org/index.php?topic=1340621.msg13881127#msg13881127 as it seems the OP locked it for some reason...

Thanks!!  
watched again!!  

wow it's really hard for a newbie 

[jl777]

But this is not symmetric analogy.

An attacker may only want to (discretely) jam decentralized exchanges, not (boisterously) bring the entire internet crashing down.

You incorrectly assume some single point of failure. Remember it is decentralized, so the attacker would have to Ddos all the participants all the time. You also incorrectly assume that it will be possible to identify which are specifically DE packets. I have provisions to encapsulate the DE packets with a layer of encryption so they cant be differentiated from other types of traffic. If needed, steganographic techniques could even be used to get the data through. If that doesnt work, there are zero knowledge ways to transmit the DE traffic. So there are quite many levels of defenses that are possible

Sounds like InstantDEX would have an incentive to attack the victim since victim won't bother to apply for 0.13% refund, so victim will try again and thus pay 0.26% fees.

why would InstantDEX want to attack its own users? That seems quite counterproductive. The volumes of an attackfree DE is much more than double one plagued by attacks. Due to the nature of the internet, over time there will be failed transactions, so eventually the users will recoup the fees. There is no permanent gain of fees from failed trades, so it is a liability on the books. There is no gain for InstantDEX to abuse its own customers.

If you refund, then attacker has no cost of jamming, or do you have a way to identify which party was the attacker? How can you differentiate a glitch/slowness in the network from a true jamming attack. What is the attacker DDoS attacks the victim and victim can complete the protocol.

Once things are automated, probably just allow for automated refunds, it is all pretty much at dust levels so the only concern is the customer support time. With an automated system, it wont be any big burden.

The attacker would be the one who is responding to a match offer, so if an address has 1000 failed trades out of 2000, it wouldn be easy to notice that. Worst case, even if the attacker doesnt lose money, they dont gain anything.

An attacker can build reputation before attacking, by trading with himself, i.e. reputation can be Sybil attacked.

I have a reputation system that cannot be sybil attacked, trading with yourself wont do any good. And before you say its not possible, let me say that it is, at least one that will be very expensive for the attacker and that is what it is all about, making the attacks cost more than the expected return.

Sorry I have thought deeply and there is no solution for decentralized exchange. Although I love it ideologically and I was very positive on you doing it, I unfortunately have to conclude that is not viable and should be abandoned. I am trying to help you not waste time on deadends. I invested my effort precisely because I wanted to help you.

Sorry, you are wrong. Maybe it will be the first time this happens? I believe that it is quite difficult to prove a negative, in spite of your claims. While I just need to make it work, and since I have quite a lot of techniques at my disposal, I am very optimistic I will get it to work.

You have no economically viable attack. Just because something is possible, that doesnt mean it is certain to happen, especially when it is economically non-viable. In crypto, the math protects us, so as long as the math yields a negative expected return, it wont attract the money motivated attackers. And if idealogical attackers conduct a permanent attack, I will just have to resort to adding highly leveraged and encrypted comms to make it very cost prohibitive to conduct any large scale attack. It would be a pain to do, but if needed, the DE can be conducted via zero knowledge networking.

I really dont think we can dismiss a project before the real world performance is established. If the failure rate is 90%, of course it wont be used. If the failure rate is 0.1%, then I dont think that will be a large deterrent.

The question is what will the real world failure rate be. I claim that NOBODY is able to predict this ahead of time. I prefer to get a real world results before making any decisions based on theory.
Until there is some significant volume being traded, it seems nonsensical for it to be attacked like that. And by the time there is a significant volume being traded, the more advanced defenses will be ready.

In order for it to fail, either InstantDEX itself would have to attack its own users or there needs to be an attacker from day one who doesnt care about costs, interfering with every single trade AND that I wont be able to devise defenses against this. Defenses can be via reputation system, insurance system, refund system, technically leveraged protections, among others. And all will have to fail with a constant and permanent attacker always interfering with significant numbers of trades.

You really believe this is 100% certain to happen?

James

[hv_]

I'd say it is same issue with Casper:

Decentral:
You need a trustless clrearing system  / notary in between - some say that 'could work' with some betting design....

Central: Easy but open to hackers.


Think of the actual process in trading as is:

- Client (has ccy1)  & wants to change it to ccy2
- Client needs to deposit (maybe partial) ccy1 first at market maker's account (market maker that could offer ccy2 vs ccy1)
- Market maker activates client to trade since now there is a credit limit = reduced counter party risk to market maker
- Client hits market maker (pays a fee for that service incl settlemet cost)
- Market maker might send real time confirmation notice to client (last chance to cancel?)
- Settlement is initiated by market maker (or escrow service) - atomic

How can you put some code around all that in a decentral way ?

[hv_]

I'm not sure if that helps (if anything does at all)  at all but I read that part here with the ..interactively verifying the presence of data in a foreign blockchain ...


"The Power of Binary Search

In the next two sections, I will give two specific examples. One is about interactively verifying the presence of data in a foreign blockchain, the second is about verifying general (deterministic) computation...."

in

https://blog.ethereum.org/2016/02/17/smart-contracts-courts-not-smart-judges/

[jl777]

I'm not sure if that helps (if anything does at all)  at all but I read that part here with the ..interactively verifying the presence of data in a foreign blockchain ...


"The Power of Binary Search

In the next two sections, I will give two specific examples. One is about interactively verifying the presence of data in a foreign blockchain, the second is about verifying general (deterministic) computation...."

in

https://blog.ethereum.org/2016/02/17/smart-contracts-courts-not-smart-judges/

It is not easy to be monitoring multiple chains at once as not only are there the data sync issues, but also just the logistics of running N daemons.

That is why I am developing iguana, a single lightweight multicoin daemon/applications all rolled into a single unified codebase. That just happens to be able to be cross compiled into a chrome app as it has virtually no external dependencies

James

P.S. I am getting BTC sync times from scratch of about half hour

[TPTB_need_war]

An attacker with infinite resources that doesnt care about monetary losses...

I claim that such an attacker can bring any network to a standstill. So defending against this is not a high priority in the beginning.

I was very sleepy when I wrote my prior post.

I understand your point. You want to design a protocol that is at least immune to jamming against any attacker other than one that has super powers.

Yet the attacker with even meager resources could cause honest participants to lose fees and so they might get turned off from the system. For example, centralized exchanges may have this incentive. Or specific coins might have this incentive to jam DE on other coins (especially those who hadn't yet been listed on a major exchange).

So you proposed to refund fees to those honest participants. You admitted that users might not be prone to apply for a refund since 0.13% is so small. And I pointed out the DE would maybe have a financial incentive (while appearing to be the good guys) to jam each honest participant say 50% of the time, to increase fees to 0.26%.

I am trying to think of a way to make this practical and robust enough, unless we are facing a prolonged attack from a super power. I like the ideological intent of DE. I will now review your latest reply with a clearer mind.

[TPTB_need_war]

Another potential solution is pegged assets on the same block chain, for those coins you want to trade with:

TPTB, have you contemplated the only immutable DEX in the top 10?

Is that trading BTC on the Bitcoin block chain with BTS on the BitShares block chain? Or rather is it trading BitBTC pegged asset on the BitShares block chain (which afaics would avoid the jamming issue)? If the latter, then it is isn't decentralized cross-chain exchange, which is what I was referring to.

Afaics, that seems to avoid the jamming issue.

[TierNolan]

Afaics, that seems to avoid the jamming issue.

I wonder if this would be a reasonable refund policy.

Both parties generate 1000 key_pairs = (private keys, hash(private keys))

Both parties exchange hash(1000 key pairs).

The fee transaction contains hash(alice_key_pair_hash | bob_key_pair_hash).

This is included in the fee transaction somehow.

To claim the fee refund, the person has to submit the 1000 key pairs and [other_party]_key_pair_hash.  That allows you verify that they had actually generated 100% valid pairs.

Someone who tries to attack the cut-and-choose cannot reclaim their fee.

They have to trust you to do that though, but that is probably ok, since it is just the fee.

[TPTB_need_war]

They have to trust you to do that though, but that is probably ok, since it is just the fee.

Then the centralized KYC pressure point is on the fee provider. So long-term this doesn't prevent KYC being forced (which one might argue is good, so government won't be against). Although one might envision many fee providers appearing over time (which can't drive fees too low because that would encourage jamming).

It does apparently solve the problem of centralized exchanges running fractional reserves and failing.

I am not sure if there is not a jamming attack in the protocol to establish the fee transactions?

The pegged assets alternative I offered in the prior post would probably still benefit from this "DE" design for exchanging the BitBTC to BTC. Note that centralized exchange isn't the only alternative, as for example a BitUSD could be converted potentially on the street.

[jl777]

Afaics, that seems to avoid the jamming issue.

I wonder if this would be a reasonable refund policy.

Both parties generate 1000 key_pairs = (private keys, hash(private keys))

Both parties exchange hash(1000 key pairs).

The fee transaction contains hash(alice_key_pair_hash | bob_key_pair_hash).

This is included in the fee transaction somehow.

To claim the fee refund, the person has to submit the 1000 key pairs and [other_party]_key_pair_hash.  That allows you verify that they had actually generated 100% valid pairs.

Someone who tries to attack the cut-and-choose cannot reclaim their fee.

They have to trust you to do that though, but that is probably ok, since it is just the fee.

These are the same 1000 key pairs used for the cut and choose right?
What is the limit on script size? Maybe there is a way to make a redeem script that requires all the keypairs?

OP_IF
    <now + INSTANTDEX_LOCKTIME*4 + 2hrs> OP_CLTV OP_DROP <TierNolan magic script> <alice_pubA0> OP_CHECKSIG
OP_ELSE
     OP_IF
    <now + INSTANTDEX_LOCKTIME*4 + 2hrs> OP_CLTV OP_DROP <TierNolan magic script> <bob_pubA0> OP_CHECKSIG
     OP_ELSE
        OP_HASH160 <hash(bob_privN)> OP_EQUALVERIFY OP_HASH160 <hash(alice_privM)> OP_EQUALVERIFY <INSTANTDEX_PUBKEY> OP_CHECKSIG
     OP_ENDIF
OP_ENDIF

The idea of the above is that if the trade has completed, then both privN and privM are available for the InstantDEX server to claim the fee. For those who scream about needing a centralized server, in the event of downtime, all that happens is a delay in fee spend.

In the event of a failed atomic swap the peers who are trading can reclaim the fee after twice the normal maxtime, I also added 2hrs to deal with the clock drift. Could we just use the redeem using secret rmd160 of the merkel root of all the cut and choose?

Not sure how the papercut attacker wouldnt be able to claim the refund. If so it would be a trustless automatable refund process that only the victim can use.  I think even if the attacker can also reclaim the fees, that is lesser of the two evils as compared to the victim not being able to collect the fees. It sounds like there is a way for the one who attacked cant claim though?

James

[TPTB_need_war]

Sorry I have thought deeply and there is no solution for decentralized exchange. Although I love it ideologically and I was very positive on you doing it, I unfortunately have to conclude that is not viable and should be abandoned. I am trying to help you not waste time on deadends. I invested my effort precisely because I wanted to help you.

Sorry, you are wrong. Maybe it will be the first time this happens? I believe that it is quite difficult to prove a negative, in spite of your claims. While I just need to make it work, and since I have quite a lot of techniques at my disposal, I am very optimistic I will get it to work.

I wrote that because I see an inviolable generative essence that there is no reference point. Both parties to the exchange trade are equal in status without a trusted third party. You can see this has been proven by academics for any "simultaneous contract signing". I had seen a PPT with references to the literature and can't find it now, but for example here is another paper:

I’m Not Signing That!
James Heather and Daniel Hill

1 Introduction
Often it is desirable to have a procedure to allow two parties to sign a contract
simultaneously. The obvious danger of having one party sign before the other is
that the second party may refuse to sign until it becomes to his advantage to do
so. For instance, suppose the contract is for Alice to buy 1,000 shares in Fudge
Labs, Inc., from Bob, at £1 per share, in a year’s time. If Alice signs first, Bob
may then delay signing until the end of the year. If the price has fallen, he will
sign, the contract will be binding on both parties, and he will make a profit; if
the price has risen, he will not sign. A similar problem will arise if Bob signs
first. Because the market changes over time, anything that allows one party the
option of delaying the decision on whether to commit will cause problems.
Simultaneity in message transmission is, in most practical situations, im-
possible to achieve, making cryptographic contract-signing protocols difficult to
realize. A trusted third party can be employed to receive the two signatures and
then distribute them, but it is clearly advantageous to construct a protocol that
does not require action on the part of a third party unless there is suspicion of
foul play by one of the parties involved in the contract.
In this paper, we examine a cryptographic contract-signing protocol that
aims to solve these problems by making the probability that one party can
abuse the protocol arbitrarily small. We demonstrate that the protocol has a
curious weakness: two rational agents whose rationality is common knowledge
will refuse to run the protocol at all.

Or this paper (which you may want to read as it talks about probabilistic solutions):

In 1980, Even and Jacobi [8] showed no deterministic contract signing protocol exists, without participation of a trusted third party (TTP).

You have no economically viable attack.

Only of we ignore externalities (external economic motivation). The same applies to the erroneous claim that proof-of-stake is as secure as proof-of-work.

Just because something is possible, that doesnt mean it is certain to happen, especially when it is economically non-viable.

As non-viable as Nxt being controlled by a dictator and Bitshares being controlled by two centralized exchanges.

The question is what will the real world failure rate be. I claim that NOBODY is able to predict this ahead of time.

IMHO, we should endeavor to analyze that before expending great effort on implementation.

Btw, I am not belittling the toolset you've developed, our shared ideological motivation, etc.. Just trying to be level-headed and rational.

My point was that purely DE will not work. You and TierNolan are apparently proposing a slightly centralized design with a trusted third party. It is well known in literature that TTP and/or probabilistic protocol is necessary.

[TierNolan]

These are the same 1000 key pairs used for the cut and choose right?

Yes.  Both parties commit to the hash before the choose part of the cut and choose.  You actually just need to commit to the public keys.

The fee transaction would contain hash(hash(alice's public keys) | hash(bob's public keys)).

What is the limit on script size? Maybe there is a way to make a redeem script that requires all the keypairs?

520 bytes for P2SH outputs.  That is technically the scriptPubKey.  The redeem script can be longer, I think.

The problem is that you need to check that the private key matches the public key.  That can't be done with script.

The idea of the above is that if the trade has completed, then both privN and privM are available for the InstantDEX server to claim the fee. For those who scream about needing a centralized server, in the event of downtime, all that happens is a delay in fee spend.

Automatic refund of the fee on trade completion is definitely possible.  I don't think you can get automatic refund from the 1000 key commitment though.  That would justify some of the fee going to the author, since he provides a service (other than coding).

Not sure how the papercut attacker wouldnt be able to claim the refund.

The attacker can only claim the refund if the attacker creates a valid set of 1000 key pairs.  At least it protects from attackers trying to do cut and choose with one invalid pair.

If the (potential) attackers follows each of these strategies

- 1000 valid pairs committed
-- can reclaim most of the fee

- 999 valid, 1 invalid pairs committed
-- 0.1% chance of successful fraud
-- 99.9% chance of losing the entire fee

Note: in the 2nd case, the party that was attacked can reclaim their share of the fee

As long as fee * 0.99 is greater than (trade value) * 0.001, then it is not worth attacking.  That means that fee > trade_value / 990.

Both parties lose the bitcoin tx minimum fee and also the refund service/author's fee

[jl777]

Here is a simple solution to the fees:

Alice fee:
OP_IF
    <now + INSTANTDEX_LOCKTIME*4 + 2hrs> OP_CLTV OP_DROP <alice_pubA0> OP_CHECKSIG
OP_ELSE
     OP_HASH160 <hash(bob_privN)> OP_EQUALVERIFY OP_HASH160 <hash(alice_privM)> OP_EQUALVERIFY <INSTANTDEX_PUBKEY> OP_CHECKSIG
OP_ENDIF

Bob fee:
OP_IF
    <now + INSTANTDEX_LOCKTIME*4 + 2hrs> OP_CLTV OP_DROP <bob_pubA0> OP_CHECKSIG
OP_ELSE
     OP_HASH160 <hash(bob_privN)> OP_EQUALVERIFY OP_HASH160 <hash(alice_privM)> OP_EQUALVERIFY <INSTANTDEX_PUBKEY> OP_CHECKSIG
OP_ENDIF

If the trade completes, InstantDEX server has 2*INSTANTDEX_LOCKTIME to spend the fee (maybe this could be changed to 24hrs minimum)

If the trade doesnt complete, the Bob can reclaim his fee and Alice can reclaim her fee at leisure. However, I remember a few cases were maybe both secrets are divulged even though the trade hasnt been completed, but those were cases the trade failed anyway.

No complicated logic, just a time window where fees for completed trades can be collected and if not the one that sent the fee can reclaim it.

A nice improvement would be if the attacker wouldnt be able to claim it, but even without that this negates the papercut effect and just becomes an annoyance attack and the attacker has no economic gain from this.

James

[jl777]

Please note I added this to my prior post. I will delete this post after you've read it.

My point was that purely DE will not work. You and TierNolan are apparently proposing a slightly centralized design with a trusted third party. It is well known in literature that TTP and/or probabilistic protocol is necessary.

I think the blockchain acts as the trusted third party here, especially with the interlocks where each side waits for confirmations.

the latest fee scripts are not centralized in any way, though if the InstantDEX doesnt spend the fees that it gets, then the deterrent effect of the fees are gone, so there is arguably a slight centralization to make the disincentives work. However, no central party is needed in the mainstream case of the trades completed. No central party is needed in case the trade doesnt complete (as both parties redeem the fee).

Sure looks like a good practical first version approach

James

[jl777]

These are the same 1000 key pairs used for the cut and choose right?

Yes.  Both parties commit to the hash before the choose part of the cut and choose.  You actually just need to commit to the public keys.

The fee transaction would contain hash(hash(alice's public keys) | hash(bob's public keys)).

What is the limit on script size? Maybe there is a way to make a redeem script that requires all the keypairs?

520 bytes for P2SH outputs.  That is technically the scriptPubKey.  The redeem script can be longer, I think.

The problem is that you need to check that the private key matches the public key.  That can't be done with script.

The idea of the above is that if the trade has completed, then both privN and privM are available for the InstantDEX server to claim the fee. For those who scream about needing a centralized server, in the event of downtime, all that happens is a delay in fee spend.

Automatic refund of the fee on trade completion is definitely possible.  I don't think you can get automatic refund from the 1000 key commitment though.  That would justify some of the fee going to the author, since he provides a service (other than coding).

Not sure how the papercut attacker wouldnt be able to claim the refund.

The attacker can only claim the refund if the attacker creates a valid set of 1000 key pairs.  At least it protects from attackers trying to do cut and choose with one invalid pair.

If the (potential) attackers follows each of these strategies

- 1000 valid pairs committed
-- can reclaim most of the fee

- 999 valid, 1 invalid pairs committed
-- 0.1% chance of successful fraud
-- 99.9% chance of losing the entire fee

Note: in the 2nd case, the party that was attacked can reclaim their share of the fee

As long as fee * 0.99 is greater than (trade value) * 0.001, then it is not worth attacking.  That means that fee > trade_value / 990.

Both parties lose the bitcoin tx minimum fee and also the refund service/author's fee

as written this needs to wait for a new opcode, so cant be done for a while.

Each side can commit to the field product of all the priv keys (https://bitcointalk.org/index.php?topic=1357845.msg13919273#msg13919273), ie. use the method in the link to get a combined product (100ns per fmul op), so 1000 multiplies will take 100 microseconds. then a hash of this is put into the feetx as data (push drop).

Each side also includes in the paymenttx the field product of all but one privkeys (which they both have before any big money is exchanged).

On redeem, the protocol would be to include the missing privkey as data so it can be verified that the hash(privkey multiplied by the all but one field product) matches the data in the feetx. This allows a reputation system to track how many trades were started by each address, how many failed, how many were properly redeemed, how many were improperly redeemed.

sybil attacking accts will all have very low completed trades, so users just need to beware of newbie accts.

James

[jl777]

@TierNolan

Did I read this right: https://bitcointalk.org/index.php?topic=1331275.msg13941835#msg13941835

RBF is opted into if sequenceid is used?
Doesnt that mean using CLTV or CSV or microchannels that use sequenceid is forced to accept RBF? If so, doesnt that break the entire premise for atomic tx

James

[TierNolan]

RBF is opted into if sequenceid is used?
Doesnt that mean using CLTV or CSV or microchannels that use sequenceid is forced to accept RBF? If so, doesnt that break the entire premise for atomic tx

The rules are

sequence = 0xFFFFFFFF means final (ignore locktime) and no replace by fee
sequence = 0xFFFFFFFE means non-final (can use locktime) but opts out of replace by fee
sequence = 0x80000000 - 0xFFFFFFFD means opt-in to replace by fee
sequence = 0x00000000 - 0x7FFFFFFF is intended for use with relative locktime (plus probably RBF)

[jl777]

RBF is opted into if sequenceid is used?
Doesnt that mean using CLTV or CSV or microchannels that use sequenceid is forced to accept RBF? If so, doesnt that break the entire premise for atomic tx

The rules are

sequence = 0xFFFFFFFF means final (ignore locktime) and no replace by fee
sequence = 0xFFFFFFFE means non-final (can use locktime) but opts out of replace by fee
sequence = 0x80000000 - 0xFFFFFFFD means opt-in to replace by fee
sequence = 0x00000000 - 0x7FFFFFFF is intended for use with relative locktime (plus probably RBF)

It seems much much worse. RBF is enabled if any input has any value other than -1 or -2
That seems to break 90%+ of whatever uses sequenceid (assuming you dont like the RBF behavior), like CSV.

Not sure but it might break SIGHASH_SINGLE signed tx, and possibly some or all coinshuffle protocols as the presence in any input affects the entire tx

Hopefully you can influence the right people to dramatically scale down the RBF's hogging of 31.99 of the 32 bits. Just give it the LSB if it is just a flag?

James