we also have a single-sig option coming soon.

note it's considered (eg by coin-center) that blockstream.com/green is non-custodial because you can spend by yourself after a time lock (with the default 2of2+timelock config).

there is also a 2of3 config (create sub-wallet, pick 2of3) which allows you to spend immediately.

The function of the server key is to have multisig enforced 2fa to protect your funds.

see reddit AMA earlier today, has some more hardware and feature Q & A https://www.reddit.com/r/Bitcoin/comments/kqgehd/were_the_blockstream_team_and_we_just_announced/

this podcast has more detail https://letstalkbitcoin.com/blog/post/the-bitcoin-game-60-dr-adam-back-part-2-liquid

that is because the paper was written 5 years after hashcash was released.  see first sentence of abstract or citation [1] in the paper "Hashcash
was originally proposed as a mechanism to throttle systematic abuse of un-metered internet resources such as email,  and anonymous remailers in May 1997"

[1] http://hashcash.org/papers/announce.txt

Actually you can soft-fork CT.  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012194.html

The main challenge is size.  I believe I have a way to reduce the range proof from 2.5kB per proof to 2kB per proof but it is still large.

Mimble Wimble is interesting also in making an aggregatable CT which allows the bloat to be more than reclaimed at least as far as catchup goes. (More total bandwidth used, but less bandwidth to catchup as catchup becomes proportional to UTXO size + a smaller overhead per historic transaction).  Maybe the historic transaction overhead can be removed.

We might need to think about moving forum because some of the people proposing the ideas apparently being "moderator incompatible". Technically I dont think it is accurate to say the clarity has been hurt by deletions directly, as far as I saw & remember contents of now deleted post no technical comments were deleted.  What has hurt clarity possibly is the refusal of people to participate because of the potential of moderation or clash of egos and moderators.

I do sympathize and dislike moderation myself, though there is a little irony in Peter R's deleted comment containing a proud link to his own heavy trolling of /r/bitcoin which is not exactly the way to encourage people to divert their time to review your proposal (moderator or not!)

I started a thread on /r/btc

https://www.reddit.com/r/btc/comments/3zc6qg/review_of_shelling_point_protocol_selection_ideas/

