Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

2019-03-13 Thread Gregory Maxwell via bitcoin-dev
On Wed, Mar 13, 2019 at 12:42 AM Jacob Eliosoff via bitcoin-dev wrote: > Also, if future disabling isn't the point of making a tx type like > OP_CODESEPARATOR non-standard - what is? If we're committed to indefinite > support of these oddball features, what do we gain by making them hard to >

Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)

2019-03-12 Thread Gregory Maxwell via bitcoin-dev
On Tue, Mar 12, 2019 at 7:45 PM Andreas Schildbach via bitcoin-dev wrote: > These two cases are understood and handled by current code. Generally > the idea is take reject messages serious, but don't overrate the lack > of. Luckily, network confirmations fill the gap. (Yes, a timeout is I'd like

Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)

2019-03-08 Thread Gregory Maxwell via bitcoin-dev
On Thu, Mar 7, 2019 at 11:46 PM Andreas Schildbach via bitcoin-dev wrote: > First and foremost, reject messages are an indication that the > transaction isn't going to confirm. Without these messages, we'd need to > revert to pre-BIP61 behaviour of using a timeout for reception of > network

Re: [bitcoin-dev] BIP174 / PSBT extensions

2019-03-07 Thread Gregory Maxwell via bitcoin-dev
On Thu, Mar 7, 2019 at 11:49 PM Andrew Chow via bitcoin-dev wrote: > I feel like this breaks the central idea of PSBT that a PSBT contains > everything you need to construct a transaction. > This would rely on parties in the transaction having state and remembering > things which I don't think

Re: [bitcoin-dev] BIP - Symbol for satoshi

2019-03-07 Thread Gregory Maxwell via bitcoin-dev
On Wed, Mar 6, 2019 at 12:32 AM Amine Chakak via bitcoin-dev wrote: > The idea has been floated around to switch to satoshi as a base unit. If Satoshi wanted the currency units named after him, he would simply have done it. I think this behaviour seems creepy and is harmful to Bitcoin. > The

Re: [bitcoin-dev] BIP proposal - addrv2 message

2019-03-06 Thread Gregory Maxwell via bitcoin-dev
On Wed, Mar 6, 2019 at 12:22 AM Wladimir J. van der Laan via bitcoin-dev wrote: > Field addr has a variable length, with a maximum of 32 bytes > (256 bits). Clients SHOULD reject > longer addresses. Is 32 bytes long enough for I2P? It seems like there are two formats, is there a reason we

Re: [bitcoin-dev] Interrogating a BIP157 server, BIP158 change proposal

2019-02-07 Thread Gregory Maxwell via bitcoin-dev
On Wed, Feb 6, 2019 at 8:10 AM Tamas Blummer wrote: > I am skeptical that commitment of any filter will come into Core soon. [...] > A committed filter makes light clients much more reliable and attractive, for > some taste too much more. You keep repeating this smear. Please stop. If you

Re: [bitcoin-dev] Transaction Input/Output Sorting

