Yeah, I get that using a new token for this sucks. But I don’t see an alternative except locking a BTC collateral up with escrow, which is worse, because it is not trustless.
Projects like Thorchain try to use massive-multisig custody in order to model "BTC locked until arbitrary outside conditions are met" – but really it’s just the same, the Thorchain can at any point defect with the Bitcoin you have locked up in it.

The $TRADE token is not meant to be a BTC-competing cryptocurrency.
One angle that would serve to make that very clear is to use a 1:1 USD-backed token.
So, some venture raises $1 Billion USD to launch a trade chain. Anybody can buy into that chain by exchanging USD for $TRADE. (Could even be KYC’d and all.)
Now the trade chain works nicely, traders can join anonymously by spending BTC to get $TRADE from KYC’d traders.
In order to cash out your $TRADE for USD again, perhaps you have to pay a 4% fee and also go through KYC.

In this design, it’s clear that 1 $TRADE will always be worth around 1 USD: It’s not a speculative asset.

Of course, this instance of the trade chain would be limited to $1 Billion USD collateral capacity.
But a competitor could raise $2 Billion and launch another instance of the chain. Now there’s $3 Billion overall, both chains can easily be arbitraged between – nice.

No no, you would do the normal fully trustless Atomic Swaps. The 'some new blockchain' construct just asserts that you actually DID go through with the Swap.
You are right, one way to do this is to have a centralized 3rd party that judges whether a Swap was executed.
But there is also the other way, which is to have a fully seperate blockchain that ALSO observes the BTC chain.
That is the participants in the Tradechain also run the Bitcoin chain, and when somebody claims to have executed an Atomic Swap, they include a pointer to the true Bitcoin TX as proof of that. Everyone running the Tradechain only accepts that "I did swap" claim only if their local Bitcoin chain state includes that Bitcoin tx.
The Bitcoin chain is oblivious of the Trade chain, it only sees the normal Atomic Swap transactions.
But the Trade chain is not oblivious of the Bitcoin chain: Certain types of "transaction" (like the claim to have gone through with a Swap) are validated against the Bitcoin chain state.



Fair enough; but the upside of leverage/derivatives is tighter spreads and more liquidity in general, even if one does not use leverage.

There is no leverage on AtomicDex, and each trade is actually executed as an Atomic Swap. It is a nice project for the average Joe looking to buy some Altcoin, but it’s not practical for power traders.
As it states on their website, for example:


"Nothing happens at all" is exactly the problem. Your liquidity gets stuck in a canceled Atomic Swap and the market moves away from you.
This is why a penalty (claim of collateral) is needed; and this penalty can only be enacted by a system that can judge whether the TX was executed or not, on the real actual BTC or ALT chain.


The $TRADE chain would be an actual standalone blockchain or DAG structure or what have you. But it’s a Smart Contract in the sense that it is aware of things "outside of it" and has specialized logic to interact with these.
It’s also a Smart Contract in the sense that competing instances could co-exist rather peacefully.

I want to propose a clever mechanism here for building actual markets/exchanges with Atomic Swap technology.

The basic idea is to run a sort of "smart contract" that is really a specialized blockchain of its own.
It does not matter which consensus algorithm it uses, the important points are:

- Has specialized transaction types for making and taking BTC/ALT Atomic Swap offers
- Is 'aware' of Bitcoin chain
- Is 'aware' of Altcoin chain
- Has a native token, let’s call it $TRADE (The native token could be airdropped, mined, backed by USD, whatever works well)

Now an offer to swap BTC/ALT looks something like:
- Volume
- Rate
- Collateral in $TRADE (deposited with the offer)
- Required taker collateral in $TRADE

