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

[Peter Todd via bitcoin-dev]

On Tue, Jan 23, 2018 at 10:49:34PM +, Gregory Maxwell via bitcoin-dev wrote:
> On Tue, Jan 23, 2018 at 10:19 PM, Rhavar via bitcoin-dev
>  wrote:
> > Interesting. I didn't think about this before, but it seems like bip125 is
> > rather incentive incompatible right now? If we're assuming a competitive
> > mempool, it really doesn't seem generally rational to accept a replacement
> > transaction of a lower fee rate.
> 
> BIP125 replacement requires that the fee rate increases.  The text of
> the BIP document is written in a confusing way that doesn't make this
> clear.

In fact I considered only requiring an increase in fee rate, based on the
theory that if absolute fee went down, the transaction must be smaller and thus
miners could overall earn more from the additional transactions they could fit
into their block. But to do that properly requires considering whether or not
that's actually true in the particular state the mempool as a whole happens to
be in, so I ditched that idea early on for the much simpler criteria of both a
feerate and absolute fee increase.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


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

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

[Peter Todd via bitcoin-dev]

On Tue, Jan 23, 2018 at 09:31:00PM +, Gregory Maxwell wrote:
> On Mon, Jan 22, 2018 at 8:00 PM, Peter Todd via bitcoin-dev
>  wrote:
> > Most transactions don't have change?! Under what circumstance? For most
> > use-cases the reverse is true: almost all all transactions have change, 
> > because
> > it's rare for the inputs to exactly math the requested payment.
> 
> It's quite easy to get no change with a not-dumb algorithm selecting
> coins if you have a decent number of outputs well under the value
> you're paying.
> 
> The number of ways n choose m combines grows exponentially, and you
> only need to get close enough over the right value so that you're
> paying excess fees equal or less than the cost of the change (which
> should include the current cost output itself as well as estimated
> cost of the future signature to spend it).
> 
> Achow101 and Murch have code to implement an efficient algorithm for
> finding these solutions for Bitcoin core which will hopefully get in
> soon.

Oh, Bitcoin Core doesn't already do that? I though that was what the (rather
complex) knapsack code was supposed to be doing.

In any case, you're assuming that there actually are a large number of outputs.
That's not likely to be the case in most "consumer-like" use-cases where the
number of deposits into the wallet is relatively low compared to the number of
withdrawls as coins are spent in smaller amounts; that's the pattern most of my
Bitcoin usage follows, particularly as I keep the amount of funds in my hot
wallets low.

Having said that, Rhavar's usage patterns could easily be different; I'd be
completely wrong in the case of a payment service for instance where a large
number of deposits are aggregated into a smaller number of payments; that
use-case happens to be a particularly interesting one for using tx replacement
to add outputs, so my criticism was definitely premature.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


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

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

[Gregory Maxwell via bitcoin-dev]

On Wed, Jan 24, 2018 at 3:50 AM, Артём Литвинович via bitcoin-dev
 wrote:
> Greetings.
>
> I wanted to ask what was the rationale behind still having both public
> key and signature in Segwit witness?
>
> As is known for a while, the public key can be derived from the
> signature and a quadrant byte, a trick that is successfully used both
> in Bitcoin message signing algorithm and in Ethereum transaction
> signatures. The later in particular suggests that this is a perfectly
> functional and secure alternative.
> Leaving out the public key would have saved 33 bytes per signature,
> which is quite a lot.
>
> So, the question is - was there a good reason to do it the old way
> (security, performance, privacy, something else?), or was it something
> that haven't been thought of/considered at the time?

It is slow to verify, incompatible with batch validation, doesn't save
space if hashing isn't used, and is potentially patent encumbered.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Артём Литвинович via bitcoin-dev]

Greetings.

I wanted to ask what was the rationale behind still having both public
key and signature in Segwit witness?

As is known for a while, the public key can be derived from the
signature and a quadrant byte, a trick that is successfully used both
in Bitcoin message signing algorithm and in Ethereum transaction
signatures. The later in particular suggests that this is a perfectly
functional and secure alternative.
Leaving out the public key would have saved 33 bytes per signature,
which is quite a lot.

So, the question is - was there a good reason to do it the old way
(security, performance, privacy, something else?), or was it something
that haven't been thought of/considered at the time?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] 2 step confirmation system

[Rhavar via bitcoin-dev]

1. Bitcoin addresses contain a "checksum", which means it's pretty much 
impossible to fat finger any address. (Note: most altcoins don't seem to do 
this, so fat-fingering is very much a risk). If you can send to an address, you 
can be sure there is no mistake.

However, there is a real risk of malware. I see on a daily basis people who 
send to the *wrong* address, because for example they have malware on their 
computer which replaces a the intended address with one controlled by the 
malware author. So verifying you are sending to the correct address is very 
much still a concern, but there's no risk you type a 2 instead of 3 and send to 
the wrong place.

2.  Google "bitcoin multisig" and "bitcoin escrow". In the core bitcoin 
protocol there's a lot of support that enables stuff like that -- but nothing 
that is really commonly used. I've done some very large deals with bitcoin, 
with the use of "2 of 3 multisig" (basically 2 of: me, counter-party, 
arbitrator)  need to sign off on it. However it's a big pain in the ass, with 
poor tooling and expensive transactions. Unless you're dealing with 100+ 
bitcoin, it's a lot easier for everyone to just use a trusted (single party) 
escrow.

-Ryan

 Original Message 
On January 23, 2018 7:42 PM, rmcc via bitcoin-dev 
 wrote:

