A bit too late I am afraid.

Any new hard fork is chosen by the miners, so how exactly is there a path from a miner determined process to one that isnt?

I am not debating what is better, just about the reality of the math. It is usually best to not fight against the math.

Maybe you can trick them to adopt something that appears neutral or even in their favor, but it isnt but highly doubtful they will miss that. One possibility is a tradeoff of giving miners even more in the short term, in exchange for less influence after this bakshish period

James

My reference implementation will be based on iguana. asset holders want the security of BTC, but it is too slow. So using BTCD for trading at one minute blocks and BTC for long term parking/coldstorage is the logical setup.

I like to use logical setups.

Since iguana is already talking to both BTC and BTCD at the same time, this requires more work, but PAX already needed AE type of functionality, so now I just need to extend that codebase to allow using NXT assets and NXT accounts directly.

Will be a bit getting used to for having an asset on different blockchains, but really it is like having deposits at different central exchanges. With a nice GUI to track it, shouldnt be a problem and this fits exactly into one of the InstantDEX GUI's: https://instantdex-gui-avidayal91.c9users.io/#/coin_exchange

It is work in progress and not always running, but if you see it you can get the idea of the "easyDEX" that is oriented toward the casual trader and not the advanced technical analysis charts

James

For those not following NXT, I have been divorced from NXT.

https://nxtforum.org/core-development-discussion/nxt-2-0-design/msg210601/#msg210601

The above is my last post in the NXT forum, unless the fNXT plan is revoked. fNXT is not NXT and NXT lifetime is limited, so we will need to migrate the NXT assets to a different blockchain.

Now before you panic, I like to make lemonade out of lemons, so like BC2 led to iguana, fNXT has led to: https://bitcointalk.org/index.php?topic=1372879

A passport system for assets that allows the asset holder to decide the blockchain they want to reside in. While the PoS mechanism is fully protecting the NXT holders as designed, it allows the creation of a hardfork that ignores other parts of the ecosystem, like assets.

This is a problem for any derivative. The core PoS or PoW or PoAnything will only protect the interests of the stakeholders, miners or whatever, that the block consensus algorithm uses. As such the hardfork attack vector is a very real and actual in the case of fNXT hardfork.

So while the PoS ensures that the NXT holders (including SuperNET) will vote for the fNXT hardfork out of their fiduciary duty to maximize revenues, there are no protections for asset holders or issuers. In some sense the PoS worked too well, instead of not well enough and it needs to be weakened.

Does this mean decentralized assets are dead?
Not at all!

This attack vector directly led me to create a solution, namely blockchain independent assets that is blockchain enforced. It does require all participating blockchains to implement an asset passport protocol, but the ones that do will allow for free travel among them.

blockchains with iron curtains that dont allow anybody to come in, still wont be able to prevent assets from leaving as long as there is a burn mechanism. So far all blockchains I have seen have either a direct burn method, or one can be devised.

That means that any blockchain that doesnt support asset immigration, is subject to a oneway outflow to ones that do. This is basically the SuperNET concept applied to assets and iguana tech will build into BTCD the ability to trade against BTC using BTCD's one minute block times but to be able to coldstore idle assets in the BTC blockchain. Even if they are in cold storage, it just means that they cannot be traded and all the dividends they earn will still go to your account.

How does this protect assets from the hardfork attack?
Simple. If an upcoming hardfork threatens your interests, just move to a different blockchain.

Even if a blockchain just increases taxes (txfees) and you want a lower cost blockchain, you can move.

If a blockchain just is slow to create useful tech, you can move to one that does.

By distributing an asset across multiple decentralized (or even distributed) blockchains appears to be the best protection available to derived crypto. The alternative is a new blockchain for each asset using itself as its PoS with blocks generated only when there is a transaction. Private chains are coming, but this seems excessive use of the blockchain "hammer" from the toolkit. And it creates a massive N*N problem of cross chain transactions for all such assetchains.

With asset passports, you just reside your assets where you are most actively using the local blockchain and since trading against the native currency of the blockchain is most efficient (it better be!) you will be able to take advantage of this affinity. But if ever some storm clouds appear, you can simply move to a safer blockchain.

