You're assuming they are perfectly rational, and have remained perfectly rational during the measurement period for the ratio. If they were perfectly rational, they wouldn't have had orphans recently, because they would have anticipated the upgrade. The ratio tells you about their past strategies, which they might have tried and abandoned (or will abandon). If they were perfectly rational, there is no reason for the 16/35=45% difference in processing times (based on ratio), I would have thought that F2Pool has slower connectivity, so should be the other way around. If miners were perfectly rational, they would pay attention, in the same way, to the way empty blocks worry users. Data has much variation, and our estimates, by completely different methods, are actually surprisingly close (~10 sec handwaving, ~16 sec empirical), not necessarily contradictory.

They gain a 600ms advantage on the verification, then another few seconds on the download, depending on their bandwidth. 600 seconds average in a block, so if they manage to get an advantage of 10 seconds, that's 10/600 or 2% greater profitability than other miners. There will be less incentive for that when the reward halvings happen (fees double relative to subsidy). *shrug* Maybe they are also making some political point, or simply can't be bothered dealing with the txns. But the recent orphans should have cost them a bit. They are playing their own sort of game theories, and not always winning.

Not sure if any solution is merged yet (see my edit above). But we are talking less than 600ms even without the extra speedup, or 10ms with the speedup.

It would be stupid to forward unverified txns, and it would also be stupid to verify them twice. Easy to fix, so there's no reason for it to verify twice.

About 600 milliseconds to verify a 1MB block, will be reduced to about 10 ms

https://github.com/bitcoin/bitcoin/pull/6077

https://github.com/bitcoin/bitcoin/pull/5835

Yes.

Moreover, I don't see why the time spent verifying would be significant. The vast majority of transactions would have been verified by a full node before being included in the block, and then it is just a case of checking the hash, and looking up that the txn was previously mempool verified. The verification time for a block should be insignificant relative to its download time (unless it's a flood attack of new txns by a miner). Or am I missing something?

You didn't get the memo? For 7 years? Duude, are you for real?  

Yeah. Footnote removed.


Removed.