2018-10-24 Thread Gregory Maxwell via bitcoin-dev
On Wed, Oct 24, 2018 at 3:52 PM Chris Belcher via bitcoin-dev wrote: > > Thanks for bringing our attention to this important topic. > > According to (https://p2sh.info/dashboard/db/bip-69-stats) around 60% of > transaction follow bip69 (possibly just by chance). A two input randomly ordered

[bitcoin-dev] Trivia on the history of compact fraud proofs and anti censorship.

2018-09-25 Thread Gregory Maxwell via bitcoin-dev
It's generally not /too/ important where ideas come from, even in our open source non-patent encumbering world the only compensation people get for sharing a good idea is the credit they receive. Most of the time people are still happy to see their ideas further developed, even if credit isn't

Re: [bitcoin-dev] Fwd: [bitcoin-core-dev] On the initial notice of CVE-2018-17144

2018-09-22 Thread Gregory Maxwell via bitcoin-dev
On Sat, Sep 22, 2018 at 7:22 PM sick...@gmail.com wrote: > > For some reason I don't understand, Andrea Suisani is stating on > > twitter that the the report by awemany was a report of an inflation > > bug, contrary to the timeline we published. > > guess that the fact you don't understand it,

Re: [bitcoin-dev] [bitcoin-core-dev] Bitcoin Core update notice

2018-09-21 Thread Gregory Maxwell via bitcoin-dev
On Sat, Sep 22, 2018 at 4:25 AM gb via bitcoin-dev wrote: > > If the bugfix can be backported to earlier versions why is the Have been backported, not merely can be. > hype/hysteria about "everybody" must immediately upgrade to 0.16.3 > currently being spread on the forums/reddit? For

Re: [bitcoin-dev] Schnorr signatures BIP

2018-09-12 Thread Gregory Maxwell via bitcoin-dev
On Tue, Sep 11, 2018 at 5:38 PM Erik Aronesty wrote: > > - Musig, by being M of M, is inherently prone to loss. M of M is a particular threshold. If you want M of M (there are plenty of cases where M of M _must_ be used) then you get the consequences of M of M, which presumably you want. This

Re: [bitcoin-dev] Schnorr signatures BIP

2018-09-12 Thread Gregory Maxwell via bitcoin-dev
On Tue, Sep 11, 2018 at 5:20 PM Erik Aronesty wrote: > The security advantages of a redistributable threshold system are huge. If > a system isn't redistributable, then a single lost or compromised key results > in lost coins... meaning the system is essetntially unusable. > > I'm actually

Re: [bitcoin-dev] Schnorr signatures BIP

2018-09-12 Thread Gregory Maxwell via bitcoin-dev
On Tue, Sep 11, 2018 at 4:34 PM Erik Aronesty wrote: > To answer points: > > - I switched to the medium article so that I could correct, edit and > improve things to make them more clear. > - I responded to feedback by modifying the protocol to make it work - not > by ignoring it. > To this

Re: [bitcoin-dev] Overhauled BIP151

2018-09-07 Thread Gregory Maxwell via bitcoin-dev
On Thu, Sep 6, 2018 at 11:33 PM Tim Ruffing via bitcoin-dev wrote: > Now you can argue that the attacker is storing encrypted traffic today to > decrypt it later. That is the argument. We know for that state level parties are storing unimaginable amounts of data for future decryption, that

Re: [bitcoin-dev] A BIP proposal for transactions that are 'cancellable'

2018-09-06 Thread Gregory Maxwell via bitcoin-dev
Functionality such as this does not currently exist not because no one thought of it before, but because it has been proposed many times before and determined to be harmful. The existing design of CLTV/CSV were carefully constructed to make it impossible for a transaction to go from valid to

Re: [bitcoin-dev] Schnorr signatures BIP

2018-09-06 Thread Gregory Maxwell via bitcoin-dev
On Wed, Sep 5, 2018 at 1:49 PM Erik Aronesty via bitcoin-dev wrote: > Detailed explanation with code snippets: > > https://medium.com/@simulx/an-m-of-n-bitcoin-multisig-scheme-[snip] This appears to be a repost of the broken scheme you posted about on Bitcointalk, but then failed to respond to

Re: [bitcoin-dev] Testnet3 Reest

2018-08-31 Thread Gregory Maxwell via bitcoin-dev
On Thu, Aug 30, 2018 at 11:21 PM Johnson Lau via bitcoin-dev wrote: > A public testnet is still useful so in articles people could make references > to these transactions. > Maybe we could have 2 testnets at the same time, with one having a smaller > block size? I would much rather have a

[bitcoin-dev] Getting around to fixing the timewarp attack.

2018-08-20 Thread Gregory Maxwell via bitcoin-dev
Since 2012 (IIRC) we've known that Bitcoin's non-overlapping difficulty calculation was vulnerable to gaming with inaccurate timestamps to massively increase the rate of block production beyond the system's intentional design. It can be fixed with a soft-fork that further constraints block

Re: [bitcoin-dev] Witness serialization in PSBT non-witness UTXOs

2018-08-13 Thread Gregory Maxwell via bitcoin-dev
An alternative is to require reading either or but also require writing without the witness. It's likely that two years from now, nothing will write the witnesses, and the requirement to support reading them could be dropped. On Mon, Aug 13, 2018 at 8:32 PM Achow101 via bitcoin-dev wrote: > >

[bitcoin-dev] Capping the size of locators [trivial protocol change BIP]

2018-08-05 Thread Gregory Maxwell via bitcoin-dev
Coinr8d posted on bct that the node software would process large locators limited only by the maximum message size yet sensible usage of locators only results in messages of log2(n_blocks) size. He was concerned that it might be a DOS vulnerability but quick measurements indicated to me that it

Re: [bitcoin-dev] BIP 174 thoughts

2018-07-11 Thread Gregory Maxwell via bitcoin-dev
On Wed, Jul 11, 2018 at 6:27 PM, Pieter Wuille via bitcoin-dev wrote: > I don't think that's a particularly useful policy, but certainly > Signers are allowed to implement any policy they like about what they > accept in signing. Do we really want the specification to permit conforming

Re: [bitcoin-dev] Multiparty signatures

2018-07-09 Thread Gregory Maxwell via bitcoin-dev
On Mon, Jul 9, 2018 at 4:33 PM, Erik Aronesty wrote: >>> with security assumptions that match the original Schnorr construction more >>> closely, >> More closely than what? > More closely than musig. Musig is instructions on using the original schnorr construction for multiparty signing which

Re: [bitcoin-dev] Multiparty signatures

2018-07-09 Thread Gregory Maxwell via bitcoin-dev
On Mon, Jul 9, 2018 at 3:02 PM, Erik Aronesty via bitcoin-dev wrote: > and where H(g*x) can > be considered their public index for the purposes of Shamir polynomial > interpolation This is isomorphic to the insecure musig variant where keys are blinded by H(g*x) instead of a commitment to all

Re: [bitcoin-dev] Multiparty signatures

2018-07-09 Thread Gregory Maxwell via bitcoin-dev
On Mon, Jul 9, 2018 at 3:02 PM, Erik Aronesty via bitcoin-dev wrote: > with > security assumptions that match the original Schnorr construction more > closely, More closely than what? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org

Re: [bitcoin-dev] Multiparty signatures

2018-07-08 Thread Gregory Maxwell via bitcoin-dev
On Sun, Jul 8, 2018 at 3:16 PM, Tim Ruffing via bitcoin-dev wrote: > so what > you want is possible already with Schnorr signatures. As also described in "Multisignatures and Threshold Signatures" in the BIP. ___ bitcoin-dev mailing list

Re: [bitcoin-dev] Schnorr signatures BIP

2018-07-06 Thread Gregory Maxwell via bitcoin-dev
On Fri, Jul 6, 2018 at 10:00 PM, Gregory Maxwell wrote: > There is a minor design preference to have message before nonce when ::sigh:: to NOT have the message before the nonce. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org

Re: [bitcoin-dev] Schnorr signatures BIP

2018-07-06 Thread Gregory Maxwell via bitcoin-dev
On Fri, Jul 6, 2018 at 9:05 PM, Russell O'Connor via bitcoin-dev wrote: > If the inputs to hash were reordered as hash(bytes(dG) || bytes(x(R)) || m) > then there is an opportunity for SHA256 expander to be partially prefilled > for a fixed public key. This could provide a little benefit,

Re: [bitcoin-dev] BIP sighash_noinput

2018-07-03 Thread Gregory Maxwell via bitcoin-dev
On Tue, Jul 3, 2018 at 5:21 AM, Peter Todd wrote: > The problem with that name is `SIGHASH_REUSE_VULNERABLE` tells you nothing > about what the flag actually does. I believe that making the signature replayable is 1:1 with omitting the identification of the specific coin being spent from it.

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

2018-07-02 Thread Gregory Maxwell via bitcoin-dev
On Thu, May 31, 2018 at 6:35 PM, Johnson Lau via bitcoin-dev wrote: > The bit 0 to 3 of hashtype denotes a value between 0 and 15: > > • If the value is 1, the signature is invalid. > • If the value is 3 or below, hashPrevouts is the hash of all input, > same as defined in

Re: [bitcoin-dev] BIP sighash_noinput

2018-07-02 Thread Gregory Maxwell via bitcoin-dev
On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev wrote: > Hi all, > > I'd like to pick up the discussion from a few months ago, and propose a new > sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous I know it seems kind of silly, but I think it's

Re: [bitcoin-dev] BIP proposal - Dandelion: Privacy Preserving Transaction Propagation

2018-06-25 Thread Gregory Maxwell via bitcoin-dev
On Tue, Jun 26, 2018 at 12:12 AM, Bradley Denby via bitcoin-dev wrote: > That's right, the idea is to choose Dandelion relays independently from > whether they support Dandelion. If the chosen nodes do not support > Dandelion, then the transactions are fluffed. Otherwise, the transactions > are

Re: [bitcoin-dev] BIP 174 thoughts

2018-06-21 Thread Gregory Maxwell via bitcoin-dev
On Thu, Jun 21, 2018 at 7:56 PM, Peter D. Gray via bitcoin-dev wrote: > PSBT is something we need, and has been missing from the ecosystem > for a long time. Let's push this out and start talking about future > versions after we learn from this one. When you implement proposals that have little

Re: [bitcoin-dev] Should Graftroot be optional?

2018-06-20 Thread Gregory Maxwell via bitcoin-dev
On Wed, Jun 20, 2018 at 12:12 PM, ZmnSCPxj via bitcoin-dev wrote: > This has the advantage that the Graftroot signature commits to a single > outpoint and cannot be used to spend all outpoints that happen to pay to the > same `P` public key. If it isn't possible to make a graftroot signature

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

2018-06-09 Thread Gregory Maxwell via bitcoin-dev
> So what's the cost in using > the current filter (as it lets the client verify the filter if they want to, An example of that cost is you arguing against specifying and supporting the design that is closer to one that would be softforked, which increases the time until we can make these filters

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

2018-06-08 Thread Gregory Maxwell via bitcoin-dev
On Fri, Jun 8, 2018 at 5:03 AM, Olaoluwa Osuntokun via bitcoin-dev wrote: > As someone who's written and reviews code integrating the proposal all the > way up the stack (from node to wallet, to application), IMO, there's no > immediate cost to deferring the inclusion/creation of a filter that

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

2018-06-05 Thread Gregory Maxwell via bitcoin-dev
On Tue, Jun 5, 2018 at 1:08 AM, Jim Posen via bitcoin-dev wrote: > hesitant to make the complexity tradeoff for bandwidth savings due to a > behavior that is actively discouraged. As an important point of clarification here. If scripts are used to identify inputs and outputs, then no use is

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

2018-06-02 Thread Gregory Maxwell via bitcoin-dev
On Sat, Jun 2, 2018 at 10:02 PM, Tamas Blummer via bitcoin-dev wrote: > Years of experience implementing wallets with BIP 37 pretty much us that all these filter things are a total waste of time. BIP37 use is nearly dead on the network-- monitor your own nodes to see the actual use of the

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

2018-06-01 Thread Gregory Maxwell via bitcoin-dev
On Sat, Jun 2, 2018 at 12:01 AM, Olaoluwa Osuntokun wrote: >> A typical network attacker (e.g. someone on your lan or wifi segmet, or >> someone who has compromised or operates an upstream router) can be all of >> your peers. > > This is true, but it cannot make us accept any invalid filters

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

2018-05-31 Thread Gregory Maxwell via bitcoin-dev
On Fri, Jun 1, 2018 at 2:52 AM, Olaoluwa Osuntokun via bitcoin-dev wrote: > One notable thing that I left off is the proposed change to use the previous > output script rather than the outpoint. Modifying the filters in this > fashion would be a downgrade in the security model for light clients,

Re: [bitcoin-dev] New serialization/encoding format for key material

2018-05-30 Thread Gregory Maxwell via bitcoin-dev
On Wed, May 30, 2018 at 6:30 AM, shiva sitamraju via bitcoin-dev wrote: > The idea to add birthdate and gap limit sounds very good and addresses lots > of problems users are facing. > > However, adding birthday to keys breaks two basic properties > > - Visually Comparing two keys to find if they

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

2018-05-28 Thread Gregory Maxwell via bitcoin-dev
On Tue, May 29, 2018 at 2:42 AM, Jim Posen wrote: > Certain wallets may be able to use only the output script filter by using > output scripts to watch for confirmations on sent transactions, assuming > that application is the only one with access to the private keys. The > additional benefit of

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

2018-05-28 Thread Gregory Maxwell via bitcoin-dev
Is there an application that requires watching for output scripts that doesn't also require watching for input scrips (or, less efficiently, input outpoints)? Any of the wallet application that I'm aware of need to see coins being spent as well as created, else they may try to spend already spent

Re: [bitcoin-dev] Minimizing the redundancy in Golomb Coded Sets

2018-05-25 Thread Gregory Maxwell via bitcoin-dev
On Fri, May 25, 2018 at 6:42 PM, Gregory Maxwell wrote: > configuration is roughly right, then M=1569861 and rice parameter 19 > should be used. That should have been M=784931 B=19 ... paste error. ___ bitcoin-dev mailing list

Re: [bitcoin-dev] Minimizing the redundancy in Golomb Coded Sets

2018-05-25 Thread Gregory Maxwell via bitcoin-dev
On Fri, May 25, 2018 at 5:54 PM, Pieter Wuille via bitcoin-dev wrote: > Hi all, > > I spent some time working out the optimal parameter selection for the > Golomb Coded Sets that are proposed in BIP158: >

Re: [bitcoin-dev] Should Graftroot be optional?

2018-05-23 Thread Gregory Maxwell via bitcoin-dev
On Thu, May 24, 2018 at 1:58 AM, Pieter Wuille via bitcoin-dev wrote: > Thanks everyone who commented so far, but let me clarify the context > of this question first a bit more to avoid getting into the weeds too > much. My understanding of the question is

Re: [bitcoin-dev] Should Graftroot be optional?

2018-05-23 Thread Gregory Maxwell via bitcoin-dev
On Wed, May 23, 2018 at 10:06 PM, Natanael via bitcoin-dev wrote: > Consider for example a P2SH address for some fund, where you create a > transaction in advance. Even if the parties involved in signing the > transaction would agree (collude), the original

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

2018-05-23 Thread Gregory Maxwell via bitcoin-dev
Any chance you could add a graph of input-scripts (instead of input outpoints)? On Wed, May 23, 2018 at 7:38 AM, Jim Posen via bitcoin-dev wrote: > So I checked filter sizes (as a proportion of block size) for each of the > sub-filters. The graph is

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

2018-05-17 Thread Gregory Maxwell via bitcoin-dev
On Thu, May 17, 2018 at 8:19 PM, Jim Posen wrote: > In my opinion, it's overly pessimistic to design the protocol in an insecure > way because some light clients historically have taken shortcuts. Any non-commited form is inherently insecure. A nearby network attacker (or

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

2018-05-17 Thread Gregory Maxwell via bitcoin-dev
On Thu, May 17, 2018 at 4:59 PM, Matt Corallo wrote: > Yea I generally would really prefer something like that but it > significantly complicates the download logic - currently clients can > easily cross-check [...] Maybe > there is some other reasonable download logic

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

2018-05-17 Thread Gregory Maxwell via bitcoin-dev
On Thu, May 17, 2018 at 4:59 PM, Matt Corallo wrote: > Yea I generally would really prefer something like that but it > significantly complicates the download logic - currently clients can > easily cross-check [...] Maybe > there is some other reasonable download logic

Re: [bitcoin-dev] UHS: Full-node security without maintaining a full UTXO set

2018-05-17 Thread Gregory Maxwell via bitcoin-dev
On Wed, May 16, 2018 at 4:36 PM, Cory Fields via bitcoin-dev wrote: > Tl;dr: Rather than storing all unspent outputs, store their hashes. My initial thoughts are it's not _completely_ obvious to me that a 5% ongoing bandwidth increase is actually a win to

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

2018-05-17 Thread Gregory Maxwell via bitcoin-dev
On Thu, May 17, 2018 at 3:25 PM, Matt Corallo via bitcoin-dev wrote: > I believe (1) could be skipped entirely - there is almost no reason why > you'd not be able to filter for, eg, the set of output scripts in a > transaction you know about I think this is

Re: [bitcoin-dev] Low-bandwidth transaction relay

2018-04-03 Thread Gregory Maxwell via bitcoin-dev
On Mon, Apr 2, 2018 at 10:18 PM, Gleb Naumenko via bitcoin-dev wrote: > Hi all, > I have a couple of ideas regarding transaction relay protocol and wanted to > share it with and probably get some feedback. https://bitcointalk.org/index.php?topic=1377345.0

Re: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption

2018-02-24 Thread Gregory Maxwell via bitcoin-dev
On Thu, Feb 22, 2018 at 7:44 PM, Daniel Edgecumbe via bitcoin-dev wrote: > I don't think that binding grafts to a particular transaction requires this > aggregation. > It seems to me that you could just sign H(txid, script) rather than H(script). > I'm not

Re: [bitcoin-dev] Alternative way to count sigops

2018-02-16 Thread Gregory Maxwell via bitcoin-dev
On Fri, Feb 16, 2018 at 10:49 PM, Johnson Lau via bitcoin-dev wrote: > Since we have a block weight limit of 4,000,000 and sigop limit of 80,000, > each sigop could not use more than 50 weight unit on average. For new script > proposals we could count the

Re: [bitcoin-dev] Amend the BIP 123 process to include buried deployments

2018-02-14 Thread Gregory Maxwell via bitcoin-dev
On Wed, Feb 14, 2018 at 10:11 PM, Luke Dashjr via bitcoin-dev wrote: > On Wednesday 14 February 2018 10:01:46 PM Marco Falke via bitcoin-dev wrote: >> BIP 123 suggests that BIPs in the consensus layer should be assigned a >> label "soft fork" or "hard fork".

Re: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption

2018-02-05 Thread Gregory Maxwell via bitcoin-dev
On Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant wrote: > Am I reading correctly that this allows unilateral key rotation (to a > previously unknown key), without invalidating the interests of other > parties in the existing multisig (or even requiring any on-chain >

[bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption

2018-02-04 Thread Gregory Maxwell via bitcoin-dev
In my post on taproot I showed a simple commitment scheme for scripts that is very efficient that there exists some collection of pubkeys (like an M-of-N or even N-of-N) whos authorization is an acceptable alternative to whatever other conditions we might want to impose on a coin. If this holds

Re: [bitcoin-dev] Proposal: rewarding fees to next block miner

2018-01-29 Thread Gregory Maxwell via bitcoin-dev
On Mon, Jan 29, 2018 at 11:21 PM, Eric Voskuil wrote: > Block space created by a miner is property that belongs to the miner, it > can be sold or not sold. That case would be stronger when there is no more subsidy, but we collectively the uses of Bitcoin are currently paying

Re: [bitcoin-dev] How accurate are the Bitcoin timestamps?

2018-01-29 Thread Gregory Maxwell via bitcoin-dev
On Mon, Jan 29, 2018 at 9:40 PM, Tier Nolan via bitcoin-dev wrote: > For check locktime, the median of the last 11 blocks is used as an improved > indicator of what the actual real time is. Again, it assumes that a > majority of the miners are honest. It

Re: [bitcoin-dev] Proposal: rewarding fees to next block miner

2018-01-29 Thread Gregory Maxwell via bitcoin-dev
On Mon, Jan 29, 2018 at 4:49 AM, Eric Voskuil via bitcoin-dev wrote: > I'm not sure who cooked up this myth about miners gaining advantage over > those who buy block space by mining empty space, rejecting higher-fee > transactions, and/or mining "recovery"

Re: [bitcoin-dev] Proposal: rewarding fees to next block miner

2018-01-27 Thread Gregory Maxwell via bitcoin-dev
Not incentive compatible. Miners would prefer to include transactions paying fees via alternative mechanisms (anyone can spend outputs, direct pay to miner outputs, or completely out of band), if they even paid attention to internal fees at all they would give a lot more weight to direct payment

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

2018-01-26 Thread Gregory Maxwell via bitcoin-dev
On Tue, Jan 23, 2018 at 12:30 AM, Gregory Maxwell wrote: > 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

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

2018-01-24 Thread Gregory Maxwell via bitcoin-dev
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] Why is deriving public key from the signature not used in Segwit?

2018-01-24 Thread Gregory Maxwell via bitcoin-dev
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?

2018-01-23 Thread 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

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

2018-01-23 Thread 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

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

2018-01-23 Thread 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

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

2018-01-23 Thread 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

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

2018-01-23 Thread 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

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

2018-01-23 Thread 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

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

2018-01-22 Thread Gregory Maxwell via bitcoin-dev
On Mon, Jan 22, 2018 at 7:21 PM, Russell O'Connor wrote: > At this point, is it better just to use GF(2^256+n)? Is GF(2^256+n) going > to be that much slower than GF(2^8) that we care to make things this > complicated? (I honestly don't know the answer.) I expect it

[bitcoin-dev] Change in contact info

2018-01-18 Thread Gregory Maxwell via bitcoin-dev
Not really all that on-topic, but since it was suggested to me that this would be an efficient venue to reach others who might care to know: In order to spend more time working independently on deep protocol work, especially new cryptographic privacy and security technology for Bitcoin, I

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

2018-01-18 Thread Gregory Maxwell via bitcoin-dev
On Thu, Jan 18, 2018 at 1:50 PM, Ondřej Vejpustek wrote: > (1) Our proposal doesn't use SSS for the whole secret, but it divides > the secret into bytes and uses SSS for every byte separately. This > scheme is weaker because to reconstruct n-th byte it suffices

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

2018-01-17 Thread Gregory Maxwell via bitcoin-dev
On Wed, Jan 17, 2018 at 3:28 PM, Russell O'Connor via bitcoin-dev wrote: > it is impossible to break SSS. Obligatory repeated point: if the scheme being used actually is SSS and not a Shamir-Shaped-Sharing instead. This should go without mention by my

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

2018-01-08 Thread Gregory Maxwell via bitcoin-dev
On Mon, Jan 8, 2018 at 12:39 PM, Pavol Rusnak wrote: > On 08/01/18 05:22, Gregory Maxwell wrote: >>> https://github.com/satoshilabs/slips/blob/master/slip-0039.md > > Hey Gregory! > > Thanks for looking into the scheme. I appreciate your time! > >> This specification forces

[bitcoin-dev] Satoshilabs secret shared private key scheme

2018-01-07 Thread Gregory Maxwell via bitcoin-dev
On Sun, Jan 7, 2018 at 3:16 PM, Pavol Rusnak via bitcoin-dev wrote: > On 05/01/18 14:58, nullius via bitcoin-dev wrote: > I am currently drafting a new standard[1] which will allow also Shamir > Secret Scheme Splitting and there we disallow usage of a custom

Re: [bitcoin-dev] Bech32 and P2SH²

2018-01-05 Thread Gregory Maxwell via bitcoin-dev
P2SH^2 wasn't a serious proposal-- I just suggested it as a thought experiment. I don't think it offers much useful in the context of Bitcoin today. Particularly since weight calculations have made output space relatively more expensive and fees are at quite non-negligible rates interest in

Re: [bitcoin-dev] Total fees have almost crossed the block reward

2017-12-21 Thread Gregory Maxwell via bitcoin-dev
On Fri, Dec 22, 2017 at 12:30 AM, Mark Friedenbach via bitcoin-dev wrote: > Every transaction is replace-by-fee capable already. Opt-in replace by fee > as specified in BIP 125 is a fiction that held sway only while the income > from fees or fee replacement

Re: [bitcoin-dev] Total fees have almost crossed the block reward

2017-12-21 Thread Gregory Maxwell via bitcoin-dev
Personally, I'm pulling out the champaign that market behaviour is indeed producing activity levels that can pay for security without inflation, and also producing fee paying backlogs needed to stabilize consensus progress as the subsidy declines. I'd also personally prefer to pay lower fees--

Re: [bitcoin-dev] Why not witnessless nodes?

2017-12-18 Thread Gregory Maxwell via bitcoin-dev
Because it would make no meaningful difference now, and if you are not going to check the history there are much more efficient things to do-- like not transfer it at all. On Mon, Dec 18, 2017 at 8:32 AM, Kalle Rosenbaum via bitcoin-dev wrote: > Dear list,

Re: [bitcoin-dev] "Compressed" headers stream

2017-12-12 Thread Gregory Maxwell via bitcoin-dev
On Tue, Dec 12, 2017 at 9:07 PM, Suhas Daftuar wrote: > I agree with this. Specifically the way I envisioned this working is that > we could introduce a new 'cmpctheaders'/'getcmpcthdrs' message pair for > syncing using this new message type, while leaving the existing >

Re: [bitcoin-dev] "Compressed" headers stream

2017-12-12 Thread Gregory Maxwell via bitcoin-dev
On Tue, Dec 12, 2017 at 9:07 PM, Suhas Daftuar wrote: > But I think we should be able to get nearly all the benefit just by > including nBits in any messages where the value is ambiguous; ie we include > it with the first header in a message, and whenever it changes from the >

Re: [bitcoin-dev] "Compressed" headers stream

2017-12-11 Thread Gregory Maxwell via bitcoin-dev
On Mon, Dec 11, 2017 at 10:41 PM, Tier Nolan via bitcoin-dev wrote: > There is a method called "high hash highway" that allows compact proofs of > total POW. That provides no security without additional consensus enforced commitments, so I think pretty

Re: [bitcoin-dev] "Compressed" headers stream

2017-12-11 Thread Gregory Maxwell via bitcoin-dev
On Mon, Dec 11, 2017 at 8:40 PM, Jim Posen via bitcoin-dev wrote: > Firstly, I don't like the idea of making the net header encoding dependent > on the specific header validation rules that Bitcoin uses (eg. the fact that > difficulty is only recalculated

Re: [bitcoin-dev] BIP Idea: Marginal Pricing

2017-11-30 Thread Gregory Maxwell via bitcoin-dev
On Thu, Nov 30, 2017 at 6:13 AM, William Morriss via bitcoin-dev wrote: > I believe this OOB scenario is imaginary. Either it would be more profitable Out of band fees are a reality even today-- and have for most of Bitcoin's life--, without a system that

Re: [bitcoin-dev] BIP Idea: Marginal Pricing

2017-11-30 Thread Gregory Maxwell via bitcoin-dev
This idea presumes that the protocol has any ability to regulate fees. I believe the locally optimal strategy for both miners and payers alike is to accept (pay) zero fees natively in the protocol and instead accept (pay) their actual fees out-of-band or via OP_TRUE outputs which the miner can

Re: [bitcoin-dev] Updates on Confidential Transactions efficiency

2017-11-14 Thread Gregory Maxwell via bitcoin-dev
On Tue, Nov 14, 2017 at 10:38 AM, Gregory Maxwell wrote: > I think it's still fair to say that ring-in and tree-in approaches > (monero, and zcash) are fundamentally less scalable than > CT+valueshuffle, but more private-- though given observations of Zcash While I'm enumerating

Re: [bitcoin-dev] Updates on Confidential Transactions efficiency

2017-11-14 Thread Gregory Maxwell via bitcoin-dev
On Tue, Nov 14, 2017 at 9:11 AM, Peter Todd wrote: > I _strongly_ disagree with this statement and urge you to remove it from the > paper. I very strongly disagree with your strong disagreement. > The worst-case risk of undetected inflation leading to the destruction of a >

[bitcoin-dev] Updates on Confidential Transactions efficiency

2017-11-13 Thread Gregory Maxwell via bitcoin-dev
Jump to "New things here" if you're already up to speed on CT and just want the big news. Back in 2013 Adam Back proposed that Bitcoin and related systems could use additive homomorphic commitments instead of explicit amounts in place of values in transactions for improved privacy. (

Re: [bitcoin-dev] Bitcoin Cash's new difficulty algorithm

2017-11-02 Thread Gregory Maxwell via bitcoin-dev
On Thu, Nov 2, 2017 at 11:53 PM, Scott Roberts wrote: > Whatever their failings from their previous code or their adversarial > nature, they got this code right and I'm only presenting it as a real and > excellent solution for the impending threat to bitcoin. As a big core

Re: [bitcoin-dev] Bitcoin Cash's new difficulty algorithm

2017-11-02 Thread Gregory Maxwell via bitcoin-dev
On Thu, Nov 2, 2017 at 11:31 PM, Scott Roberts via bitcoin-dev wrote: > Bitcoin cash will hard fork on Nov 13 to implement a new difficulty > algorithm. Bitcoin itself might need to hard fork to employ a similar > algorithm. It's about as good as they come

Re: [bitcoin-dev] Simplicity: An alternative to Script

2017-10-30 Thread Gregory Maxwell via bitcoin-dev
On Mon, Oct 30, 2017 at 9:42 PM, Matt Corallo via bitcoin-dev wrote: > I admittedly haven't had a chance to read the paper in full details, but I > was curious how you propose dealing with "jets" in something like Bitcoin. > AFAIU, other similar systems are

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

2017-09-30 Thread Gregory Maxwell via bitcoin-dev
On Sat, Sep 30, 2017 at 3:55 AM, Jorge Timón via bitcoin-dev wrote: > Gmaxwell I think what's new is that in this case, with a single tx you would > take out all txs with fee below 1 btc. With current rules, you would only > remove enoguh txs for that one to

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

2017-09-29 Thread Gregory Maxwell via bitcoin-dev
On Fri, Sep 29, 2017 at 10:43 AM, Daniele Pinna via bitcoin-dev wrote: > As an example, mined blocks currently carry ~0.8 btc in fees right now. If I > were to submit a transaction paying 1 btc in maximal money fees, then the > miner would be incentivized to

Re: [bitcoin-dev] Address expiration times should be added to BIP-173

2017-09-28 Thread Gregory Maxwell via bitcoin-dev
On Fri, Sep 29, 2017 at 1:50 AM, Peter Todd wrote: > What do you mean by "an embedded amount"? I ask you to pay 1 Bitcoin to bc1blahblah. ...you make a typo, or a poorly placed cosmic ray switches it in your ram to bc1blohblahbah. No problem, it'll get rejected. (even if

Re: [bitcoin-dev] Address expiration times should be added to BIP-173

2017-09-27 Thread Gregory Maxwell via bitcoin-dev
On Wed, Sep 27, 2017 at 7:35 PM, Chris Priest via bitcoin-dev wrote: > A better solution is to just have the sending wallet check to see if the > address you are about to send to has been used before. So every wallet needs all the addresses ever used and a

Re: [bitcoin-dev] Bitcoin Assistance

2017-09-27 Thread Gregory Maxwell via bitcoin-dev
On Wed, Sep 27, 2017 at 9:54 PM, Tim Ruffing via bitcoin-dev wrote: > Also, even the old version lists some icons "based on Stephan Hutchings > Typicons" as "License: MIT", which could be a violation of CC BY-SA if > I'm not mistaken. Relicensed by the

Re: [bitcoin-dev] Bitcoin Assistance

2017-09-27 Thread Gregory Maxwell via bitcoin-dev
On Wed, Sep 27, 2017 at 9:20 PM, Cory Fields via bitcoin-dev wrote: >> License for A fast alternative to the modulo reduction > > This references a comment cuckoocache.h. No code from the site is used. The > link to the site was added after the code, as the

  1   2   3   >