> I know from speaking to my friends not involved with Bitcoin that two of 
> their major concerns are as follows:
>
> 1. They are afraid if they fat finger the address there is nothing they can 
> do about it and not get their Bitcoin back.
>
> and/or
>
> 2. They would like to at least have the option to use some sort of 2 step 
> confirmation system when dealing ith people they do not know. For example, 
> after sending the Bitcoin to a seller they would like to be able to do a 
> final approval of the tm transaction. If the 2 people involved in the 
> transaction approve of it within X hours, the coin returns to the original 
> person. This system would basically act as an escrow.
>
> This 2 step system could work with both of these.
>
> I apologize if this is the incorrect place to post this. I did not know where 
> else to share these thoughts.
>
> Thanks for your time.
>
> --
>
> ** This message was likely sent using voice to text. Please ignore any 
> typos.**___
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

[Andrew Poelstra via bitcoin-dev]

On Tue, Jan 23, 2018 at 10:45:06PM +, Gregory Maxwell via bitcoin-dev wrote:
> 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 didn't involve hashing the key,
> 
> Can you show me a model of quantum computation that is conjectured to
> be able to solve the discrete log problem but which would take longer
> than fractions of a second to do so? Quantum computation has to occur
> within the coherence lifetime of the system.
> 
> > way for individuals to hedge against quantum attacks in case they're ever 
> > feasible, at least that I can see (well, without moving their funds out of 
> > bitcoin anyway)?
> 
> By using scriptpubkeys with actual security against quantum computers
> instead of snake-oil.
> 
> > (It seems like using the point at infinity wouldn't work because
> 
> Indeed, that doesn't work.
> 
> > that when quantum attacks start approaching feasibility. If funds are
> > being held in reused addresses over the long term, that would be more
> 
> 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 knowledge of the hashed public key. I expect
that in a post-quantum world there will be demand for such a fork,
especially if we came into such a world through surprise evidence of
a discrete log break.

-- 
Andrew Poelstra
Mathematics Department, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

"A goose alone, I suppose, can know the loneliness of geese
 who can never find their peace,
 whether north or south or west or east"
   --Joanna Newsom



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

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

[Adam Ficsor via bitcoin-dev]

> It's quite easy to get no change with a not-dumb algorithm selecting
coins if you have a decent number of outputs well under the value
you're paying.

I have been playing around quite a lot these lines, too and created some
content that is worth to look at:
https://github.com/nopara73/ZeroLink/#coin-selection
Also, you can try a simpler privacy oriented coin control implementation
with HiddenWallet:
https://medium.com/@nopara73/coin-control-is-must-learn-if-you-care-about-your-privacy-in-bitcoin-33b9a5f224a2

-- 
Best,
Ádám
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Gregory Maxwell via bitcoin-dev]

On Tue, Jan 23, 2018 at 10:19 PM, Rhavar via bitcoin-dev
 wrote:
> Interesting. I didn't think about this before, but it seems like bip125 is
> rather incentive incompatible right now? If we're assuming a competitive
> mempool, it really doesn't seem generally rational to accept a replacement
> transaction of a lower fee rate.

BIP125 replacement requires that the fee rate increases.  The text of
the BIP document is written in a confusing way that doesn't make this
clear.
___
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

[Gregory Maxwell via bitcoin-dev]

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 didn't involve hashing the key,

Can you show me a model of quantum computation that is conjectured to
be able to solve the discrete log problem but which would take longer
than fractions of a second to do so? Quantum computation has to occur
within the coherence lifetime of the system.

> way for individuals to hedge against quantum attacks in case they're ever 
> feasible, at least that I can see (well, without moving their funds out of 
> bitcoin anyway)?

By using scriptpubkeys with actual security against quantum computers
instead of snake-oil.

> (It seems like using the point at infinity wouldn't work because

Indeed, that doesn't work.

> that when quantum attacks start approaching feasibility. If funds are
> being held in reused addresses over the long term, that would be more

They are. But I don't believe that is relevant; the attacker would
simply steal the coins on spend.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Rhavar via bitcoin-dev]

Interesting. I didn't think about this before, but it seems like bip125 is 
rather incentive incompatible right now? If we're assuming a competitive 
mempool, it really doesn't seem generally rational to accept a replacement 
transaction of a lower fee rate.

So how about if we change the fee requirement to bet at least:

MIN(
 $ORIGINAL_FEE_RATE * $REPLACEMENT_TX_SIZE + $RELAY_FEE * ( 
REPLACEMENT_TX_SIZE + $ORIGINAL_SIZE),
$ORIGINAL_ABS_FEE  / 3
)  in fees

This could make it:
* More incentive compatible
* Support more use-cases (my transaction merging example)
* Be resistant to any attacks (that I can see, there's no doubt cases I haven't 
thought about)

-Ryan

 Original Message 
On January 23, 2018 4:56 PM, Moral Agent  wrote:

> Another way to limit abuse would be to have the fee *rate* be required to 
> increase, which is kind of the spirit of RBF, applied to this situation.
>
> That is to say, if you wished to replace transactions A and B with C which 
> spends the same inputs as A and B, then the following must be true before C 
> will be relayed:
>
> (Fee_A + Fee_B) / (Weight_A + Weight_B) < Fee_C / Weight_C
>
> On Tue, Jan 23, 2018 at 11:31 AM, Rhavar via bitcoin-dev 
>  wrote:
>
>> Getting back on topic:
>>
>>> It would definitely introduce DoS vectors by making it much cheaper to use
>>> relay bandwidth.
>>
>> I think I'm missing something, as I don't really understand this DoS vector. 
>> Relay bandwidth is already very cheap and easy to use by repeatedly fee 
>> bumping. And it's not obvious to me that requiring an absolute higher fee 
>> actually makes such an attack more expensive.
>>
>> I can see that my "proposed" change would make it cheaper to evict low-fee 
>> transactions from other node's mempool. Maybe I'm being naive, but I don't 
>> really see why this would be such a big deal.
>>
>> But what about a compromise, and require that the absolute fee must be >= 
>> half the original fees. I know everyone hates magic values, but I think in 
>> practice it will allow legitimate and useful use of "retroactive transaction 
>> merging" without much downside.
>>
>> And really the great thing about "retroactive transaction merging" is just 
>> how easy it is to implement. In fact, right now it's quite possible to do -- 
>> but because of the "higher absolute fee" rule the benefits are pretty muted 
>> (although if you can compress 2 change into 1, that's still likely 
>> worthwhile)
>>
>> -Ryan
>>
>>  Original Message 
>> On January 22, 2018 3:00 PM, Peter Todd  wrote:
>>
>>> On Mon, Jan 22, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev wrote:
>>>
 So my half-baked idea is very simple:
 Allow users to merge multiple unconfirmed transactions, stripping 
 extraneous inputs and change as they go.
 This is currently not possible because of the bip125 rule:
 "The replacement transaction pays an absolute fee of at least the sum paid 
 by the original transactions."
 Because the size of the merged transaction is smaller than the original 
 transactions, unless there is a considerable feerate bump, this rule isn't 
 possible to observe.
 I my question is: is it possible or reasonable to relax this rule? If this 
 rule was removed in its entirety, does it introduce any DoS vectors? Or 
 can it be changed to allow my use-case?
>>>
>>> It would definitely introduce DoS vectors by making it much cheaper to use
>>> relay bandwidth. You'd also be able to push others' txs out of the mempool.
>>>
 ---
 Full backstory: I have been trying to use bip125 (Opt-in Full 
 Replace-by-Fee) to do "transaction merging" on the fly. Let's say that I 
 owe John 1 bitcoin, and have promised to pay him immediately: Instead of 
 creating a whole new transaction if I have an in-flight (unconfirmed) 
 transaction, I can follow the rules of bip125 to create a replacement that 
 accomplishes this goal.
 From a "coin selection" point of view, this was significantly easier than
 I had anticipated. I was able to encode the rules in my linear model and
 feed in all my unspent and in-flight transactions and it can solve it 
 without difficulty.
 However, the real problem is tracking the mess. Consider this sequence of 
 events:

 - I have unconfirmed transaction A
 - I replace it with B, which pays John 1 BTC
 - Transaction A gets confirmed
 So now I still owe John 1 BTC, however it's not immediately clear if
 it's safe to send to him without waiting $n transactions. However even
 for a small $n, this breaks my promise to pay him immediately.
 One possible solution is to only consider a transaction "replaceable" if 
 it has change, so if the original transaction confirms -- payments can 
 immediately 

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

[Anthony Towns via bitcoin-dev]

On Tue, Jan 23, 2018 at 01:15:38PM +, Gregory Maxwell wrote:
> On Tue, Jan 23, 2018 at 6:44 AM, Anthony Towns  wrote:
> > Is this really intended as paying directly to a pubkey, instead of a
> > pubkey hash?
> > If so, isn't that a step backwards with regard to resistance to quantum
> > attacks against ECC?
> Considering the considerable level of address reuse -- I recall prior
> stats that a majority of circulating funds are on addresses that had
> previously been used, on top of the general race limitations-- I am
> now dubious to the idea that hashing provides any kind of meaningful
> quantum resistance and somewhat regret introducing that meme to the
> space in the first place. If we considered quantum resistance a
> meaningful concern we should address that specifically.  --- so I
> don't think that should be a factor that drives a decision here.

Hmm, at least people can choose not to reuse addresses currently --
if everyone were using taproot and that didn't involve hashing the key,
there would be no way for individuals to hedge against quantum attacks
in case they're ever feasible, at least that I can see (well, without
moving their funds out of bitcoin anyway)?

Even "X + H(X|script)g" with X being a random point would end up
attackable, since that would almost always end up corresponding with a
valid public key that a successful attack could then find a private key
for.

(It seems like using the point at infinity wouldn't work because 
P = 0+H(0||S)g = H(0||S)g, so as soon as you tried to spend it via S,
someone watching the mempool would know H(0||S), which is the secret key
for P, and be able to spend it via the pubkey path -- no quantum crypto
needed. Or am I missing something?)

Also, if the people currently reusing addresses tend to cycle the funds
through fairly quickly anyway, they might be able to simply stop doing
that when quantum attacks start approaching feasibility. If funds are
being held in reused addresses over the long term, that would be more
of a problem though...

> When collision resistance is needed (as I think it clearly is for
> taproot) you don't get a space savings in the txout from hashing, so
> there is an argument to use the public key directly at least... but
> it's worth considering.  Direct SPK use is also adventitious for being
> able to efficiently ZKP over the UTXO set, e.g. for private solvency
> proofs, but it isn't absolutely mandatory for that (one can hash
> inside the proof, but it's slower).

Yeah, that was one of the assumptions for
http://www.jbonneau.com/doc/DBBCB15-CCS-provisions.pdf iirc. 

(Also, pretty sure you mean "advantageous", but at least I learnt a new
word today)

Cheers,
aj

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

[bitcoin-dev] BIP16 enforcement change in V0.16

[John Newbery via bitcoin-dev]

The upcoming v0.16 release contains a slight change to the way that BIP16
is enforced, by basing activation on block height instead of block time.
This brings BIP 16 enforcement in line with BIP 34, BIP 66 and BIP 65.