and typed up a summary of ideas explained so far (including the below one that I already read before starting this thread we're in).


I had read that one before starting the thread. It seems to be a different idea again not mentioned on this thread.  Maybe we should be analysing a set of features that BU proposes to combine.

Immediate observation with empty block ratios is that this appears not to work in the face of 4 existing network behaviours SPV mining, relay network, big pools and selfish-mining.


Dont recall if I read that one yet.


Ha after thought I figured /r/btc is the next best option given the egos and the moderators clashing, yes, see above.

Adam

The idea of enabling nodes & miners to set a market block-size is quite reasonable so there is no criticism of the idea.  Dont take review of the mechanism as a critique of the idea: for ideas to be deployed we need game-theory reviewed protocols and rigorously tested implementations.  Dynamic block-size is actually on the core roadmap and the best proposal I've seen for it is flexcap by GMaxwell & Maaku, with some ideas from Jeff.  You can watch a video about flexcap presented at scaling bitcoin HK.  Maaku has code for the core parts of it, I believe he was going to publish it, probably online by now.


The precursor idea was BIP "100" which Jeff retracted.  The BIP "100" proposal is similar but only miners vote.  In flexcap both users and miners vote.

I would suggest people interested in the idea of dynamic blocks, learn about BIP "100" and flex-cap and see if they can improve them.  There are design considerations that have been refined between 100 and the improvement on it flex-cap.

The bitcoin unlimited project has presented some ideas which do try to automate things.  Unfortunately all of the ones so far seem to be defective suffering sybil attack, constant centralisation pressure, dont take account of SPV mining, shared pools, relay network existing practice nor selfish-mining, attacks.

I have not really analysed the idea of validating two chains, but it seems likely to have problems based on intuition, particularly in the area of race-conditions, chain sharding and divergence risk, and in an adversarial environment.

Bear in mind that the consensus mechanism is extremely fragile, it only just works in that there are many design close things that completely fail.  Most variants I tried I self-broke fairly immediately.  But some of these things take a long time to realise, or require review from GMaxwell or others to disprove.  For example selfish mining was not noticed for years.  I did spend about 3 - 4 months cooking up analysing mining variants to improve bitcoin mining centralisation (eg I invented ghost, but rejected it as over complex for what it achieved, before the academic paper proposed it and a bunch of other variants), before getting into side-chains.

The idea for users to vote by delaying block relay wont work because most miners are already using the relay network or SPV mining.  Over 50% of the network was SPV mining during the 4th july fork.  A large portion of miners use the relay network.

Users voting by advertisement wont work because of sybil as others have explained.

You can read flex-cap to see how they combine miner and user voting in a secure, game-theory stable way that defends against all these attacks.

In summary:

1. The use case: dynamic market set block-sizes are interesting.

2. bitcoin unlimited proposals so far seems broken as discussed by multiple people for a whole range of reasons.  We didnt have a crisp definition and it seems that some things maybe undecided.  That's ok - just keep working on it and make a concrete proposal later and people can analyse it from that.

3. BIP "100" seemed plausible, but was only miner meta-incentive secure. Meaning we would be trusting miners to do the right thing, limited only by their commitment to not do anything too selfish for fear of hurting bitcoin's long term value.

4. flex-cap adds user voting (in transactions) and an economic quadratic feed-back mechanism to create an incentive to right-size blocks (to deter miner zero sum attacks against other miners and curtail the continuous centralisation pressure). Flex-cap also ensures miner fee profit in conditions where otherwise mining fees can be driven to zero by excess capacity in a non-dynamic block-size growth proposals like BIP-103.

[EDIT: I suppose the other thing is it might be better to run experiments on testnet rather than bitcoin or putting clear warnings for users if you have not.  People could lose bitcoin running partial implementations of incomplete ideas.  Encouraging users arent understanding it is a research project to run experimental code with real Bitcoin under it's control or even on the same machine, would be inadvisable.]

Adam

Here are two posts from testing1567 on reddit (says he doesnt have a bitcointalk account):


and another one:


_{Mod note: fixed quote links}

So what happens if I left my node at 1MB +10% user threshold and a 1.2MB block comes - does my node reject it?

How will the network not split into a myriad little shards which diverge following accidental and/or intentional double-spends without manual human coordination?

Adam

If you can stay on topic as I suggested: "To make progress on review it would be helpful to separate technical from political opinions." I dont see a problem. People have been discussing bitcoin NG ideas on here for years.

Are you able to explain what BU is and how you think it works?  I gave some reviewer questions in the OP.

Adam

Here are some links from kanzure on IRC (Aquentys started a discussion but wanted to continue on a forum for persistence):


Adam

Agree I was kind of hoping Aquentys would be able to explain what it is and how they think it works.  It saves time reviewing when people take the time to explain their assumptions.

Adam

The idea was to have some technical focussed constructive discourse and this is a more neutral forum and also where more Bitcoin experts hang out.

Adam

The proposers of bitcoin unlimited said they would like to get some review which seems reasonable, if others would like to help.

The proposal seems at first skim to be a copy of a few existing technologies from Bitcoin's roadmap and were first proposed by Greg Maxwell and others*: weak-blocks & network-compression/IBLT to reduce orphan risk, and flexcap (or a variant of it perhaps).

Perhaps they could start by explaining what it is & how it works.  This might include unimplemented ideas, and a summary of what the code currently for download on the manifesto page does.

To review it will be clearer if you state your assumptions, and claimed benefits, and why you think those benefits hold.  (Bear in mind if input assumptions are theoretical and known to not hold in practice, while that can be fine for theoretical results, it will be difficult to use the resulting conclusions in a real system).  Particularly claimed compatibilities with Bitcoin and how the dynamic block-size game-theory is expected to work and remain secure with SPV mining, selfish-mining, block-withholding and fair (progress-free) mining could also use explaining.

I suggest the sensible thing is if there is something new or insightful, that Bitcoin consider adopting the technology and the BU proponents get behind that.

Maintaining a new coin is a rather complex undertaking and screwing up, as something like 40% of projects that have tried it have done, is very expensive of other peoples money.

To make progress on review it would be helpful to separate technical from political opinions.

Adam

* some citations seem to be notably missing, I trust this is unintentional.

It looks like Joseph Liu, Victor Wei and Duncan Wong made the same observation in "Linkable Spontaneous Anonymous Group
Signature for Ad Hoc Groups" 2004 https://eprint.iacr.org/2004/027.pdf

The proposed scheme is basically the same as what I propose above, and the Liu, Wei & Wong 2004 publication seems to predate the 2007 Fujisaki & Suzuki "Traceable ring signature" https://eprint.iacr.org/2006/389.pdf cited by cryptonote.

Adam

The traceable ring signature used in cryptonote https://cryptonote.org/whitepaper.pdf looks like:

KEYGEN: P_i=x_i*G, I_i=x_i*H(P_i)

SIGN: as signer j; random s_i, w_i

(I relabeled q_i as s_i to be more standard, and relabeled the signer s as signer j)

IF i=j THEN L_i=s_i*G ELSE L_i=s_i*G+w_i*P_i
IF i=j THEN R_i=s_i*H(P_i) ELSE R_i=s_i*H(P_i)+w_i*I_j

c=h(m,L_1,...,L_n,R_1,...,R_n)

IF i=j THEN c_i=c-sum_{i!=j}(c_i) ELSE c_i=w_i
IF i=j THEN r_i=w_i-c_i*x_i ELSE r_i=w_i

\sigma = (m,I_j,c_1,...,c_n,r_1,...,r_n)

VERIFY:

L_i'=r_i*G+c_i*P_i
R_i'=r_i*H(P_i)+c_i*I_j
sum_{1..n}( c_j ) =? h(m,L_1',...,L_n',R_1',...,R_n')

LINK: reject duplicate I_j values.

where H(.) is a hash2curve function (taking a value in Zn and deterministically mapping it to a curve point), and h(.) is a hash function with a hash output size very close to n the order of the curve, ie h(.)=SHA256(.) mod n.

Towards finding a more compact ring signature I'd been trying to find a way to make c_i into a CPRNG generated sequence as they are basically arbitrary, though they must be bound to the rest of the signature (non-malleable) so that you can compute at most n-1 existential signature forgeries without knowing any private keys.  

I found this paper "1-out-of-n Signatures from a Variety of Keys" by Abe, Ohkubo and Suzuki http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.363.3431&rep=rep1&type=pdf section 5.1 shows a way to do it.  I show here how to add traceability to it in a way that makes it compatible with crypto note:

KEYGEN: P_i=x_i*G, I_i=x_i*H(P_i)

SIGN: as signer j; \alpha = random, \forall_{i!=j} s_i = random

c_{j+1} = h(P_1,...,P_n,\alpha*G,\alpha*H(P_j))
c_{j+2} = h(P_1,...,P_n,s_{j+1}*G+c_{j+1}*P_{j+1},s_{j+1}*H(P_{j+1})+c_{j+1}*I_j)
...
c_j = h(P_1,...,P_n,s_{j-1}*G+c_{j-1}*P_{j-1},s_{j-1}*H(P_{j-1})+c_{j-1}*I_j)

so that defines c_1,...,c_n with j values taken mod l some number of signers.  Next find the s_j value:

Now \alpha*G = s_j*G+c_j*P_j so \alpha = s_j+c_j*x_j so s_j = \alpha - c_j*x_j mod n.

Similarly \alpha*H(P_j) = s_j*H(P_j)+c_j*I_j so \alpha works there too.

\sigma = (m,I_j,c_1,s_1,...,s_n)

VERIFY:

\forall_{i=1..n} compute e_i=s_i*G+c_i*P_i and E_i=s_i*H(P_i)+c_i*I_j and c_{i+1}=h(P_1,...,P_n,e_i,E_i)

check c_{n+1}=c_1

LINK: reject duplicate I_j values.

This alternate linkable ring signature tends to 1/2 the size of the crypto note ring signature as the signature is 3+n values vs 2+2n values.

Adam

And this is important because if you reuse k with different messages you reveal a simultaneous equation allowing the private key to be computed.  private key is d, public key is Q=dG, address is a=H(Q),  signature is (s,r) where s=(h(m)+rd)/k, r=[kG].x, n is the order of the curve.

s=(h(m)+rd)/k mod n
s2=(h(m2)+rd)/k mod n

=> sk = h(m)+rd, s2k = h(m2)+rd
=> (s-s2)k = h(m)-h(m2)
=> k=(h(m)-h(m2))/(s-s2).

now we know k and substituting:

sk=h(m)+rd
=> d=(sk-h(m))/r

There are worse attacks where even knowing a bias of a few bits eg http://www.irisa.fr/celtique/zapalowicz/papers/asiacrypt2014.pdf can result in d being recovered over a modest number of signatures, or that the NIST original DSA standard was partly broken due to a small bias in k generation algorithm by Bleichenbacher, see section 2.2 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.122.3190&rep=rep1&type=pdf

Avoiding reuse of k is also tricky because that implies log transactional storage in the RNG state.  What if the RNG is in a VM, and the VM snapshotted and rolled back?  What if the RNG is poorly seeded (eg in a server environment).

The lesson for bitcoin is dont reuse addresses but as there are usability difficulties with that also dont have biases in k, and dont rely on transactional, non-rollbackable storage: hence deterministic DSA.

Adam

No thats not how it works.  Deterministic DSA is to use k=H(d,m) as the nonce.  In that way if you sign the same message m=H(transaction), you'll get the same signature.

Adam

Sometimes people want the ability to tell which k of n signed (for accountability purposes, if k < n) and there a multisig has additional functionality that schnorr (or other) mulitparty sigs dont.

I did also mention on twitter another idea to use schnorr to make a compact multisg.  The idea is  to have enough different keys per signer to make it unambiguous which k signed, and commit the public key sums for the needed permutations in a merkle tree.  Then to sign reveal the path to the public key sum used and a multiparty sig with that (via the usual schnorr method).

It seems that Micali et al thought of this idea before see http://www.cs.bu.edu/~reyzin/multisig.html though the numbers sound better for them as they're assuming prime fields not EC where a hash of a public key is a smaller ratio than in EC.

I expect it wouldnt be too useful to use the bootstap method I mentioned earlier because the subset doing the bootstrapping know everyone elses keys and so could impersonate them for accountability purposes.  So you do need an enrollment process which does not involve third parties knowing parties private keys!

Adam

Did someone tune up the spondoolies hosted miners?

http://eligius.st/~wizkid057/newstats/userstats.php/1Adam3usQMbQWScA5AXnnDsRMeZeCh6ovu

my 4x sp10 hashrate jumped from ~6TH to ~ 7.5TH?  (Which'd be a very nice hashrate at 1.85 TH/sp10 vs 1.4-1.5TH advertised).

Maybe someone accidentally configured another one for my payout address during a reshuffle or config change?

Adam