BTC is here to stay. Certainly as the reference currency, but even the tech development pace is starting to accelerate, so this is encouraging for all of crypto. iguana is achieving less than an hour BTC blockchain sync for full 60 GB blockchain, so the problem I used to think was so big a problem is not so big anymore. bitcoin 0.12 supports pruning, so HDD space is also going to be an issue not so important. Most importantly, I will be able to run a bitcoind node on my laptop!

So why not everything BTC? Well if you ever are waiting for a trade to go through, you know that waiting even a minute is a long time. Try waiting 10 minutes. Just not a good experience. So I will make a hybrid system combining the speed of BTCD 1 minute blocks with BTC for long term storage. Trading against BTC should really be a requirement, but not sure if all passport enable blockchains will be able to do this, so it would probably need to be a strong recommendation.

iguana unites all the bitcoin compatibles using technology. It is inching toward completion and we even have a freelancer based GUI dev team now, using fully open source development.

docs.supernet.org shows the API and in spite of the external events that keep happening to cause delays, we still march on. This is a marathon and we will complete it.

James

P.S. Before any NXT holder panics, do not worry, NXT peoples are doing everything they can, literally, to make sure NXT goes up, so it seems pretty likely that NXT price will do just fine. I just have some ideological and technical disagreements and since I have no actual power within NXT, I was forced to move.

If only someone can setup an automatic posting from #iguana archive to here.
I post kilobytes per day of text, everyday. I just dont have the time to be manually cross posting. I will if people insist, but would you rather have me spending time cutting and pasting my posts or coding?

and actually when I was more active, many many people complained about it.

Too much info, they complained.

If you want to follow my progress and cannot understand the github.com/jl777/SuperNET's activity, then #iguana in SuperNET slack is where I am.

I dont tend to do things that other people are capable to do. It is because I can only work 16hours per day this year

James

For those not following NXT, I have been divorced from NXT.

https://nxtforum.org/core-development-discussion/nxt-2-0-design/msg210601/#msg210601

The above is my last post in the NXT forum, unless the fNXT plan is revoked. fNXT is not NXT and NXT lifetime is limited, so we will need to migrate the NXT assets to a different blockchain.

Now before you panic, I like to make lemonade out of lemons, so like BC2 led to iguana, fNXT has led to: https://bitcointalk.org/index.php?topic=1372879

A passport system for assets that allows the asset holder to decide the blockchain they want to reside in. While the PoS mechanism is fully protecting the NXT holders as designed, it allows the creation of a hardfork that ignores other parts of the ecosystem, like assets.

This is a problem for any derivative. The core PoS or PoW or PoAnything will only protect the interests of the stakeholders, miners or whatever, that the block consensus algorithm uses. As such the hardfork attack vector is a very real and actual in the case of fNXT hardfork.

So while the PoS ensures that the NXT holders (including SuperNET) will vote for the fNXT hardfork out of their fiduciary duty to maximize revenues, there are no protections for asset holders or issuers. In some sense the PoS worked too well, instead of not well enough and it needs to be weakened.

Does this mean decentralized assets are dead?
Not at all!

This attack vector directly led me to create a solution, namely blockchain independent assets that is blockchain enforced. It does require all participating blockchains to implement an asset passport protocol, but the ones that do will allow for free travel among them.

blockchains with iron curtains that dont allow anybody to come in, still wont be able to prevent assets from leaving as long as there is a burn mechanism. So far all blockchains I have seen have either a direct burn method, or one can be devised.

That means that any blockchain that doesnt support asset immigration, is subject to a oneway outflow to ones that do. This is basically the SuperNET concept applied to assets and iguana tech will build into BTCD the ability to trade against BTC using BTCD's one minute block times but to be able to coldstore idle assets in the BTC blockchain. Even if they are in cold storage, it just means that they cannot be traded and all the dividends they earn will still go to your account.

How does this protect assets from the hardfork attack?
Simple. If an upcoming hardfork threatens your interests, just move to a different blockchain.

Even if a blockchain just increases taxes (txfees) and you want a lower cost blockchain, you can move.

If a blockchain just is slow to create useful tech, you can move to one that does.

By distributing an asset across multiple decentralized (or even distributed) blockchains appears to be the best protection available to derived crypto. The alternative is a new blockchain for each asset using itself as its PoS with blocks generated only when there is a transaction. Private chains are coming, but this seems excessive use of the blockchain "hammer" from the toolkit. And it creates a massive N*N problem of cross chain transactions for all such assetchains.