Finding the actual 3 squares for a specific random integer can get too expensive at these bit levels. Some (maybe all) algorithms require factoring (or similar expense), and it is not convenient for a user to have to factor 252-bit numbers to generate a transaction output (regardless of a coin network's scalability). I will do more background reading to see if there is a better alternative.

Worse than that, even if 3 exact squares are found, one of the three square roots is likely to turn out to be very small (fewer than 32 bits). None of the roots are blinded for the proofs to work; they have to be the actual commitments. Then either the prover has to generate a new random number and run large-integer factoring again (and again...), or the attacker will know that one of the 3 committed values is cheap to break. Then the smallest square might as well be in plaintext and save the 50% overhead anyway. To solve that problem, [38] suggests using a probabilistic ECC system instead of a deterministic one, which doubles the cost of all commitments (though there are probably some new methods to push some of the cost back down), introduces the need for additional explicit equality proofs and other complexities.


There's a good chance that the first random number will just work.

If not, all the heuristic does is: two square roots, two squares, one difference, one addition and two comparisons. Plain ultra-fast ops to repeat. Nothing like factoring, and much less work than one ECC multiplication.


It does have many solutions, as there are many more integers close (up to ∆) to sums of squares than there are integers that are actually sums of squares. There are also many more sums of squares than there are squares. Easy way to think about it is to set ∆=1, and see how sums of squares can work with it (4+9+1=14, 9+16+1=26, 4+16+1=21, 16+25+1=42, 4+25+1=30, ...), and that this is only bounded by the modulus of the system.

A proof of exactly how well [sum_of_two_squares, sum_of_two_squares + n] covers the integers would be good to include in the paper (it might also help to calibrate a better upper limit for ∆), but difficult to come up with.


The goal in those sources is to provide proof for a very specific integer, they have no choice to opt out of the high level problem. For application in transactions with fuzz blinding, CCT is not constrained in that way, and can simply pick a different random number at the output level. This is actually what is done at low level in many NIZKP of small magnitude. It is done in the NIZKP of source [38] itself, in section 4.22.2, heading "ZK-proof of membership in a much-widened interval." If the random w doesn't work, the algorithm just tries another w until it succeeds. This does not necessarily weaken the system, although as you mentioned, the burden of proof is on the whitepaper. I think solving your point 4 is sufficient.

Also as per my response to point 3, in a deterministic ECC system, using the actual three squares can reveal the smallest one of them.

Indeed, building wider motorways doesn't necessarily solve traffic congestion. A bunch of other things sometimes do (raising gasoline/car taxes/prices, regulation, unemployment, crime, alternative transport, virtual working, better city layout, emigration...).

The problem was with an invalid assumption that two curves of different orders would not be able to generate proof of same negative value, as long as the negative value is in the small range being proved. They clearly can, because "m = r + c*x" allows a negative x to leak into the negative cx and then offset against the positive random r, and the resulting m is then used for both curves.

That assumption is no longer present in the current version of paper (now with:.. diagrams!), but the resulting proofs are not as compact as initially hoped.

To be honest, I think the muted response speaks for itself. This stuff turns out to be less important than I thought. Someone will eventually re-implement the same things from the paper (maybe Blockstream or Monero guys?). Multiple independent implementations are a good way to do crypto, because then they can be compared and tested against each other.



I'm not 100% sure of the CT method, but it sounds like some information about the exponent is exposed to make the proofs shorter (you could keep it secret at a big cost). Maybe not the input magnitude, but the proof exponent range is public, and that selection, can itself give some information away. This is why CT is targeted at smaller 32-bit numbers.


Yes. There's a DH key exchange, which give a common secret through which you could share as much as you want.

Just as well that it does not say "for completed code". Otherwise I would be going against the thing. In a knowledge economy, new knowledge (and new code) takes a lot of completed works. Anyway, the review is not complete yet so my claim might not be valid. And even if it is valid or invalid logically, the fund is ultimately at the discretion of two individuals. If they want to encourage or discourage this kind of research is up to them.

Nobody can claim the specific piece of paper money from you, solely on the basis that it was the very same piece of paper money that was stolen.

They (and others) can still make all sorts of other claims, for money or otherwise, like if you had reasonable cause to believe the paper money was proceeds from criminal activity, and accepted it anyway (see Shrem). The act of spending such knowingly dirty money to make it fungible, is called money laundering, I thought...

They hide only the mantissa part of the number and take 2.5KB to achieve that.

My confidential values technique hides the whole number in 0.4KB (subject to ongoing peer review, positive so far).

https://bitcointalk.org/index.php?topic=1085436.msg11597427#msg11597427


Yes.

I would like to make a claim on this fund for work done on Compact Confidential Transactions (subject to the ongoing peer review).

https://bitcointalk.org/index.php?topic=1085436.msg11597427

CoinJoin should 'just work' in this scheme, and has a similar interface to gmaxwell's Confidential Transactions for keeping participant's balances hidden from other participants.

Participants generate some random inputs, and same number of random outputs, to themselves with a zero sum, and ensure that they do not introduce any fuzz over/underflow, so the fee is fixed.

An alternative approach, is to let participants share only their fee delta, guaranteeing that everyone makes the same fee adjustment, in which case the number of outputs can also differ to the number of inputs for each participant.

If anyone puts in too much or too little, their sum, and the whole transaction sum, won't come out as zero and the transaction will be invalid.

Nope.


Integrating Proof of Stake with the current design would likely require stake disclosure. Confidential Proof of Stake would require more proofs than in the paper.

Thank you for your feedback.



Attempt noted.


The author (me) does not think that.

But does, apparently, attempt to publish pragmatic improvements in technology, without raising his expectations of others to the point of being discouraging.

As you do not publish your design, I can only respond with wild imagination. Your bearer coin might do well to hide values in its off-chain components; whether this specific technology may be useful for that, I do not know. I can imagine that the pure hash on-chain re-orgs are going to be possible and fun. Lamport signatures or much longer keylength for quantum computing. Of course, when people are Sybil nodes, and your spend is to an under-cover agent, and the courts shall accept the agent's circumstantial proof as sufficient and ignore the [lack of] math, ... oh what a world.

Sumcoin is work/stake agnostic (stake may require disclosure), and does not break the core scripting language; so the opcodes remain possible.

It is early yet, want to get this out for review to the people who can - very possible I've made some mistakes.
Off-top-my-head, Monero seems like the easiest fit because it already has a view key, but I have not looked in detail.

Thanks for WK. Long term, it might be possible to auto-generate equivalent-difficulty hash functions. A new hash function for every block. That would fix things back down to FPGA technology level, and contribute better to generic hardware development.

Request for comment

http://voxelsoft.com/dev/cct.html

Request for comments

http://voxelsoft.com/dev/sumcoin.pdf