Re: [bitcoin-dev] NIST 8202 Blockchain Technology Overview

[Damian Williamson via bitcoin-dev]

Then you have my apology, I will not claim to be any kind of advocate or user 
of Bitcoin Cash but *had* understood that segwith had been enabled. Clearly my 
mistake.


Regards,

Damian Williamson


From: CANNON 
Sent: Tuesday, 6 February 2018 1:08:24 PM
To: Damian Williamson; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] NIST 8202 Blockchain Technology Overview

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/31/2018 11:16 AM, Damian Williamson wrote:
> I disagree with the correctness of the following statement:
>
>
>> Rather than implementing the SegWit changes, the developers of Bitcoin Cash 
>> decided to simply increase the blocksize.
>
>
> I would suggest "Rather than being satisfied with the implementation of 
> SegWit changes alone, the developers of
> Bitcoin Cash decided to also increase the blocksize.
>
>
> Regards,
>
> Damian Williamson

You do realize that segwit includes many improvements of which are unrelated to 
scaling? These same improvements of which
simply increasing the blocksize alone would not fix or enable. Segwit is not 
just a blocksize increase.
Bitcoin Cash, while increasing the blocksize directly, from my understanding 
has yet to implement the
improvements and capabilities that segwit enables.

One example being, with transactions hashes being able to be calculated in 
advanced prior to signing
(due to the signature being in different section than that used
to calculate the transaction ID) it is possible to create transaction trees, 
enhanced smart contracts, trustless mixing protocols,
micropayment networks, etc...

Segwit also increases the security of signatures.

There are lots of other things segregated witness enables as well.

By saying "..segwit changes alone decided to also..." Bitcoin Cash has not 
implemented segwit. Bitcoin Cash only
increased the blocksize.

that wording above at least from the way I read it, seems to imply that Bitcoin 
Cash has segwit.
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJaeQ3IAAoJEAYDai9lH2mwKkQP/3dgYApq1qv2lGIyZIdeN9SE
D5AuXPqFQYAoMwhC0RPNQU/jUisKIyd6zm4XCIm6KPufCtXkjfH9FLhd0ThbCTcy
Gk+pYYRBzSuBZdPBKg0DHu7alRETtxbdtUI0zDfERt1FFZb+HmcDcGTfwdVci3fa
jBiFXq1R+myMW5xdB44dipSk5kBhcpx2zitr1bIA4rF11QbxKAmzU7iPdRpA+PXz
gB9NImc1Dbz+TEA50tdq3v9Ov3x7m7F+QtBnqyLAigJh6XKa6guCfwKIGoawRGwZ
v2ur7T+Qh3KGRXCBlHnxgtFte16wHagwvsVgE5EEmJR0yJUc/4XU2kCGANVNDZ/P
pphqk8pruQ5rjQ8S+s6i5XG8oHVSB2fDh56NvPY7msA72j+Gk+XneV2eJbEAdjhb
9Ci7u1uPJL3pb3c/ZOwQvpIRV3tRjlh0DertWkd3Li5RZLO3uFvBTxNxrni6+9bf
/cmAOwfHjoUp8BX/nvgMjpIDCoEu+Rv9IO/ok3s3mX300JbczAdGbXbsPTE5G+DI
RB1kSmszwst8wOlOAsdVqk/iKRJdN9daTGGN6aE/wjkpSg8rW9BOaoI2X9t4oXCU
+oe/WlgkxhxPcNyhKpLeeYVe6nFX2fjU+THyyiAq/LJ/qHU/brKpXc4NesCVHhQP
BBlxiN0E4gndMGs/Lx89
=+UCK
-END PGP SIGNATURE-

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] NIST 8202 Blockchain Technology Overview