This has no impact on consensus since BIP 16 was activated before the last
checkpoint and is buried under >300,000 blocks.

I've written up the changes in the BIP style below, although I don't think
this necessarily requires a full BIP. BIP 16 enforcement will likely change
again with https://github.com/bitcoin/bitcoin/pull/11739 in the next
bitcoin core release, so a formal proposal for this as a BIP will quickly
be superseded.


  BIP: ??
  Layer: Consensus
  Title: Buried Deployments (P2SH)
  Author: John Newbery 
  Comments-Summary: No comments yet
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-
  Status: Draft
  Type: Informational
  Created: 2018-01-22
  License: CC-0



==Abstract==

Enforce BIP 16 consensus rules based on block height rather than block time.

==Background==

BIP 16 was deployed via a hardcoded flag day consensus rule change. Prior
to the date of the consensus rule change being fixed, the miners signaled
readiness for the change by placing the string "/P2SH/" in the scriptSig of
the coinbase transaction txIn. The rule change was originally intended to
come into effect on 15 Feb 2012, but due to lack of miner signaling, the
activation date was pushed back to April 1st 2012. See [
https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki The BIP 16
specification] for full details on the deployment method. The final
activation method was via a hardcoded block time of 1333238400 (April 1st
2012).

Now that the chain has long since passed the block at which the P2SH
consensus rule was activated, we can (as a simplification) replace the
trigger mechanism by caching the block height at which those consensus
rules became enforced.

==Motivation==

Activating the BIP 16 consensus change based on block time has several
disadvantages:

* The consensus change can be activated and later deactivated in the same
chain (since block time is not necessarily monotonically increasing).
* It is less flexible for constructing test chains for testing P2SH and
other soft fork activation

The flag day activation mechanism for code deployments was deprecated in
favor of [https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
IsSuperMajority] deployments, and later by [
https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki version
bits] deployments.

BIP 34, BIP 65, and BIP 66 deployments were later 'buried' by [
https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki BIP 90] with
simple height checks. This simplification of the consensus rules reduced
the technical debt associated with deployment of those consensus changes.

This BIP changes the BIP 16 activation method to also be a 'buried'
deployment, activating at the block height that BIP 16 actually activated.
For the mainnet chain, this is block height 173805.

==Considerations==

Just as for the buried BIP 34, BIP 65 and BIP 66 deployments, it is
technically possible for this to be a non-backwards compatible change. For
example, if an alternate chain were created in which block height 173805
was reached after April 1st 2012, and a block with height <173805 but block
time after April 1st 2012 included an invalid P2SH spend, older software
would see that chain as invalid, but newer software implementing this
change would not.

See [https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki BIP 90]
for justification of why this class of change is acceptable. As of January
2018, BIP 16 is buried by over 300,000 blocks. BIP 16 activation is also
protected by checkpoints (the most recent of which is at height 295000).

==Specification==

The BIP 16 activation height is set to 173805.

To determine whether to enforce BIP 16 on a given block, we just compare
the height of the block being validated with the stored activation height:

// Start enforcing P2SH (BIP16)
if (pindex->nHeight >= consensusparams.BIP16Height) {
flags |= SCRIPT_VERIFY_P2SH;
}

See the implementation for additional details.

==Implementation==

https://github.com/bitcoin/bitcoin/commit/18e071841e83044b47aa45c3e98c0796a407d445

==Acknowledgements==

Thanks to Russ Yanofsky, Marco Falke and Suhas Daftuar for suggestions and
feedback.

==Copyright==

This document is placed in the public domain.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Moral Agent via bitcoin-dev]

Another way to limit abuse would be to have the fee *rate* be required to
increase, which is kind of the spirit of RBF, applied to this situation.

That is to say, if you wished to replace transactions A and B with C which
spends the same inputs as A and B, then the following must be true before C
will be relayed:

(Fee_A + Fee_B) / (Weight_A + Weight_B) < Fee_C / Weight_C