What is the collateral for? Atomic Swap markets are easily DoS-attackable, you just initiate lots of trades, but don’t follow through with the Atomic Swap protocol. In my proposed design, if either side stops following protocol, they lose their collateral to the counterparty.
That is, in the happy case, both sides can conduct the Atomic Swap entirely in private and simply sign off on a final "Atomic Swap executed" TX jointly, to unlock both of their collaterals on the $TRADE chain.
In the unhappy case that one side tries to dodge the Swap, the victim commits a "complaint" tx to the $TRADE chain. If the perpetrator does not respond with a counter-proof (by pointing to the TX it has conducted on the BTC or ALT chain), their collateral is claimed.
(Inspired by this article: https://medium.com/@graycoding/lessons-learned-from-making-a-chess-game-for-ethereum-6917c01178b6)

Now the interesting thing is we don’t have to dictate the amount of collateral deposited. We can let the market decide.
You can offer better exchange rates, at lower collateral, or worse rates at higher collateral.
At any point, if the unrealized loss from your position exceeds the collateral, you will probably just forfeit the collateral instead of following through with the Swap.
See this very good article for an intro to these dynamics: https://blog.bitmex.com/atomic-swaps-and-distributed-exchanges-the-inadvertent-call-option/

(What you can also try is to build a reputation (your trade history can be public on-chain, after all) as being an honest trader that always Swaps, letting you 'get away' with lower collateral because you have executed 1000 Swaps and dodged 0, for example.)

_____

OK, now we take this to another level. We don’t want every trade to actually be an Atomic Swap – transactions on $BTC and other chains are costly!
Let’s make positions fungible.

Alice posts offer:
- 1 BTC for 50 ALT
- Collateral 100 $TRADE, taker has to bring the same. Let’s say 100 $TRADE is worth 0.1 BTC, so the collateral covers 10% of the position.

Bob takes the offer. Now Bob owes Alice 50 $ALT and Alice owes Bob 1 $BTC. We can think of these as 'positions' in trading,
as long as neither Bob nor Alice insists on the Atomic Swap being executed, they simply hold the 'Call Option'.

Market develops, Carol comes around and posts offer:
- 55 ALT for 1 BTC
- 110 $TRADE collateral

Bob can use the +1 BTC position he holds against Alice, to take this trade! He pockets the 5 $ALT / 10 $TRADE winnings.
Now we have:
- Carol owes Alice 50 $ALT
- Carol owes Bob 5 $ALT, or 10 $TRADE (excess collateral)
- Alice owes Carol 1 BTC
- The position between Alice and Carol is collateralized with 100 $TRADE as before. (Collateral must not shrink)

Bob can now demand payment of 5 $ALT from Carol. Again if Carol does not pay, he complains on the $TRADE chain and the chain decides to let him claim the 10 $TRADE collateral, unless Carol can point to the transaction on the ALT chain where she has actually paid Bob.

Note that Bob needed to find an offer that had a better rate as well as excess collateral to cover his winnings.
He could’ve also made use of an offer that had the _same_ rate, but more collateral, and just claim the excess collateral!

_____


What we discovered is that Bob can trade with leverage. Maybe he owns neither 1 BTC or 50 ALT – he just owns 0.1 BTC worth of $TRADE. So he just traded with 10x leverage.
The scheme is extremely capital-efficient. Rather than locking up the complete worth of the position like in a spot market, or taking out a loan to fund a leveraged position, you transparently engage in trades that are in the end only secured by the collateral.
As the Bitmex article put it, »it may be better to embrace the call option feature as a viable product, rather than ignoring or fighting it.«

Since both "force execution of a position" and "exit a position by trading it away" would be actions on the $TRADE chain, Alice can try calling Bob out on his leveraged play, by frontrunning his trade TX with a TX that forces their pending Swap to start being executed.
In this case, his lack of real funds would come to light and he’d lose his position AND his collateral, even though he was winning the trade! This is a feature.

So, to make life for people like Bob feasible, we can introduce timing windows to positions, e.g. "this Atomic Swap can only be forced to execute from Oct 1, and no later than Oct 3" – like Futures. So if Bob takes the position with Alice on Sep1, he’s got 1 month to exit until his 'bluff' can be called.
He can 'roll' his futures by finding trades of Oct1 vs. Nov1 position etc. A lot of different markets can develop on the $TRADE chain. The number of actually executed Atomic Swaps may grow very very small, but the threat of forcing execution is the thing that makes this market work completely without price Oracles.

There’s a lot of questions I haven’t touched in this overview, and maybe the idea holds a fatal flaw – hard to tell. Would love to hear input on this.

Stray notes:
- Of course there must be BTC/TRADE and ALT/TRADE markets, too
- Many trade-chains can exist and parallel and be arbitraged between, it works wonderfully, scales
- Frontends could offer close-to normal exchange experience, hide the nitty-gritty details of comparing different offers
- Closing one position via another trade can also be done just partially, with the obvious implications of looking at keeping collateral/volume ratio the same etc.
- Positions can also demand an up-front premium in exchange for better rates, mimicking Options. The premium can even be payable in BTC or ALT, does not have to be $TRADE
- To avoid adjusting rates on your offers all the time, you can hook into external price streams. Basically you demand from the Taker a "signed message from #myFavorityCentralizedExchange" that asserts the rate at block height X is Y. Your favorite exchange publishes these messages as a service. Could be multi-sig by a consortium of CEX, too. You get the idea.

Trying to understand PoS incentives.

Let’s say the Majority of staking power conspires, because it is not satisfied with the state of things (e.g. too little ROI on staked capital).

The % of staking power required to be Majority differs between algorithms, but always for liveness/finality there is some threshold that says: x% of nodes (Minority) may fail and the network will still make progress.

So let’s say the Majority of staking power "takes the chain private." Meaning, the chain is continued in a private network. Minority staking power is treated as being offline.

"We only publish the chain once TX fees are raised."

Effectively the chain is stalled until users give in to the demand.
There is no direct cost for the Majority. In fact, the value of the stake may rise if TX fees are raised, because now the stake is bringing in a larger ROI. Depending on the algorithm, there is also revenue from slashing the Minority stake.

In this sense it is as if the Majority stake "owns" the network and can make demands of the users.
Depending on how much they depend on the chain, users may be forced to give in to far-reaching demands.
On the flipside, users may fork-off the Majority by switching to a client that just blacklists the Majority’s addrs. However, this would potentially discourage future stakers / make staking even less appealing. The remaining Majority (which was Minority before) may try to pull off the same thing again.

So both users and stakers make themselves vulnerable by committing to a PoS chain?

Hey there,

just going to point out I’m still working on this, updated with CN/2 and multi algo switching included via xmrig base: https://github.com/949f45ac/xmrig-HIP

There’s interesting CN/2 performance in some cases, and CN/1 I have also been able to make faster. Of course, RX Vega generally works well on Linux now, so this miner has become a bit more useful.

Current exemplary numbers:

Card description	Core, mem clk	Miner config	CN/2 hashrate	CN/1 hashrate (TxB, if different)
470 4GB	1126, 1750	8x124 * 2	870	840 (4x496)
460 2GB	1020, 1750	64x14	439	442
Vega 64	1630@905, 1100	32x64 + 32x60	2000	2180
Vega 56	1485@900, 920	32x56 * 2	1830	1910 (32x112)

If you’re interested in trying new stuff, give this one a spin~ I’ll be glad to help out with any issues, and hear about results.

Cheers

I can run a 2GB RX 460, but only via ROCm. So if you only tried with AMDGPU-PRO until now, give ROCm a shot.

Profit-switching is useless if you do not immediately sell the coins you mine. (Pretty impractical to do yourself for CN coins, due to the relatively high tx fees.)
If you want to make bank on surging CN shitcoins, try the moneroocean pool. It does algo switching for you and immediately sells the shitcoins for XMR, so you don’t have to bother. (For them it’s also practical, since they’re trading higher amounts, obviously.) Only CN7 coins, though.

From the program output and strace it looks somewhat like you plugged some optimized kernels into ccminer, added a dev fee, and finally compiled and obfuscated the whole thing.
But you are technically not allowed to do that. ccminer is licensed under GPL. All modifications have to also be open source.
Sorry if I’m mistaken and you actually built the whole pool protocol handling and all yourself. The algo speedup is certainly nice and impressive. It’s just that everyone who’s dabbled in closed source miner development knows that the kind of most annoying part is building the whole shell around the actual GPU code. Building on top of a GPL-licensed open source miner is a cheap and not actually legal way around that.


If anyone cares, on Arch you get around this problem by doing
export LD_PRELOAD=libcurl.so.3
with installed libcurl-compat. How did I know? Ran into the same issue with ccminer already.

Work continues here:
https://github.com/949f45ac/xmrig-HIP
(See first reply itt as well, for current status.)



Original OP:

Hey everyone.

I’ve developed a new miner on the basis of xmr-stak-nvidia. Here is the link: https://github.com/949f45ac/xmr-stak-hip
It is all open source and can run both AMD and Nvidia cards, usually a bit faster than the other open source miners. (I did not test against closed source.)
Building requires a quite specialized setup with ROCm. If you run Nvidia cards, there is a portable binary in the "releases" section. I could upload one for AMD as well, but you’ll still need to setup ROCm to run it, so you may as well build the miner yourself.

As for the hashrates, here is a small table with some test results. ("Previous" = open source CUDA/OpenCL monero7 implementations that come with xmr-stak/xmrig.)
As you can see, the HIP miner does especially well on power-optimized settings.

Card	Card setting	Previous T x B	Previous H/s	x-s-hip T x B	x-s-hip H/s
1050Ti 4GB	pl=52.5W	64x30	296	32x48	313
1050Ti 4GB	pl=75W	64x30	303	32x48	319
460 2GB mod	sclk=3	8x448	385	8x112	416
460 2GB mod	sclk=4	8x448	405	8x112	419
Vega 56 reference	sclk=0 mem+10%	8x1928 * 2	1075-1120	8x224 * 2	1170 stable
Vega 56 reference	sclk=5 mem+10%	8x1928 * 2	1240-1325	8x224 * 2	1304 stable

Notes:

• "T x B" indicates "threads x blocks" configuration, or "worksize x intensity" in the case of OpenCL.
• RX 460 had modded BIOS, but memory not overclocked. (Polaris memory is hard to OC on Linux.)
• OpenCL miner cannot use higher intensity than 448 on the 2 GB RX 460 for some reason.
• Vega 56 fluctuates quite a bit on OpenCL.
• Vega 56 numbers for the HIP miner have two processes started. Scheduling two GPU workloads in the same process does not work for some reason. But hashrate for a single 8x448 process is only about 15 H/s less in both cases.
• All Vega numbers are with Kernel driver patch applied. (Slightly increases both OpenCL and HIP miner speed.)

Dev donation address in the miner is unchanged. If you insist on giving me coins personally, addresses are in the README.
You may also just give a star to the repo or send me some thanks, if you use this miner and like it.

Cheers