On Wed, Jun 28, 2017 at 12:37 AM, Chris Stewart via bitcoin-dev
wrote:
> A new block rule is added which requires that the miner's coinbase reward be
> at index 0 in the coinbase transaction's output vector.
This is an absurd restriction-- I hope it was not your intent to
directly ban P2Pool and
On Sun, Jul 2, 2017 at 8:35 PM, Rhavar via bitcoin-dev
wrote:
> ==Abstract==
>
> BIP125 allows transactions to opt into replaceability with a primary use
> case
> of allowing users to increase the fees of unconfirming transactions, helping
> create
> a more efficient fee market place.
I don't rea
On Sun, Jul 2, 2017 at 9:01 PM, Rhavar wrote:
> That's not really realistic. In practice some receivers do big sweeps and
> include unconfirmed inputs. Replacing the transaction means you need to pay
> the cost of the sweep, which you probably don't want to do (can be in the
> order of $100s of do
On Wed, Jul 5, 2017 at 3:50 AM, Luke Dashjr via bitcoin-dev
wrote:
> I've already opened a PR almost 2 weeks ago to do this and fix the other
> issues BIP 9 has. https://github.com/bitcoin/bips/pull/550
>
> It just needs your ACK to merge.
These proposals for gratuitous orphaning are reckless and
On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev
wrote:
> Hello,
>
> Here is a BIP that matches the reference code that the Segwit2x group has
> built and published a week ago.
I'm happy to see that someone has begun writing a specification. But I
am appalled to see one just
On Fri, Jul 7, 2017 at 10:44 PM, Matt Corallo via bitcoin-dev
wrote:
> This is not a hard fork, simply adding a new limit is a soft fork. You
> appear to be confused - as originally written, AFAIR, Jeff's btc1 branch
> did not increase the block size, your specification here matches that
> origina
On Fri, Jul 7, 2017 at 11:27 PM, Luke Dashjr via bitcoin-dev
wrote:
> Larger block sizes is not likely to have a meaningful impact on fee pressure.
> Any expectations that do not match the reality are merely misguided, and
> should not be a basis for changing Bitcoin.
I think it's very clear that
I think it's great that people want to experiment with things like
drivechains/sidechains and what not, but their security model is very
distinct from Bitcoin's and, given the current highly centralized
mining ecosystem, arguably not very good. So positioning them as a
major solution for the Bitco
On Tue, Jul 11, 2017 at 8:18 PM, Paul Sztorc via bitcoin-dev
wrote:
> I wrote the roadmap to try to be representative of a Core / developer
> position.
A fine intention, but I've checked with many of the top contributors
and it sounds like the only regular developer you spoke with was
Luke-Jr. N
On Tue, Jul 11, 2017 at 9:11 PM, Gregory Maxwell wrote:
> which I have included here a private email
> thread on the subject
To make it clear, since I munged the English on this: Most of my post
is just copied straight out of a private thread where I explained my
perspective on 'roadmaps' as they
On Tue, Jul 11, 2017 at 10:17 PM, Paul Sztorc wrote:
> I don't understand this at all. This document attempts to do exactly
> what its predecessor did -- nothing more or less.
That might be your impression, then you've misunderstood what I
intended-- What I wrote was carefully constructed as a pe
On Wed, Jul 12, 2017 at 1:40 AM, Paul Sztorc wrote:
> Separately, and very important to me, is that you feel that there are
> unresolved objections to drivechain's security model, which you decline
> to share with me and/or the list. So I would hope that you instead
> choose to share your thoughts
On Wed, Jul 12, 2017 at 6:17 AM, Dan Libby via bitcoin-dev
wrote:
> Hi!
>
> Up to now, I have purposefully been running bitcoin releases prior to
> 0.13.1 as a way to avoid the (possible) segwit activation, at least
> until such time as I personally am comfortable with it.
It is not simple to do
This construction appears to me to be completely insecure.
Say my pubkey (the result of the derivation path) is P.
We agree to contract C1. A payment is made to P + G*H(C1).
But in secret, I constructed contract C2 and pubkey Q and set P = Q + G*H(C2).
Now I can take that payment (paid to Q
On Mon, Aug 28, 2017 at 3:29 PM, Alex Nagy via bitcoin-dev
wrote:
> If Alice gives Bob 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a, is there any way Bob
> can safely issue Native P2WPKH outputs to Alice?
Absolutely not. You can only pay people to a script pubkey that they
have specified.
Trying to constr
On Mon, Aug 28, 2017 at 3:50 PM, Riccardo Casatta via bitcoin-dev
wrote:
> Hi everyone,
>
> the Bitcoin headers are probably the most condensed and important piece of
> data in the world, their demand is expected to grow.
>
> When sending a stream of continuous block headers, a common case in IBD
On Mon, Sep 11, 2017 at 5:43 PM, Daniel Stadulis via bitcoin-dev
wrote:
> I think it's relevant to treat different bug severity levels with different
> response plans.
>
> E.g.
> Compromising UTXO custody (In CVE-2010-5141, OP_RETURN vulnerability)
> Compromising UTXO state (In CVE-2013-3220, bloc
On Tue, Sep 12, 2017 at 3:37 AM, Anthony Towns via bitcoin-dev
wrote:
> If you can't pick even a small group that's trustworthy
No.
> I find it hard to imagine bitcoin's still obscure enough that people
> aren't tracking git commit logs to use them as inspiration for attacks
For embargoed fixes
On Tue, Sep 12, 2017 at 4:49 AM, Sergio Demian Lerner via bitcoin-dev
wrote:
> It also implies that some times a researcher works hard to investigate a
> vulnerability and later he finds out it was previously reported. It also
> means that the researcher cannot report to alt-coins which have a dif
On Wed, Sep 13, 2017 at 9:24 AM, Peter Todd via bitcoin-dev
wrote:
> Quite simply, I just don't think the cost-benefit tradeoff of what you're
> proposing makes sense.
I agree that dropping zero value outputs is a needless loss of
flexibility. In addition to the CT example, something similar cou
On Wed, Sep 13, 2017 at 9:24 AM, Peter Todd via bitcoin-dev
wrote:
> 2) Spending CT-shielded outputs to unshielded outputs
>
> Here one or more CT-shielded outputs will be spent. Since their value is zero,
> we make up the difference by spending one or more outputs from the CT pool,
> with the cha
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 site provides a helpful
> explanation fo
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 copyright holder:
https://github.com/bitcoi
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 fast index into them?
This seems pretty
On Wed, Sep 27, 2017 at 4:06 PM, Peter Todd via bitcoin-dev
wrote:
> Re-use of old addresses is a major problem, not only for privacy, but also
> operationally: services like exchanges frequently have problems with users
> sending funds to addresses whose private keys have been lost or stolen; the
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 the
cosmic ray happens
On Fri, Sep 29, 2017 at 12:45 PM, Andreas Schildbach via bitcoin-dev
wrote:
> 15+ Mio Coinbase users
Who's payment protocol SSL cert was expired for months without even
generating a post on reddit. Not exactly convincing there.
The fact that someone supports it doesn't mean its being used.
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 include my transaction alone to avoid t
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 fit, not empty the whole block and mine
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 left doing hard-forks to reduce the
> si
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 because it followed the
This is the bit
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 fan, I
> really wanted t
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. (
https://b
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
> currency is an easily
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 private transacti
On Mon, Nov 20, 2017 at 5:24 PM, Praveen Baratam via bitcoin-dev
wrote:
> Bitcoin Noob here. Please forgive my ignorance.
>
> From what I understand, in SegWit, the transaction needs to be serialized
> into a data structure that is different from the current one where
> signatures are separated fr
With the way pruning works today my expirence is that virtually no one
sets any parameter other than the minimum, though even with that set a
few more blocks can be available.
In the future we would set further pruning identifying bits, with
those set node would (obviously) answer for their blocks
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
simp
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 has any particular incentive
for them.
>
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 every 2016 blocks). This would be coupling
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 off-topic for this discussion.
_
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
> previous header's nB
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
> 'headers'/'getheaders' me
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,
>
> I find it hard to understand why a f
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-- cur
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 was so much smaller than subsidy.
The d
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 "storin
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 wordlist
> in order to eradicate this m
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 the key being used thro
On Wed, Jan 10, 2018 at 8:28 PM, Pavol Rusnak wrote:
> On 09/01/18 16:12, Pavol Rusnak via bitcoin-dev wrote:
>> On 09/01/18 00:47, Gregory Maxwell wrote:
>>> Have you considered using blind host-delegated KDFs, where the KDF
>>> runs on the user's computer instead of the hardware wallet, but the
On Tue, Jan 16, 2018 at 1:06 AM, Rusty Russell via bitcoin-dev
wrote:
> The rule AFAICT is "standard transactions must still work". This was
> violated with low-S, but the transformation was arguably trivial.
That is my view, generally. Like any other principle, its
applicability is modulated b
On Wed, Jan 17, 2018 at 11:39 AM, Ondřej Vejpustek via bitcoin-dev
wrote:
> Consider a few notes:
> * Nowadays there exists more complicated variants of mentioned attacks
> which have weaker premisses.
> * There is a considerable similarity between RSA and SSS. Both schemes
> are algebraically
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 experience is that a great many things which
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 to have
> n-th bytes from k shares
On Thu, Jan 18, 2018 at 4:59 PM, Ondřej Vejpustek
wrote:
>> If being secure against partial share leakage is really part of your
>> threat model the current proposal is gratuitously insecure against it.
>
> I don't think that is true. Shared secret is an input of KDF which
> should prevent this ki
A common question when discussing newer more efficient pubkey types--
like signature aggregation or even just segwit-- is "will this thing
make the spending of already existing outputs more efficient", which
unfortunately gets an answer of No because the redemption instructions
for existing outputs
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 resigned
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 would be especially since op
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 differenc
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
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
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
>
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
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
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
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 behavior) and when, so whether
On Wed, Jan 24, 2018 at 11:16 AM, Aymeric Vitte wrote:
> Then what about
> https://blockchain.info/tx/226a8b08dc46a00e9ecec5567a303a0b354bef3c1674476eb5e4b627b2ace493?format=hex
> ?
>
> Scriptsig:
>
> 473044022057a1234709270325e7215200f982546304cf465971cbd55d54231ead54ef1a7802207a82e93ef2b0f87188a
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 overhead at all
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 fe
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" transactions, but the idea is
> complete
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 would be more accurate to say that the me
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 miners around
$130k U
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 th
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
> transaction), at the cost of storing
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". However, I think the differentiation
>>
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 actual number of sigop at execution (i.e.
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 aware of whether this would break aggreg
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
https://people.xiph.org/~greg/mempool_sy
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 convincing for the txids themselves.
W
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 get something like a
40% reduction in the
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 to replace it with, however.
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 to replace it with, however.
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 eclipse attacker) or wh
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 attached.
>
> As interpretation, the first ~12
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 intent of this particular
> P2SH address
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 this:
Are there any useful applications
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:
> https://gist.github.com/sipa/576d5f09c3b86c3b1b75598d799fc845
>
> TL;DR: if we really want an
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
bitcoin-dev@lists.linuxfo
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
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 t
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 a
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, a
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 unle
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 filters
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 requi
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 inc
> 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
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 in
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 t
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
1 - 100 of 283 matches
Mail list logo
