Yes, let us not count that MGW is finished for over a year, lite wallet almost a year, and most of docs.supernet.org has working API. Of course, a project without a GUI cannot possibly have any value as all that matters are the pretty graphics visible on the screen and not the underlying core tech.

Anyway, scheduling issues are not what is at issuer for an interop standard.

All crypto is dependent financially on BTC, with the possible exception of ETH. I dont think many crypto projects would mind inheriting some of the BTC security. Might was well utilize all the electricity being used for BTC for all the cryptos.

If you dont want your coin to depend on BTC, that is fine. People will decide if a project that adds some BTC secured backstops is more secure than similar ones without. Let the market decide

James

That is a commitment, but no way to verify until after the file is received.

Who sends first? the BTC or the mp3? Either way, your method requires trusting the other party.

That is why ZKP is a significant breakthrough, just at the impractical "only for lab" stage. Just need to identify the 100 largest data markets that have verifiable deliverables and code up the 100 verifiers.

The next step is to identify the top such markets. Maybe its just me, but I dont see a large market for solutions to simple games, when you can run computers to do bruteforce searches for most all games. Seems the big markets for this would be when there are cryptographically verifiable deliverables tied to real world things, like deed and titles.

Then you can do an official closing for a real estate deal without any escrow company in the middle taking the percents, and neither side at risk of non-delivery. As I said before, this is "hello world", but from that everything can be built

James

Some practical estimates:

Most top 100 bitcoin compatible altcoins trade a total of $1000 to $25000 per day, some get a lot more volume but usually it is due to CNY trading. The second 100 ranked trade $5000 or less as a guideline.

The CE risk is that 100% of all funds for all coins and in this aspect, even if it the only aspect, makes the DE much safer to trade. http://www.coindesk.com/court-cryptsy-ceo-predicted-exchange-failure/ vs blockchains to see where all the funds are. just the open disclosure would make DE superior, even if DE had all the same risks as CE. But I argue that DE risk is dramatically less due to the fragmenting of the funds across all coins. Also, the attacker is only able to make money by selling altcoins for BTC en masse to a lot of buyers which is quite a bit harder than the reverse

Let us say an exchange DE or CE gets 10% of the trading market and roughly $100,000 per day is traded. This would translate to a lot more on deposit, hard to estimate what percentage of trades are vs amount on deposit, if it is 10:1, then that means $1 million is at risk at this CE, all the time, from reorg attacks like DE and many other attacks and internal theft and simply flight of owner.

Now the DE, let us assume 100% of a coin is at risk, it is $2500 in this context. But actually it would be just the trades that are pending and if average trades complete in one hour or so, it might be $100.

With a budget of $100 or even $2500, I am having a hard time seeing that it would be a cash positive expectation if the process isnt fully automated. Even with a fully automated system, the cost to rent hashrate varies in realtime based on supply/demand and it is not like you can buy arbitrary amounts at a fixed cost.

My feeling is that like the cut and choose itself, it is all about positive expected return from conducting the attack and opportunity cost. Unless attacking the DE offers positive expected ROI, it is the same thing as saying someone can attack cut and choose and continue to lose money.

Can you estimate the hashrate it would take to attack some middlemarket coin,or rather, what coin could be attacked with a $2500 budget? Wouldnt the attacker need to pregenerate the blocks ahead of time? if so, there is a very big risk of not being able to make the trades to take advantage of this alternate chain. or can he wait until he has all the trades pending, then buy the hashrate, hope he is able to build a stronger attackchain with his double spends, then complete all the swaps, push the attack chain to reverse the altcoin payments.

Now he gets back the altcoins used for the trade, which had to be of equal value to the BTC gained, so he is stuck with altcoins for a chain that got attacked. maybe that will cause it to lose value and add more risk.

There seem to be quite a few "ifs" that all have to work out and the reward is 5BTC, not any 5000 BTC. So this seems an attack scenario for the financially challenged attacker, unless I am dramatically overestimating the cost to conduct the attack.

James

What is the method of attack if peers limit the amount of trades to the total fees paid by an address? other than some small amount for newbie accounts.

Wouldnt that require the attacker to conduct all attacks simultaneously using properly aged UTXO? Or are we assuming arbitrary depth of reorging the altcoin is available to attacker to deploy at anytime? Since the attacker wouldnt get the BTC until the trades complete, it seems he would have to borrow the BTC to buy the hashrate. And if an altcoin can be rewritten at will with the attacker's existing resources, what secures that chain without atomic swaps?

I guess the probability of successful attack creates some expected value, but I am having a hard time correlating the hashcosts for coins with decent trading volumes and the likely number of open trades at any given time. If the success of attack is not 100%, then that raises the risk of lost capital. I think realistic cost estimates are needed to attack the various chains and compare it to trading volume and amount of time that would be at risk

James