With asset passports, you just reside your assets where you are most actively using the local blockchain and since trading against the native currency of the blockchain is most efficient (it better be!) you will be able to take advantage of this affinity. But if ever some storm clouds appear, you can simply move to a safer blockchain.

BTC is here to stay. Certainly as the reference currency, but even the tech development pace is starting to accelerate, so this is encouraging for all of crypto. iguana is achieving less than an hour BTC blockchain sync for full 60 GB blockchain, so the problem I used to think was so big a problem is not so big anymore. bitcoin 0.12 supports pruning, so HDD space is also going to be an issue not so important. Most importantly, I will be able to run a bitcoind node on my laptop!

So why not everything BTC? Well if you ever are waiting for a trade to go through, you know that waiting even a minute is a long time. Try waiting 10 minutes. Just not a good experience. So I will make a hybrid system combining the speed of BTCD 1 minute blocks with BTC for long term storage. Trading against BTC should really be a requirement, but not sure if all passport enable blockchains will be able to do this, so it would probably need to be a strong recommendation.

iguana unites all the bitcoin compatibles using technology. It is inching toward completion and we even have a freelancer based GUI dev team now, using fully open source development.

docs.supernet.org shows the API and in spite of the external events that keep happening to cause delays, we still march on. This is a marathon and we will complete it.

James

P.S. Before any NXT holder panics, do not worry, NXT peoples are doing everything they can, literally, to make sure NXT goes up, so it seems pretty likely that NXT price will do just fine. I just have some ideological and technical disagreements and since I have no actual power within NXT, I was forced to move.

You speak of blasphemy.

To contaminate the separation of mining and owning BTC is violation of the sacred PoW commandments

You will be called a PoS zealot if to require BTC. Next thing you know you would want it based on some sort of PoS basis. Only miners are supposed to have any powers to decide.

Why not require some special PoW calculations that cost 21BTC? That way the miners who keep selling all their BTC will still have the total power to decide everything

James

they thought we were slaves and had no choice. Dont they realize who I am?

James

Of course, things have always been setup with bid/ask spreads, but I was thinking of some sort of automated compensator for the slippage attack.

Otherwise, the burden of estimating the black-scholes value being granted falls on the user. I guess I could just have a standard spread factor that is added, but it is variable depending primarily on the other party to the trade.

It seems that the fully precise system will need realtime monitoring of past behavior, tracked by fees paid, number of transactions, volumes of transactions, number of "disconnects", etc.

But all this would be a layer on top of the atomic swap, so I dont think I need to worry about it for now. Maybe someone will want to help coding the insurance tracking aspect of this.

James

The cut and choose attack is very cash negative. The papercut attack appears to be the biggest attack vector now.

I think just making InstantDEX a TTP (trusted third party) with full discretion as to the disposition of fees will solve this. Granted it requires trusting that I wont abuse the DE users, myself, but we are talking about the fee here not the trading capital. If this really is an issue that people wont trust that I wont papercut attack the DE users, then we would need some other method.

Since you already have a solution, I could just use that too.

Does this mean there are no attacks left?

James

These are onetime throwaway private keys and the output is hardwired to Bob's address, so if anybody else does the spend it pays to Bob anyway.

There is no way to know for sure that the hash of the privkey was provided until it works when it is revealed. That is why the fee is required, so that any attack by cheating has a negative expected return.

I changed to 2000 keypairs, so with a 1/777 fee, the expected return is a loss of about 20%. This presupposes there are anywhere near 2000 trades that can be done. Since newbie accounts will only be traded with reluctantly, it will take time to build up an account with 1000+ trades.

And what is achieved? You have lost 1000+ fees, you steal from who you traded with (worth 777 fees), still you lost 200+ fees. The account you built up is blacklisted and the victim is compensated from the fees that have been paid by the attacker. Any balance is forfeited. So any cut and choose attacker will be helping the InstantDEX bank account and the victim would just need to wait a bit extra before being reimbursed. No financial harm to the victim, financial gain to InstantDEX, financial loss to the attacker.

Another point. The 2000 keypairs acts as PoW. It takes several seconds to calculate them all, so you would need one CPU core per attack. Its not like you can simply notify 2000 other peers that you want to start a trade. The initiator has to calculate all the keypairs upfront.

