These are good guidelines so far.

I will not buy any coin that has engaged in one of these manual coin swaps.

This can sometimes prove problematic
As a general rule its perfectly valid, however factoring in various techniques developers may wish to employ on their platforms/networks this may not be possible so maintain multiple nodes/blockchains, Also this can be a cause of cross-broadcast messages if not done correctly.

What about a realtime technique, where the swap process occurs transparently to the end-user.. the funds from the old wallet are sent to a burn address and every X number of minutes a poll can request to swap out funds from a specific burn address and change to the new coin and forwarded over to the end-user who instigated the transaction..

Suggestions on how to partially achieve this can be found below:-
https://github.com/casascius/Bitcoin-Address-Utility

https://casascius.wordpress.com/2013/01/26/bitcoin-address-utility/

for the version prefixes as a reference
http://earlz.net/view/2014/10/22/0340/provably-spendable-altcoin-burn-addresses


This is also covered in what I briefly described above. Its just the second part of that sentence..
Send back all the coins in the first block of the new blockchain

For this to happen you need to have determined several variables OR made several assumptions.

What if the coin supply has changed in the new coin which is to be swapped.. OR even decreased supply??
What if you have conflicts on the blockchain..
What if you cannot scrape all the addresses form the BE/BC??
What if end-users don't wish to swap their coins.. stupid i know but what if?? Therefore will it be mandatory swap or voluntary swap process..
What if the algo has changed in the new coin which is being swapped
What if the coin to be swapped has enabled PoW OR simply disable PoS

I'm trying to say sometimes things are not cut and dry kind of thing.. but again in principle its sound!





* Maintain copies of the older blockchains through multiple channels of distribution.
This costs money.. what if the costs of keeping several nodes running and a BE service is prohibitively expensive on a shoe string budget?
Maybe Multiple channels of distributions could be a simple .CSV file containing past TXID OR a recursive bootstrap.dat file containing TX's upto the cutoff block

*Advanced work can be done to create a custom block explorer that combines both blockchains allowing users to search through both seamlessly as 1 chain.
Yes agreed this is a valid approach. but the question arises. Time/funding/technical ability's.?

The added time it takes to arrange something like this
The costs involved in maintaining a solution like this
Developers inabilities to actually produce a working BE which can harmonize both old/new TX in one seamless data stream, Not every developer is compliant?




To have such a hard stance and cynical view on the methods employed by a development team is to harsh.. I can understand many, many people have been burned in the crypto game. But what about that 1/100 genuine developer/coin project which is attacked (maybe by you) even when trying to do something for the best of intentions/reasons to help its community..

personally I don't not think its fair to tar the same brush as the other malicious developers who use cryptos as a scam with those who try to do good things for crytpos and actually believe in what cryptos stands for. Just because they did not adhere to these guidelines above!

Just a suggestions:-
A retro-active follow up maybe a good course of action..
After the swap has ended then follow up with your questions to see if they comply.
BUT first make sure they know what it is they have to comply with before calling SCAM!!!.
Give them time to fix any problems and then allow them to justify legitimate discrepancy and leave it upto the community to decide.
Maybe compile a table showing swap data maybe create a service around it.
kind of like what CryptoAsian has done for Proof of developer (http://proofofdev.com) except use swap data and award a points system.



Hi compmaster,

Im curious whether you would consider buying a coin which has had a small element of manual coin-swapping activity (10% +/-) applied to the coin AFTER an automated swap which reached about (90% +/-) of the total coin supply.?

Take AERO which swapped over to AM (AeroME) In this particular issue most of the coins were taken offline and burned by the Exchange.. as I said approximitly 90+% of the coin supply.
However there is a small portion of users whom were unable to meet the swap date for various reasons and as such were offered a Manual coinswap which happened after the automated swap process. Even these manual swapped coins were also burned. Reason for the manual step was to ensure the swap reached and penitrated with the maximum covrage.

So by using a combination of both Automated/manual swaps (primarily focused on automated swap) does your comment (above) still stand based on the details specified above?

Like I said I'm just curious and interested to find out if indeed there is a case to made to get some kind of "standard" formed and agreed to community wide. A standard consensus on coin-swaps "good-practices" for all alts?

We also realized that It may not be possible to collect the complete total coin supply due to breakages.
As a example of what i mean by breakage coins lost from missing privkeys or coins sent to incorrect accounts, or just human error, etc, etc

This is why we considered a second *MANUAL* swap offering to allow those who had genuine reasons why then missed the official automated swap phase..


Thanks,

Majika

Lead AeroME Developer

These are good guidelines. I will try it. Thanks.

is there any example of a backwards compatable swap yet???

I've been in two swap in my crypto life, BT -> BTX and yesterday with DRZ

Congratulations on possibly the very first transparent and automatic coin swap.

@mrbodz aka Ahmed

We've decided to reboot GiveCoin 2.0 as a completely new chain, including changing the address type to support vanity "Give***" style addresses.

The primary motivator however was that we determined that some POS coinbases and wallets have "backdoor keys" in them that allow the developers to essentially do unlimited staking!

More details about our design and value proposition can be found in the whitepaper:

http://bit.ly/2GiveCoin

The pos code is horrible ypu should steer far away from it..

I hope you don't force every address to use vanity otherwise the entire network loses massive entropy.. sounds like you are going to use POS still... gluck with that... POS is slowly becoming dying codebase.