The above just solves half the problem, the common externally verifiable time reference.

The other half is being discussed in #passport in supernet slack, the goals are making each asset have its own PoS chain where it uses itself to protect itself. So no more hardfork attacks and each asset chain is not dependent on any other chain, other than BTC for the common clock and backstop security.

since each asset chain is technically independent, there is literally no limit to the number of them that are possible

[3:49]
no single chain is having to authenticate all chains

[3:49]
no single chain is having to store all the tx for all chains

[3:49]
no single chain has to deal with the bandwidth for all chains

[3:49]
asset immigration/emigration events need to go somewhere, BTCD is logical place

[3:50]
some sort of assetchain defined storing of summary hashes need to go somewhere, BTCD for higher frequency, BTC for lower frequency

[3:51]
from a practical point, each asset can do tx denominated in itself and if desired "zero cost" txfee can be used

[3:52]
before you start saying, "spam attack, spam attack, what about the spam attack"

[3:52]
I say that PoW nonces can be required for even submitting to the network, for a non-attacker it is a second of computation, which wont be a big deal

[3:53]
for the attacker, its a second of computation per spam. doesnt sound like much, but 3600 packets per hour is not much of a spam attack.

[3:55]
each asset chain can decide how far back it wants to store data, but using ramchain tech, the BTC blockchain now is about 15GB and it syncs at bandwidth speed, so the reason blockchain bloat has been such an issue is because iguana didnt exist to make things 100x to 1000x faster

[3:56]
If anybody likes proof about the disconnect between cmc marketcaps and tech, rimbit is almost trading at the combined BTCD + SuperNET marketcap

jl777 [4:07 AM]
It seems pretty clear to me that anything that solves the crypto scalability problem as the above will do, will generate significant value. But do not worry about any new IPO to raise thousands of BTC, there wont be, especially as there is no need to. Daily latte's just dont cost that much

jl777 [4:15 AM]
If you are trying to read the tea leaves to find the best place to invest to benefit from this, the best place is in the assets as it changes them from being a total slave to full master of their own destiny, with the future evolution only limited by what new tech can be created. I was serious when I said I would use the crypto777 asset as a way for people to get customized features for their asset chain. There would be some period of exclusivity, but after a few months, then the other asset chains would be able to use it too. But realistically it will take a bit of time for a chain to adopt new tech and probably most will be watching things to make sure it works. So I would estimate 3 to 6 months of practical exclusivity. Not much, but being the first can never be taken away, so we will end up with assets that are the leaders and the ones that are followers as far as their asset chain functions go.

SuperNET nodes will likely be needed to add strength to many asset chains, in addition to the indirect benefit that SuperNET owned assets are using asset chains, there will likely be some asset txfees earned by SuperNET nodes, but this would be more up to the free market to determine

BTCD would benefit from its DCH (decentralized clearing house) role and being the likely conduit to the BTC atomic function, at least as first. I cant say the exact details of what BTCD will do, just that if any bitcoin protocol chain with a 1 minute time is the right tech solution, BTCD will be utilized.

But the big win will be the entire SuperNET ecosystem, as any diaspora of asset chains would bring a lot of new users and issuers into the iguana based universe of browser based crypto systems.

or you could bet on rimbit continuing its march toward replacing bitcoin itself

James

In order for independent chains to securely trade with each other, all chains must be secure. The problem with smaller coins and any asset specific chain is it security. The following is the first half of the solution that enables weaker chains to inherit some of BTC's security.


From Satoshi's paper:

3. Timestamp Server
The solution we propose begins with a timestamp server. A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post [2-5]. The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.

###

It is the timestamp server that enables the rest of bitcoin to work and without a timestamp server, it appears trivial to double spend as there wont be a way to know the balance of an account at any given time. Regardless of whether a timestamp server alone is sufficient, it is clearly necessary.

We will ignore all issues regarding PoW vs PoS vs PoAnything and concentrate on creating a universal timestamp, or rather a time sequence server via bitcoin. The effect of having a universal clock is that synchronized operations can be done across all other blockchains who adopt the bitcoin time sequence server.

A. In the beginning there was no bitcoin and until genesis block it was not possible to be utilized in any way. However, now that it exists and is clearly "real", we have enormous amounts of hashrate securing the steady stream of bitcoin blocks. Due to the way the consensus works, there is a chance that the current block is superceded by a "better" block and even the most recent 2 blocks, or 3, or ... However, the chances rapidly diminish to an extremely remote possibility. The exact number of confirmations that is considered safe from reorg is certainly a critical decision, but it does not affect the proof of time stamp serverness.

Let us call this depth L, for lag. It will be assumed that any bitcoin blocks with L or more confirmations are permanent. For practical applications, it is suggested to have a mechanism to detect and recalibrate in the rare case of a bitcoin reorg beyond L blocks, but if the probability of such an event is remote enough, other means of compensating for it are also possible, ie insurance type methods of risk sharing.

