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
>
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
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 confir
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 i
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 lig
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 might
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 woul
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 trans
the earliest or clearest
description, perfect for this case since the context is that it's a
complaint that the same author was failing to cite our communities
past efforts on fraud proofs, and as a result they weren't aware of
the state of the art like anti-withholding.
-- For
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, it'
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 instructi
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
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 wor
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 mome
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 threa
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 inval
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 th
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 signe
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 timestam
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:
>
> Hi,
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 lik
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
implementa
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 is
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 key
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
ht
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
bitcoin-dev@lis
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
ht
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, especia
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.
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 BIP143.
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 somewha
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
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 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
> 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 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
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 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 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 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 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 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
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 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
bitco
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 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 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
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 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
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 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 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 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, 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 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 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 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
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, 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
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 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
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 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 signatur
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 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 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 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 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 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 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 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
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 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
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
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
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
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 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 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 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 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
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 specif
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
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 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
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
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
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
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 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 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 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.
>
were able to spend.
On Thu, Nov 30, 2017 at 9:11 AM, Gregory Maxwell wrote:
>
>
> 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 proto
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
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
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
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
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 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
1 - 100 of 292 matches
Mail list logo
