Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks
>Under this point-of-view, then, extension block is "not" soft fork. >It is "evil" soft fork since older nodes are forced to upgrade as their >intended functionality becomes impossible. >In this point-of-view, it is no better than a hard fork, which at least is >very noisy about how older fullnode versions will simply stop working Offtopic: I believe that this kind of "evil soft fork" where nodes who don't upgrade can continue to read the blockchain, update their utxoset, etc. but can't actually spend some or all of the coins they have has been referred to as a "firm fork". I think this is a pretty useful term to pass around when talking about potential future forks. The earliest reference I can find to that term from a quick search is this talk from 2016 by Adam Back: http://diyhpl.us/wiki/transcripts/adam3us-bitcoin-scaling-tradeoffs/ -Trey Del Bonis On Tue, Feb 12, 2019 at 7:48 AM ZmnSCPxj via bitcoin-dev wrote: > > Good morning Kenshiro, > > > - Soft fork: old nodes see CT transactions as "sendtoany" transactions > > There is a position that fullnodes must be able to get a view of the UTXO > set, and extension blocks (which are invisible to pre-extension-block > fullnodes) means that fullnodes no longer have an accurate view of the UTXO > set. > SegWit still provides pre-SegWit fullnodes with a view of the UTXO set, > although pre-SegWit fullnodes could be convinced that a particular UTXO is > anyone-can-spend even though they are no longer anyone-can-spend. > > Under this point-of-view, then, extension block is "not" soft fork. > It is "evil" soft fork since older nodes are forced to upgrade as their > intended functionality becomes impossible. > In this point-of-view, it is no better than a hard fork, which at least is > very noisy about how older fullnode versions will simply stop working. > > > - Safe: if there is a software bug in CT it's impossible to create new > > coins because the coins move from normal block to normal block as public > > transactions > > I think more relevant here is the issue of a future quantum computing breach > of the algorithms used to implement confidentiality. > > I believe this is also achievable with a non-extension-block approach by > implementing a globally-verified publicly-visible counter of the total amount > in all confidential transaction outputs. > Then it becomes impossible to move from confidential to public transactions > with a value more than this counter, thus preventing inflation even if a > future QC breach allows confidential transaction value commitments to be > opened to any value. > > (do note that a non-extension-block approach is a definite hardfork) > > > - Capacity increase: the CT signature is stored in the extension block, so > > CT transactions increase the maximum number of transactions per block > > This is not an unalloyed positive: block size increase, even via extension > block, translates to greater network capacity usage globally on all fullnodes. > > Regards, > ZmnSCPxj > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks
Good morning ZmnSCPxj, Thank you for your answer. There is a position that fullnodes must be able to get a view of the UTXO set, and extension blocks (which are invisible to pre-extension-block fullnodes) means that fullnodes no longer have an accurate view of the UTXO set. I think old nodes don't need to know the CT part of the UTXO set. It would be possible to move coins from normal address to CT address and the opposite, it would be written as "anyone-can-spend" transactions in the main block so old nodes are fully aware of these transactions. Miners would enforce that "anyone-can-spend" transactions are true. The full details of the transactions involving CT would be in the extension block. CT to CT transactions don't need to be written in the main block. Maybe I'm missing some technical detail here but it looks good for me. > - Capacity increase: the CT signature is stored in the extension block, so CT > transactions increase the maximum number of transactions per block This is not an unalloyed positive: block size increase, even via extension block, translates to greater network capacity usage globally on all fullnodes. Yes, there is an increase in block size and network usage but I think it would still be possible for people with regular computers to run a full node, an people in developing countries could use light wallets. Regards From: ZmnSCPxj Sent: Monday, February 11, 2019 5:29 To: Kenshiro \[\]; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks Good morning Kenshiro, > - Soft fork: old nodes see CT transactions as "sendtoany" transactions There is a position that fullnodes must be able to get a view of the UTXO set, and extension blocks (which are invisible to pre-extension-block fullnodes) means that fullnodes no longer have an accurate view of the UTXO set. SegWit still provides pre-SegWit fullnodes with a view of the UTXO set, although pre-SegWit fullnodes could be convinced that a particular UTXO is anyone-can-spend even though they are no longer anyone-can-spend. Under this point-of-view, then, extension block is "not" soft fork. It is "evil" soft fork since older nodes are forced to upgrade as their intended functionality becomes impossible. In this point-of-view, it is no better than a hard fork, which at least is very noisy about how older fullnode versions will simply stop working. > - Safe: if there is a software bug in CT it's impossible to create new coins > because the coins move from normal block to normal block as public > transactions I think more relevant here is the issue of a future quantum computing breach of the algorithms used to implement confidentiality. I believe this is also achievable with a non-extension-block approach by implementing a globally-verified publicly-visible counter of the total amount in all confidential transaction outputs. Then it becomes impossible to move from confidential to public transactions with a value more than this counter, thus preventing inflation even if a future QC breach allows confidential transaction value commitments to be opened to any value. (do note that a non-extension-block approach is a definite hardfork) > - Capacity increase: the CT signature is stored in the extension block, so CT > transactions increase the maximum number of transactions per block This is not an unalloyed positive: block size increase, even via extension block, translates to greater network capacity usage globally on all fullnodes. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks
Good morning Kenshiro, > - Soft fork: old nodes see CT transactions as "sendtoany" transactions There is a position that fullnodes must be able to get a view of the UTXO set, and extension blocks (which are invisible to pre-extension-block fullnodes) means that fullnodes no longer have an accurate view of the UTXO set. SegWit still provides pre-SegWit fullnodes with a view of the UTXO set, although pre-SegWit fullnodes could be convinced that a particular UTXO is anyone-can-spend even though they are no longer anyone-can-spend. Under this point-of-view, then, extension block is "not" soft fork. It is "evil" soft fork since older nodes are forced to upgrade as their intended functionality becomes impossible. In this point-of-view, it is no better than a hard fork, which at least is very noisy about how older fullnode versions will simply stop working. > - Safe: if there is a software bug in CT it's impossible to create new coins > because the coins move from normal block to normal block as public > transactions I think more relevant here is the issue of a future quantum computing breach of the algorithms used to implement confidentiality. I believe this is also achievable with a non-extension-block approach by implementing a globally-verified publicly-visible counter of the total amount in all confidential transaction outputs. Then it becomes impossible to move from confidential to public transactions with a value more than this counter, thus preventing inflation even if a future QC breach allows confidential transaction value commitments to be opened to any value. (do note that a non-extension-block approach is a definite hardfork) > - Capacity increase: the CT signature is stored in the extension block, so CT > transactions increase the maximum number of transactions per block This is not an unalloyed positive: block size increase, even via extension block, translates to greater network capacity usage globally on all fullnodes. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Safer NOINPUT with output tagging
On Sun, Feb 10, 2019 at 12:48:40AM +0800, Johnson Lau wrote: > In a 3 parties channel, let’s say the balance for A, B, C is 2, 3, 6BTC > respectively, there are few ways they could make the settlement tx. The way I look at this is: * you can have a "channel factory" of 3 or more members (A,B,C,...) * it's protected by an n-of-n multisig output * it contains some combination of: - spends directly to members - lightning channels between pairs of members - channel factories between subgroups of members * when initially setup, the factory just has direct spends to each member matching the amount they contributed to the factory * whether you create a lightning channel or a sub-factory is the same decision as whether you create a lightning channel or a factory on-chain, so there's no combinatorial explosion. You can close any channel factory by publishing it (and any higher level channel factories it was a subgroup of) to the blockchain (at which point the lower level channel factories and lightning channels remain open), or you can update a channel factory off-chain by having everyone agree to a new state -- which is only possible if everyone is online, of course. Updates to transactions in a lightning channel in a factory, or updates to a subfactory, don't generally involve updating the containing factory at all, I think. I don't think there's much use to having sub-factories -- maybe if you have a subgroup that's much more active and wants to change channel balances between each other more frequently than the least active member of the main factory is online? As far as NOINPUT goes; this impacts channel factories because cheating could be by any member of the group, so you can't easily penalise the cheater. So an eltoo-esque setup where you publish a commitment to the state that's spendable only by any later state, and is then redeemed after a timelock seems workable. In that case closing a factory when you can't get all group members to cooperatively close looks like: funding tx: n-of-n multisig state commitment: n-of-n multisig spends funding tx or earlier state commitment spendable by later state commitment or settlement settlement: n-of-n multisig relative timelock spends state commitment spends to members, channels or sub-factories The settlement tx has to spend with a NOINPUT sig, because the state commitment could have had to spend different things. If it's a sub-factory, the funding tx will have been in a factory, so the state commitment would also have had to be a NOINPUT spend. So tagging NOINPUT-spendable outputs would mean: - tagging state commitment outputs (which will be spent shortly with NOINPUT by the settlement tx, so no real loss here) - tagging settlement tx outputs if they're lightning channels or sub-factories (which is something of a privacy loss, I think, since they could continue off-chain for an indefinite period before being spent) I think Johnson's suggested elsewhere that if you spend an input with a NOINPUT signature, you should make all the outputs be tagged NOINPUT (as a "best practice rule", rather than consensus-enforced or standardness). That would avoid the privacy loss here, I think, but might be confusing. If you wanted to close your factory and send your funds to an external third-party (a cold-wallet, custodial wallet, or just paying someone for something), you'd presumably do that via a cooperative close of the factory, which doesn't require the state/settlement pair or NOINPUT spends, so the NOINPUT-in means NOINPUT-tagged-outputs doesn't cause a problem for that use case. FWIW, I think an interesting way to improve this model might be to *add* centralisation and trust; so that instead of having the factory have an n-of-n multisig, have it be protected by k-of-n plus a trusted third party. If you have the trusted third party check that the only balances that change in the factory are from the "k" signers, that allows (n-k) members to be offline at any time, but the remaining members to rebalance their channels happily. (Theoretically you could do this trustlessly with covenants, but the spending proofs on chain would be much larger) Of course, this allows k-signers plus the trusted party to steal funds. It might be possible for the trusted party to store audit logs of the partial signatures from each of the k-signers for each transaction to provide accountability -- where the lack of such logs implies the trusted third party was cheating. Cheers, aj > > > > > On 9 Feb 2019, at 6:01 PM, Alejandro Ranchal Pedrosa via bitcoin-dev > > wrote: > > > > Hi all, > >> > >> Side note: I was not able to come up with an similar, eltoo-like protocol > >> that works > >> if you can't predict in advance who will become absent. > >> > > An eltoo-like protocol that works (without going on-chain) if you can't > > predict in advance who will become absent would be a