B. Given the assumption that any blocks with L confirmations are valid, at any given time there is a "current" permanent BTC block, with its blockhash. And most times a new block is generated, we get a new permanent BTC block. However, when there is a small reorg or a replacement of the tip, we do not get a new permanent BTC block. A simple way to calculate whether a new BTC block advances the permanet BTC block is to verify that it is L+1 confirmations from the previous permanent block.

What this means is that as bitcoin does its small reorgs, the permanent blocks will not advance until things catch up. However since most reorgs are caused by a new pair of blocks that extend the chain and bypassing the current tip, this stop/starting of the permanent blocks are mostly insulated. This stop and go behavior combined with the +/- 2 hours tolerance on timestamps makes the BTS not a timestamp server, but a time sequence server. It is not as useful, but still a framework that can be built upon.

We now have a sequence of permanent blocks Ti, Ti+1, Ti+2, ... with the proven characteristic that each Ti came after the preceding one, ie. an ordering of blockhashes. Another small concession that will be made is that we will assume that SHA256 collisions can be ignored, bitcoin now does not allow duplicate blockhashes, so even if there is a collision it will probably not affect things, but the odds of such are so small, it will simplify the analysis to ignore its effects.

C. What can be done with the set of permanent blockhashes? They can be used by any external blockchain or in fact anything as proof of time sequence. Using the law of common sense and assuming the ban on time travel is still in effect, we can see that to be able to know a specific blockhash Ti indicates it must have happened after that blockhash appeared. Since Ti first appeared in the mining node even before it was submitted, it could have been known right after blockhash Ti-1 appeared. Yes, this will be a very slow clock indeed, but a clock nonetheless.

Being able to refer to a permanent blockhash Ti shows that it happened after L+1 confirmations ago. What this means is that regardless of whether this hash Ti is put into the altcoin's chain via consensus or by attacker, all blocks after it are shown to have happened after the earliest time that Ti was known.

Let us assume that the permanent blockhash sequence is either fully or partially referred to in the external chain. This gives us a partial ordering of all the external chain blocks as having happened no sooner than when Ti was known. If the protocol gives more weight to referals to the oldest Ti, then an eventual consensus will arise with external chain blocks grouped into segments such that each segment is known to have happened after the blocks in the prior segment. By having a block rejection rule to reject blocks too far from the past, if this "too far" is set to be a fraction of the times between Ti, then we get a provable time ordering if there is 1 or more Ti between two external chain segments and a likely time ordering for adjacent segments.

D. Now each external chain is divided into universally verifiable groups of blocks, that regardless of the strength of the consensus mechanism for that external chain (even if it has none!), it is able to conduct cross chain transactions with other external chains using the same segmentation. Well, not quite. Of course if the external chain is some arbitrary ledger that can be updated at will by some corporate entity, then these security assumptions do not hold up. What is required is another rule in the external chain that after R permanent Ti blocks have passed, that it is permanent. This R (for reorg) factor will then allow other external chains to know that after R permanent blocks it cannot change and also the partial time sequence is externally verifiable.

E. This is just a first draft and many improvements are possible. For instance, by using blocks very close to the current, the external chain can create a lot finer grain ordering internally, unless bitcoin reorgs the referred blocks away.

F. tl:dr it wont be fast, but using bitcoin as the universal clock, all external chains that add a few consensus rules can interact as long as enough bitcoin confirmations are waited.

G. Appendix: put fancy math that almost nobody understands here

The passport systems requires that any blockchain that wants to participate would be able to. It is an interop standard. I am working on a method that will allow weaker chains to utilize BTC for security. Not for all tx, but for a backstop past which all the tx in that chain would become permanent

But in all the scenarios, iguana must be fully working first, so for now I will be slogging through all the bitcoin rpc and make sure they are working.well almost all, there are a few RPC that are not relevant in iguana's context.

James

A trustless sudoku solutions market can now be created.

For each class of problem, there needs to be a custom verifier and also a defined format for the proposed solutions, so the custom verifiers will know how exactly to verify it.

At the abstract level, it is very cool
At the practical level, it is just the "hello world"

Now we just need dozens of verifiers for the top dozens of information markets that can be automatically verified.

Maybe it is possible to verify the chemical properties of complex molecules with a simulator. If so, then that simulator combined with specific required properties to evaluate true/false and you would have a trustless way to get a copy of the chemical formula with said properties. But not sure if thre is a way to detect something is a "cure for cancer" via simulation.

Keep in mind, you only get a copy as there is no known way (to me) to prove that you have destroyed all copies. Still in spite of the practical issues, it is the first atomic trade of bitcoin for information that I know of.

James

It is "standard" ZKP, code is at https://github.com/zcash/pay-to-sudoku