On Tue, Jan 23, 2018 at 11:31 AM, Rhavar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Getting back on topic:
>
>
> It would definitely introduce DoS vectors by making it much cheaper to use
> relay bandwidth.
>
>
> I think I'm missing something, as I don't really understand this DoS
> vector. Relay bandwidth is already very cheap and easy to use by repeatedly
> fee bumping. And it's not obvious to me that requiring an absolute higher
> fee actually makes such an attack more expensive.
>
> I can see that my "proposed" change would make it cheaper to evict low-fee
> transactions from other node's mempool. Maybe I'm being naive, but I don't
> really see why this would be such a big deal.
>
> But what about a compromise, and require that the absolute fee must be >=
> half the original fees. I know everyone hates magic values, but I think in
> practice it will allow legitimate and useful use of "retroactive
> transaction merging" without much downside.
>
> And really the great thing about "retroactive transaction merging" is just
> how easy it is to implement. In fact, right now it's quite possible to do
> -- but because of the "higher absolute fee" rule the benefits are pretty
> muted (although if you can compress 2 change into 1, that's still likely
> worthwhile)
>
>
>
> -Ryan
>
>
>  Original Message 
> On January 22, 2018 3:00 PM, Peter Todd  wrote:
>
> On Mon, Jan 22, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev wrote:
>
> So my half-baked idea is very simple:
> Allow users to merge multiple unconfirmed transactions, stripping
> extraneous inputs and change as they go.
> This is currently not possible because of the bip125 rule:
> "The replacement transaction pays an absolute fee of at least the sum paid
> by the original transactions."
> Because the size of the merged transaction is smaller than the original
> transactions, unless there is a considerable feerate bump, this rule isn't
> possible to observe.
> I my question is: is it possible or reasonable to relax this rule? If this
> rule was removed in its entirety, does it introduce any DoS vectors? Or can
> it be changed to allow my use-case?
>
>
> It would definitely introduce DoS vectors by making it much cheaper to use
> relay bandwidth. You'd also be able to push others' txs out of the mempool.
>
>
> --
>
> Full backstory: I have been trying to use bip125 (Opt-in Full
> Replace-by-Fee) to do "transaction merging" on the fly. Let's say that I
> owe John 1 bitcoin, and have promised to pay him immediately: Instead of
> creating a whole new transaction if I have an in-flight (unconfirmed)
> transaction, I can follow the rules of bip125 to create a replacement that
> accomplishes this goal.
> From a "coin selection" point of view, this was significantly easier than
> I had anticipated. I was able to encode the rules in my linear model and
> feed in all my unspent and in-flight transactions and it can solve it
> without difficulty.
> However, the real problem is tracking the mess. Consider this sequence of
> events:
>
>1. I have unconfirmed transaction A
>2. I replace it with B, which pays John 1 BTC
>3. Transaction A gets confirmed
>
> So now I still owe John 1 BTC, however it's not immediately clear if
> it's safe to send to him without waiting $n transactions. However even
> for a small $n, this breaks my promise to pay him immediately.
> One possible solution is to only consider a transaction "replaceable" if
> it has change, so if the original transaction confirms -- payments can
> immediately be made that source the change, and provide safety in a reorg.
> However, this will only work <50% of the time for me (most transactions
> don't have change) and opens a pandora's box of complexity.
>
>
> Most transactions don't have change?! Under what circumstance? For most
> use-cases the reverse is true: almost all all transactions have change,
> because
> it's rare for the inputs to exactly math the requested payment.
>
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
>
>
> ___
> 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] Taproot: Privacy preserving switchable scripting

[Gregory Maxwell via bitcoin-dev]

On Tue, Jan 23, 2018 at 9:23 PM, Matt Corallo via bitcoin-dev
 wrote:
> The issue with that approach without support for the privacy-encouraging
> wrapper proposed by Greg here is that it encourages adoption halfway and
> destroys a lot of the value of the apparent-script monoculture for privacy
> preservation. Greg's proposal here doesn't change the format of any specific
> MAST implementation, but instead adds the privacy wrapper that I always felt
> was missing in existing proposals, without any real additional overhead in
> many use-cases!
>
> Indeed, permissionless innovation is important, but the huge advantage of
> providing the privacy wrapper by default here is absolutely massive to the
> ecosystem and should not be handwaved away for vague possibly-advantages.

Even if to someone who didn't care about anyone's privacy at all,
non-taproot is simply inefficient.  In the (I argue) overwhelmingly
common case of everyone-agrees simple hash based branching requires a
30% overhead to communicate the commitment to the untaken branch (and
worse in the case of extensive aggregation).  I don't think an
argument can be sustained in favor of that kind of communications
overhead.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Gregory Maxwell via bitcoin-dev]

On Mon, Jan 22, 2018 at 8:00 PM, Peter Todd via bitcoin-dev
 wrote:
> Most transactions don't have change?! Under what circumstance? For most
> use-cases the reverse is true: almost all all transactions have change, 
> because
> it's rare for the inputs to exactly math the requested payment.

It's quite easy to get no change with a not-dumb algorithm selecting
coins if you have a decent number of outputs well under the value
you're paying.

The number of ways n choose m combines grows exponentially, and you
only need to get close enough over the right value so that you're
paying excess fees equal or less than the cost of the change (which
should include the current cost output itself as well as estimated
cost of the future signature to spend it).

Achow101 and Murch have code to implement an efficient algorithm for
finding these solutions for Bitcoin core which will hopefully get in
soon.
___
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

[Matt Corallo via bitcoin-dev]

The issue with that approach without support for the privacy-encouraging 
wrapper proposed by Greg here is that it encourages adoption halfway and 
destroys a lot of the value of the apparent-script monoculture for privacy 
preservation. Greg's proposal here doesn't change the format of any specific 
MAST implementation, but instead adds the privacy wrapper that I always felt 
was missing in existing proposals, without any real additional overhead in many 
use-cases!

Indeed, permissionless innovation is important, but the huge advantage of 
providing the privacy wrapper by default here is absolutely massive to the 
ecosystem and should not be handwaved away for vague possibly-advantages.

Matt

