Topic: [ANN][KMD][dPoW] Komodo - An Open, Composable Smart Chain Platform, Secured by B - page 370. (Read 1192381 times)

Hi all !
I got back in BTCD cause of the market ...

How shall I take the swap regarrding KOMODO and or BTCD ...
Is the swap urgent and what is the dead line (Janv 2008) ?
Is there any risk to stay in BTCD regarding its rate ?
And finally, if Komo / BTCD rate is fixed about 50, how is runing the cours BTCD or COMODO Huh

Thanks guys, I c a nice comunity over ther ...

good luck !

I will continue to add api calls to barterDEX, especially regarding price history, and I can also make custom api calls to help the GUI devs. So if you are a GUI dev and need a new api call, just ask

With the barterDEX core, we can have an exchange of the native coin utxos directly. This is already working at the command line level, but I know how much everybody hates using the command line. So we will incentivize many GUIs, in addition to the inhouse ones.

The HUSH dev team is already starting on a GUI and I expect VRC/VRM team will also. Maybe there are other coins that want to get a barterDEX customized for their coin and have a chance at $100,000 at the same time

There will be some common sense assumptions to the barterDEX GUI bounties:

Working GUI must be deployed within some reasonable timeframe, I am thinking 2 to 3 months
A limit to the number of different GUI projects that will have bounty reserved. In the event they dont meet the deadline, then an alternate would be eligible.

To spice things up, I am considering a usability contest where the most used GUI gets an additional bonus. By having a specific deadline for tallying the usage, this incentives an early release, but of course if it is early but not so good, it wont get much usage.

Still undecided on the cutoff for the usage tally and I am also considering supplementing the usage tally with a poll of this thread. That would have less weight than the usage. And a final component which would be made by me only in the event that some technically deficient version was winning to ensure that the bonus doesnt go to some version that has technical issues but still gets a lot of usage.

Something like usage 50%, poll results 25%, technical 25%

The bonus amount I want to be big enough to get some project management types to manage a few devs. To achieve this effect, I am proposing a $100,000 USD equivalent of KMD (max of 50,000)

So if you can manage a barterDEX GUI project, you can get it accepted as a bounty setaside to make sure that you recoup your costs and also get a shot at the $100,000 bonus. In addition to the nice money bonus, the winning GUI will become the official barterDEX GUI, which will of course establish whoever created this to be a bona fide award winning GUI dev (team).

It looks like we will get not only an Agama barterDEX, but also a simple html, a swing wallet and a QT wallet, with more likely to enter the contest.

I think the timing for the contest would be based on a time delay from when the first viable barterDEX GUI is released, say 2 months after that event.

Feedback appreciated, this is an idea that is in the process of being formed so now is the time for feedback before it becomes set. The 10,000 per GUI is already set, but the number of approved GUI projects is not and the specific way the winning GUI will be selected is not finalized

added a "gui" field to the barterDEX startup json so we can track which GUI is most used.

For those that missed it, we are offering multiple 10,000 KMD bounties for barterDEX GUI. At a minimum it needs to support KMD, BTC and the assetchains and be an original implementation. Preferably from a slightly different point of view than the other GUI.

This is about $20,000 per GUI at today's prices and of course once we get one or more GUI for barterDEX that people are happy with, the price is expected to reflect that.

Just contact me if you feel you are able to make such a GUI with some rough ideas (screenshots) and I will reserve the 10,000 KMD for your GUI completion. By complete, that means real users actually using it as evidenced by the "gui" field set to your GUI for completed transactions in the stats records of the atomic swaps.

I will next work on barterDEX'ing BTC, as painfully slow as that is. It used to work and I dont think I broke it, so it shouldnt take too long to verify it, but it does have to deal with dynamically calculated txfees, which can easily make ordermatch reject things as the ordermatch protocol is quite strict currently.

I guess after that, what is left to do is to get the default LP nodes funded with a variety of coins and have some sort of realtime pricing based on..., not sure what to base it on as there is little reference, so maybe I will just set some crazy low prices for the early birds to make some free money with.

Please dont complain if you miss out on the totally underpriced coins that I will initialize the LP nodes with

alice fee KMD 5e6918488af45b129dc2a46fbfb0c6811f9ed78a30506a875e8a3df9ed4e220f

bobdeposit HUSH bb52c5d7c574bd692689202beb48d42c3c4fd48a061a0f48c8ea31032f19d73e

alicepayment KMD 78875404d71c19a369d14ddc29988daae4fad1f20d62e9cf2e956ff19d38ce5b

bobpayment HUSH 04b304604d10211dd4af77ef73c11eec270eec14756311de9606655aaeff51ec

alicespend (of bobpayment) HUSH 7b11d0be299fdd0d2e6f3755d69e61ee39b42264c751d5bb81ad628f5d05c1ba

bobspend (of alicepayment) KMD a42d65d4b8b14dcfee64eb8658b01632fdabcbbf95cecafa756ac3cd5097956e

bobrefund (of bobdeposit) HUSH d66725e32ea484261e16570a9a0853da1e1901f811cccbd71ea6c624669abb81

for those keeping up to date with progress, the above was between two client nodes, both configured with canbind:0


As you can see, to add a coin to the list of supported coins is a matter of adding the appropriate coins[] array object:

{\"coin\":\"LTC\", \"name\":\"litecoin\", \"rpcport\":9332, \"pubtype\":48, \"p2shtype\":5, \"wiftype\":176, \"txfee\":100000 },

most of this info is in the chainparams.cpp file. If someone is interested in a bounty to dig up this info for the top 100 bitcoin forks, let me know how much it would cost.

Now that two canbind:0 nodes have done an atomic swap, that was the hardest networking test point, so barring silly bugs, all the easier cases should have a good chance to work. We need to now verify proper operation across all the OS platforms and networking configs.

With client mode able to atomic swap with another client node, that means the LP nodes dont have to run a coin for that coin's orderbook to be live in the network. If just two nodes run a specific coin (with the valid JSON definition), then they can create an orderbook between them (everyone else can also see this orderbook) and either party can start an autotrade.

I added blacklisting for nodes that dont connect (based on pubkey) and specific bob utxo that didnt respond. This allows multiple calls to autotrade to iterated down the list from most desirable to least, skipping a utxo after an error and skipping a pubkey after too many errors on utxo connects (currently set at 3).

I also added a bit of smarts to the ignoring of unresponsive peers and a way for them to come back into the active pool if they were just offline for a while.

What does all this mean?
It means that we are now in the "wait for the GUI to make all this easy to use" phase.

There is an uglyGUI that gets the job done, even though it isnt prettified. Also the HUSH devteam is starting a HUSH-centric DEX GUI. While it is possible to support 100+ coins, it is also ok to just support a few. If a coin is in the coins array, it can be active or inactive. If it is inactive (default for most), then all you can do is activate it. So this allows a bit of sanity to the list of available coins where we can verify that the parameters are correct and indeed it represents the coin specified.

So far there have been very few bugs reported with the barterDEX core, even though there is a minimum 100 KMD bounty per bug. I guess most people are afraid to issue curl commands like:

curl --url "http://127.0.0.1:7779" --data "{\"userpass\":\"$userpass\",\"method\":\"setprice\",\"base\":\"HUSH\",\"rel\":\"KMD\",\"price\":0.93234}"

curl --url "http://127.0.0.1:7779" --data "{\"userpass\":\"$userpass\",\"method\":\"orderbook\",\"base\":\"HUSH\",\"rel\":\"KMD\"}"

curl --url "http://127.0.0.1:7779" --data "{\"userpass\":\"$userpass\",\"method\":\"autotrade\",\"base\":\"HUSH\",\"rel\":\"KMD\",\"volume\":0.5,\"price\":1.534}"


The above three are really all the API calls that are needed for a minimal trade setup, ie. set the price, get the orderbook and issue autotrade. probably also want to call swapstatus to see the status of swaps:

curl --url "http://127.0.0.1:7779" --data "{\"userpass\":\"$userpass\",\"method\":\"swapstatus\",\"requestid\":2291973695,\"quoteid\":3387529385}"

I tried hard to abstract out the difficult parts of barterDEX and map it to something similar to existing exchange requests. If you have experience in writing software to exchange GUI, please contact me, looking for several parallel developed exchange GUI so there is a variety of solutions for users to choose from.

There is 10,000 KMD reserved for bug finding and testing

I can offer a similar amount for a fully working GUI that is independently developed and preferably takes a different approach than the other GUI projects toward barterDEX. Contact me if you are interested in developing such a GUI and if it seems likely you will be able to complete one, I will reserve 10,000 KMD for the completion bounty

Kmd steady on the move despite the dump buying some more setting low bids and waiting I can see a 100kplus

AFAIK you don't need another Ledger, you can recover the private key with just the 24-word passphrase (not sure about Komodo though).
https://ledger.groovehq.com/knowledge_base/topics/how-to-restore-my-backup-without-a-ledger-wallet

OK, for passphrase based privkeys, it isnt forever. Though Murphy's Law will guarantee that you lose the hardware just as you go on a vacation and dont notice until you come back and then you can find any place that sells it in stock, so a couple weeks can easily pass.

My guess is that if any side channel attack is going to be practical, it wont take weeks to perform, but more like many hours or a day or two. Otherwise it is just too long a time and as you say the funds can be transferred out

I wouldnt say they had forever, could you just order another nano ledger S then recover using the previous passphrase and send the coins to another secure wallet.

I would say your more likely to get caught with a malware key logger than someone physically stealing your hardware wallet.  May not be perfect but for me its about risk reduction.

It is an announcement of side channel attacks against hardware wallets, which requires you to lose physical access to the physical wallet.

Under such conditions, the attacker has forever to crack it and forever is enough time to accumulate statistical correlations using many side channel methods.

How long this process takes might be less than expected, but the important point is that if you dont lose your hardware wallet, none of these side channel attacks can be done.

If you want a hardware device that can withstand arbitrary amounts of attack after being physically lost... Well I doubt any such thing was ever possible. Maybe some setup with a deadman switch that pays out to a preset emergency address upon violation of the keepalive protocol, something like that would be needed to make sure funds in a lost device are recovered.

Hi all !
I got back in BTCD cause of the market ...

How shall I take the swap regarrding KOMODO and or BTCD ...
Is the swap urgent and what is the dead line (Janv 2008) ?
Is there any risk to stay in BTCD regarding its rate ?
And finally, if Komo / BTCD rate is fixed about 50, how is runing the cours BTCD or COMODO

Thanks guys, I c a nice comunity over ther ...

good luck !

Link with the info about the hack?

Have recently ordered a ledger nano s and would like to confirm before using it.

Ledger is hacked, as also the Trezor. Good luck

Does Trezor support KMD?
Or would I have to buy a Nano to store my KMD?

wow.. HW wallet ledger nano S supports kmd. I just put my komodos to nano...

tank you for let us know about the issues and i hope for verry  good news in the next days  or weeks. i wait to see what you guys succed at money2020 FinTech event. not a lot of projects are in. this is huge !!!!

We found additional security issues that need to be fixed as well. It's on hold again as we are now on the money2020 FinTech event. The developer responsible for looking into it is here in Copenhagen and very busy in networking with the other people.