Thanks Foxpup, so..

* Use freshly minted coins (hard to get significant quantity from miners)
* Send coins to different accounts you own on each chain (trial and error, could take a few attempts)
* Try trigger different consensus rules (not always possible depending on fork reason)
* Try find a miner who can directly accept new tx (no relay) and place in one chain only. (not many powerful miners to choose from, requires effort from them to build)

Not really any great solutions.. probably the double spend until you have coins in separate accounts sounds best.

Lets say for whatever reason (deliberate or accidental) Bitcoin hardforks into two chains.. I have 10 bitcoins in my wallet, on chain 1 I would like to send those 10 bitcoins to address 12345 and on chain 2 I would like to send those same 10 bitcoins to address 19876..

Assuming both chains have nodes still relaying txs amongst both chains, how do I prevent the first tx from being applied to the 2nd chain accidentally? 

Is there a way to specify to only include this tx if block x hash = <some known hash>?

Any other way to keep the tx on one chain and not the other?

Its a shame, I used DividendRippler back in the day.. back when Ripple was a little more free and open.

Thanks for the service all these years and good luck for your next project

By the way, there is a reward for flying the "Available on the DAppStore" banner on your projects website..

See here:  http://dappcentral.com/dappstore/publish.html

By the way, there is a reward for flying the "Available on the DAppStore" banner on your projects website..

See here:  http://dappcentral.com/dappstore/publish.html

Someone has added support for Nxt tx signing for the Trezor, I tried it and its working pretty well.. You can even use both Bitcoin and Nxt addresses for the same secret key..

https://nxtforum.org/index.php?topic=4550.msg171812#msg171812

Have you guys considered merging his changes into the Trezor codebase?

For those who haven't seen the new DAppStore.. http://dappstore.dappcentral.com

If you want your favourite alt-coin added to the DAppStore then I am offering a service to do it on your behalf. Currently adding a new DApp costs 1000 DSV each, I will cover this cost and accept payment in your chosen alt coin (starting off at $10 USD converted to alt coin)

If alt-coin lead developers want to put their hands up for DSV, I will send them some DSV for no charge so they can manage their own submission and voting.

Note: DAppStore is still Alpha, Its not decentralized yet, only one node, there also be bugs!

Great

So if we had a non Bitcoin based coin like Nxt, Ripple or BitShares, and they implemented some sort of PayOnSecretReveal & SecretReveal API would that be pretty straight forward to implement into Mecury?

Hi mappum, do you plan to add support for interacting with coin daemons instead of relying on inbuilt SPV clients?  This way people could host their own nubits daemon and mecury could just call its APIs? This seems to me a much more scalable solution.

Another UI demo video for those interested.  More IPFS integration.

http://youtu.be/_q4SPNeSfck

Just updated the demo node at http://dappstore.dappcentral.com

Changes include:
* Filtering by DApp tags   e.g. You can filter your DApps by Crowdfunding, or File Sharing etc
* Added pagination to the DApp list and Projects list pages.

With pagination now active it is even more important to vote for your favourite DApps/Projects as the best place to be is on page #1

A brief video demo..

https://www.youtube.com/watch?v=yHj2bwuJYqQ

Hi GenieBTC, its not even available on Desktop yet

Unfortunately no, mobile has not been started just yet.  Once a solid desktop version is out then I can look at building a lite mobile version.. but that is a ways off right now.

Years ago I created a website called bitcoincounsel.com, that was a directory of all Bitcoin related websites/businesses and just like nearly every other bitcoin directory out there I lost motivation in keeping it updated.  So I have created a decentralized DAppStore that not only includes Bitcoin and its related websites/businesses but also caters for the larger DApp ecosystem in general.

Think of this project as a cross between App Stores like Apples AppStore and the Google play store and Coinmarketcap.  It can be used to both advertise your project and provide reviews and rankings on related projects.

The DAppStore introduces a new token called "DAppStore Votes" or DSV, these votes are used for various functions in the DApp, but primarily they are used to cast votes towards projects of interest. Votes when cast are locked and cannot be used, but can easily be unlocked to be transferred or sold.

Its still early alpha quality code right now, although there is a live GUI you can try out here: http://dappstore.dappcentral.com/

It includes not only crypto-currency projects, but other DApps like BitMessage and TOR for example.

I'm aiming to release the full node source code in the next few weeks.  In the meantime, try out the demo GUI, get voting for your favourite DApps

Some feedback..

The auto syncing for each blockchain is not a scalable solution.. the user should be presented with a screen of supported coins and the user selects which coins he wishes to trade.

Each coin chosen should give the user the option to use a pre-existing coin daemon (ipaddress, port) or use the Mecury inbuilt SPV client.

Then you can more easily support coins that arent bitcoin copy/paste clones.

Are you on Java 1.8?  I had to upgrade from 1.7 due to the same error.

Thanks mappum, this is something i've been thinking about for a while now.. Your implementation looks pretty good, I will be supporting this project

I have a question, the cross-chain protocol for Btc and its clones is not straightforward as you have to use nlocktime and multisig transactions etc to facilitate the process.. however what about crypto-coins that already implement a standardized "pay on secret reveal" API that automatically locks coins for a number of blocks and releases the funds on secret reveal??  Would it be hard/easy to include these coins into Mecury?

Coins with "pay on secret reveal" functionality built in would also not be vulnerable to the malleability issue.

Just saw this...

https://bitsharestalk.org/index.php?topic=10132.0

Which public key to you hash as the secret? obviously not one that has been made public I assume?

I agree, we should try match the swapbill method initially.