without all the math, the idea is that there is a program, which is converted to a circuit which can be implemented out of crypto operations so what you end up with is a blackbox that outputs true or false

no information leaks outside the blackbox, other than true or false

so all you need is a validation program for each class of data being exchanged that can evaluate the solution and determine if it works or not.

triggering a bitcoin payment based on the true or false output and we get the announced sudoku result.

James

the profile based optimizations can lead to giant wins, especially if the compiler chose the wrong default.

to get double digit gains, you would need to find ways to take full advantage of vectorizing and we rapidly get CPU specific. and usually required refactoring an algorithm to simd model, which could easily make things slower depending on the exact algo.

if you are willing go that far, then nothing beats hand tuned assembler using whatever is best for each line of code. kind of an extreme analogy to using different compilers for different portions of the project

If you are using beyond -O2, probably a good idea to only to it for the purely algorithmic files and not the networking or other system oriented ones. There isnt that much time spent there anyway and the risk of over aggressive compiler optimizations changing the behavior enough to become incompatible just doesnt seem worth it.

James

It allows transactions that cant be spent yet to be confirmed

Without this assurance, to rely on an offchain signed tx, even if all is valid, leaves you at the mercy of txid malleability.

Of course, depending on whether the spend script is a conditional or not, factors like who controls the spending in the non-timelock case, is it a multisig that is funded and other factors need to be carefully designed

James

correct, i need a new keyboard!

you cant be sure that it is still a valid input without knowing all prior tx.

That would be a separate thing.

From what I can tell, this method allows to exchange bitcoins for any digital info that you can write a custom verifier for. As such, it would be possible to trade solutions to verifiable problems without disclosing the solution to the other party, so it is indeed quite a feat.

Now we just need a zillion different verifiers. Unfortunately I dont see how to make verifiers for most classes of things, especially anything with any subjective aspects. How could an mp3 recording be verified to be what it is supposed to be? You couldnt code the verifier to compare signals, well you could but if you could and already have the signal, then why would you pay for another copy?

However within the scope of verifiable things, ie crypto payments, validity of privkey, etc. it appears to be quite useful and would solve some otherwise sticky wickets.

James

Thanks. very useful info. I am assuming default uses -O2?

I have found that in rare cases, -O3 and others beyond -O2 change behavior of some types of code. Not sure what class of code is broken as I didnt have time to isolate it, especially when -O2 results are so close to the best times.

I think there is some very aggressive control flow optimizations with some optimization modes that might change the time sequence of some side effects in the code sequence. I think it might have been networking code that was affected, so pure algorithmic code without any external side effects should be fine with whatever valid optimizations, but of course new -O settings code output should be fully validated again without assuming the code behavior is unchanged

James

such efforts are well underway: https://bitcointalk.org/index.php?topic=1377459.0

with a fanout of 2 and 6000 nodes, wouldnt it be 10 to 12 hops on average? assuming average ping time of 300 millis, plus latency of ?, I guess it is ~5 seconds. pretty good.

If a bit of privacy is sacrificed and it is started with sending to 16 peers, I think that would reduce things by 3 hops or so. probably not worth doing. But it would dramatically reduce the chances of a propagation "fizzling" out. That could be avoided by retransmitting to a pair of two other peers if the tx is not seen in the network after 15 seconds

James

Do you have example code for how the sudoku was verified in zero knowledge? If you are using libsnark, I assume it is in C, which is perfect for me.

To paraphrase this, it looks like transactions can be done where both he payment is assured and the deliverable is assured, without any chance of gun fights. Totally decoupling the payment from the content.

However each content type will need to have a libsnark circuit derived from C code. How to verify subjective things? I guess that is a problem for another day. Could it be verified that what is being delivered is a valid privkey? If that privkey had utxo in a 2of2 multisig where the buyer controlled the other privkey, then I think it enables guaranteed atomic swaps.

The main question is when will this hit mainnet?

James

I heard how evil RBF is, but it seems to just be a flag that indicates the tx is not final and likely to be changed, like when used in micropayments.

https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki

The only thing to quibble with I saw was the lack of ability to use the sequenceid to encode information without enabling RBF as the entire bitspace (other than -2 and -1) activate RBF. But encoding stuff into sequenceid is probably a bad idea anyway.

I have no idea how this got turned into "anybody can cancel payments"
Anybody making such claims, can you explain how somebody can cancel a payment I send with sequenceid of 0xffffffff?

Or how anybody can undo a micropayment with a sequenceid and undo a payment?

James

I am not sure  I understand. This exact issue came up in another conversation.

Can you explain how to deal with price slippage during the time for transferring into and out of the sidechain? Last I heard it is a day or longer. What happens if the price of the altcoin changes by 20% during this time?

And is it easy to have a dynamic peg (one that changes with market prices)?

James