[CANNON via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/31/2018 11:16 AM, Damian Williamson wrote:
> I disagree with the correctness of the following statement:
> 
> 
>> Rather than implementing the SegWit changes, the developers of Bitcoin Cash 
>> decided to simply increase the blocksize.
> 
> 
> I would suggest "Rather than being satisfied with the implementation of 
> SegWit changes alone, the developers of
> Bitcoin Cash decided to also increase the blocksize.
> 
> 
> Regards,
> 
> Damian Williamson

You do realize that segwit includes many improvements of which are unrelated to 
scaling? These same improvements of which
simply increasing the blocksize alone would not fix or enable. Segwit is not 
just a blocksize increase.
Bitcoin Cash, while increasing the blocksize directly, from my understanding 
has yet to implement the
improvements and capabilities that segwit enables.

One example being, with transactions hashes being able to be calculated in 
advanced prior to signing
(due to the signature being in different section than that used
to calculate the transaction ID) it is possible to create transaction trees, 
enhanced smart contracts, trustless mixing protocols,
micropayment networks, etc...

Segwit also increases the security of signatures.

There are lots of other things segregated witness enables as well.

By saying "..segwit changes alone decided to also..." Bitcoin Cash has not 
implemented segwit. Bitcoin Cash only
increased the blocksize.

that wording above at least from the way I read it, seems to imply that Bitcoin 
Cash has segwit.
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJaeQ3IAAoJEAYDai9lH2mwKkQP/3dgYApq1qv2lGIyZIdeN9SE
D5AuXPqFQYAoMwhC0RPNQU/jUisKIyd6zm4XCIm6KPufCtXkjfH9FLhd0ThbCTcy
Gk+pYYRBzSuBZdPBKg0DHu7alRETtxbdtUI0zDfERt1FFZb+HmcDcGTfwdVci3fa
jBiFXq1R+myMW5xdB44dipSk5kBhcpx2zitr1bIA4rF11QbxKAmzU7iPdRpA+PXz
gB9NImc1Dbz+TEA50tdq3v9Ov3x7m7F+QtBnqyLAigJh6XKa6guCfwKIGoawRGwZ
v2ur7T+Qh3KGRXCBlHnxgtFte16wHagwvsVgE5EEmJR0yJUc/4XU2kCGANVNDZ/P
pphqk8pruQ5rjQ8S+s6i5XG8oHVSB2fDh56NvPY7msA72j+Gk+XneV2eJbEAdjhb
9Ci7u1uPJL3pb3c/ZOwQvpIRV3tRjlh0DertWkd3Li5RZLO3uFvBTxNxrni6+9bf
/cmAOwfHjoUp8BX/nvgMjpIDCoEu+Rv9IO/ok3s3mX300JbczAdGbXbsPTE5G+DI
RB1kSmszwst8wOlOAsdVqk/iKRJdN9daTGGN6aE/wjkpSg8rW9BOaoI2X9t4oXCU
+oe/WlgkxhxPcNyhKpLeeYVe6nFX2fjU+THyyiAq/LJ/qHU/brKpXc4NesCVHhQP
BBlxiN0E4gndMGs/Lx89
=+UCK
-END PGP SIGNATURE-

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

[ZmnSCPxj via bitcoin-dev]

Good morning Greg,

I am probably being exceedingly naive, but I would like to compare Taproot to a 
generalization of funding transactions.

For instance, CoinSwapCS:

1.  It uses an HTLC in an off-chain transaction, and a funding transaction TX0 
whose output is a "simple" 2-of-2.
2.  The HTLC tx spends this 2-of-2.
3.  If a branch of the HTLC succeeds, the parties contact each other and create 
a replacement of the (unconfirmed and unbroadcasted but signed) HTLC tx that 
assigns the funds to the correct owners.
4.  If the above step fails, individual parties can in isolation publish the 
HTLC tx and provide its requirements.

Both of #3 and #4 above, appear to me naively as similar to the two "top" cases 
of Taproot, i.e. either C is signed by all parties, or S is revealed and 
fulfilled.

The important bits of this "generalized funding transaction" pattern is:

1. The contract that enforces correct behavior spends an unsigned and 
unbroadcasted funding transaction output (which requires N-of-N).
2. The enforcement contract is signed first by all parties before the funding 
transaction is signed by anybody.  This is possible due to SegWit.
3.  Then, when all parties are sure they have the fully-signed smart contract, 
the initial funding transaction is signed and broadcast and confirmed.
4.  When the condition that the contract requires is achieved, then the parties 
contact each other and try to jointly create a simpler transaction that spends 
the funding transaction directly to whoever gets the money in the correct 
proportion.  This avoids publishing the smart contract onchain, and looks like 
an ordinary N-of-N spend.
5.  If they fail to get all required signatures for any reason, any party can 
publish the enforcement contract transaction and subsequently fulfill its 
conditions in another transaction.

Admittedly, Taproot if added to the consensus would reduce the number of 
transactions by 1 in the "S is revealed" case.
But the "generalized funding transaction" pattern is already possible today, 
and MuSig (to my limited understanding) can be used to make it 
indistinguishable from 1-of-1 (so, possibly, make it P2WPKH?).


(I am probably neglecting something very simple and direct, however...)

Regards,
ZmnSCPxj

 Original Message 
 On January 23, 2018 8:30 AM, Gregory Maxwell via bitcoin-dev 
 wrote:

>Interest in merkelized scriptPubKeys (e.g. MAST) is driven by two main
> areas: efficiency and privacy. Efficiency because unexecuted forks of
> a script can avoid ever hitting the chain, and privacy because hiding
> unexecuted code leaves scripts indistinguishable to the extent that
> their only differences are in the unexecuted parts.
>
> As Mark Friedenbach and others have pointed out before it is almost
> always the case that interesting scripts have a logical top level
> branch which allows satisfaction of the contract with nothing other
> than a signature by all parties.  Other branches would only be used
> where some participant is failing to cooperate. More strongly stated,
> I believe that any contract with a fixed finite participant set
> upfront can be and should be represented as an OR between an N-of-N
> and whatever more complex contract you might want to represent.
>
> One point that comes up while talking about merkelized scripts is can
> we go about making fancier contract use cases as indistinguishable as
> possible from the most common and boring payments. Otherwise, if the
> anonymity set of fancy usage is only other fancy usage it may not be
> very large in practice. One suggestion has been that ordinary
> checksig-only scripts should include a dummy branch for the rest of
> the tree (e.g. a random value hash), making it look like there are
> potentially alternative rules when there aren't really.  The negative
> side of this is an additional 32-byte overhead for the overwhelmingly
> common case which doesn't need it.  I think the privacy gains are
> worth doing such a thing, but different people reason differently
> about these trade-offs.
>
> It turns out, however, that there is no need to make a trade-off.  The
> special case of a top level "threshold-signature OR
> arbitrary-conditions" can be made indistinguishable from a normal
> one-party signature, with no overhead at all, with a special
> delegating CHECKSIG which I call Taproot.
>
> Let's say we want to create a coin that can be redeemed by either
> Alice && Bob   or by CSV-timelock && Bob.
>
> Alice has public A, Bob has pubkey B.
>
> We compute the 2-of-2 aggregate key C = A + B.  (Simplified; to
> protect against rogue key attacks you may want to use the MuSig key
> aggregation function [1])
>
> We form our timelock script S =  " OP_CSV OP_DROP B 
> OP_CHECKSIGVERIFY"
>
> Now we tweak C to produce P which is the key we'll publish: P = C + H(C||S)G.
>
> (This is the attack hardened pay-to-contract construction described in [2])
>
> Then we pay to a