On January 23, 2018 2:39:37 PM UTC, Mark Friedenbach  
wrote:
>I had the opposite response in private, which I will share here. As
>recently as Jan 9th feedback on BIP 117 was shared on this list by
>Pieter Wuille and others suggesting we adopt native MAST template
>instead of the user programmable combination of BIPs 116 and 117. Part
>of my response then was, I quote:
>
>I havent the hubris to suggest that we know exactly what a templated
>MAST *should* look like. It's not used in production anywhere. Even if
>we did have the foresight, the tail-call semantics allow for other
>constructions besides MAST and for the sake of the future we should
>allow such permission-less innovation. The proper sequence of events
>should be to enable features in a generic way, and then to create
>specialized templates to save space for common constructions. Not the
>other way around. [1]
>
>I take this advance as further evidence in favor of this view. As
>recently as 24 hours ago if you had asked what a native-MAST template
>would have looked like, the answer would have been something like
>Johnson Lau’s BIP 114, with some quibbling over details. Taproot is a
>clearly superior approach. But is it optimal? I don’t think we can
>claim that now. Optimality of these constructs isn’t something easily
>proven, with the nearest substitute being unchanging consensus over
>extended periods of time.
>
>Every time we add an output type specialization, we introduce a new
>codepath in the core of the script consensus that must be maintained
>forever. Take P2SH: from this point forward there is no reason to use
>it in new applications, ever. But it must be forever supported. In an
>alternate universe we could have deployed a native MAST proposal, like
>BIP 114, only to have Taproot-like schemes discovered after activation.
>That would have been a sucky outcome. It is still the case that we
>could go for Taproot right now, and then in six months or a year’s time
>we find an important tweak or a different approach entirely that is
>even better, but the activation process had already started. That would
>be a sucky outcome we haven’t avoided yet.
>
>This is not an argument against template specialization for common code
>paths, especially those which increase fungibility of coins. I do think
>we should have a native MAST template eventually, using Taproot or
>something better. However if I may be allowed I will make an educated
>guess about the origin of Taproot: I think it’s no coincidence that
>Greg had this insight and/or wrote it up simultaneous with a push by
>myself and others for getting MAST features into bitcoin via BIPs 98,
>116, and 117, or 114. Cryptographers tend to only think up solutions to
>problems that are on their minds. And the problems on most people’s
>minds are primarily those that are deployable today, or otherwise
>near-term applicable.
>
>BIPS 116 and 117 each provide a reusable component that together
>happens to enable a generic form of MAST. Even without the workarounds
>required to avoid CLEANSTACK violations, the resulting MAST template is
>larger than what is possible with specialization. However let’s not
>forget that (1) they also enable other applications like honeypots, key
>trees, and script delegation; and relevant to this conversation (2)
>they get the MAST feature available for use in production by the wider
>community. I don’t think I’d personally be willing to bet that we found
>the optimal MAST structure in Greg’s Taproot until we have people doing
>interesting production work like multisig wallets, lightning protocol,
>and the next set of consensus features start putting it into production
>and exploring edge cases. We may find ways Taproot can be tweaked to
>enable other applications (like encoding a hash preimage as well) or
>simplify obscure corner cases.
>
>I feel quite strongly that the correct approach is to add support for
>generic features to accomplish the underlying goal in a user
>programmable way, and THEN after activation and some usage consider
>ways in which common use cases can be made more efficient through
>output specialization. To take a more obvious example, lightning
>protocol is still an active area or research and I think it is
>abundantly clear that we 

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

[Rhavar via bitcoin-dev]

Getting back on topic:

> It would definitely introduce DoS vectors by making it much cheaper to use
> relay bandwidth.

I think I'm missing something, as I don't really understand this DoS vector. 
Relay bandwidth is already very cheap and easy to use by repeatedly fee 
bumping. And it's not obvious to me that requiring an absolute higher fee 
actually makes such an attack more expensive.

I can see that my "proposed" change would make it cheaper to evict low-fee 
transactions from other node's mempool. Maybe I'm being naive, but I don't 
really see why this would be such a big deal.

But what about a compromise, and require that the absolute fee must be >= half 
the original fees. I know everyone hates magic values, but I think in practice 
it will allow legitimate and useful use of "retroactive transaction merging" 
without much downside.

