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

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 compe

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

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, > > becau

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

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 byt

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

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

Re: [bitcoin-dev] 2 step confirmation system

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 m

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

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

[bitcoin-dev] 2 step confirmation system

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

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

> 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/#c

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

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 > tra

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

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 discret

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

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 requi

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

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

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

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 check

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

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

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

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 >

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

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

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

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 specifi

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

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 obvio

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

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.o

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

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

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

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,

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

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

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

> 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,

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

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