Only if a node decides to accept this incoming offer, will the similar calcs need to be done on the receiving side. Due to the time it takes, probably need to put in some checks for the desirability of the initiating side, but that is for later.

I have a strong feeling that losing 20% will be a pretty strong deterrent, in fact I am hoping we will get a bunch of idealogical cut and choose attackers who want to disrupt the DE without regard to losing money. I can then use those funds to pay for bots that will be making bids, just waiting to be cheated on. In fact, this could create a massive positive feedback loop and the net result is that the DE is unusable by people, but the bots make the attacker pay thousands of BTC in fees, forever.

Not a great result, but I think I can live with that.

James

A tweak to the PoW that takes into account the total tx in a block would achieve this. Since the total fees are being ignored. Just add the txn_count to the PoW weight, since most of the competing blocks will have the same PoW weight, any small increase will win.

But now that can be attacked by a miner including a bunch of 1 satoshi tx, just to win the block and bloating the chain... And since it is hard to tell whether a tx is "real" or not, if the miner is willing to ignore the extra fees (that is what they are supposed to want more of), there really isnt much that can be done to force them to include transactions

James

The fundamental issue about anything like this is that if you can understand all that you can make a windfall, at the cost of some poor small business that didnt

It seems no way to force everybody to run the latest software at the same moment, especially high volume places that might not want to shutdown until the slow time of day (or week)

So any solution needs to take into account that pre-hardfork and post-hardfork versions are running and that there will be bots written by guys that understand the above trying to find the laggards who still honor the invalid utxo

That is why a total shutdown seems to be required to get past not only the +/- 2 hours (4 hours worst case) timestamp tolerance, but migration time.

It could be like Hardfork Saturday GMT (that is the only day of the week that is a weekend all over the world).

It should be really easy to get all 6000+ nodes to coordinate the shutdown and update at the same time.

James

I mean in the discussion and setting of standard. The coloredcoins.org spec is a pretty good place to start, but it doesnt handle multiple chains.

And a blockchain would need to implement importing, so if they dont do that, they are prevented from joining. If this standard is closed and secret, then any chain not in the inner circle would have been prevented.

James

Not limited to N of 16.

a lot shamir's secret implementations can handle M of 256 as it uses a 2^8 field

but the shnorr's can handle arbitrary number of M of N. Not sure if it is practical but you could setup a M = 500,001 of N =1,000,000 to get a majority of 1 million accounts.

I wouldnt recommend it as it will probably blow up somewhere, but the current multisig implementation is not using fancy crypto, just a brute force list of pubkeys, so all the N pubkeys need to go in the blockchain. Current limit is 15 or 16 using compressed pubkeys. For older altcoins N = 3 is the most due to strict limits on script sizes

James

P.S. Another reason for more security is that by disclosing the pubkey msig addresses are not cold as the pubkey is known. However, short of using bad RNG, I wouldnt worry too much about revealing pubkeys until QC's become more widespread

Pretty sure it would take a hardfork, but it would change the emission rate unless we adjusted the block reward at the same time. The code changes would be minimal.

Actually, that would solve the blocksize problem!

Just go to 5 minute blocktimes with half the block reward. Even with 1MB blocksize we get 1MB per 10 minutes so it matches the 2MB blocksize increase.

At 5 minutes I dont think we would get too many of the small reorgs. If to go to 1 min, we get 10MB per 10 min capacity, but at that frequency there would be a fair number of reorgs. I dont think going below 3 minutes is wise.

It was your idea, so you can submit the 5 min blocktime BIP

James

My understanding is that it is like shamir's shared secret for getting MofN

Without M valid sets of data, it is garbage with M to N valid data, you can recreate the original.

Taking this concept further, add some crypto magic and we get:

 secp256k1_schnorr_partial_sign() from the zkp lib:
* The intended procedure for creating a multiparty signature is:
 * - Each signer S with private key x and public key Q runs
 *   secp256k1_schnorr_generate_nonce_pair to produce a pair (k,R) of
 *   private/public nonces.
 * - All signers communicate their public nonces to each other (revealing your
 *   private nonce can lead to discovery of your private key, so it should be
 *   considered secret).
 * - All signers combine all the public nonces they received (excluding their
 *   own) using secp256k1_ec_pubkey_combine to obtain an
 *   Rall = sum(R[0..i-1,i+1..n]).
 * - All signers produce a partial signature using
 *   secp256k1_schnorr_partial_sign, passing in their own private key x,
 *   their own private nonce k, and the sum of the others' public nonces
 *   Rall.
 * - All signers communicate their partial signatures to each other.
 * - Someone combines all partial signatures using
 *   secp256k1_schnorr_partial_combine, to obtain a full signature.
 * - The resulting signature is validatable using secp256k1_schnorr_verify, with
 *   public key equal to the result of secp256k1_ec_pubkey_combine of the
 *   signers' public keys (sum(Q[0..n])).
 *
 *  Note that secp256k1_schnorr_partial_combine and secp256k1_ec_pubkey_combine
 *  function take their arguments in any order, and it is possible to
 *  pre-combine several inputs already with one call, and add more inputs later
 *  by calling the function again (they are commutative and associative).


Not sure if false data will prevent reconstruction, if so, then M choose n (where n is the total received and it must be between M and n) possibilities would need to be reconstructed to get a valid result. So depending on the attacker ratio, processing power available, practical limits of the M and N values that can be used will be limited

James

Atomic Cross chain https://bitcointalk.org/index.php?topic=1364951.0 is not easy, but possible. Additionally side chains shows another method for cross chain.

The key is to make sure that at the high level all the current and likely future blockchains can provide the required import function. Ideally into the native asset type, but some coins like Bitcoin and all its forks, of course dont have any intrinsic assets. but with OP_RETURN data or colored coins, even for blockchains without native asset support can support assets.

I think "simple" things like asset id preservation/mapping and support of a meta-assetid is probably the trickiest issue. Once we have a way to have a universal assetid, then it becomes possible for each blockchain to track it and transfer it and trade it.

It is a bit space intensive, but one way is to combine the issuers pubkey with the assetid it was originally created on. This will typically be between 256 bits to 512 bits. One way to make it more convenient is to map that to an rmd160 hash like bitcoin, which then gets us to 160 bits, or 20 bytes per address. That also allows creating bitcoin-style address out of the universal assetid. To avoid confusion with bitcoin addresses, the address type shouldnt be 0 or 5, best to use a unique address type, maybe 0xff which I havent seen used in any coin yet, but I have seen all of them so it might still conflict.

James

Sorry, too busy to deal with anything but technical issues.
This is purely an interop standards effort. All participating blockchains benefit from the network effect.

The user centric goals, means that users that are most comfortable on blockhain X, just stay there. Trades against the host currency will be the most efficient, so for most of the people most of the time nothing changes.

However, if something makes a different blockchain more attractive for that specific user, he would be able to migrate some or all of his assets there. This sets up the different blockchains to compete for residency of the assets and since the asset total is blockchain(s) enforced, short of a blockchain totally stopping, the asset value is protected. Even in that case, we could probably have some provisions for snapshot resurrections.

Due to essentially side chain type of issues, the transfers will necessarily take many confirmations, but like moving your own place of residence, it is not something that is done very often, if at all.

Also, for a blockchain that is afraid of losing their assets and thus not wanting to participate, there will need to be methods created for a onetime exit from that chain. However that is a oneway move (until that blockchain supports importing external assets), so not one to be made lightly.

From what I can tell, all existing decentralized asset systems support exporting already, not specifically as such, but if an asset can be burned, it can be exported using a burn protocol

This appears to be a form of meta-decentralization, where the decentralized assets can be spread across multiple blockchains, yet retain their fixed supply. While the relatively small number of host blockchains makes it more like a distributed model, since each blockchain is decentralized (we hope!) maybe that property infused into the distributed aspect.

Regardless of its exact taxonomy in this space, what is clear is that having a passport to travel is much better than not having one.

James

I think you would need at least a 4 hour gap to avoid the +/-2 hour leeway on timestamps and additionally some other method to avoid double spending based on using tainted inputs.

Actually it wont be double spending if to use a tainted input as it is following the protocol for both forks.

In essence having two versions after a hardfork doubles the coin supply. Kind of a little violation of the 21 million coin promise.

But if the ripple way is acceptable, then push forward for this

James

See: https://bitcointalk.org/index.php?topic=1157679.0

just changing the magic number is not enough, that only affects the network protocol.
Which means if all other parameters are the same, just rebroadcasting on the other network and it is accepted (assuming it is valid in other ways)

James