And really the great thing about "retroactive transaction merging" is just how 
easy it is to implement. In fact, right now it's quite possible to do -- but 
because of the "higher absolute fee" rule the benefits are pretty muted 
(although if you can compress 2 change into 1, that's still likely worthwhile)

-Ryan

 Original Message 
On January 22, 2018 3:00 PM, Peter Todd  wrote:

> On Mon, Jan 22, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev wrote:
>
>> So my half-baked idea is very simple:
>> Allow users to merge multiple unconfirmed transactions, stripping extraneous 
>> inputs and change as they go.
>> This is currently not possible because of the bip125 rule:
>> "The replacement transaction pays an absolute fee of at least the sum paid 
>> by the original transactions."
>> Because the size of the merged transaction is smaller than the original 
>> transactions, unless there is a considerable feerate bump, this rule isn't 
>> possible to observe.
>> I my question is: is it possible or reasonable to relax this rule? If this 
>> rule was removed in its entirety, does it introduce any DoS vectors? Or can 
>> it be changed to allow my use-case?
>
> It would definitely introduce DoS vectors by making it much cheaper to use
> relay bandwidth. You'd also be able to push others' txs out of the mempool.
>
>> ---
>>
>> Full backstory: I have been trying to use bip125 (Opt-in Full 
>> Replace-by-Fee) to do "transaction merging" on the fly. Let's say that I owe 
>> John 1 bitcoin, and have promised to pay him immediately: Instead of 
>> creating a whole new transaction if I have an in-flight (unconfirmed) 
>> transaction, I can follow the rules of bip125 to create a replacement that 
>> accomplishes this goal.
>> From a "coin selection" point of view, this was significantly easier than
>> I had anticipated. I was able to encode the rules in my linear model and
>> feed in all my unspent and in-flight transactions and it can solve it 
>> without difficulty.
>> However, the real problem is tracking the mess. Consider this sequence of 
>> events:
>>
>> - I have unconfirmed transaction A
>> - I replace it with B, which pays John 1 BTC
>> - Transaction A gets confirmed
>>
>> So now I still owe John 1 BTC, however it's not immediately clear if
>> it's safe to send to him without waiting $n transactions. However even
>> for a small $n, this breaks my promise to pay him immediately.
>> One possible solution is to only consider a transaction "replaceable" if it 
>> has change, so if the original transaction confirms -- payments can 
>> immediately be made that source the change, and provide safety in a reorg.
>> However, this will only work <50% of the time for me (most transactions
>> don't have change) and opens a pandora's box of complexity.
>
> Most transactions don't have change?! Under what circumstance? For most
> use-cases the reverse is true: almost all all transactions have change, 
> because
> it's rare for the inputs to exactly math the requested payment.
>
> https://petertodd.org 'peter'[:-1]@petertodd.org___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Suggestion to remove word from BIP39 English wordlist

[Ronald van der Meer via bitcoin-dev]

I’m new to this so what is the next step?

--
Ronald van der Meer

E: ron...@vandermeer.frl | W: 
https://www.vandermeer.frl
S: https://twitter.com/truly_secure

GPG: 8203 CE3E 064D C462 1D22 F635 A1EC 45F9 645F 878D



From: bitcoin-dev-boun...@lists.linuxfoundation.org 
[mailto:bitcoin-dev-boun...@lists.linuxfoundation.org] On Behalf Of Alan Evans 
via bitcoin-dev
Sent: donderdag 18 januari 2018 22:29
To: Matthew Clancy 
Cc: Bitcoin Protocol Discussion 
Subject: Re: [bitcoin-dev] Suggestion to remove word from BIP39 English wordlist


> and then agree that by convention,  the words 'satoshi' or the alternative 
> word will represent the same number on the list

That convention would be the alternative to BIP0039 I am referring to.


On Thu, Jan 18, 2018 at 4:49 PM, Matthew Clancy 
> wrote:
I would disagree here:

>But most of all:
>7. Removing a word or changing a list *is impossible* as verification of an
>existing mnemonic requires the list. To change one word, you would need to
>provide an alternative to BIP0039 to cope with alternative words, or change
>all the words to a completely new set of 2048 English words so that it is
>clear which wordlist is in use.

All that really would need to be done is select another word that is not on the 
2048 list, and then agree that by convention,  the words 'satoshi' or the 
alternative word will represent the same number on the list. It seems to be to 
be a fairly simple thing to implement.



___
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

[Greg Sanders via bitcoin-dev]

Interesting parallels to current Elements sidechain peg-in functionality.
User tweaks the watchmen(BTC holder) pubkey using P2CH, committing to a
script that is used on the *sidechain side* as spending authorization for
that bitcoin output rather than mainnet.

I think composing the two can be done as:

P = C' + H(C'||S')G + H(C||S)G

where C is redefined as `C' + H(C'||S')G`, which for Bitcoin consensus
purposes is just a single pubkey.



On Mon, Jan 22, 2018 at 7:30 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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 scriptPubKey of [Taproot supporting version] [EC point P].
>
> Now Alice and Bob-- assuming they are both online and agree about the
> resolution of their contract-- can jointly form a 2 of 2 signature for
> P, and spend as if it were a payment to a single party (one of them
> just needs to add H(C||S) to their private key).
>
> Alternatively, the Taproot consensus rules would allow this script to
> be satisfied by someone who provides the network with C (the original
> combined pubkey), S, and does whatever S requires-- e.g. passes the
> CSV check and provides Bob's signature. With this information the
> network can verify that C + H(C||S) == P.
>
> So in the all-sign case there is zero overhead; and no one can tell
> that the contract alternative exists. In the alternative redemption
> branch the only overhead is revealing the original combined pubkey
> and, of course, the existence of the contract is made public.
>
> This composes just fine with whatever other merkelized script system
> we might care to use, as the S can be whatever kind of data we want,
> including the root of some tree.
>
> My example shows 2-of-2 but it works the same for any number of
> participants (and with setup interaction any threshold of
> participants, so long as you don't mind an inability to tell which
> members signed off).
>
> The verification computational complexity of signature path is
> obviously the same as any other plain signature (since its
> indistinguishable). Verification of the branch redemption requires a
> hash and a multiplication with a constant point which is strictly more
> efficient than a signature verification and could be efficiently fused
> into batch signature validation.
>
> The nearest competitor to this idea that I can come up with would
> supporting a simple delegation where the output can be spent by the
> named 

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

[Mark Friedenbach via bitcoin-dev]

I had the opposite response in private, which I will share here. As recently as 
Jan 9th feedback on BIP 117 was shared on this list by Pieter Wuille and others 
suggesting we adopt native MAST template instead of the user programmable 
combination of BIPs 116 and 117. Part of my response then was, I quote:

I havent the hubris to suggest that we know exactly what a templated MAST 
*should* look like. It's not used in production anywhere. Even if we did have 
the foresight, the tail-call semantics allow for other constructions besides 
MAST and for the sake of the future we should allow such permission-less 
innovation. The proper sequence of events should be to enable features in a 
generic way, and then to create specialized templates to save space for common 
constructions. Not the other way around. [1]

I take this advance as further evidence in favor of this view. As recently as 
24 hours ago if you had asked what a native-MAST template would have looked 
like, the answer would have been something like Johnson Lau’s BIP 114, with 
some quibbling over details. Taproot is a clearly superior approach. But is it 
optimal? I don’t think we can claim that now. Optimality of these constructs 
isn’t something easily proven, with the nearest substitute being unchanging 
consensus over extended periods of time.

Every time we add an output type specialization, we introduce a new codepath in 
the core of the script consensus that must be maintained forever. Take P2SH: 
from this point forward there is no reason to use it in new applications, ever. 
But it must be forever supported. In an alternate universe we could have 
deployed a native MAST proposal, like BIP 114, only to have Taproot-like 
schemes discovered after activation. That would have been a sucky outcome. It 
is still the case that we could go for Taproot right now, and then in six 
months or a year’s time we find an important tweak or a different approach 
entirely that is even better, but the activation process had already started. 
That would be a sucky outcome we haven’t avoided yet.

This is not an argument against template specialization for common code paths, 
especially those which increase fungibility of coins. I do think we should have 
a native MAST template eventually, using Taproot or something better. However 
if I may be allowed I will make an educated guess about the origin of Taproot: 
I think it’s no coincidence that Greg had this insight and/or wrote it up 
simultaneous with a push by myself and others for getting MAST features into 
bitcoin via BIPs 98, 116, and 117, or 114. Cryptographers tend to only think up 
solutions to problems that are on their minds. And the problems on most 
people’s minds are primarily those that are deployable today, or otherwise 
near-term applicable.

BIPS 116 and 117 each provide a reusable component that together happens to 
enable a generic form of MAST. Even without the workarounds required to avoid 
CLEANSTACK violations, the resulting MAST template is larger than what is 
possible with specialization. However let’s not forget that (1) they also 
enable other applications like honeypots, key trees, and script delegation; and 
relevant to this conversation (2) they get the MAST feature available for use 
in production by the wider community. I don’t think I’d personally be willing 
to bet that we found the optimal MAST structure in Greg’s Taproot until we have 
people doing interesting production work like multisig wallets, lightning 
protocol, and the next set of consensus features start putting it into 
production and exploring edge cases. We may find ways Taproot can be tweaked to 
enable other applications (like encoding a hash preimage as well) or simplify 
obscure corner cases.

I feel quite strongly that the correct approach is to add support for generic 
features to accomplish the underlying goal in a user programmable way, and THEN 
after activation and some usage consider ways in which common use cases can be 
made more efficient through output specialization. To take a more obvious 
example, lightning protocol is still an active area or research and I think it 
is abundantly clear that we don’t know yet what the globally optimal layer-2 
caching protocol will be, even if we have educated guesses as to its broad 
structure. A proposal right now to standardize a more compact lightning script 
type would be rightly rejected. It is less obvious but just as true that the 
same should hold for MAST.

I have argued these points before in favor of permission less innovation first, 
then application specialization later, in [1] and at the end of the rather long 
email [2]. I hope you can take the time to read those if you still feel we 
should take a specialized template approach instead of the user programmable 
BIPSs 116 and 117.

[1] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015537.html
 

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

[Adam Back via bitcoin-dev]

Makwa sites [1] https://bitcointalk.org/index.php?topic=311000.0

Seems like they independently rediscovered it.

Adam


On 23 January 2018 at 05:54, Ondřej Vejpustek via bitcoin-dev
 wrote:
>> Yes, this scheme.
>> https://bitcointalk.org/index.php?topic=311000.msg3342217#msg3342217
>
> In addition to the scheme, I found out, that Makwa
> (https://www.bolet.org/makwa/), a hashing function which received a
> special recognition in the Password Hashing Competition, supports a
> delegation. In fact, Makwa is similar to the suggested scheme.
>
> Unfortunately, both schemes have two drawbacks:
>   (1) There is no proof that the host computes what he's suppose to do.
>   (2) The delegation is far more slower than the normal computation.
> According to the Makwa paper
> (https://www.bolet.org/makwa/makwa-spec-20150422.pdf) the delegation is
> typically 100 to 1000 slower. So I see little advantage in delegating.
>
> I doubt there is a scheme that suits our needs.
> ___
> 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] Satoshilabs secret shared private key scheme

[Ondřej Vejpustek via bitcoin-dev]

> Yes, this scheme.
> https://bitcointalk.org/index.php?topic=311000.msg3342217#msg3342217

In addition to the scheme, I found out, that Makwa
(https://www.bolet.org/makwa/), a hashing function which received a
special recognition in the Password Hashing Competition, supports a
delegation. In fact, Makwa is similar to the suggested scheme.

Unfortunately, both schemes have two drawbacks:
  (1) There is no proof that the host computes what he's suppose to do.
  (2) The delegation is far more slower than the normal computation.
According to the Makwa paper
(https://www.bolet.org/makwa/makwa-spec-20150422.pdf) the delegation is
typically 100 to 1000 slower. So I see little advantage in delegating.

I doubt there is a scheme that suits our needs.
___
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

[Gregory Maxwell via bitcoin-dev]

On Tue, Jan 23, 2018 at 6:44 AM, Anthony Towns  wrote:
> Is this really intended as paying directly to a pubkey, instead of a
> pubkey hash?
>
> If so, isn't that a step backwards with regard to resistance to quantum
> attacks against ECC?

You're reading too much into a description of the idea. It's not a BIP
or a spec; I tried to provide enough details to make the general idea
concrete. I didn't dive into details or optimizations (for example,
you can use this with a "no EC redemption path" by special casing
empty C as the point at infinity, and you'd have an output that was
indistinguishable until spend... yadda yadda).

Considering the considerable level of address reuse -- I recall prior
stats that a majority of circulating funds are on addresses that had
previously been used, on top of the general race limitations-- I am
now dubious to the idea that hashing provides any kind of meaningful
quantum resistance and somewhat regret introducing that meme to the
space in the first place. If we considered quantum resistance a
meaningful concern we should address that specifically.  --- so I
don't think that should be a factor that drives a decision here.

When collision resistance is needed (as I think it clearly is for
taproot) you don't get a space savings in the txout from hashing, so
there is an argument to use the public key directly at least... but
it's worth considering.  Direct SPK use is also adventitious for being
able to efficiently ZKP over the UTXO set, e.g. for private solvency
proofs, but it isn't absolutely mandatory for that (one can hash
inside the proof, but it's slower).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev