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

On Wed, 2018-01-24 at 19:51 +0100, Natanael wrote: > > That's not the type of attack I'm imagining. Both versions of your > scheme are essentially equivalent in terms of this attack. > > Intended steps: > 1: You publish a hash commitment. > 2: The hash ends up in the blockchain. > 3: You

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

Den 24 jan. 2018 16:38 skrev "Tim Ruffing via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: Okay, I think my proposal was wrong... This looks better (feel free to break again): 1. Commit (H(classic_pk, tx), tx) to the blockchain, wait until confirmed 2. Reveal classic_pk in the

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

Den 25 jan. 2018 00:22 skrev "Tim Ruffing via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: I think you misread my second proposal. The first step is not only to publish the hash but to publish a *pair* consisting of the hash and the transaction. If the attacker changes the transaction

[bitcoin-dev] Merge of protocol

2017 was fork year, Is it technically possible to merge two protocoles ? And thus bringing the strength of both into one resulting coin. I would not be surprized to see a lot of altcoin wanting to merge with bitcoin or between them, especially with LN current development, if it is possible, If

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

So, OP, in your scenario, you have 1 transaction in the mempool, A, then you want to spend the change before confirmation, so you broadcast a new transaction, B, which replaces A. > Because the size of the merged transaction is smaller than the original transactions, unless there is a

Re: [bitcoin-dev] Merge of protocol

If the communities behind two coins wanted to merge, it would be possible, but difficulty and risky. It represents a hard fork on both chains. Not only does each coin's community need to agree, the two communities need to agree with each other. They would both have to agree the join point. The

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

On Wed, 2018-01-24 at 01:52 +, Andrew Poelstra via bitcoin-dev wrote: > > > They are. But I don't believe that is relevant; the attacker would > > simply steal the coins on spend. > > > Then the system would need to be hardforked to allow spending through > a > quantum-resistant ZKP of

Re: [bitcoin-dev] Why is deriving public key from the signature not used in Segwit?

34 bytes in fact I have asked already the question at least twice on this list pointing out the fact that pubkey is there now even for standard p2pkh transactions and it was not the case some time ago But I never got any answer regarding what motivated this change (compared to the previous

Re: [bitcoin-dev] Why is deriving public key from the signature not used in Segwit?

On Wed, Jan 24, 2018 at 10:24 AM, Aymeric Vitte wrote: > out the fact that pubkey is there now even for standard p2pkh > transactions and it was not the case some time ago > > But I never got any answer regarding what motivated this change > (compared to the previous

Re: [bitcoin-dev] Why is deriving public key from the signature not used in Segwit?

Then what about https://blockchain.info/tx/226a8b08dc46a00e9ecec5567a303a0b354bef3c1674476eb5e4b627b2ace493?format=hex ? Scriptsig: 473044022057a1234709270325e7215200f982546304cf465971cbd55d54231ead54ef1a7802207a82e93ef2b0f87188abe87bccb67ee9d5c650b1b58948e5b1c80ba1b4c43dc301 No pubkey... Le

Re: [bitcoin-dev] Why is deriving public key from the signature not used in Segwit?

Indeed... I would have bet that I had other examples with p2pkh this time but apparently I imagined it Le 24/01/2018 à 12:35, Gregory Maxwell a écrit : > On Wed, Jan 24, 2018 at 11:16 AM, Aymeric Vitte > wrote: >> Then what about >>

Re: [bitcoin-dev] Why is deriving public key from the signature not used in Segwit?

On Wed, Jan 24, 2018 at 11:16 AM, Aymeric Vitte wrote: > Then what about > https://blockchain.info/tx/226a8b08dc46a00e9ecec5567a303a0b354bef3c1674476eb5e4b627b2ace493?format=hex > ? > > Scriptsig: > >

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

Den 23 jan. 2018 23:45 skrev "Gregory Maxwell via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: On Tue, Jan 23, 2018 at 10:22 PM, Anthony Towns wrote: > Hmm, at least people can choose not to reuse addresses currently -- > if everyone were using taproot and that

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

On Wed, 2018-01-24 at 13:51 +0100, Natanael via bitcoin-dev wrote: > Sidenote: There's a risk here with interception, insertion of a new > commitment and getting the new transaction into the blockchain first. > However, I would suggest a mining policy here were two known > conflicting transactions