Nostr notes by

📅 Original date posted:2019-03-12 📝 Original message:On ...

2023-06-07T20:16:48+02:00

In reply to nevent1q…5h40
_________________________

📅 Original date posted:2019-03-12
📝 Original message:On Wed, Mar 13, 2019 at 12:42 AM Jacob Eliosoff via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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 use/mine?

It makes them infeasible to abuse without miner assistance... which
doesn't fix them, but in practice greatly reduces the risk they create
and allows efforts improving the system to be allocated to other more
pressing issues.

> I see questions like "Is it possible someone's existing tx relies on this?" as overly black-and-white. We all agree it's possible: the question is how likely, vs the harms of continued support - including not just security risks but friction on other useful changes, safety/correctness analyses, etc.

Don't underestimate the value of taking a principled position that
*strongly* avoids confiscating user funds. Among many other benefits
being cautious about this avoids creating a situation where people are
demanding human intervention to restore improperly lost funds and the
associated loss of effort that would come from the effort wasted
debating that.

It's true that most other cryptocurrencies proceed without any such
caution or care-- e.g. bcash recently confiscating all funds
accidentally sent to segwit using Bitcoin addresses because of their
reckless address aliasing as a result of promoting the standardness
rule that made those txn non-standard before segwit without
considering the implications--, but they're not the standard we should
hold Bitcoin to...

> Again, the point being not to throw caution to the wind, but that a case like this where extensive research unearthed zero users, is taking caution too far.

All things in balance: Codeseperator and its related costs are not an
especially severe problem. The arguments on both side of this point
have enough merit to be worth discussing, at least.

📅 Original date posted:2019-03-06 📝 Original message:On ...

2023-06-07T20:16:40+02:00

In reply to nevent1q…jskh
_________________________

📅 Original date posted:2019-03-06
📝 Original message:On Wed, Mar 6, 2019 at 12:22 AM Wladimir J. van der Laan via
bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Field <code>addr</code> 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 want to use the longer one?
https://geti2p.net/en/docs/naming

Probably the spec should define the limit per address type (e.g.
sending a 32 byte IPv4 makes no sense). And either a maximum for ANY
type (so that 1000*largest size is reasonable), or a maximum size for
the message (e.g. regardless of the included size, an add message
should never be over, say 100k).

> * ''Client MAY store and gossip address formats that they do not know about'': does it ever make sense to gossip addresses outside a certain overlay network? Say, I2P addresses to Tor? I'm not sure. Especially for networks that have no exit nodes as there is no overlap with the globally routed internet at all.

I think clients should be discouraged from gossiping stuff they cannot
test but not forbidden from doing so. Separately, they should be
strongly discouraged from gossiping types they don't understand at
all. We don't really want to see people doing file xfer over invalid
addr types. :)

📅 Original date posted:2019-03-12 📝 Original message:On ...

2023-06-07T20:16:37+02:00

In reply to nevent1q…95wj
_________________________

📅 Original date posted:2019-03-12
📝 Original message:On Tue, Mar 12, 2019 at 7:45 PM Andreas Schildbach via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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 to better understand this, but it would be easier to just
read the code than ask a bunch of questions. I tried looking for the
handling of reject messages in Android Bitcoin Wallet and BitcoinJ
and didn't really find and handling other than logging exceptions.
Would you mind giving me a couple pointers to where in the code
they're handled?

📅 Original date posted:2019-03-07 📝 Original message:On ...

2023-06-07T20:16:36+02:00

In reply to nevent1q…rq0n
_________________________

📅 Original date posted:2019-03-07
📝 Original message:On Thu, Mar 7, 2019 at 11:46 PM Andreas Schildbach via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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 confirmations.

That is already required because even in the presence of perfectly
honest and cooperative hosts reject messages at most can only tell you
about first-hop behaviour. It won't even tell you if the transaction
was ever even attempted to be sent to a next hop. So alternative
handling must be provided and must be reliable for the software to
work at all regardless of reject messages.

> - Not enough fee

Rejection on low fee (over the static minimum feerate) only happens at
the point where the nodes mempool is full, which is already at a point
where you might be waiting weeks for confirmation.

Rejection causes were also not stable or reliable because the validity
criteria cannot generally be tested independently. For example, if a
transaction is queued due to missing a parent it isn't rejected
because missing the parent is often a temporary issue, but its feerate
cannot be measured without the parent. Later, when the parent is
obtained, the transaction can then be rejected due to feerate-- but no
reject is sent then.

Output already spend is often completely indistinguishable from a
missing parent and can't get rejects generated for it generally.

Similarly, the error state detected for things like invalid signatures
are often not very useful. The software knows that script execution
returned false, but in the general case _why_ it returned false is not
clear, and a straightforward high performance validation
implementation doesn't necessarily yield a good way of figuring out
and propagating up that information. (I think invalid signatures end
up returning a stack-nonempty state from validation currently, as an
example of that).

📅 Original date posted:2019-02-06 📝 Original message:On ...

2023-06-07T20:16:25+02:00

In reply to nevent1q…5ydn
_________________________

📅 Original date posted:2019-02-06
📝 Original message:On Wed, Feb 6, 2019 at 8:10 AM Tamas Blummer <tamas.blummer at gmail.com> 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 would actually bother reading the threads where this was
discussed previously you will see that there was significant interest
from bitcoin developers to eventually commit an output filter, and a
significant investment of effort in improving the proposal to that
end. It is really disheartening to see you continue to repeat your
negative assumptions about other people's wishes when you haven't even
invested the time required to read their words.

📅 Original date posted:2018-09-06 📝 Original message:On ...

2023-06-07T20:14:33+02:00

In reply to nevent1q…jck2
_________________________

📅 Original date posted:2018-09-06
📝 Original message:On Thu, Sep 6, 2018 at 11:33 PM Tim Ruffing via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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 threat isn't
theoretical.

> Sure,
> but if that's your threat model then Bitcoin is probably not the right tool for you. (And if

Why not?

> you insist that Bitcoin is the right tool, then you can and probably should use it over Tor
> anyway.)

Currently, Tor provides _no confidentiality at all_ in that threat
model. Part of why I think this enhancement is interesting is because
without it BIP151 doesn't actually add anything for those p2p
connections running over Tor, but with it -- it at least adds some
long term confidentiality hedge.

> It's not worth the hassle, would hinder adoption,

Why do you say this?

> impression of "bulletproof" security. Even worse, there will be too many people that will suddenly
> assume that Bitcoin is post-quantum secure.

People already make that claim with respect to public key hashing. I
don't think "we shouldn't improve security because someone will
mistake an improvement for perfection" is an an especially interesting
argument.

> Key exchange indistinguishable from random
> ==========================================
> I would rather love to see a simple ECDH key exchange as currently used but with an encoding of
> public key that provides indistinguishability from random bitstrings. "Elligator" does not work
> but "Elligator Squared" [1] does the job for secp256k1 -- it just doubles the size of the public

Here is where I turn the argument around on you: This requires
writing a non-trivial amount of moderately complex new cryptographic
code (which is not the case for PQ schemes-- that merely requires
dropping in pre-existing code) and yet I am not aware of any attack
model that this which would any improvement in actually delivered
security: Bitcoin traffic is _trivially_ identifiable by its traffic
patterns.

(Blockstream previously wrote the SW forward transform for asset
generation, but this requires the inverse too, as well as glue code.
It also isn't clear to me if it's possible to make this construction
constant time, which would be okay for BIP151 purposes but if we
wanted to have a generic uniform encoder in libsecp256k1 I think we'd
prefer it be constant time? maybe?)

The scheme in the BIP thus far achieves the property that there are no
fixed bytes for brain-dead byte matching DPI traffic filtering or
anti-virus to match on (or accidentally false positive on). AV false
positives are already an existing problem with the current protocol
and any fixed bytes in the communication are at risk for false
positives or targeted filtering. And achieving that property
requires basically nothing: a test for the first byte of a generated
serialized pubkey and a negate on the private key if it was wrong.

> key. Together with the encrypted packet lengths, the entire data stream looks like random then,

No, it doesn't-- due to traffic analysis. Including, for example, the
pattern that 64-bytes must be sent in each direction, before further
data continues, bursts of traffic coinciding with blocks newly found
on the network, etc.

I don't believe that indistinguishable keys are actually useful
outside of the context of things like stegnographic embedding-- cases
where protocol 'metadata' doesn't tell you that a key is there
regardless.

I suppose if the code already existed to do it I might as well go
"okay, sure why not", it's not going to harm anything (the added
computation time to generate the uniform encoding would probably be no
more than a 10% slowdown). I wouldn't argue against it on the basis
that someone might believe it resulted in anti-censorship properties
that it doesn't have ... even though it's clearly the case... because
I categorically reject that form of argument. :)

I think your view on the two distinctive proposals is askew: PQ
agreement has a clear benefit under a plausible threat model and is
quite easy to implement... while uniform encoding is somewhat harder
to implement (though admittedly not very hard) but doesn't appear to
provide a concrete benefit under any threat model that I'm currently
aware of...

> The key derivation can be improved. It should include each peer's understanding of its role,
> i.e., requester (or "initiator" is the more common term) or responder. At the moment, an attacker
> can create a situation where two peers think they're in the same session (with the same session
> id) but they're actually not. Also, it's possible for an attacker to rerandomize the public keys.
> That's nothing bad by itself but anything which restricts the flexibility of the attacker without
> adding complexity is a good idea. Something like
> "salt = BitcoinSharedSecret||INITIATOR_PUBKEY||RESPONDER_PUBKEY" should just avoid this issue.

I also prefer the contributory key model, but Pieter proved me on IRC
last week that the attack form that I was concerned about was not
possible.

Do you actually have an attack in mind that you can spell out here? I
don't see a harm in changing that, but given that I'd already twice
talked myself out of proposing the same thing, I'd like to understand
if I'm missing something. :)

> Re-keying
> =========
> The problem with signalling re-keying in the length field is that the length field is not covered
> by the MAC.

It's AAD data in the mac, unless I misunderstand the protocol.

> Deterministic rekeying rules may be better. Otherwise there will be implementations that rekey
> every 10 seconds

That would be pretty harmless, since the rekeying operation costs
similar to one message decryption.

> and implementations that just don't rekey at all (rendering the 10 s rekeying
> interval in the opposite direction useless).

The protocol requires rekeying at least after a given amount of data
is transmitted. Peers that violate that can be disconnected. But it
could be unfortunately infrequent.

> Different policies also make it possible to
> fingerprint implementations.

I agree that is a good point.

Personally I'd prefer that we used a ciphersuite that effectively
"rekeyed" every message-- along the lines of the constructions
described https://blog.cr.yp.to/20170723-random.html Unfortunately I
was unable to find _any_ well analyized authenticated encryption mode
that has the fast erasure property. It's too bad because it would be
trivial to adhoc one (e.g. use the extra 32 bytes from the poly1305
chacha run to update the keys for the next message).

> What's better: 5 min or 30 min? I don't know, but both are reasonable choices. (Thats's very much

It doesn't much matter, except for fingerprinting reasons.

> like discussions about ciphers... What's better AES-GCM or ChaCha20/Poly1305? I don't know, but
> again both are reasonable choices.)

Here we have a very clear motiviation. On devices without hardware
AES/clmul constant time AES-GCM is _terribly slow_ compared to
ChaCha20/Poly1305. Performance on the slowest devices is where the
the ones where the ciphersuite choice likely matters at all (because
it could actually make a meaningful difference in their system's
ability to keep up), and the slowest devices that I'm aware of users
commonly using are also devices without good AES-GCM performance.
Unfortunately.

On fast desktop hardware the performance of AES-GCM and
ChaCha20/Poly1305 is also fairly close.

So when it matters, chacha20/poly1305 is higher performance by a wide
margin. (Too bad, because otherwise I'd much rather use AES-GCM)

> I didn't think about this in detail: maybe there are a few meaningful cases where padding could
> hide the message length without too much overhead. (I'm not convinced, just a random thought.)

This can be done at the message level. E.g. new TX messages that round
tx sizes up to the next multiple. I don't think useful low overhead
padding is otherwise possible.

> written in stone, again to avoid complexity and to avoid fingerprinting.

Writing things in stone is a great way to never finish a protocol.
Right now we know we have new upcoming proposals for messages where
the overhead matters, e.g. we need a replacement addr message ASAP,
and there is ongoing work for transaction relay that would also
benefit from low overhead.

The norm in Bitcoin is to ignore messages you don't know how to parse
anyways, so there is no complexity that arises from "may negotiate"
itself-- only from actually making use of that possibility in the
future, so the merits of any particular usage could be decided when
something wants to actually use it. The purpose of pointing out "may
negotiate" is, I think, primarily to avoid a debate about who would
assign numbers from this limited space in the future-- and the answer
just is that they're implementation defined (e.g. by the BIPs using
them).

> necessary anyway, so maybe just use IDs for anything? ASCII is nice if you want to debug your code
> or some random network failure but that's hard anyway when encryption is used.

Right, encryption kills external analysers in any case. It's also easy
to just logprintf traffic (this is open source software after all),
which doesn't have a decoding problem.

> - "The Re-Keying must be done after every 1GB of data sent or received" Hm, every peer updates its
> own sending key, so this should just read "sent" instead of "sent or received"?

I think it says 'received there' mostly because it's implicitly
telling you that you can hang up on someone who violates it. I agree
it would be more consistent to express it sending side there.

📅 Original date posted:2018-09-11 📝 Original message:On ...

2023-06-07T20:14:31+02:00

In reply to nevent1q…zpwm
_________________________

📅 Original date posted:2018-09-11
📝 Original message:On Tue, Sep 11, 2018 at 5:38 PM Erik Aronesty <erik at q32.com> 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 has nothing to do with musig. If you want a threshold other than
M of M then you use a threshold other than M of M.

No one is under the impression that M of M is somehow a replacement
for other thresholds. We've spent more time talking about M of M in
some writeups in the past because it's exactly the case you need for
signature aggregation in Bitcoin and because it's a simpler case to
explain.

> - Having the senders of the G*x pubkey shares sign their messages with the associated private key share should be sufficient to prevent them from using wagner's algorithm to attack the combined key.

Yes, that is one possibility which is described in the musig paper,
but it requires users communicate an extra signature per key. So, for
example, if used with aggregate signature it would completely
eliminate the communications efficiency gains from aggregation, making
aggregation worse than pointless. It also has somewhat worse failure
properties than delinearization, because a signer that fails to
validate other's share signatures behaves behaves exactly the same as
a correct one, on honest inputs. That approach has its uses but I
think that in any case where delinearization can be used it's a better
option.

📅 Original date posted:2018-09-11 📝 Original message:On ...

2023-06-07T20:14:30+02:00

In reply to nevent1q…fw8c
_________________________

📅 Original date posted:2018-09-11
📝 Original message:On Tue, Sep 11, 2018 at 5:20 PM Erik Aronesty <erik at q32.com> 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 worried that Bitcoin releases a multisig that encourages loss.

There is no "non- edistributiable multisig" proposed for Bitcoin
anywhere that I am aware of.

📅 Original date posted:2018-09-05 📝 Original message:On ...

2023-06-07T20:14:28+02:00

In reply to nevent1q…2z8u
_________________________

📅 Original date posted:2018-09-05
📝 Original message:On Wed, Sep 5, 2018 at 1:49 PM Erik Aronesty via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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 the response.

https://bitcointalk.org/index.php?topic=4973123.0

> The more I look into it and speak to professors about i, the more it seems "so trivial nobody really talks about it".

I think you might be falling into the trap of ignoring feedback you
don't like and and accepting that which sounds like "yea yea,
something like that".

Something "like that" does work: and is expressly and explicitly
anticipated by the BIP but to be both secure and functional requires
proper delineation (E.g. musig) _and_ interaction. What you're
proposing is continually vague. My best efforts at making sense of
what you've written indicate that either it's non-interactive and
not-actually functional at all, OR it's interactive and just a less
secure subset (no proper delinearization to prevent rogue key attacks)
of what we already propose.

When Poelstra suggests a CAS implementation he means something like
this Sage notebook: http://bitcoin.ninja/secp256k1.ecdsa.sage This
provides for a method of communicating in both directions which is
completely precise.

📅 Original date posted:2018-07-09 📝 Original message:On ...

2023-06-07T20:13:42+02:00

In reply to nevent1q…p88a
_________________________

📅 Original date posted:2018-07-09
📝 Original message:On Mon, Jul 9, 2018 at 3:02 PM, Erik Aronesty via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> with
> security assumptions that match the original Schnorr construction more
> closely,

More closely than what?

📅 Original date posted:2018-07-08 📝 Original message:On ...

2023-06-07T20:13:40+02:00

In reply to nevent1q…nn2j
_________________________

📅 Original date posted:2018-07-08
📝 Original message:On Sun, Jul 8, 2018 at 3:16 PM, Tim Ruffing via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> so what
> you want is possible already with Schnorr signatures.

As also described in "Multisignatures and Threshold Signatures" in the BIP.

📅 Original date posted:2018-07-06 📝 Original message:On ...

2023-06-07T20:13:38+02:00

In reply to nevent1q…j0ax
_________________________

📅 Original date posted:2018-07-06
📝 Original message:On Fri, Jul 6, 2018 at 9:05 PM, Russell O'Connor via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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, especially
> when multiple signatures for a single public key need to be generated and/or
> verified. If all things are otherwise equal, perhaps this alternate order
> is better.

There is a minor design preference to have message before nonce when
H() is a MD-style hash function. Say the attacker knows some weakness
in H and can find pairs of messages m and m' so that the compression
function results in the same midstate. He could then ask you to sign
m but get a signature that also works for m'. If the signer
controlled R value comes first, then this doesn't work. The pubkey
being where it is in the current design just follows from the idea
that it is just logically prepended on the message. I don't think the
pubkey is sufficiently attacker controlled that the above argument
would apply, so H(P || R.x || m) would be okay.

BUT, the sha256 compression function reads 64 bytes at a time. PRM
would not let you precompute a whole compression function run, but
instead would just let you hardwire part of the expander in a pubkey
dependant way-- an optimization I'm pretty confident virtually no one
would use. (Hardwiring to a constant, yes. Hardwiring to a reused
dynamic value that comes in from the network, no)

If instead the hash function were defined as using 31 zeros then
P||R||m (or P || 31 zeros bytes || R || m, I'm not sure what would be
better), an entire midstate could be cached for different pubkeys. m
is often 32 bytes, sadly- - but the final compression run in that case
would only be the constant update with the length.... and
almost-all-zeros + constant length, is an easy optimization. (Bitcoin
core even has it for computing sha256(sha256())).

[I'm not really sure if I was clear, so I'll try TLDRing it: I think
optimizing sha256 where part of the input is constant is realistic,
optimizing midstate reuse is realistic, optimizing where part is
reused is less realistic. If we insert padding, and put P first, we
can make it possible to midstate cache P, and the 'extra' compression
function run ends up with all constant input, so it could be made
faster.]

📅 Original date posted:2018-07-06 📝 Original message:On ...

2023-06-07T20:13:38+02:00

In reply to nevent1q…vqdq
_________________________

📅 Original date posted:2018-07-06
📝 Original message:On Fri, Jul 6, 2018 at 10:00 PM, Gregory Maxwell <greg at xiph.org> wrote:
> There is a minor design preference to have message before nonce when

::sigh:: to NOT have the message before the nonce.

📅 Original date posted:2018-06-09 📝 Original message:> ...

2023-06-07T20:12:42+02:00

In reply to nevent1q…p32n
_________________________

📅 Original date posted:2018-06-09
📝 Original message:> 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 secure
because it slows convergence on the design of what would get
committed.

>> I don't agree at all, and I can't see why you say so.
>
> Sure it doesn't _have_ to, but from my PoV as "adding more commitments" is
> on the top of every developers wish list for additions to Bitcoin, it would
> make sense to coordinate on an "ultimate" extensible commitment once, rather
> than special case a bunch of distinct commitments. I can see arguments for
> either really.

We have an extensible commitment style via BIP141 already. I don't see
why this in particular demands a new one.

> 1. The current filter format (even moving to prevouts) cannot be committed
> in this fashion as it indexes each of the coinbase output scripts. This
> creates a circular dependency: the commitment is modified by the
> filter,

Great point, but it should probably exclude coinbase OP_RETURN output.
This would exclude the current BIP141 style commitment and likely any
other.

Should I start a new thread on excluding all OP_RETURN outputs from
BIP-158 filters for all transactions? -- they can't be spent, so
including them just pollutes the filters.

> 2. Since the coinbase transaction is the first in a block, it has the
> longest merkle proof path. As a result, it may be several hundred bytes
> (and grows with future capacity increases) to present a proof to the

If 384 bytes is a concern, isn't 3840 bytes (the filter size
difference is in this ballpark) _much_ more of a concern? Path to the
coinbase transaction increases only logarithmically so further
capacity increases are unlikely to matter much, but the filter size
increases linearly and so it should be much more of a concern.

> In regards to the second item above, what do you think of the old Tier Nolan
> proposal [1] to create a "constant" sized proof for future commitments by
> constraining the size of the block and placing the commitments within the
> last few transactions in the block?

I think it's a fairly ugly hack. esp since it requires that mining
template code be able to stuff the block if they just don't know
enough actual transactions-- which means having a pool of spendable
outputs in order to mine, managing private keys, etc... it also
requires downstream software not tinker with the transaction count
(which I wish it didn't but as of today it does). A factor of two
difference in capacity-- if you constrain to get the smallest possible
proof-- is pretty stark, optimal txn selection with this cardinality
constraint would be pretty weird. etc.

If the community considers tree depth for proofs like that to be such
a concern to take on technical debt for that structure, we should
probably be thinking about more drastic (incompatible) changes... but
I don't think it's actually that interesting.

> I don't think its fair to compare those that wish to implement this proposal
> (and actually do the validation) to the legacy SPV software that to my
> knowledge is all but abandoned. The project I work on that seeks to deploy

Yes, maybe it isn't. But then that just means we don't have good information.

When a lot of people were choosing electrum over SPV wallets when
those SPV wallets weren't abandoned, sync time was frequently cited as
an actual reason. BIP158 makes that worse, not better. So while I'm
hopeful, I'm also somewhat sceptical. Certainly things that reduce
the size of the 158 filters make them seem more likely to be a success
to me.

> too difficult to implement "full" validation, as they're bitcoin developers
> with quite a bit of experience.

::shrugs:: Above you're also arguing against fetching down to the
coinbase transaction to save a couple hundred bytes a block, which
makes it impossible to validate a half dozen other things (including
as mentioned in the other threads depth fidelity of returned proofs).
There are a lot of reasons why things don't get implemented other than
experience! :)

📅 Original date posted:2018-06-08 📝 Original message:On ...

2023-06-07T20:12:40+02:00

In reply to nevent1q…usrr
_________________________

📅 Original date posted:2018-06-08
📝 Original message:On Fri, Jun 8, 2018 at 5:03 AM, Olaoluwa Osuntokun via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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 includes
> prev scripts (b) instead of the outpoint as the "regular" filter does now.
> Switching to prev script in the _short term_ would be costly for the set of
> applications already deployed (or deployed in a minimal or flag flip gated
> fashion) as the move from prev script to outpoint is a cascading one that
> impacts wallet operation, rescans, HD seed imports, etc.

It seems to me that you're making the argument against your own case
here: I'm reading this as a "it's hard to switch so it should be done
the inferior way". That in argument against adopting the inferior
version, as that will contribute more momentum to doing it in a way
that doesn't make sense long term.

> Such a proposal would need to be generalized enough to allow several components to be committed,

I don't agree at all, and I can't see why you say so.

> likely have versioning,

This is inherent in how e.g. the segwit commitment is encoded, the
initial bytes are an identifying cookies. Different commitments would
have different cookies.

> and also provide the necessary extensibility to allow additional items to be committed in the future

What was previously proposed is that the commitment be required to be
consistent if present but not be required to be present. This would
allow changing whats used by simply abandoning the old one. Sparsity
in an optional commitment can be addressed when there is less than
100% participation by having each block that includes a commitment
commit to the missing filters ones from their immediate ancestors.

Additional optionality can be provided by the other well known
mechanisms, e.g. have the soft fork expire at a block 5 years out
past deployment, and continue to soft-fork it in for a longer term so
long as its in use (or eventually without expiration if its clear that
it's not going away).

> wallets which wish to primarily use the filters for rescan purposes can't
> just construct them locally for this particular use case independent of
> what's currently deployed on the p2p network.

Absolutely, but given the failure of BIP37 on the network-- and the
apparent strong preference of end users for alternatives that don't
scan (e.g. electrum and web wallets)-- supporting making this
available via P2P was already only interesting to many as a nearly
free side effect of having filters for local scanning. If it's a
different filter, it's no longer attractive.

It seems to me that some people have forgotten that this whole idea
was originally proposed to be a committed data-- but with an added
advantage of permitting expirementation ahead of the commitment.

> Maintaining the outpoint also allows us to rely on a "single honest peer"security model in the short term.

You can still scan blocks directly when peers disagree on the filter
content, regardless of how the filter is constructed-- yes, it uses
more bandwidth if you're attacked, but it makes the attack ineffective
and using outpoints considerably increases bandwidth for everyone
without an attack. These ineffective (except for increasing
bandwidth) attacks would have to be common to offset the savings. It
seems to me this point is being overplayed, especially considering the
current state of non-existing validation in SPV software (if SPV
software doesn't validate anything else they could be validating, why
would they implement a considerable amount of logic for this?).

📅 Original date posted:2018-06-02 📝 Original message:On ...

2023-06-07T20:12:39+02:00

In reply to nevent1q…sgdy
_________________________

📅 Original date posted:2018-06-02
📝 Original message:On Sat, Jun 2, 2018 at 10:02 PM, Tamas Blummer via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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: it's very low. I see under average
of 1 peer per day using it.

Moreover the primary complaint from users about BIP37 vs the
alternatives they're choosing over it (electrum and web wallets) is
that the sync time is too long-- something BIP158 doesn't improve.

So if we were going to go based on history we wouldn't bother with on
P2P at all. But I think the history's lesson here may mostly be an
accident, and that the the non-use of BIP37 is due more to the low
quality and/or abandoned status of most BIP37 implementing software,
rather than a fundamental lack of utility. Though maybe we do find
out that once someone bothers implementing a PIR based scanning
mechanism (as electrum has talked about on and off for a while now)
we'll lose another advantage.

BIP37 also got a number of things wrong-- what went into the filters
was a big element in that (causing massive pollution of matches due to
useless data), along with privacy etc. This kind of approach will
have the best chances if it doesn't repeat the mistakes... but also
it'll have the best chances if it has good security, and getting SPV-
equivalent security will require committing the filters, but
committing them is a big step because then the behaviour becomes
consensus normative-- it's worth spending a few months of extra
iteration getting the design as good as possible before doing that
(which is what we've been seeing lately).

📅 Original date posted:2018-06-01 📝 Original message:On ...

2023-06-07T20:12:38+02:00

In reply to nevent1q…pr8j
_________________________

📅 Original date posted:2018-06-01
📝 Original message:On Sat, Jun 2, 2018 at 12:01 AM, Olaoluwa Osuntokun <laolu32 at gmail.com> 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 unless the
> attacker is also creating invalid blocks w/ valid PoW.

I wish that were the true, but absent commitments that wouldn't be the
case unless you were always downloading all the blocks-- since you
wouldn't have any sign that there was something wrong with the
filter-- and downloading all the blocks would moot using the filters
in the first place. :)

Or have I misunderstood you massively here?

For segwit originally I had proposed adding additional commitments
that would make it possible to efficiently prove invalidity of a
block; but that got stripped because many people were of the view that
the "assume you have at least one honest peer who saw that block and
rejected it to tell you that the block was invalid" security
assumption was of dubious value. Maybe it's more justifiable to make
use of a dubious assumption for a P2P feature than for a consensus
feature? Perhaps, I'd rather have both filter types from day one so
that things not implementing the comparison techniques don't get the
efficiency loss or the extra work to change filter types for a
consensus one.

[I think now that we're much closer to a design that would be worth
making a consensus committed version of than we were a few months ago
now, since we are effectively already on a second generation of the
design with the various improvements lately]

📅 Original date posted:2018-06-01 📝 Original message:On ...

2023-06-07T20:12:37+02:00

In reply to nevent1q…7uef
_________________________

📅 Original date posted:2018-06-01
📝 Original message:On Fri, Jun 1, 2018 at 2:52 AM, Olaoluwa Osuntokun via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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, as it

Only if you make a very strong assumption about the integrity of the
nodes the client is talkign to. 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.

The original propsal for using these kinds of maps was that their
digests could eventually be commited and then checked against the
commitment, matching the same general security model used otherwise in
SPV.

Unfortunately, using the scripts instead of the outpoints takes us
further away from a design that is optimized for committing (or, for
that matter, use purely locally by a wallet)...

📅 Original date posted:2018-05-25 📝 Original message:On ...

2023-06-07T20:12:29+02:00

In reply to nevent1q…tm68
_________________________

📅 Original date posted:2018-05-25
📝 Original message:On Fri, May 25, 2018 at 5:54 PM, Pieter Wuille via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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 FP rate of exactly 1 in 2^20, the Rice
> parameter should be 19, not 20. If we don't, we should pick an FP rate
> of 1 in a 1.4971*2^B. So for example M=784931 B=19 or M=1569861 B=20.

I did a rough analysis using Pieter's approximations on what
parameters minimizes the total communications for a lite wallet
scanning the chain and fetching a witnessless block whenever they get
a filter hit. For a wallet with 1000 keys and blocks of 1MB if the
number of entries in the is at least 5096 then M=784931 results in a
lower total data rate rate (FP blocks + filters) than M=1569861.
M=392465 (the optimal value for the rice parameter 18) is
communications is better if at least 10192 entries are set, and
M=196233 (optimal FP for rice 17) is better if at least 20384 entries
are set.

The prior filter set proposal is setting roughly 13300 entries per
full block, and I guestimate that the in+out scripts only ones are
setting about 7500 entries (if that actual number was in any of the
recent posts I missed it, I'm guessing based on jimpo's sizes graph).

The breakpoints are obviously different if the client is monitoring
for, say, 10,000 keys instead of 1000 but I think it generally makes
more sense to optimize for lower key counts since bigger users are
more likely to tolerate the additional bandwidth usage.

So I think that assuming that all-scripts inputs and outputs (but no
txids) are used and that my guess of 7500 bits set for that
configuration is roughly right, then M=1569861 and rice parameter 19
should be used.

The actual optimal FP rate for total data transferred won't be one
that gets the optimal rice coding efficiency, but since different
clients will be monitoring for different numbers of keys, it probably
makes sense to pick a parameter with optimal compression rather than
optimal-data-transfer-for-a-specific-key-count-- at least then we're
spending the least amount of filter bits per false positive rate,
whatever that rate is... if we can't be optimal at least we can be
efficient. :)

📅 Original date posted:2018-05-28 📝 Original message:Is ...

2023-06-07T20:12:17+02:00

In reply to nevent1q…axas
_________________________

📅 Original date posted:2018-05-28
📝 Original message: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 coins. If we're not aware of any applications that wouldnt use
both, there isn't much reason to separate them and if input scripts
are used instead of input outpoints there is additional savings from
combining them (due to the same scripts being spent as were created in
the block-- due to reuse and chaining).

I still am of the belief, based on Matt's argument, that there is no
use for txid what-so-ever (instead just watch for an outpoint).

On Mon, May 28, 2018 at 6:28 PM, Tamas Blummer <tamas.blummer at gmail.com> wrote:
> Forgot to mention: The link I sent is to a branch that is patched to produce the filter stats.
> This is the main project and the BIP158 implementation: https://github.com/rust-bitcoin/rust-bitcoin-spv/blob/master/src/blockfilter.rs
>
> Tamas Blummer
>
>> On May 28, 2018, at 20:18, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>>
>> Hi Jim,
>>
>> A “basic” combined filter would mean up to 0.5 GB filter data per month (with 100% segwith use). Considering that 1 GB is the usual data quota for an entry level mobile phone contract, this could be a too high barrier for adoption.
>>
>> I repeated your calculations and produced a slightly different graph that shows the fraction of cummulative filter size to cummulative blockchain size. This is less noisy but otherwise confirms your measurement.
>>
>> I think that the data supports separation of filters as a combined filter does not seem to come with significant savings. (basic size ~= txid + input points + output scripts sizes)
>>
>> My calculations are repeatable with:
>>
>> https://github.com/tamasblummer/rust-bitcoin-spv/blob/blockfilterstats/src/bin/blockfilterstats.rs
>>
>> that is using a Rust implementation of an SPV client built on top of other libraries we work on in the rust-bitcoin GitHub community (https://github.com/rust-bitcoin). Yes, this is a shameles plug for the project hoping to attract more developer.
>>
>> Tamas Blummer
>>
>>
>> <filters.png>
>>
>>> On May 24, 2018, at 05:48, Jim Posen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> Greg, I've attached a graph including the input scripts.
>>>
>>> In the top graph, we can see how the input script filter compares to the input outpoint filter. It is definitely smaller as a result of address reuse. The bottom graph shows the ratio over time of combining the input prev script and output script filters vs keeping them separate. In more recent blocks, it appears that there are decreasing savings.
>>>
>>
>

📅 Original date posted:2018-05-23 📝 Original message:Any ...

2023-06-07T20:12:15+02:00

In reply to nevent1q…6039
_________________________

📅 Original date posted:2018-05-23
📝 Original message: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
<bitcoin-dev at lists.linuxfoundation.org> 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 ~120,000 blocks are so small that the
> Golomb-Rice coding can't compress the filters that well, which is why the
> filter sizes are so high proportional to the block size. Except for the
> input filter, because the coinbase input is skipped, so many of them have 0
> elements. But after block 120,000 or so, the filter compression converges
> pretty quickly to near the optimal value. The encouraging thing here is that
> if you look at the ratio of the combined size of the separated filters vs
> the size of a filter containing all of them (currently known as the basic
> filter), they are pretty much the same size. The mean of the ratio between
> them after block 150,000 is 99.4%. So basically, not much compression
> efficiently is lost by separating the basic filter into sub-filters.
>
> On Tue, May 22, 2018 at 5:42 PM, Jim Posen <jim.posen at gmail.com> wrote:
>>>
>>> My suggestion was to advertise a bitfield for each filter type the node
>>> serves,
>>> where the bitfield indicates what elements are part of the filters. This
>>> essentially
>>> removes the notion of decided filter types and instead leaves the
>>> decision to
>>> full-nodes.
>>
>>
>> I think it makes more sense to construct entirely separate filters for the
>> different types of elements and allow clients to download only the ones they
>> care about. If there are enough elements per filter, the compression ratio
>> shouldn't be much worse by splitting them up. This prevents the exponential
>> blowup in the number of filters that you mention, Johan, and it works nicely
>> with service bits for advertising different filter types independently.
>>
>> So if we created three separate filter types, one for output scripts, one
>> for input outpoints, and one for TXIDs, each signaled with a separate
>> service bit, are people good with that? Or do you think there shouldn't be a
>> TXID filter at all, Matt? I didn't include the option of a prev output
>> script filter or rolling that into the block output script filter because it
>> changes the security model (cannot be proven to be correct/incorrect
>> succinctly).
>>
>> Then there's the question of whether to separate or combine the headers.
>> I'd lean towards keeping them separate because it's simpler that way.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2018-05-17 📝 Original message:On ...

2023-06-07T20:12:12+02:00

In reply to nevent1q…q9pp
_________________________

📅 Original date posted:2018-05-17
📝 Original message:On Thu, May 17, 2018 at 4:59 PM, Matt Corallo <lf-lists at mattcorallo.com> 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.

I think lite clients cross checking is something which very likely
will never be implemented by anyone, and probably not stay working
(due to under-usage) if it is implemented. This thought is driven by
three things (1) the bandwidth overhead of performing the check, (2)
thinking about the network-interacting-state-machine complexity of it,
and by the multitude of sanity checks that lite clients already don't
implement (e.g. when a lite client noticed a split tip it could ask
peers for the respective blocks and check at least the stateless
checks, but none has ever done that), and...

(3) that kind of checking would be moot if the filters were committed
and validated... and the commitment would be both much simpler to
check for lite clients and provide much stronger protection against
malicious peers.

My expectation is that eventually one of these filter-map designs
would become committed-- not after we already had it deployed and had
worked out the design to the n-th generation (just as your proposed
revisions are doing to the initial proposal), but eventually.

Also, even without this change clients can still do that "are multiple
peers telling me the same thing or different things" kind of checking,
which I expect is the strongest testing we'd actually see them
implement absent a commitment.

📅 Original date posted:2018-05-17 📝 Original message:On ...

2023-06-07T20:12:12+02:00

In reply to nevent1q…shwn
_________________________

📅 Original date posted:2018-05-17
📝 Original message:On Thu, May 17, 2018 at 8:19 PM, Jim Posen <jim.posen at gmail.com> 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 whatnot can moot whatever kind of
comparisons you make, and non-comparison based validation doesn't seem
like it would be useful without mooting all the bandwidth improvements
unless I'm missing something.

It isn't a question of 'some lite clients' -- I am aware of no
implementation of these kinds of measures in any cryptocurrency ever.

The same kind of comparison to the block could have been done with
BIP37 filtering, but no one has implemented that. (similarly, the
whitepaper suggests doing that for all network rules when a
disagreement has been seen, though that isn't practical for all
network rules it could be done for many of them-- but again no
implementation or AFAIK any interest in implementing that)

> If the
> protocol can provide clients the option of getting additional security, it
> should.

Sure, but at what cost? And "additional" while nice doesn't
necessarily translate into a meaningful increase in delivered security
for any particular application.

I think we might be speaking too generally here.

What I'm suggesting would still allow a lite client to verify that
multiple parties are offering the same map for a given block (by
asking them for the map hash). It would still allow a future
commitment so that lite client could verify that the hashpower they're
hearing from agrees that the map they got is the correct corresponding
map for the block. It would still allow downloading a block and
verifying that all the outpoints in the block were included. So still
a lot better than BIP37.

What it would not permit is for a lite client to download a whole
block and completely verify the filter (they could only tell if the
filter at least told them about all the outputs in the block, but if
extra bits were set or inputs were omitted, they couldn't tell).

But in exchange the filters for a given FP rate would be probably
about half the current size (actual measurements would be needed
because the figure depends on much scriptpubkey reuse there is, it
probably could be anywhere between 1/3 and 2/3rd). In some
applications it would likely have better anonymity properties as well,
because a client that always filters for both an output and and input
as distinct items (and then leaks matches by fetching blocks) is more
distinguishable.

I think this trade-off is at leat worth considering because if you
always verify by downloading you wash out the bandwidth gains, strong
verification will eventually need a commitment in any case. A client
can still partially verify, and can still multi-party comparison
verify. ... and a big reduction in filter bandwidth

Monitoring inputs by scriptPubkey vs input-txid also has a massive
advantage for parallel filtering: You can usually known your pubkeys
well in advance, but if you have to change what you're watching block
N+1 for based on the txids that paid you in N you can't filter them
in parallel.

> On the general topic, Peter makes a good point that in many cases filtering
> by txid of spending transaction may be preferable to filtering by outpoint
> spend, which has the nice benefit that there are obviously fewer txs in a
> block than txins. This wouldn't work for malleable transactions though.

I think Peter missed Matt's point that you can monitor for a specific
transaction's confirmation by monitoring for any of the outpoints that
transaction contains. Because the txid commits to the outpoints there
shouldn't be any case where the txid is knowable but (an) outpoint is
not. Removal of the txid and monitoring for any one of the outputs
should be a strict reduction in the false positive rate for a given
filter size (the filter will contain strictly fewer elements and the
client will match for the same (or usually, fewer) number).

I _think_ dropping txids as matt suggests is an obvious win that costs
nothing. Replacing inputs with scripts as I suggested has some
trade-offs.

📅 Original date posted:2018-05-17 📝 Original message:On ...

2023-06-07T20:12:11+02:00

In reply to nevent1q…75an
_________________________

📅 Original date posted:2018-05-17
📝 Original message:On Thu, May 17, 2018 at 4:59 PM, Matt Corallo <lf-lists at mattcorallo.com> 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.

I think lite clients cross checking is something which very likely
will never be implemented by anyone, and probably not stay working
(due to under-usage) if it is implemented. This thought is driven by
three things (1) the bandwidth overhead of performing the check, (2)
thinking about the network-interacting-state-machine complexity of it,
and by the multitude of sanity checks that lite clients already don't
implement (e.g. when a lite client noticed a split tip it could ask
peers for the respective blocks and check at least the stateless
checks, but none has ever done that), and...

(3) that kind of checking would be moot if the filters were committed
and validated... and the commitment would be both much simpler to
check for lite clients and provide much stronger protection against
malicious peers.

My expectation is that eventually one of these filter-map designs
would become committed-- not after we already had it deployed and had
worked out the design to the n-th generation (just as your proposed
revisions are doing to the initial proposal), but eventually.

Also, even without this change clients can still do that "are multiple
peers telling me the same thing or different things" kind of checking,
which I expect is the strongest testing we'd actually see them
implement absent a commitment.

📅 Original date posted:2018-05-17 📝 Original message:On ...

2023-06-07T20:12:11+02:00

In reply to nevent1q…e9z3
_________________________

📅 Original date posted:2018-05-17
📝 Original message:On Thu, May 17, 2018 at 3:25 PM, Matt Corallo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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.

What about also making input prevouts filter based on the scriptpubkey
being _spent_? Layering wise in the processing it's a bit ugly, but
if you validated the block you have the data needed.

This would eliminate the multiple data type mixing entirely.

📅 Original date posted:2018-01-29 📝 Original message:On ...

2023-06-07T20:10:24+02:00

In reply to nevent1q…ve9n
_________________________

📅 Original date posted:2018-01-29
📝 Original message:On Mon, Jan 29, 2018 at 9:40 PM, Tier Nolan via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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 median is not used for
improved accuracy but to mitigate a consensus incompatibility:

If the block's own timestamp were used for nlocktime and time based
nlocks were common on the network each miner would maximize their fee
income by setting the value as high as they could get away with. What
concerned us wasn't so much that this would make the times less
accurate (though it would) but rather that it would create an
incentive for a runaway situation that could harm network stability
(e.g. with all miners cranking times against the 2hr window, then
creating pressure for miners to accept further and further in the
future; each responding to his own local incentives).

This incentive incompatibility could have been addressed e.g. by using
the prior block's time, but since the protocol doesn't require times
to be monotone (and for good reason!) the simple implementation of
that wouldn't have been a soft-fork. The 11 block MTP worked out
nicely because the protocol already required new times to be larger
than that.

The timestamps in Bitcoin aren't intended to be particularly accurate.
They're used only for controlling the difficulty, and the adjustment
window is large enough that there isn't much distortion that can be
accomplished there. It's not clear to me that much better can really
be done... if there were tighter time requirements in the protocol
miners would address them by running NTP which as an _astounding_ lack
of security in terms of how it is commonly deployed. As far as I
know, I'm the only person whos ever mined blocks with their own
stratum 1 time source.

If times need to be accurate Bitcoin would need to use a rather
different design (e.g. each block would commit to the observation time
of the prior N blocks, and an iterative algorithm would solve for each
blocks time and each miners local offset).

IIRC open-timestamp calendar servers provide more precise
time-stamping under the assumption that the calendar server is
behaving correctly.

📅 Original date posted:2018-01-23 📝 Original message:On ...

2023-06-07T20:10:08+02:00

In reply to nevent1q…09dn
_________________________

📅 Original date posted:2018-01-23
📝 Original message:On Tue, Jan 23, 2018 at 6:44 AM, Anthony Towns <aj at erisian.com.au> wrote:
> Is this really intended as paying directly to a pubkey, instead of a
> pubkey hash?
>
> If so, isn't that a step backwards with regard to resistance to quantum
> attacks against ECC?

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

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

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

📅 Original date posted:2018-01-23 📝 Original message:On ...

2023-06-07T20:09:58+02:00

In reply to nevent1q…jz3y
_________________________

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

BIP125 replacement requires that the fee rate increases. The text of
the BIP document is written in a confusing way that doesn't make this
clear.

📅 Original date posted:2018-01-18 📝 Original message:On ...

2023-06-07T20:09:34+02:00

In reply to nevent1q…m2hf
_________________________

📅 Original date posted:2018-01-18
📝 Original message:On Thu, Jan 18, 2018 at 4:59 PM, Ondřej Vejpustek
<ondrej.vejpustek at satoshilabs.com> 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 kind of attack.

My post provided a concrete example. I'd be happy to answer any
questions about it, but otherwise I'm not sure how to make it more
clear.

> Actually, we've been considering something like that. We concluded that it is to much "rolling your own crypto". Instead of diffusion layer we decided to apply KDF on the shared secret.

Quite the opposite-- a large block cipher is a standard
construction... and the off-label application of a KDF that you've
used here doesn't provide any protection against the example I gave.

📅 Original date posted:2018-01-10 📝 Original message:On ...

2023-06-07T20:09:30+02:00

In reply to nevent1q…qqsg
_________________________

📅 Original date posted:2018-01-10
📝 Original message:On Wed, Jan 10, 2018 at 8:28 PM, Pavol Rusnak <stick at satoshilabs.com> 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
>>> computer doesn't learn anything about they keys?
>>
>> Any examples of these?

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

> Actually, scratch that. HW wallet would not know whether the host
> computer is lying or not. The computer would not learn about the keys,
> but still could be malicious and provide invalid result. Is that correct?

I believe that can be avoided by having the computer do somewhat more
work and checking the consistency after the fact.

(or for decode time, having a check value under the encryption...)

📅 Original date posted:2018-01-08 📝 Original message:On ...

2023-06-07T20:09:25+02:00

In reply to nevent1q…gr5t
_________________________

📅 Original date posted:2018-01-08
📝 Original message:On Sun, Jan 7, 2018 at 3:16 PM, Pavol Rusnak via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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 mess. Will try to push this as BIP too once
> we get it to the point we are OK with the contents.
>
> https://github.com/satoshilabs/slips/blob/master/slip-0039.md

This specification forces the key being used through a one way
function, -- so you cannot take a pre-existing key and encode it with
this scheme. The KDF it specifies is unconfigurable and fairly weak
(20000xhmac-sha2-- which can be cracked at about 0.7M passwords a
second on a single motherboard GPU cracker). The construction also
will silently result in the user getting a different private key if
they enter the wrong passphrase-- which could lead to funds loss. It
is again, unversioned-- so it kinda of seems like it is intentionally
constructed in a way that will prevent interoperable use, since the
lack of versioning was a primary complaint from other perspective
users. Of course, it fine if you want to make a trezor only thing,
but why bother BIPing something that was not intended for
interoperability? Even for a single vendor spec the lack of
versioning seems to make things harder to support new key-related
features such as segwit.

The 16-bit "checksum" based on sha2 seems pretty poor since basing
small checksums on a cryptographic hash results in a fairly poor
checksum that is surprisingly likely to accept an errored string. Your
wordlist is 10 bits and you have much less than 1023*10 bits of input,
so you could easily have a 20 bit code (two words) which guaranteed
that up to two errored words would always be detected, and probably
could choose one which catches three words much more often 1:2^20
(sipa's crc tools can help find codes like this).

The metadata seems to make fairly little affordance to help users
avoid accidentally mixing shares from distinct sharings of the same
key. Is it the idea that this is the only likely cause of a checksum
error? (1:2^16 chance of silently returning the wrong key seems kinda
bad). -- I'm not sure much could be done here, though, since
additional payload is precious.

As an aside, your specification might want to give some better advice
about the SSS since my experience virtually everyone gets it wrong in
ways that degrade or destroy its properties e.g. many fail to generate
the additional coefficients of the polynominal randomly which results
in insecurity (see armory for an example). Oh, also, I believe it is
normally refereed to as "SSS" (three S)-- four S is the name of a
linux program for secret sharing.

I'm happy to see that there is no obvious way to abuse this one as a
brainwallet scheme!

📅 Original date posted:2017-12-18 📝 Original ...

2023-06-07T20:08:50+02:00

In reply to nevent1q…r6dy
_________________________

📅 Original date posted:2017-12-18
📝 Original message: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
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Dear list,
>
> I find it hard to understand why a full node that does initial block
> download also must download witnesses if they are going to skip
> verification anyway. If my full node skips signature verification for
> blocks earlier than X, it seems the reasons for downloading the
> witnesses for those blocks are:
>
> * to be able to send witnesses to other nodes.
>
> * to verify the witness root hash of the blocks
>
> I suppose that it's important to verify the witness root hash because
> a bad peer may send me invalid witnesses during initial block
> download, and if I don't verify that the witness root hash actually
> commits to them, I will get banned by peers requesting the blocks from
> me because I send them garbage.
>
> So both the reasons above (there may be more that I don't know about)
> are actually the same reason: To be able to send witnesses to others
> without getting banned.
>
> What if a node could chose not to download witnesses and thus chose to
> send only witnessless blocks to peers. Let's call these nodes
> witnessless nodes. Note that witnessless nodes are only witnessless
> for blocks up to X. Everything after X is fully verified.
>
> Witnessless nodes would be able to sync faster because it needs to
> download less data to calculate their UTXO set. They would therefore
> more quickly be able to provide full service to SPV wallets and its
> local wallets as well as serving blocks to other witnessless nodes
> with same or higher assumevalid block. For witnessless nodes with
> lower assumevalid they can serve at least some blocks. It could also
> serve blocks to non-segwit nodes.
>
> Do witnessless nodes risk dividing the network in two parts, one
> witnessless and one with full nodes, with few connections between the
> parts?
>
> So basically, what are the reasons not to implement witnessless
> nodes?
>
> Thank you,
> /Kalle
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2017-12-11 📝 Original message:On ...

2023-06-07T20:08:39+02:00

In reply to nevent1q…ue6t
_________________________

📅 Original date posted:2017-12-11
📝 Original message:On Mon, Dec 11, 2017 at 8:40 PM, Jim Posen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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

In the last proposal I recall writing up, there was a one byte flag on
each header to indicate what was included.

Nbits _never_ needs to be sent even with other consensus rules because
its more or less necessarily a strict function of the prior headers.
This still holds in every clone of Bitcoin I'm aware of; sending it
with the first header in a group probably makes sense so it can be
checked independently.

> with insufficient benefit.

another >18% reduction in size beyond the removal of prev. is not
insubstantial by any means. I don't think it should lightly be
ignored.

Prev omission itself is not, sadly, magically compatible: I am quite
confident that if there is a bitcoin hardfork it would recover the
nbits/4-guarenteed always-zero bits of prev to use as extra nonce for
miners. This has been proposed many times, implemented at least once,
and the current requirement for mining infrastructure to reach inside
the coinbase txn to increment a nonce has been a reliable source of
failures. So I think we'd want to have the encoding able to encode
leading prev bits.

Many altcoins also change the header structures. If the better thing
is altcoin incompatible, we should still do it. Doing otherwise would
competitively hobble Bitcoin especially considering the frequent
recklessly incompetent moves made by various altcoins and the near
total lack of useful novel development we've seen come out of the
clones.

Probably the most important change in a new header message wouldn't be
the encoding, but it would be changing the fetching mechanism so that
header sets could be pulled in parallel, etc.

I would rather not change the serialization of existing messages,
nodes are going to have to support speaking both messages for a long
time, and I think we already want a different protocol flow for
headers fetching in any case.

📅 Original date posted:2017-11-20 📝 Original message:On ...

2023-06-07T20:07:50+02:00

In reply to nevent1q…wfhx
_________________________

📅 Original date posted:2017-11-20
📝 Original message:On Mon, Nov 20, 2017 at 5:24 PM, Praveen Baratam via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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 from the rest of the transaction data.
>
> Why change the format at all? Why cant we just compute the Transaction ID
> the same way the hash for signing the transaction is computed?

That is effectively what segwit does, upto engineering minutia and
compatibility details.

Segwit does not serialize transactions in to a data structure where
signatures are separated from the rest of the transaction data; this
is a misunderstanding. The "segregated" refers to them being excluded
from the TXID. The serialization of segwit on the p2p network in
transactions and in blocks encodes the witness field inside the
transactions, immediately prior to the nlocktime field.

📅 Original date posted:2017-09-27 📝 Original message:On ...

2023-06-07T20:06:15+02:00

In reply to nevent1q…l6ul
_________________________

📅 Original date posted:2017-09-27
📝 Original message:On Wed, Sep 27, 2017 at 9:54 PM, Tim Ruffing via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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/bitcoin/bitcoin/commit/dae0a89d4b66f08c83ccc8c20cf37521084b6257

(For future reference, git log -p <file> makes it easy to go find
where some string was last in a file, so you can look at the commit
that changed it.)

📅 Original date posted:2017-09-12 📝 Original message:On ...

2023-06-07T20:05:56+02:00

In reply to nevent1q…2d8g
_________________________

📅 Original date posted:2017-09-12
📝 Original message:On Tue, Sep 12, 2017 at 4:49 AM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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 different
> policy.

I agree with your post, but wanted to make a point of clarification on
the use of "can't".

If someone wants to report something to the Bitcoin project we're
obviously at your mercy in how we handle it. If we disagree on the
handling approach we may try to talk you into a different position
based with a rational judgement based on our experience (or, if
justified, advice that we're likely to whine about your approach in
public). But if you still want to go also report a common issue to
something else with a different approach then you can. Even our
ire/whining can be avoided by a sincere effort to communicate and give
us an opportunity to mitigate harm.

That said, as mentioned, we'd encourage otherwise for issues that
warrant it-- and I think with cause enough that the reporter will
agree. So that is a different kind of "cant". :)

In Bitcoin the overwhelming majority of serious issues we've
encountered have been found by people I'd consider 'inside the
project' (frequent regular contributors who aren't seriously involved
in other things). That hasn't been so obviously the case for other
open source projects that I've been involved with; but Bitcoin is
pretty good from a basic security perspective and finding additional
issues often requires specialized experience that few people outside
of the project regulars have (though some, like Sergio, clearly do).

I know through direct experience that both Mozilla and the Chrome
project fix _serious_ (like RCE bugs) issues based on internal
discoveries which they do not make public (apparently ever), though
they may coordinate with distributors on some of them. (Some of
these experiences are also why I give the advice that you should not
consider any computer which has ever run a web browser to be strongly
secure...)

📅 Original date posted:2017-07-07 📝 Original message:On ...

2023-06-07T20:04:03+02:00

In reply to nevent1q…tgjx
_________________________

📅 Original date posted:2017-07-07
📝 Original message:On Fri, Jul 7, 2017 at 11:27 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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 they will in the very short term
(https://anduck.net/bitcoin/fees/4320_blocks.php note the rate drops
when demand falls below supply). But I agree with you if you mean a
somewhat longer term e.g. a year out.

📅 Original date posted:2017-07-07 📝 Original message:On ...

2023-06-07T20:04:02+02:00

In reply to nevent1q…hkqn
_________________________

📅 Original date posted:2017-07-07
📝 Original message:On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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 being written now for change it's authors
expect to be irreversibly applied to the network in less than 30 days.

The timeline of this proposal is recklessly short to such an extreme
level that we have never, to the best of my knowledge, seen a prior
proposal so hasty. Nowhere does this specification provide
justification or assurance that this is at all safe. The time line of
it violates the most minimal of responsible engineering practices, by
being shorter than even a fast development and release candidate
timeframe. This proposal carries an extreme risk for parties to lose
money due to transaction reversals at two distinct points in time and
provides no proposed countermeasures to avoid these losses.

The proposal adds another gratuitous limit to the system: A maximum
transaction size where none existed before, yet this limit is almost
certainly too small to prevent actual DOS attacks while it is also
technically larger than any transaction that can be included today
(the largest possible transaction today is 1mb minus the block
overheads). The maximum resource usage for maliciously crafted 1MB
transaction is enormous and permitting two of them greatly exacerbates
the existing vulnerability.

> Assuming the current transaction pattern is replicated in a 2 MB plain-sized block that is 100% filled with transactions, then the witness-serialized block would occupy 3.6 MB

But in a worst case the result would be 8MB, which this document fails
to mention.

> This is considered safe by many users, companies, miners and academics [2].

The claim that the document's [2] says that these increases are "safe"
is incorrect and is a matter which has been previously corrected by
the authors of the document:
https://www.reddit.com/r/btc/comments/626ud7/coauthor_of_the_paper_that_blockstream_core_keep/dflrshg/
.

The cited paper does an approximate best case analysis considering
only a couple of risk factors (in particular, block relay time, but
ignoring durability to dos attacks, robustness against state
intervention, and initial synchronization time) and concluded that 4MB
was the largest they could argue was safe. The paper goes on to then
argue that even if you crank Bitcoin's parameters to the maximum in
those dimensions that it doesn't result in a truly meaningful increase
in scalablity-- in effect, it's a weak argument against your proposal
and ones like it.

> Deploy a modified BIP91 to activate Segwit. The only modification is that the signal "segsignal" is replaced by "segwit2x".

This means that BIP-91 and your proposal are indistinguishable on the
network, because the string "segsignal" is merely a variable name used
in the software.

> If segwit2x (BIP91 signal) activates at block N,

The proposal is unable to distinguish itself from BIP-91. Does this
mean if segwit2x or BIP91 activates ?

> This reduces the fee pressure on users and companies creating on-chain transactions, matching market expectations and preventing further market disruption

Considering that we just spent the whole weekend with the mempool
having ~1 block or less worth of transactions most of the time, it
seems highly likely that just activating segwit will substantially
disrupt the fee market; to say nothing for the further doubling that
isn't even tempered by new wallet adoptions. There seems to be no
consideration given to avoiding this disruption and preventing further
emergency events when the new capacity is eventually used and software
is again left unprepared for having to pay market fees.

> and buy time for more comprehensive solutions to be developed and tested

In effect, the document admits that it isn't a solution that
meaningfully improves the scale or scalablity but rather it's just a
bailout to temporarily lower/negate transaction fees. It doesn't seem
to make any argument (or even acknowledge) that the risks and
disruption are worth its benefit, and it exacerbates those risks by
being the product of a closed process and having a timeline shorter
than basically any software update for production software (much less
the timeframe for any consensus update previously). Kudos for being
frank here, but it's not exactly selling itself.

It seems to me that the document doesn't really even make an effort to
justify the bailout at all and don't explain how it will result in
anything except an endless series of additional fee bailouts.

Moreover, it doesn't discuss any remediation against the replay
exposure that the proposed hardfork is sure to create. ( I can
guarantee to you, I will not adopt this hardfork; especially given
that is has been made completely clear that the terms of it were set
in its closed door meetings and the input of non-supporters was not
welcome. )

📅 Original date posted:2017-07-07 📝 Original message:On ...

2023-06-07T20:04:02+02:00

In reply to nevent1q…5yay
_________________________

📅 Original date posted:2017-07-07
📝 Original message:On Fri, Jul 7, 2017 at 10:44 PM, Matt Corallo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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
> original change, and does not increase the block size.

Indeed, their code previously did not increase the blocksize but it
was adjusted at the last minute to do so-- so it may actually do that
now. Because they don't appear to have implemented any tests for it, I
wouldn't be too surprised if it still didn't work at all but also
wouldn't be surprised if it did.

You are correct that the specification text appears to refer to the
prior change that did not. (In my response I just assumed that it
meant what they actually did-- good catch).

📅 Original date posted:2017-06-20 📝 Original message:On ...

2023-06-07T20:03:26+02:00

In reply to nevent1q…wnqc
_________________________

📅 Original date posted:2017-06-20
📝 Original message:On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Because a large percentage of miners are indifferent, right now miners have
> to choose between BIP148 and Segwit2x if they want to activate Segwit.

Miners can simply continuing signaling segwit, which will leave them
at least soft-fork compatible with BIP148 and BIP91 (and god knows
what "segwit2x" is since they keep changing the actual definition and
do not have a specification; but last I saw the near-term behavior the
same as BIP91 but with a radically reduced activation window, so the
story would be the same there in the near term).

Ironically, it looks like most of the segwit2x signaling miners are
faking it (because they're not signaling segwit which it requires).
It'll be unfortunate if some aren't faking it and start orphaning
their own blocks because they are failing to signal segwit.

I don't think the rejection of segwit2x from Bitcoin's developers
could be any more resolute than what we've already seen:
https://en.bitcoin.it/wiki/Segwit_support

On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I think it is very naïve to assume that any shift would be temporary.
> We have a hard enough time getting miners to proactively upgrade to
> recent versions of the reference bitcoin daemon. If miners interpret
> the situation as being forced to run non-reference software in order
> to prevent a chain split because a lack of support from Bitcoin Core,
> that could be a one-way street.

I think this is somewhat naive and sounds a lot like the repeat of the
previously debunked "XT" and "Classic" hysteria.

There is a reason that segwit2x is pretty much unanimously rejected by
the technical community. And just like with XT/Classic/Unlimited
you'll continue to see a strong correlation with people who are
unwilling and unable to keep updating the software at an acceptable
level of quality-- esp. because the very founding on their fork is
predicated on discarding those properties.

If miners want to go off and create an altcoin-- welp, thats something
they can always do, and nothing about that will force anyone to go
along with it.

As far as prevent a chain split goes, all those things
(148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
don't think that holds.

📅 Original date posted:2017-04-14 📝 Original message:I do ...

2023-06-07T20:00:02+02:00

In reply to nevent1q…5m0t
_________________________

📅 Original date posted:2017-04-14
📝 Original message:I do not support the BIP148 UASF for some of the same reasons that I
do support segwit: Bitcoin is valuable in part because it has high
security and stability, segwit was carefully designed to support and
amplify that engineering integrity that people can count on now and
into the future.

I do not feel the the approach proposed in BIP148 really measures up
to the standard set by segwit itself, or the existing best practices
in protocol development in this community.

The primary flaw in BIP148 is that by forcing the activation of the
existing (non-UASF segwit) nodes it almost guarantees at a minor level
of disruption.

Segwit was carefully engineered so that older unmodified miners could
continue operating _completely_ without interruption after segwit
activates.

Older nodes will not include segwit spends, and so their blocks will
not be invalid even if they do not have segwit support. They can
upgrade to it on their own schedule. The only risk non-participating
miners take after segwit activation is that if someone else mines an
invalid block they would extend it, a risk many miners already
frequently take with spy-mining.

I do not think it is a horrible proposal: it is better engineered than
many things that many altcoins do, but just not up to our normal
standards. I respect the motivations of the authors of BIP 148. If
your goal is the fastest possible segwit activation then it is very
useful to exploit the >80% of existing nodes that already support the
original version of segwit.

But the fastest support should not be our goal, as a community-- there
is always some reckless altcoin or centralized system that can support
something faster than we can-- trying to match that would only erode
our distinguishing value in being well engineered and stable.

"First do no harm." We should use the least disruptive mechanisms
available, and the BIP148 proposal does not meet that test. To hear
some people-- non-developers on reddit and such-- a few even see the
forced orphaning of 148 as a virtue, that it's punitive for
misbehaving miners. I could not not disagree with that perspective any
more strongly.

Of course, I do not oppose the general concept of a UASF but
_generally_ a soft-fork (of any kind) does not need to risk disruption
of mining, just as segwit's activation does not. UASF are the
original kind of soft-fork and were the only kind of fork practiced by
Satoshi. P2SH was activated based on a date, and all prior ones were
based on times or heights. We introduced miner based activation as
part of a process of making Bitcoin more stable in the common case
where the ecosystem is all in harmony. It's kind of weird to see UASF
portrayed as something new.

It's important the users not be at the mercy of any one part of the
ecosystem to the extent that we can avoid it-- be it developers,
exchanges, chat forums, or mining hardware makers. Ultimately the
rules of Bitcoin work because they're enforced by the users
collectively-- that is what makes Bitcoin Bitcoin, it's what makes it
something people can count on: the rules aren't easy to just change.

There have been some other UASF proposals that avoid the forced
disruption-- by just defining a new witness bit and allowing
non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
think they are vastly superior. They would be slower to deploy, but I
do not think that is a flaw.

We should have patience. Bitcoin is a system that should last for all
ages and power mankind for a long time-- ten years from now a couple
years of dispute will seem like nothing. But the reputation we earn
for stability and integrity, for being a system of money people can
count on will mean everything.

If these discussions come up, they'll come up in the form of reminding
people that Bitcoin isn't easily changed at a whim, even when the
whims are obviously good, and how that protects it from being managed
like all the competing systems of money that the world used to use
were managed. :)

So have patience, don't take short cuts. Segwit is a good improvement
and we should respect it by knowing that it's good enough to wait for,
and for however its activated to be done the best way we know how.

📅 Original date posted:2017-04-07 📝 Original message:On ...

2023-06-07T19:59:40+02:00

In reply to nevent1q…0g47
_________________________

📅 Original date posted:2017-04-07
📝 Original message:On Fri, Apr 7, 2017 at 9:14 PM, Tomas <tomas at tomasvdw.nl> wrote:
> The long term *minimal disk storage* requirement, can obviously not be less
> then all the unspent outputs.

Then I think you may want to retract the claim that "As this solution,
reversing the costs of outputs and inputs, [...] updates to the
protocol addressing the UTXO growth, might not be worth considering
*protocol improvements* "

As you note that the output costs still bound the resource
requirements. Short of radical protocol changes like TXO-proofs the
UTXO data remains a driving unavoidable long term resource cost, not
an implementation detail. Implementation optimizations like improving
locality further or keeping spentness in memory do not change this
fact.

> The storage that is accessed during peak load (block validation with
> pre-synced transactions), is minimized as this only needs the transaction
> index (to lookup ptrs from hashes), the tip of the spend-tree and the tip of

Latency related costs in Bitcoin Core also do not depend on the number
of outputs in transactions in a block. When a transaction is handled
it goes into an in-memory buffer and only gets flushed later if isn't
spent before the buffer fills. A block will take more time to
validate with more inputs, same as you observer, but the aggregate
resource usage for users depends significantly on outputs (so, in fact
there is even further misaligned incentives than just the fact that
small outputs have a outsized long term cost).

📅 Original date posted:2017-04-07 📝 Original message:On ...

2023-06-07T19:59:38+02:00

In reply to nevent1q…mwmm
_________________________

📅 Original date posted:2017-04-07
📝 Original message:On Thu, Apr 6, 2017 at 10:12 PM, Tomas via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>As this
> solution, reversing the costs of outputs and inputs, seems to have
> excellent performance characteristics (as shown in the test results),
> updates to the protocol addressing the UTXO growth, might not be worth
> considering *protocol improvements*

I'm still lost on this-- AFAICT your proposals long term resource
requirements are directly proportional to the amount of unspent output
data, which grows over time at some fraction of the total transaction
volume (plus the rate of spending which is more or less a constant).

Can you help out my understanding here?

📅 Original date posted:2017-04-05 📝 Original message:On ...

2023-06-07T19:59:15+02:00

In reply to nevent1q…lt00
_________________________

📅 Original date posted:2017-04-05
📝 Original message:On Thu, Apr 6, 2017 at 12:39 AM, Joseph Poon <joseph at lightning.network> wrote:
> #bitcoin at freenode:
> 00:04 gmaxwell| lol poon pretending that he isn't complicit in all this stuff.
>
> Are you *fucking* serious? Is this how you resolve all problems? I'm
> taking you seriously and having second thoughts and want to make public
> commitments to do the right thing without any evidence and you come out
> and say *this*?

I apologize for the glib talk on chat and I hope you understand that
the tone in such venues is significantly informal; and that my remark
was a causal one among friends which was not intended in a spirit as
seriously as you've taken it.

That said, two days ago you participated in a highly unusual
announcement of a protocol change that-- rather than being sent for
community review in any plausible venue for that purpose-- was
announced as a done deal in embargoed media announcements. This
proposed protocol change seemed custom tailored to preserve covert
boosting, and incorporated direct support for lightning -- and the
leading competing theory was that a large miner opposed segwit
specifically because they wanted to block lightning. Moreover, I have
heard reports I consider reliable that this work was funded by the
miner in question.

In the time since, when people asked for revisions to the proposal to
not block segwit they received responses from the Bcoin account on
twitter that "there would be no amendments", and I was sent leaked
chatlogs of you making considerably hostile statements, claiming that
if your extension block proposal is "a litmus test for corruption",
and claimed (before AFAIK anyone had had a chance to comment on it)
that the Bitcoin project contributors opposed it for "nonsense
reasons".

It is with this in mind that when you tried to pull me into an off the
record conversation that I responded stating:

"[...] I am disinclined to communicate with you except in email where I can
get third party transferable proof of our communication. I'm
concerned that you may now be involved in a conspiracy which I do not
want to be implicated in myself.

It is my estimation that, for that above reason, it would be in my
best interest to not communicate with you at all. But in all your
prior interactions you appeared to have integrity and sense, so out of
respect for that history I'm willing to communicate with you, but only
in public or in email where my end is on gmail."

This was two days ago and you did not respond further.

With that in mind I hope you do not find some casual crap-talking on
chat to be especially surprising.

I understand that you didn't intend for the initial message to be
posted in public, so I'm sorry for continuing the thread here-- but I
thought it was useful for people to understand the context behind that
glib remark: Including the point that I do not know for a fact that
you are complicit in anything, but I consider your recent actions to
be highly concerning.

📅 Original date posted:2017-04-05 📝 Original message:A ...

2023-06-07T19:59:13+02:00

In reply to nevent1q…6hgr
_________________________

📅 Original date posted:2017-04-05
📝 Original message:A month ago I was explaining the attack on Bitcoin's SHA2 hashcash which
is exploited by ASICBOOST and the various steps which could be used to
block it in the network if it became a problem.

While most discussion of ASICBOOST has focused on the overt method
of implementing it, there also exists a covert method for using it.

As I explained one of the approaches to inhibit covert ASICBOOST I
realized that my words were pretty much also describing the SegWit
commitment structure.

The authors of the SegWit proposal made a specific effort to not be
incompatible with any mining system and, in particular, changed the
design at one point to accommodate mining chips with forced payout
addresses.

Had there been awareness of exploitation of this attack an effort
would have been made to avoid incompatibility-- simply to separate
concerns. But the best methods of implementing the covert attack
are significantly incompatible with virtually any method of
extending Bitcoin's transaction capabilities; with the notable
exception of extension blocks (which have their own problems).

An incompatibility would go a long way to explain some of the
more inexplicable behavior from some parties in the mining
ecosystem so I began looking for supporting evidence.

Reverse engineering of a particular mining chip has demonstrated
conclusively that ASICBOOST has been implemented
in hardware.

On that basis, I offer the following BIP draft for discussion.
This proposal does not prevent the attack in general, but only
inhibits covert forms of it which are incompatible with
improvements to the Bitcoin protocol.

I hope that even those of us who would strongly prefer that
ASICBOOST be blocked completely can come together to support
a protective measure that separates concerns by inhibiting
the covert use of it that potentially blocks protocol improvements.

The specific activation height is something I currently don't have
a strong opinion, so I've left it unspecified for the moment.

<pre>
BIP: TBD
Layer: Consensus
Title: Inhibiting a covert attack on the Bitcoin POW function
Author: Greg Maxwell <greg at xiph.org>
Status: Draft
Type: Standards Track
Created: 2016-04-05
License: PD
</pre>

==Abstract==

This proposal inhibits the covert exploitation of a known
vulnerability in Bitcoin Proof of Work function.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.

==Motivation==

Due to a design oversight the Bitcoin proof of work function has a potential
attack which can allow an attacking miner to save up-to 30% of their energy
costs (though closer to 20% is more likely due to implementation overheads).

Timo Hanke and Sergio Demian Lerner claim to hold a patent on this attack,
which they have so far not licensed for free and open use by the public.
They have been marketing their patent licenses under the trade-name
ASICBOOST. The document takes no position on the validity or enforceability
of the patent.

There are two major ways of exploiting the underlying vulnerability: One
obvious way which is highly detectable and is not in use on the network
today and a covert way which has significant interaction and potential
interference with the Bitcoin protocol. The covert mechanism is not
easily detected except through its interference with the protocol.

In particular, the protocol interactions of the covert method can block the
implementation of virtuous improvements such as segregated witness.

Exploitation of this vulnerability could result in payoff of as much as
$100 million USD per year at the time this was written (Assuming at
50% hash-power miner was gaining a 30% power advantage and that mining
was otherwise at profit equilibrium). This could have a phenomenal
centralizing effect by pushing mining out of profitability for all
other participants, and the income from secretly using this
optimization could be abused to significantly distort the Bitcoin
ecosystem in order to preserve the advantage.

Reverse engineering of a mining ASIC from a major manufacture has
revealed that it contains an undocumented, undisclosed ability
to make use of this attack. (The parties claiming to hold a
patent on this technique were completely unaware of this use.)

On the above basis the potential for covert exploitation of this
vulnerability and the resulting inequality in the mining process
and interference with useful improvements presents a clear and
present danger to the Bitcoin system which requires a response.

==Background==

The general idea of this attack is that SHA2-256 is a merkle damgard hash
function which consumes 64 bytes of data at a time.

The Bitcoin mining process repeatedly hashes an 80-byte 'block header' while
incriminating a 32-bit nonce which is at the end of this header data. This
means that the processing of the header involves two runs of the compression
function run-- one that consumes the first 64 bytes of the header and a
second which processes the remaining 16 bytes and padding.

The initial 'message expansion' operations in each step of the SHA2-256
function operate exclusively on that step's 64-bytes of input with no
influence from prior data that entered the hash.

Because of this if a miner is able to prepare a block header with
multiple distinct first 64-byte chunks but identical 16-byte
second chunks they can reuse the computation of the initial
expansion for multiple trials. This reduces power consumption.

There are two broad ways of making use of this attack. The obvious
way is to try candidates with different version numbers. Beyond
upsetting the soft-fork detection logic in Bitcoin nodes this has
little negative effect but it is highly conspicuous and easily
blocked.

The other method is based on the fact that the merkle root
committing to the transactions is contained in the first 64-bytes
except for the last 4 bytes of it. If the miner finds multiple
candidate root values which have the same final 32-bit then they
can use the attack.

To find multiple roots with the same trailing 32-bits the miner can
use efficient collision finding mechanism which will find a match
with as little as 2^16 candidate roots expected, 2^24 operations to
find a 4-way hit, though low memory approaches require more
computation.

An obvious way to generate different candidates is to grind the
coinbase extra-nonce but for non-empty blocks each attempt will
require 13 or so additional sha2 runs which is very inefficient.

This inefficiency can be avoided by computing a sqrt number of
candidates of the left side of the hash tree (e.g. using extra
nonce grinding) then an additional sqrt number of candidates of
the right side of the tree using transaction permutation or
substitution of a small number of transactions. All combinations
of the left and right side are then combined with only a single
hashing operation virtually eliminating all tree related
overhead.

With this final optimization finding a 4-way collision with a
moderate amount of memory requires ~2^24 hashing operations
instead of the >2^28 operations that would be require for
extra-nonce grinding which would substantially erode the
benefit of the attack.

It is this final optimization which this proposal blocks.

==New consensus rule==

Beginning block X and until block Y the coinbase transaction of
each block MUST either contain a BIP-141 segwit commitment or a
correct WTXID commitment with ID 0xaa21a9ef.

(See BIP-141 "Commitment structure" for details)

Existing segwit using miners are automatically compatible with
this proposal. Non-segwit miners can become compatible by simply
including an additional output matching a default commitment
value returned as part of getblocktemplate.

Miners SHOULD NOT automatically discontinue the commitment
at the expiration height.

==Discussion==

The commitment in the left side of the tree to all transactions
in the right side completely prevents the final sqrt speedup.

A stronger inhibition of the covert attack in the form of
requiring the least significant bits of the block timestamp
to be equal to a hash of the first 64-bytes of the header. This
would increase the collision space from 32 to 40 or more bits.
The root value could be required to meet a specific hash prefix
requirement in order to increase the computational work required
to try candidate roots. These change would be more disruptive and
there is no reason to believe that it is currently necessary.

The proposed rule automatically sunsets. If it is no longer needed
due to the introduction of stronger rules or the acceptance of the
version-grinding form then there would be no reason to continue
with this requirement. If it is still useful at the expiration
time the rule can simply be extended with a new softfork that
sets longer date ranges.

This sun-setting avoids the accumulation of technical debt due
to retaining enforcement of this rule when it is no longer needed
without requiring a hard fork to remove it.

== Overt attack ==

The non-covert form can be trivially blocked by requiring that
the header version match the coinbase transaction version.

This proposal does not include this block because this method
may become generally available without restriction in the future,
does not generally interfere with improvements in the protocol,
and because it is so easily detected that it could be blocked if
it becomes an issue in the future.

==Backward compatibility==

==Implementation==

==Acknowledgments==

==Copyright==

This document is placed in the public domain.

📅 Original date posted:2016-09-23 📝 Original ...

2023-06-07T19:53:37+02:00

In reply to nevent1q…lzcn
_________________________

📅 Original date posted:2016-09-23
📝 Original message:I've proposed a revision to BIP-1 that removes the option to license
the work under the OPL: https://github.com/bitcoin/bips/pull/446

The OPL contains troublesome terms where the licensor can elect to
prohibit print publication of the work as well as the creation of
modified versions without their approval.

"Distribution of substantively modified versions of this document is
prohibited without the explicit permission of the copyright holder."
"Distribution of the work or derivative of the work in any standard
(paper) book form is prohibited unless prior permission is obtained
from the copyright holder."

Additionally, even without these optional clauses the specific
construction of this licenses' attribution requirements are
restrictive enough that Debian does not consider it acceptable for
works included in their distribution
(https://lists.debian.org/debian-legal/2004/03/msg00226.html).

I can't find any discussion that indicates anyone involved with the
project was aware of these clauses at the time this text was added...
and I believe they are strongly incompatible with having a
transparent, public, collaborative process for the development of
standard for interoperablity. I certainly wasn't aware of it, and
would have argued against it if I was.

Moreover, the project that created this license has recommended people
use creative commons licenses instead since 2007.

The only BIPs that have availed themselves of this are BIP145 (which
is dual licensed under the permissive 2-clause BSD, which I wouldn't
object to adding as an option-- and which doesn't active the
objectionable clauses) and the recently assigned BIP134.

📅 Original date posted:2016-09-23 📝 Original message:On ...

2023-06-07T19:53:34+02:00

In reply to nevent1q…p63u
_________________________

📅 Original date posted:2016-09-23
📝 Original message:On Fri, Sep 23, 2016 at 10:20 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> In the innocent use case of this opcode, a double-spend has already occurred,
> and this should be a strict improvement. In the non-innocent abuse of this
> opcode, I don't see that it's any worse than simply double-spending.

There is a fungibility hit... right now, absent double spends (and
privacy issues), every coin you might get paid is equal.

With this script feature as described, you could get paid a coin which
has one of these in its recent past, pinning the block immediately
before it. A reorg long enough to remove that block-- due to an
attack, or an ordinary block race, or some kind of consensus glitch
(like we had in March 2013 or around the activation of BIP65)-- is
_guaranteed_ to invalidate those coins, even without any double spend.

If the scheme doesn't do as I suggest and prevent over-eager usage
(perhaps 100 is too much, I just decided to match coinbases); then it
should probably have a consensus enforced explicit "maximum survivable
reorg" that is traced along with the outputs, so that someone who
received exposed coins could handle it sensibly.

Just for plain engineering reasons, I still think it is important to
now allow overly short back references. If the reference has to be a
few blocks back we don't need to worry about short forks breaking
propagation, and simple mempool handling like purging all CBAH
transactions on a large reorg would work fine. It need not be so long
as to implicate Petertodd's concern that you could only use it where
it wouldn't matter. (Though I also disagree that a depth of 100
achieves that, consider persistent chain forks).

📅 Original date posted:2016-09-09 📝 Original message:On ...

2023-06-07T19:53:18+02:00

In reply to nevent1q…qw4v
_________________________

📅 Original date posted:2016-09-09
📝 Original message:On Sat, Sep 10, 2016 at 12:58 AM, Peter Todd <pete at petertodd.org> wrote:
> Good to do this sooner rather than later, as alert propagation on the P2P
> network is going to continue to get less reliable as nodes upgrade to software

Yes, this was one of my motivations for doing this soon.

It would only require about 2 LOC to have Bitcoin Core vomit out a
blob containing the final alert to any old protocol version peers that
connect. I don't know how other people would feel about that, but I
wouldn't mind implementing it, and it would greatly improve the
likelihood that they continue to to get once propagation of it is
gone. This could be left in the codebase for a couple years or until
other changes made those old versions p2p incompatible for other
reasons.

📅 Original date posted:2016-09-09 📝 Original message:The ...

2023-06-07T19:53:17+02:00

In reply to nevent1q…atxl
_________________________

📅 Original date posted:2016-09-09
📝 Original message:The alert system was a centralized facility to allow trusted parties
to send messages to be displayed in wallet software (and, very early
on, actually remotely trigger the software to stop transacting).

It has been removed completely in Bitcoin Core after being disabled for a while.

While the system had some potential uses, there were a number of
problems with it.

The alert system was a frequent source of misunderstanding about the
security model and 'effective governance', for example a years ago a
BitcoinJ developer wanted it to be used to control fee levels on the
network and few months back one of Bloq's staff was pushing for a
scheme where "the developers" would use it to remotely change the
difficulty-- apparently with no idea how abhorrent others would find
it.

The system also had a problem of not being scalable to different
software vendors-- it didn't really make sense that core would have
that facility but armory had to do something different (nor would it
really make sense to constantly have to maintain some list of keys in
the node software).

It also had the problem of being unaccountable. No one can tell which
of the key holders created a message. This creates a risk of misuse
with a false origin to attack someone's reputation.

Finally, there is good reason to believe that the key has been
compromised-- It was provided to MTGox by a developer and MTGox's
systems' were compromised and later their CEO's equipment taken by the
Japanese police.

In any case, it's gone now in Core and most other current software--
and I think it's time to fully deactivate it.

I've spent some time going around the internet looking for all
software that contains this key (which included a few altcoins) and
asked them to remove it. I will continue to do that.

One of the facilities in the alert system is that you can send a
maximum sequence alert which cannot be overridden and displays only a
static key compromise text message and blocks all other alerts. I plan
to send a triggering alert in the not-distant future (exact time to be
announced well in advance) feedback on timing would be welcome.

There are likely a few production systems that automatically shut down
when there is an alert, so this risks some small one-time disruption
of those services-- but none worse than if an alert were sent to
advise about a new system upgrade.

At some point after that, I would then plan to disclose this private
key in public, eliminating any further potential of reputation attacks
and diminishing the risk of misunderstanding the key as some special
trusted source of authority.

Cheers,

📅 Original date posted:2016-08-24 📝 Original message:On ...

2023-06-07T19:53:08+02:00

In reply to nevent1q…ynn0
_________________________

📅 Original date posted:2016-08-24
📝 Original message:On Wed, Aug 24, 2016 at 11:03 PM, Chris Priest via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> How does your system prevent against insider attacks? How do you know
> the money is stolen by someone who compromised server #4, and not
> stolen by the person who set up server #4? It is my understanding
> these days most attacks are inside jobs.

Working as designed in that case: You know #4 is compromised, it
doesn't tell you if it was an insider or an outsider, but in both
cases someone unauthorized or without integrity got access to the
key(s).

📅 Original date posted:2016-08-24 📝 Original message:On ...

2023-06-07T19:53:02+02:00

In reply to nevent1q…7qw9
_________________________

📅 Original date posted:2016-08-24
📝 Original message:On Tue, Aug 23, 2016 at 8:54 PM, Kenneth Heutmaker via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> SPV is kinda broken if the wallet doesn’t do this detection. If your wallet connects only to nodes that don’t support bloom filtering, the wallet never gets updates. We have had a spike in users reporting that their wallet isn't getting updated. To compound the problem, they rescan the blockchain and lose all of their transaction history. It has caused much panic among less technical users.
>
> We believe that failing to detect the NODE_BLOOM bit is the culprit, although it is non-deterministic, so we aren't certain.

There are almost no NODE_BLOOM supporting bloom-off nodes on the
network currently. So, while supporting this is important, I am
doubtful that its the current problem you've suffered.

There are a great many fake nodes which appear to exist purely to
monitor transactions. Many do not implement enough of the protocol to
support scanning or transaction relay. (and, in fact, relaying
transactions would make monitoring less effective).

You can't count on peers on a peer to peer network to be honest and
cooperative. Implementations need to work hard to be robust to abusive
peers. Unfortunately, the design of the bloom filtering is such that
it isn't always easy (or even possible) to be robust.

📅 Original date posted:2016-08-08 📝 Original message:On ...

2023-06-07T19:52:21+02:00

In reply to nevent1q…gl59
_________________________

📅 Original date posted:2016-08-08
📝 Original message:On Mon, Aug 8, 2016 at 5:09 PM, Andy Schroder via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I have mixed feelings about strictly tying the identity-public-keys with a
[...]
> guaranteed static IP address. The second reason is because the DNS PTR

I don't see any reason that it couldn't also accept a DNS name there.

The purpose of that table is so the client knows which server ID to expect.

> I consider it a good thing from a privacy perspective if my IP address
> changes every once and a while.

And the design seeks to preserve that privacy.

> Maybe a strict check option where the identity-public-keys must optionally
> match a specific network identifier would be a compromise? Maybe this is up

The client must know the identity of the server it is expecting. The
server does not announce itself. If it did then your changing of IPs
would provide you with no privacy at all.

If the design is to provide any protection against MITM you need to
know who you expected to connect to in any case.

> I think the purpose of this is to detect if someone has physically stolen and compromised my bitcoin node and placed it on another network under control of an attacker.

Huh. No. Almost the opposite. The system is designed to inhibit
fingerprinting. You can't tell what identity key(s) a node has unless
you already know them. This means that if you don't publish your node
pubkey, no one can use it to track your node around the network.

> Is there an option for a wildcard here? Couldn't there be a case where the
> client wants to authenticate, but the bitcoin node does not care who it's
> clients are? This would be similar to many of the http based bitcoin block
> explorer API services that are out there. The API operators have built up
> some reputation, so people use them, but they don't necessarily care about
> who their users are.

Then they're just not listed in the file. The client can ask the server to
authenticate without authenticating itself.

> Does openssh have this same problem?

No. OpenSSH doesn't make an effort to protect the privacy of its users.

> I'm assuming this could be parallelized very easily, so it is not a huge
> problem?

It's not a issue because we're not aware of any usecase where a node
would have a large list of authenticated peers.

> Each peer can configure one identity-key (ECC, 32 bytes) per listening
network interface (IPv4, IPv6, tor).

I'm not aware of any reason for this limitation to exist. A node
should be able to have as many listening identities as it wants, with
a similar cost to having a large authorized keys list.

📅 Original date posted:2016-06-28 📝 Original message:> I ...

2023-06-07T19:51:45+02:00

In reply to nevent1q…ktj4
_________________________

📅 Original date posted:2016-06-28
📝 Original message:> I understand the use, when coupled with a yet-to-be-devised identity system, with Bloom filter features. Yet these features

This is a bit of a strawman, you've selected a single narrow usecase
which isn't proposed by the BIP and then argue it is worthless. I
agree that example doesn't have much value (and I believe that
eventually the BIP37 bloom filters should be removed from the
protocol).

Without something like BIP151 network participants cannot have privacy
for the transactions they originate within the protocol against
network observers. Even if, through some extraordinary effort, their
own first hop is encrypted, unencrypted later hops would rapidly
expose significant information about transaction origins in the
network.

Without something like BIP151 authenticated links are not possible, so
manually curated links (addnode/connect) cannot be counted on to
provide protection against partitioning sybils.

Along the way BIP151 appears that it will actually make the protocol faster.

> Given that the BIP relies on identity

This is untrue. The proposal is an ephemerally keyed opportunistic
encryption system. The privacy against a network observer does not
depend on authentication, much less "identity". And when used with
authentication at all it makes interception strongly detectable after
the fact.

> The BIP does not [...] contemplate the significant problems associated with key distribution in any identity system

Because it does not propose any "identity system" or authorization
(also, I object to your apparent characterization of authentication as
as an 'identity system'-- do you also call Bitcoin addresses an
identity system?).

That said, manually maintaining adds nodes to your own and somewhat
trusted nodes is a recommend best practice for miners and other high
value systems which is rendered much less effective due to a lack of
authentication, there is no significant key distribution problem in
that case, and I expect the future auth BIP (Jonas had one before, but
it was put aside for now to first focus on the link layer encryption)
to address that case quite well.

📅 Original date posted:2016-06-28 📝 Original message:On ...

2023-06-07T19:51:38+02:00

In reply to nevent1q…mycx
_________________________

📅 Original date posted:2016-06-28
📝 Original message:On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> An "out of band key check" is not part of BIP151.

It has a session ID for this purpose.

> It requires a secure channel and is authentication. So BIP151 doesn't provide the tools to detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised.

One might wonder how you ever use a Bitcoin address, or even why we
might guess these emails from "you" aren't actually coming from the
NSA.

📅 Original date posted:2016-05-10 📝 Original message:On ...

2023-06-07T19:50:21+02:00

In reply to nevent1q…l9kn
_________________________

📅 Original date posted:2016-05-10
📝 Original message:On Tue, May 10, 2016 at 5:28 AM, Rusty Russell via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I used variable-length bit encodings, and used the shortest encoding
> which is unique to you (including mempool). It's a little more work,
> but for an average node transmitting a block with 1300 txs and another
> ~3000 in the mempool, you expect about 12 bits per transaction. IOW,
> about 1/5 of your current size. Critically, we might be able to fit in
> two or three TCP packets.

Hm. 12 bits sounds very small even giving those figures. Why failure
rate were you targeting?

I've mostly been thing in terms of 3000 txn, and 20k mempools, and
blocks which are 90% consistent with the remote mempool, targeting
1/100000 failure rates (which is roughly where it should be to put it
well below link failure levels).

If going down the path of more complexity, set reconciliation is
enormously more efficient (e.g. 90% reduction), which no amount of
packing/twiddling can achieve.

But the savings of going from 20kb to 3kb is not interesting enough to
justify it*. My expectation is that later we'll deploy set
reconciliation to fix relay efficiency, where the savings is _much_
larger, and then with the infrastructure in place we could define
another compactblock mode that used it.

(*Not interesting because it mostly reduces exposure to loss and the
gods of TCP, but since those are the long poles in the latency tent,
it's best to escape them entirely, see Matt's udp_wip branch.)

> I would also avoid the nonce to save recalculating for each node, and
> instead define an id as:

Doing this would greatly increase the cost of a collision though, as
it would happen in many places in the network at once over the on the
network at once, rather than just happening on a single link, thus
hardly impacting overall propagation.

(The downside of the nonce is that you get an exponential increase in
the rate that a collision happens "somewhere", but links fail
"somewhere" all the time-- propagation overall doesn't care about
that.)

Using the same nonce means you also would not get a recovery gain from
jointly decoding using compact blocks sent from multiple peers (which
you'll have anyways in high bandwidth mode).

With a nonce a sender does have the option of reusing what they got--
but the actual encoding cost is negligible, for a 2500 transaction
block its 27 microseconds (once per block, shared across all peers)
using Pieter's suggestion of siphash 1-3 instead of the cheaper
construct in the current draft.

Of course, if you're going to check your whole mempool to reroll the
nonce, thats another matter-- but that seems wasteful compared to just
using a table driven size with a known negligible failure rate.

64-bits as a maximum length is high enough that the collision rate
would be negligible even under fairly unrealistic assumptions-- so
long as it's salted. :)

> As Peter R points out, we could later enhance receiver to brute force
> collisions (you could speed that by sending a XOR of all the txids, but
> really if there are more than a few collisions, give up).

The band between "no collisions" and "infeasible many" is fairly
narrow. You can add a small amount more space to the ids and
immediately be in the no collision zone.

Some earlier work we had would send small amount of erasure coding
data of the next couple bytes of the IDs. E.g. the receiver in all
the IDs you know, mark totally unknown IDs as erased and the let the
error correction fix the rest. This let you algebraically resolve
collisions _far_ beyond what could be feasibly bruteforced. Pieter
went and implemented... but the added cost of encoding and software
complexity seem not worth it.

📅 Original date posted:2016-05-09 📝 Original message:On ...

2023-06-07T19:50:18+02:00

In reply to nevent1q…2039
_________________________

📅 Original date posted:2016-05-09
📝 Original message:On Mon, May 9, 2016 at 9:35 AM, Tom Zander via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> You misunderstand the networking effects.
> The fact that your node is required to choose which one to set the announce
> bit on implies that it needs to predict which node will have the best data in
> the future.

Not required. It may. If it chooses fortunately, latency is reduced--
to 0.5 RTT in many cases. If not-- nothing harmful happens.

Testing on actual nodes in the actual network (not a "lab") shows that
blocks are normally requested from one of the last three peers they
were requested from 70% of the time, with no special affordances or
skipping samples when peers disconnected.

(77% for last 4, 88% for last 8)

This also _increases_ robustness. Right now a single peer failing at
the wrong time will delay blocks with a long time out. In high
bandwidth mode the redundancy means that node will be much more likely
to make progress without timeout delays-- so long at least one of the
the selected opportunistic mode peers was successful.

Because the decision is non-normative to the protocol, nodes can
decide based on better criteria if better criteria is discovered in
the future.

> Another problem with your solution is that nodes send a much larger amount of
> unsolicited data to peers in the form of the thin-block compared to the normal
> inv or header-first data.

"High bandwidth" mode uses somewhat more bandwidth than low
bandwidth... but still >>10 times less than an ordinary getdata relay
which is used ubiquitously today.

If a node is trying to minimize bandwidth usage, it can choose to not
request the "high bandwidth" mode.

The latency bound cannot be achieved without unsolicited data. The
best we can while achieving 0.5 RTT is try to arrange things so that
the information received is maximally useful and as small as
reasonably possible.

If receivers implemented joint decoding (combining multiple
comprblocks in the event of faild decoding) 4 byte IDs would be
completely reasonable, and were what I originally suggested (along
with forward error correction data, in that case).

> Am I to understand that you choose the solution based on the fact that service
> bits are too expensive to extend? (if not, please respond to my previous
> question actually answering the suggestion)
>
> That sounds like a rather bad way of doing design. Maybe you can add a second
> service bits field of message instead and then do the compact blocks correctly.

Service bits are not generally a good mechanism for negating optional
peer-local parameters.

The settings for compactblocks can change at runtime, having to
reconnect to change them would be obnoxious.

> Wait, you didn't steal the variable length encoding from an existing standard
> and you programmed a new one?

This is one of the two variable length encodings used for years in
Bitcoin Core. This is just the first time it's shown up in a BIP.

[It's a little disconcerting that you appear to be maintaining a fork
and are unaware of this.]

> Look at UTF-8 on wikipedia, you may have "invented" the same encoding that IBM
> published in 1992.

The similarity with UTF-8 is that both are variable length and some
control information is in the high bits. The similarity ends there.

UTF-8 is more complex and less efficient for this application (coding
small numbers), as it has to handle things like resynchronization
which are critical in text but irrelevant in our framed, checksummed,
reliably transported binary protocol.

> Just the first (highest) 8 bytes of a sha256 hash.
>
> The amount of collisions will not be less if you start xoring the rest.
> The whole reason for doing this extra work is also irrelevant as a spam
> protection.

Then you expose it to a trivial collision attack: To find two 64 bit
hashes that collide I need perform only roughly 2^32 computation. Then
I can send them to the network. You cannot reason about these systems
just by assuming that bad things happen only according to pure chance.

This issue is eliminated by salting the hash. Moreover, with
per-source randomization of the hash, when a rare chance collision
happens it only impacts a single node at a time, so the propagation
doesn't stall network wide on an unlucky block; it just goes slower on
a tiny number of links a tiny percent of the time (instead of breaking
everywhere an even tinyer amount of the time)-- in the non-attacker,
chance event case.

📅 Original date posted:2016-05-03 📝 Original message:On ...

2023-06-07T19:50:15+02:00

In reply to nevent1q…pp7v
_________________________

📅 Original date posted:2016-05-03
📝 Original message:On Mon, May 2, 2016 at 10:13 PM, Matt Corallo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> The following is a BIP-formatted design spec for compact block relay
> designed to limit on wire bytes during block relay. You can find the
> latest version of this document at
> https://github.com/TheBlueMatt/bips/blob/master/bip-TODO.mediawiki.

Thanks Matt!

I've been testing this for a couple weeks (in various forms). I've
been getting over 96% reduction in block-bytes sent. I don't have a
good metric for it, but bandwidth spikes are greatly reduced. The
largest blocktxn message I've seen on a node that has been up for at
least a day is 475736 bytes. 94% of the blocks less than 100kb must be
sent in total.

In the opportunistic mode my measurements are showing 73% of blocks
transferred with 0.5 RTT even without prediction, 87% if up to 4
additional transactions are predicted, and 91% for 30 transactions (my
rough estimate for the 10k maximum prediction suggested in the BIP.

📅 Original date posted:2016-03-02 📝 Original message:On ...

2023-06-07T19:49:35+02:00

In reply to nevent1q…cd5g
_________________________

📅 Original date posted:2016-03-02
📝 Original message:On Wed, Mar 2, 2016 at 5:14 PM, David A. Harding via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Mar 02, 2016 at 02:56:14PM +0000, Luke Dashjr via bitcoin-dev wrote:
>> To alleviate this risk, it seems reasonable to propose a hardfork to the
>> difficulty adjustment algorithm so it can adapt quicker to such a significant
>> drop in mining rate.
>
> Having a well-reviewed hard fork patch for rapid difficulty adjustment
> would seem to be a useful reserve for all sorts of possible problems.
> That said, couldn't this specific potential situation be dealt with by a
> relatively simple soft fork?
[...]

What you are proposing makes sense only if it was believed that a very
large difficulty drop would be very likely.

This appears to be almost certainly untrue-- consider-- look how long
ago since hashrate was 50% of what it is now, or 25% of what it is
now-- this is strong evidence that supermajority of the hashrate is
equipment with state of the art power efficiency. (I've also heard
more directly-- but I think the this evidence is more compelling
because it can't be tainted by boasting). If a pre-programmed ramp and
drop is set then it has the risk of massively under-setting
difficulty; which is also strongly undesirable (e.g. advanced
inflation and exacerbating existing unintentional selfish mining)...
and that is before suggesting that miners voluntarily take a loss of
inflation now.

So while I think this concern is generally implausible; I think it's
prudent to have a difficulty step patch (e.g. a one time single point
where a particular block is required to lower bits a set amount) ready
to go in the unlikely case the network is stalled. Of course, if the
alternative is "stuck" from a large hashrate drop the deployment would
be both safe and relatively uncontroversial. I think the
unfavorability of that approach is well matched to the implausibility
of the situation, and likely the right coarse of action compared to
risky interventions that would likely cause harm. The cost of
developing and testing such a patch is low, and justified purely on
the basis of increasing confidence that an issue would be handled (a
fact _I_ am perfectly confident in; but apparently some are not).

With respect what Luke was suggesting; without specifics its hard to
comment, but most altcoin "tolerate difficulty drop" changes have made
them much more vulnerable to partitioning attacks and other issues
(e.g. strategic behavior by miners to increase inflation), and have
actually been exploited in practice several times (solidcoin's being
the oldest I'm aware of). Many survived a fairly long time before
being shown to be pretty broken, simply because they were deployed in
cases where no one cared to attack. I'm currently doubtful that
particular path would be fruitful.

📅 Original date posted:2016-02-29 📝 Original message:Better ...

2023-06-07T19:49:23+02:00

In reply to nevent1q…6ysz
_________________________

📅 Original date posted:2016-02-29
📝 Original message:Better late than never, I should correct things here. In the future it
would probably be more productive to open an issue. Otherwise there is
no mechanism for someone to take ownership of a response.

On Sun, Aug 30, 2015 at 7:45 PM, Kristov Atlas via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>> 1. Does your application take any steps to create ambiguity between
>> transactions which unavoidably spend from multiple addresses at the same
>> time and intentional mixing transactions?
> No, Bitcoin-Qt does not try to make non-mixing transactions look like mixing
> transactions.
>> 2. What algorithms does your application use for ordering inputs and
>> outputs in a transaction? In particular, how do you handle the change output
>> and do you take into account common practices of other wallet applications
>> when determining ordering?
>
> Not yet BIP 69. These notes suggest that outputs are randomized:
> https://bitcoin.org/en/release/v0.8.1

The ordering used by Bitcoin-QT is cryptographically randomized. This
provides the greatest privacy possible.

The BIP 69 recommendation would currently be equally as private if
universally used, but today would reduce privacy by making the
software more distinguishable. It is unclear if BIP69 will be equal
in privacy in the future, because external infrastructure may impose
ordering requirements that are incompatible with it.

>> 3. Does your application minimize the harmful effects of address
>> reuse by spending every spendable input (“sweeping”) from an address when a
>> transaction is created?
>
> Unknown

>> 4. Does your application fully implement BIP 62?

BIP 62 is withdrawn. The useful mechanisms in it for standardness
rules are, of course, implemeted in Bitcoin Core-- were invented
there, and have been there for years.

>> Mixing
>>
>> 5. If your application supports mixing:

It's unclear to me precisely what is meant here. I'll answer broadly.

Bitcoin Core is compatible with and can be used with the joinmarket
module to include coinjoins. The raw transaction functionality in
Bitcoin Core was also created specifically to facilitate coinjoins.
Beyond joinmarket there have been several other coinjoin modules
created for Bitcoin Core though today JM is by far the most common,

This functionality is not directly implemented for a number of reasons
including the non-existence of decenteralized tools for this that
don't harm the user's privacy in other ways.

>> a. What is the average number of participants a user can expect to
>> interact with on a typical join transaction?
>> b. Does your application attempt to construct join transactions in a
>> way that avoids distinguishing them from non-join transactions?
>> c. Does your application perform any kind of reversibility analysis
>> on join transactions prior to presenting them to the user for confirmation?
>> d. Is the mixing technique employed secure against correlation
>> attacks by the facilitator, such as a CoinJoin server or off-chain mixing
>> service?
>> e. Is the mixing technique employed secure against theft of funds by
>> the facilitator or its participants?

Skipped as these are specific to the implementation in use.

>> Donations
>> 6. If your application has a fee or donation to the developers
>> feature:
> No donation feature last time I checked.
>> a. What steps do you take to make the donations indistinguishable
>> from regular spend in terms of output sizes and destination addresses?

As Kristov noted, Bitcoin Core does not implement anti-features like donations.

>> Balance Queries and Tx Broadcasting
>>
>> 7. Please describe how your application obtains balance information
>> in terms of how queries from the user’s device can reveal a connection
>> between the addresses in their wallet.
>> a. Does the application keep a complete copy of the blockchain
>> locally (full node)?
> Yes

Optionally, but in all cases the user's privacy is indistinguishable
from keeping all the data locally.

>> b. Does the user’s device provide a filter which matches some
>> fraction of the blockchain while providing a false positive rate (bloom or
>> prefix filters)?
> No, it just downloads the whole blockchain and performs local queries.

It would be more correct to say that Bitcoin Core always has the
highest possible FP rate. It uses the only currently available tool
to avoid leaking private address information to indexing services. As
several academic studies have shown, bloom filters are completely
inadequate for protecting user privacy.

>> i. If so, approximately what fraction of the blockchain does the
>> filter match in a default configuration (0% - 100%)?
> 100%, unless a user bootstraps downloading the blockchain. Bootstrapping
> will potentially limit the user's anonymity set to other people who have
> downloaded that bootstrap.dat file.

I user that has downloaded a bootstrap.dat is indistinguishable from
any other user on the network; their transaction anonymity set is not
reduced in any way by doing this. By running bitcoin at all they are
distinguished from other people who do not, but thousands of hosts run
Bitcoin without even having a wallet.

>> c. Does the user’s device query all of their addresses at the same
>> time?
> N/A

To be clear: This is N/A because there are no queries that would leak
private information about the user's wallet.

>> d. Does the user’s device query addresses individually in a manner
>> that does not allow the query responder to correlate queries for different
>> addresses?
> No. Just download blocks and processes that information locally.

Yes. Because the Bitcoin Core downlaods all information, the third
parties cannot correlate responses.

>> e. Can users opt to obtain their balance information via Tor (or
>> equivalent means)?
> If Tor is set up as a SOCKS proxy, you can configure Bitcoin-QT download the
> blockchain and broadcast txs through a single Tor circuit. This can be
> configured once before opening Bitcoin-Qt.

Bitcoin Core does make remote queries to obtain "balance information",
but it can be directed to perform all commmunications via tor, before
starting it as noted.

>> 8. Does the applications route outgoing transactions independently
>> from the manner in which it obtains balance information? Can users opt to
>> have their transactions submitted to the Bitcoin network via Tor (or an
>> equivalent means) independently of how they obtain their balance
>> information?
> No, you can only configure a single proxy.

Bitcoin Core can simultaneously connect to both Tor hidden services
and the public IPv4 network for improved partitioning resistance (and
has been able to for years). Instead of setting the socks proxy, the
user configures onion=<tor proxy>.

As of 0.12 inbound tor HS is also auto-configured by default when tor
is installed.

>> 9. If your application supports multiple identities/wallets, does
>> each one connect to the network as if it were completely independent from
>> the other?
>
>
> No built-in support for multiple identities. You can hotswap wallet files to
> crudely simulate this. You'd have to manually change the Tor connection
> outside of Bitcoin-Qt to create the effect of making the network connections
> independent.

All network connections are independent via Tor by default, no manual
change is required there. Separate "identities" do require separate
wallets, as noted.

>> a. Does the application ever request balance information for
>> addresses belonging to multiple identities in the same network query?

No it does not and cannot. Freedom from this kind of leak is one of
the benefits of the current design that doesn't allow intermixing
"identities" in wallets.

> Blocks are downloaded and tx broadcasts received/relayed rather than
> querying the utxo set for a particular address. When swapping between wallet
> files, some information may be leaked e.g. the client may be at the same
> block height in terms of what it has downloaded from the p2p network, which
> may leak to global passive adversaries/AS's or sybil attackers the fact that
> a single client was used for multiple wallets.

However, unlikely most other wallets, Bitcoin nodes forward
transactions for third parties and do not make external queries for
private information. Because of this the ability to correlate a
particular node connection multiple times does not necessarily leak
anything about wallet usage.

>> b. Are outgoing transactions from multiple identities routed
>> independently of each other to the Bitcoin network?
>
> Transactions from multiple identities would not be routed at the same time.
> I'm not clear what happens if you have a single wallet (identity) open and
> then open a new wallet (identity) without closing Bitcoin-Qt -- some of the
> same routing paths may still be used such that an attacker might observe
> transactions broadast signed by private keys from multiple wallets
> (identities) and observe that they appear to come from the same wallet
> client. OBPP should assume the worst unless prevented contrary evidence.

This assumption is incorrect. All the private wallet state is stored
in the wallet. If the wallet is changed the node does know any of them
anymore. There is no ability to open a new wallet without restarting
the software.

That said, Bitcoin Core normally relays transactions for third
parties-- unlikely virtually all other wallets. This means that where
observation of a transaction from another wallet would give a nearly
guaranteed identification that the system on the other end of the link
is the source, with Bitcoin Core sending a transaction is merely
potentially suggestive of origination.

>> c. When an identity/wallet is deleted, does the deletion process
>> eliminate all evidence from the user's device that the wallet was previously
>> installed?
> Identity is primarily tied to a wallet.dat file. Deleting it will remove
> most of the evidence that the wallet was installed on that device, but there
> may be some extra information in ancillary files that should also be
> deleted. This is an OS-level function, as there is no operation built into
> the client to delete a wallet file (identity).

After review and testing we've determined that reliable deletion of
private data is not very feasible on current hardware/OSes. Techniques
which used to work, like overwriting are defeated by write balancing.
We recommend users use OS level encryption to protect their privacy
locally.

>> Network Privacy
>> 10. When a user performs a backup operation for their wallet, does
>> this generate any automatic network activity, such as a web query or email?
> No. Backups are local, and no email or SMS is linked. No web queries related
> to backup.

Right.

>> 11. Does your application perform any lookup external to the user’s
>> device related to identifying transaction senders or recipients?
> No

Not for normal transactions. Bitcoin Core currently supports payment
URIs and BIP70, and if a user follows a payment URI it may instruct
the user to make a connection to a location requested by the payee.

>> 12. Does you application connect to known endpoints which would be
>> visible to an ISP, such as your domain?
> Yes, some connections to known p2p full nodes to bootstrap the connection to
> the Bitcoin p2p network. This is configurable, but there are defaults. An
> ISP is likely to be able to identify a customer as running the Bitcoin-Qt
> client in particular on this basis.

Kind of. If a Bitcoin Core node already knows of peers through prior
operation and is able to get at least two network connections within
11 seconds, it will make no further queries.

If a node is completely new and hasn't been otherwise configured; it
will perform four DNS queries to determine lists of candidate nodes.
These queries are frequently answered by caching name servers and do
not go all the way back to their origins. Only if both of these step
fail does it consult a hardcoded list of several hundred nodes to
attempt initialization.

That said, Bitcoin traffic is easily identifiable regardless of how
peers are found. We recommend users run Tor, and if tor is used no
identifiable traffic should happen, except for timing/volume analysis.
And many parties run Bitcoin Core nodes without running wallets; so
the use of Bitcoin does not identify a user as even having a wallet at
all.

>> 13. If your application connects directly to nodes in the Bitcoin P2P
>> network, does it either use an unremarkable user agent string (Bitcoin Core.
>> BitcoinJ, etc), or randomize its user agent on each connection?
>
>
> BIP12 specifies format for user agents:
> https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki
>
> It appears that the Bitcoin-QT leaks specific information about its client
> version through User Agent. This file defines the current client version:
> https://github.com/bitcoin/bitcoin/blob/55294a9fb673ab0a7c99b9c18279fe12a5a07890/src/clientversion.h
>
> Various other files seem to use this to build up the UA string, which is
> transmitted to other peers.

Bitcoin Core is this questions _definition_ of an unremarkable useragent.

But yes, the useragent notes the major/minor version. Concealing this
would have little to no privacy advantage, as functional/behavioral
analysis would easily reveal the version with at least that level of
precision.

>> 14. Does the application uninstall process for your application
>> eliminate all evidence from the user's device that the application was
>> previously installed? Does it also eliminate wallet data?
> Probably depends on the platform. Last time I checked, I think Bitcoin-Qt
> leaves behind a .bitcoin directory on most platforms even after you run an
> uninstall script.

If uninstall deleted the wallet it would reliably result in massive
funds loss for users.

To conceal their user of Bitcoin users should at a minimum do a
security erase of their system.

Other wallets who claim to "delete" private information which was
previously stored on disk are likely giving their users a false sense
of security. Doubly so in that many other wallets are written in
dynamic lanaguages which make it impossible to prevent highly secret
data from being written to system swap.

>> 15. Does your application use techniques such as steganography to
>> store persistent wallet metadata in a form not identifiable as belong to a
>> Bitcoin wallet application?
> No

I believe any software which claimed to do this would have to meet a
rather high burden of proof.

>> 16. Please describe the degree to which users can use passwords/PINs
>> to protect their data:
>> a. Can the user set a password/PIN to protect their private keys?
> You can encrypt the wallet file with a password. The wallet is "locked"
> until the password is entered, preventing decryption of the private keys.

Correct. And unlike some other Wallets the KDF used to harden the
users key takes 100ms with efficient native code; this substantially
limits attacker brute for performance.

>> b. Can the user set a password/PIN to protect their public keys and
>> balance information?
> No -- any wallet.dat file can be opened and the public keys inspected
> without the password.
>> c. Can the user set a password/PIN to encrypt other wallet metadata,
>> such as address books and transaction notes?
> No -- any wallet.dat file can be opened and the metadata inspected without
> the password.

We recommend users use full disk encryption. Encrypting the public
data in the wallet would require the wallet to enter their key at
every use and increase the probability that their key was leaked (or
if two keys were used, that they'd forget their spending key).

Even if the public key information were encrypted, other data on their
computer (browser cache, swap, logs) would likely compromise the
user's privacy, thus the full disk encryption recommendation. Full
disk encryption is a common, easily used tool; and I don't believe any
wallet software that stores data locally can provide strong privacy in
practice without it.

>> d. Does the application use a single password/PIN to cover all
>> protected data, or does it allow the use of multiple passwords/PINs?
> A single password for the wallet file.

Right. Each wallet file can have it's own single password which
protect spending.

>> 17. Do you as a wallet provider ever have access to unencrypted copies
>> of the user’s private keys, public keys, or any other wallet metadata which
>> may be used to associate a user with their transactions or balances?
> No custodianship.

Right.

>> Telemetry Data
>> 18. If your application reports telemetry data, such as usage
>> information or automatic crash reporting, does the user have the opportunity
>> to review and approve all information transmitted before it is sent?
> No obvious telemetry data being sent.

No telemetry data.

>> Source Code and Building
>> 19. Can a user of your application compile the application themselves
>> in a manner that produces a binary version identical to the version you
>> distribute (deterministic build system)?

Yes, and a large portion of our user base does their own builds. Our
determinstic build process is also actively audited by a good dozen
parties who post cryptographic signatures of their duplicated builds.

📅 Original date posted:2016-02-26 📝 Original message:I am ...

2023-06-07T19:49:20+02:00

In reply to nevent1q…7afv
_________________________

📅 Original date posted:2016-02-26
📝 Original message:I am happy to announce the first successful Zero-Knowledge Contingent
Payment (ZKCP) on the Bitcoin network.

ZKCP is a transaction protocol that allows a buyer to purchase
information from a seller using Bitcoin in a manner which is private,
scalable, secure, and which doesn’t require trusting anyone: the
expected information is transferred if and only if the payment is
made. The buyer and seller do not need to trust each other or depend
on arbitration by a third party.

Imagine a movie-style “briefcase swap” (one party with a briefcase
full of cash, another containing secret documents), but without the
potential scenario of one of the cases being filled with shredded
newspaper and the resulting exciting chase scene.

An example application would be the owners of a particular make of
e-book reader cooperating to purchase the DRM master keys from a
failing manufacturer, so that they could load their own documents on
their readers after the vendor’s servers go offline. This type of sale
is inherently irreversible, potentially crosses multiple
jurisdictions, and involves parties whose financial stability is
uncertain–meaning that both parties either take a great deal of risk
or have to make difficult arrangement. Using a ZKCP avoids the
significant transactional costs involved in a sale which can otherwise
easily go wrong.

In today’s transaction I purchased a solution to a 16x16 Sudoku puzzle
for 0.10 BTC from Sean Bowe, a member of the Zcash team, as part of a
demonstration performed live at Financial Cryptography 2016 in
Barbados. I played my part in the transaction remotely from
California.

The transfer involved two transactions:

8e5df5f792ac4e98cca87f10aba7947337684a5a0a7333ab897fb9c9d616ba9e
200554139d1e3fe6e499f6ffb0b6e01e706eb8c897293a7f6a26d25e39623fae

Almost all of the engineering work behind this ZKCP implementation was
done by Sean Bowe, with support from Pieter Wuille, myself, and Madars
Virza.

Read more, including technical details at
https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/

[I hope to have a ZKCP sudoku buying faucet up shortly. :) ]

📅 Original date posted:2015-12-13 📝 Original message:On ...

2023-06-07T19:46:14+02:00

In reply to nevent1q…xya8
_________________________

📅 Original date posted:2015-12-13
📝 Original message:On Sun, Dec 13, 2015 at 9:17 AM, Chris Priest <cp368202 at ohiou.edu> wrote:
>> In none of these cases do you lose anything.
>
> Nor do you gain anything. Archive nodes will still need to exist

Not every node is an archive node; that's even the case today.
Lowering the resource requirements to independently enforce the rules
of the system is highly virtuous.

> precisely because paper wallets don't include UTXO data. This is like
> adding the ability to partially seed a movie with bittorrent.
[...]
> Every paper wallet would have to be re-printed with UTXO data

They are not printed now with UTXO data
(txid:vout:scriptpubkey:amount), and unless you start and fully
synchronize (or are running a full node) you already cannot author a
transaction without that data. The private key is already not enough,
and no Bitcoin node will just give you what you need to know.

The only additional information JL2012's scheme would add would be the
hash tree fragments to show membership; and the same places that
currently give you what is required to author a transaction could
provide it for you.

> included. It doesn't even solve the core problem because someone can
> still flood the network with lots of UTXOs, as long as they spend them
> quickly.

The system already inhibits the rate new UTXO can be added; but we're
still left with the perpetually growing history that contains many
lost and otherwise unspendable outputs.

📅 Original date posted:2015-12-13 📝 Original message:On ...

2023-06-07T19:46:14+02:00

In reply to nevent1q…jn9p
_________________________

📅 Original date posted:2015-12-13
📝 Original message:On Sun, Dec 13, 2015 at 8:13 AM, Chris Priest <cp368202 at ohiou.edu> wrote:
> Lets say it's 2050 and I want to sweep a paper wallet I created in
> 2013. I can't just make the TX and send it to the network, I have to
> first contact an "archive node" to get the UTXO data in order to make
> the TX. How is this better than how the system works today?

You already are in that boat. If your paper wallet has only the
private key (as 100% of them do today). You'll have no idea what coins
have been assigned to it, or what their TXids are. You'll need to
contact a public index (which isn't a service existing nodes provide)
or synchronize the full blockchain history to find it. Both are also
sufficient for jl2012's (/Petertodd's STXO), they'd only be providing
you with somewhat more data. If instead, you insist that you'd
already be running a full node and not have to wait for the sync, then
again you'd also be your own archive. In none of these cases do you
lose anything.

📅 Original date posted:2015-12-13 📝 Original message:On ...

2023-06-07T19:46:13+02:00

In reply to nevent1q…k7mr
_________________________

📅 Original date posted:2015-12-13
📝 Original message:On Sun, Dec 13, 2015 at 1:00 AM, Vincent Truong via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> have run a node/kept their utxo before they were aware of this change and
> then realise miners have discarded their utxo. Oops?

I believe you have misunderstood jl2012's post. His post does not
cause the outputs to become discarded. They are still spendable,
but the transactions must carry a membership proof to spend them.
They don't have to have stored the data themselves, but they must
get it from somewhere-- including archive nodes that serve this
purpose rather than having every full node carry all that data forever.

Please be conservative with the send button. The list loses its
utility if every moderately complex idea is hit with reflexive
opposition by people who don't understand it.

Peter Todd has proposed something fairly similar with "STXO
commitments". The primary argument against this kind of approach that
I'm aware of is that the membership proofs get pretty big, and if too
aggressive this trades bandwidth for storage, and storage is usually
the cheaper resource. Though at least the membership proofs could be
omitted when transmitting to a node which has signaled that it has
kept the historical data anyways.

📅 Original date posted:2015-12-10 📝 Original message:On ...

2023-06-07T19:46:07+02:00

In reply to nevent1q…590k
_________________________

📅 Original date posted:2015-12-10
📝 Original message:On Thu, Dec 10, 2015 at 6:47 AM, jl2012--- via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> It seems the current consensus is to implement Segregated Witness. SW opens
> many new possibilities but we need a balance between new features and
> deployment time frame. I'm listing by my priority:

> 2. Deployment time frame: I prefer as soon as possible, even if none of the following new features are implemented.

Thanks, I agree there.

A point to keep in mind: Segregated Witness was specifically designed
to make script changes / improvements / additions / total rewrites no
harder to do _after_ SW then they would be do do along with it. For
many people the "ah ha! lets do this" was realizing it could be a
pretty clean soft-fork. For me, it was realizing that we could
structure Segwit in a way that radically simply future script updates
... and in doing so avoid a getting trapped by a rush to put in every
script update someone wants.

This is achieved by having the 'version' byte(s) at the start of the
witness program. If the witness program prefix is unrecognized it
means RETURN TRUE. This recaptures the behavior that seems to have
been intended by OP_VER in the earliest versions of the software, but
actually works instead of giving every user the power to hardfork the
system at any time. :) This escapes much of the risk in script
changes, as we no longer need to worry about negation, or other
interactions potentially breaking things. A new version flag can have
its whole design crafted as if it were being created on a clean slate.

Optimizing layout and such I think makes sense, but I think we should
consider any script enhancements completely off the table for SW;
otherwise the binding will delay deployment and increase complexity. I
want most of those things too (a couple I disagree with) and a few of
them we could do quite quickly-- but no need to bind them up; post SW
and esp with version bits we could deploy them quite rapidly and on
their own timeframes.

> Multiplication and division may still considered to be risky and not very useful?

Operations like these make sense with fixed with types, when they are
over arbitrary bignums, they're a complexity nightmare... as
demonstrated by Bitcoin. :)

RE: OP_DUPTOALTSTACK yea, I've wanted that several times (really I've
been sad that there isn't just a stack flag on every manipulation
instruction).

📅 Original date posted:2015-12-08 📝 Original message:On ...

2023-06-07T19:45:47+02:00

In reply to nevent1q…fx35
_________________________

📅 Original date posted:2015-12-08
📝 Original message:On Tue, Dec 8, 2015 at 11:48 PM, Jonathan Toomim <j at toom.im> wrote:
> I understood that SegWit would allow about 1.75 MB of data in the average
> case while also allowing up to 4 MB of data in the worst case. This means
> that the mining and block distribution network would need a larger safety
> factor to deal with worst-case situations, right? If you want to make sure

By contrast it does not reduce the safety factor for the UTXO set at
all; which most hold as a much greater concern in general; and that
isn't something you can say for a block size increase.

With respect to witness safety factor; it's only needed in the case of
strategic or malicious behavior by miners-- both concerns which
several people promoting large block size increases have not only
disregarded but portrayed as unrealistic fear-mongering. Are you
concerned about it? In any case-- the other improvements described in
my post give me reason to believe that risks created by that
possibility will be addressable.

📅 Original date posted:2015-12-09 📝 Original message:On ...

2023-06-07T19:45:44+02:00

In reply to nevent1q…xy3t
_________________________

📅 Original date posted:2015-12-09
📝 Original message:On Wed, Dec 9, 2015 at 7:54 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> From this question one could think that when you said "we can do the
> cleanup hardfork later" earlier you didn't really meant it. And that
> you will oppose to that hardfork later just like you are opposing to
> it now.
> As said I disagree that making a softfork first and then move the
> commitment is less disruptive (because people will need to adapt their
> software twice), but if the intention is to never do the second part
> then of course I agree it would be less disruptive.
> How long after the softfork would you like to do the hardfork?
> 1 year after the softfork? 2 years? never?

I think it would be logical to do as part of a hardfork that moved
commitments generally; e.g. a better position for merged mining (such
a hardfork was suggested in 2010 as something that could be done if
merged mining was used), room for commitments to additional block
back-references for compact SPV proofs, and/or UTXO set commitments.
Part of the reason to not do it now is that the requirements for the
other things that would be there are not yet well defined. For these
other applications, the additional overhead is actually fairly
meaningful; unlike the fraud proofs.

📅 Original date posted:2015-12-09 📝 Original message:On ...

2023-06-07T19:45:43+02:00

In reply to nevent1q…2dwk
_________________________

📅 Original date posted:2015-12-09
📝 Original message:On Wed, Dec 9, 2015 at 6:59 AM, Mark Friedenbach <mark at friedenbach.org> wrote:
> Greg, if you have actual data showing that putting the commitment in the
> last transaction would be disruptive, and how disruptive, that would be
> appreciated. Of the mining hardware I have looked at, none of it cared at
> all what transactions other than the coinbase are. You need to provide a
> path to the coinbase for extranonce rolling, but the witness commitment
> wouldn't need to be updated.
>
> I'm sorry but it's not clear how this would be an incompatible upgrade,
> disruptive to anything other than the transaction selection code. Maybe I'm
> missing something? I'm not familiar with all the hardware or pooling setups
> out there.

I didn't comment on the transaction output. I have commented on
coinbase outputs and on a hard-fork.

Using an output in the last transaction would break the assumption
that you can truncate a block and still have a valid block. This is
used by some mining setups currently, because GBT does not generate
the coinbase transaction and so cannot know its size; and you may have
to drop the last transaction(s) to make room for it.

That a block can be truncated and still result in a valid block also
seems like a useful property to me.

If the input for that transaction is supposed to be generated from a
coinbase output some blocks earlier, then this may again run into
hardware output constraints in coinbase transactions. (But it may be
better since it wouldn't matter which output created it.). This could
likely be escaped by creating a zero value output only once and just
rolling it forward.

📅 Original date posted:2015-12-09 📝 Original message:On ...

2023-06-07T19:45:42+02:00

In reply to nevent1q…pt48
_________________________

📅 Original date posted:2015-12-09
📝 Original message:On Wed, Dec 9, 2015 at 4:44 AM, Ryan Butler <rryananizer at gmail.com> wrote:
>>I agree, but nothing I have advocated creates significant technical
>>debt. It is also a bad engineering practice to combine functional
>>changes (especially ones with poorly understood system wide
>>consequences and low user autonomy) with structural tidying.
>
> I don't think I would classify placing things in consensus critical code
> when it doesn't need to be as "structural tidying". Gavin said "pile on"
> which you took as implying "a lot", he can correct me, but I believe he
> meant "add to".

Nothing being discussed would move something from consensus critical
code to not consensus critical.

What was being discussed was the location of the witness commitment;
which is consensus critical regardless of where it is placed. Should
it be placed in an available location which is compatible with the
existing network, or should the block hashing data structure
immediately be changed in an incompatible way to accommodate it in
order to satisfy an ascetic sense of purity and to make fraud proofs
somewhat smaller?

I argue that the size difference in the fraud proofs is not
interesting, the disruption to the network in an incompatible upgrade
is interesting; and that if it really were desirable reorganization to
move the commitment point could be done as part of a separate change
that changes only the location of things (and/or other trivial
adjustments); and that proceeding int this fashion would minimize
disruption and risk... by making the incompatible changes that will
force network wide software updates be as small and as simple as
possible.

>> (especially ones with poorly understood system wide consequences and low
>> user autonomy)
>
> This implies there you have no confidence in the unit tests and functional
> testing around Bitcoin and should not be a reason to avoid refactoring.
> It's more a reason to increase testing so that you will have confidence when
> you refactor.

I am speaking from our engineering experience in a public,
world-wide, multi-vendor, multi-version, inter-operable, distributed
system which is constantly changing and in production contains private
code, unknown and assorted hardware, mixtures of versions, unreliable
networks, undisclosed usage patterns, and more sources of complex
behavior than can be counted-- including complex economic incentives
and malicious participants.

Even if we knew the complete spectrum of possible states for the
system the combinatioric explosion makes complete testing infeasible.

Though testing is essential one cannot "unit test" away all the risks
related to deploying a new behavior in the network.

📅 Original date posted:2015-12-08 📝 Original message:On ...

2023-06-07T19:45:41+02:00

In reply to nevent1q…wkmq
_________________________

📅 Original date posted:2015-12-08
📝 Original message:On Wed, Dec 9, 2015 at 1:09 AM, Gavin Andresen <gavinandresen at gmail.com> wrote:
> Create a 1-megabyte transaction, with all of it's inputs spending
> segwitness-spending SIGHASH_ALL inputs.
>
> Because the segwitness inputs are smaller in the block, you can fit more of
> them into 1 megabyte. Each will hash very close to one megabyte of data.

Witness size comes out of the 1MB at a factor of 0.25. It is not
possible to make a block which has signatures with the full 1MB of
data under the sighash while also having signatures externally. So
every byte moved into the witness and thus only counted as 25% comes
out of the data being hashed and is hashed nInputs (*checksigs) less
times.

> I think it is a huge mistake not to "design for success" (see
> http://gavinandresen.ninja/designing-for-success ).

We are designing for success; including the success of being able to
adapt and cope with uncertainty-- which is the most critical kind of
success we can have in a world where nothing is and can be
predictable.

> I think it is a huge mistake to pile on technical debt in consensus-critical
> code. I think we should be working harder to make things simpler, not more
> complex, whenever possible.

I agree, but nothing I have advocated creates significant technical
debt. It is also a bad engineering practice to combine functional
changes (especially ones with poorly understood system wide
consequences and low user autonomy) with structural tidying.

> And I think there are pretty big self-inflicted current problems because
> worries about theoretical future problems have prevented us from coming to
> consensus on simple solutions.

That isn't my perspective. I believe we've suffered delays because of
a strong desire to be inclusive and hear out all ideas, and not
forestall market adoption, even for ideas that eschewed pragmatism and
tried to build for forever in a single step and which in our hear of
hearts we knew were not the right path today. It's time to move past
that and get back on track with the progress can make and have been
making, in terms of capacity as well as many other areas. I think that
is designing for success.

📅 Original date posted:2015-12-08 📝 Original message:On ...

2023-06-07T19:45:40+02:00

In reply to nevent1q…8x2v
_________________________

📅 Original date posted:2015-12-08
📝 Original message:On Tue, Dec 8, 2015 at 3:12 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Why segwitness as a soft fork? Stuffing the segwitness merkle tree in the
> coinbase is messy and will just complicate consensus-critical code (as
> opposed to making the right side of the merkle tree in block.version=5
> blocks the segwitness data).

It's nearly complexity-costless to put it in the coinbase transaction.
Exploring the costs is one of the reasons why this was implemented
first.

We already have consensus critical enforcement there, the height,
which has almost never been problematic. (A popular block explorer
recently misimplemented the var-int decode and suffered an outage).

And most but not all prior commitment proposals have suggested the
same or similar. The exact location is not that critical, however,
and we do have several soft-fork compatible options.

> It will also make any segwitness fraud proofs significantly larger (merkle
> path versus merkle path to coinbase transactions, plus ENTIRE coinbase
> transaction, which might be quite large, plus merkle path up to root).

Yes, it will make them larger by log2() the number of transaction in a
block which is-- say-- 448 bytes.

With the coinbase transaction thats another couple kilobytes, I think
this is negligible.

>From a risk reduction perspective, I think it is much preferable to
perform the primary change in a backwards compatible manner, and pick
up the data reorganization in a hardfork if anyone even cares.

I think thats generally a nice cadence to split up risks that way; and
avoid controversy.

> We also need to fix the O(n^2) sighash problem as an additional BIP for ANY
> blocksize increase.

The witness data is never an input to sighash, so no, I don't agree
that this holds for "any" increase.

> Segwitness will make the current bottleneck (block propagation) a little
> worse in the short term, because of the extra fraud-proof data. Benefits
> well worth the costs.

The fraud proof data is deterministic, full nodes could skip sending
it between each other, if anyone cared; but the overhead is pretty
tiny in any case.

> I think a barrier to quickly getting consensus might be a fundamental
> difference of opinion on this:
> "Even without them I believe we’ll be in an acceptable position with
> respect to capacity in the near term"
>
> The heaviest users of the Bitcoin network (businesses who generate tens of
> thousands of transactions per day on behalf of their customers) would
> strongly disgree; the current state of affairs is NOT acceptable to them.

My message lays out a plan for several different complementary
capacity advances; it's not referring to the current situation--
though the current capacity situation is no emergency.

I believe it already reflects the emerging consensus in the Bitcoin
Core project; in terms of the overall approach and philosophy, if not
every specific technical detail. It's not a forever plan, but a
pragmatic one that understand that the future is uncertain no matter
what we do; one that trusts that we'll respond to whatever
contingencies surprise us on the road to success.

📅 Original date posted:2015-12-08 📝 Original message:On ...

2023-06-07T19:45:36+02:00

In reply to nevent1q…gele
_________________________

📅 Original date posted:2015-12-08
📝 Original message:On Tue, Dec 8, 2015 at 4:58 AM, Anthony Towns via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Having a cost function rather than separate limits does make it easier to
> build blocks (approximately) optimally, though (ie, just divide the fee by
> (base_bytes+witness_bytes/4) and sort). Are there any other benefits?

Actually being able to compute fees for your transaction: If there are
multiple limits that are "at play" then how you need to pay would
depend on the entire set of other candidate transactions, which is
unknown to you. Avoiding the need for a fancy solver in the miner is
also virtuous, because requiring software complexity there can make
for centralization advantages or divert development/maintenance cycles
in open source software off to other ends... The multidimensional
optimization is harder to accommodate for improved relay schemes, this
is the same as the "build blocks" but much more critical both because
of the need for consistency and the frequency in which you do it.

These don't, however, apply all that strongly if only one limit is
likely to be the limiting limit... though I am unsure about counting
on that; after all if the other limits wouldn't be limiting, why have
them?

> That seems kinda backwards.

It can seem that way, but all limiting schemes have pathological cases
where someone runs up against the limit in the most costly way. Keep
in mind that casual pathological behavior can be suppressed via
IsStandard like rules without baking them into consensus; so long as
the candidate attacker isn't miners themselves. Doing so where
possible can help avoid cases like the current sigops limiting which
is just ... pretty broken.

📅 Original date posted:2015-10-30 📝 Original message:On ...

2023-06-07T19:43:55+02:00

In reply to nevent1q…t9gg
_________________________

📅 Original date posted:2015-10-30
📝 Original message:On Fri, Oct 30, 2015 at 3:04 AM, Simon Liu via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Given that UTXO storage is considered critical, it seems reasonable to

This sounds like a misunderstanding of what consensus criticial means.
It does not mean that it must be right (though obviously that is
preferable) but that it must be _consistent_, between all nodes.

> full node and keep up with the network, why not let those users with the
> resources to operate big iron databases do so? It would be a good
> feature to have.

Because it provides no value, the data is opaque and propritarily
encoded with a compression function which we may change from version
to version, and because many of these alternatives are enormously
slow; enough that they present problems with falling behind the
network even on high performance hardware.

Moreover, additional functional which will not be sufficiently used
will not adequately maintained and result in increased maintains costs
and more bugs.

📅 Original date posted:2015-10-22 📝 Original message:On ...

2023-06-07T19:43:45+02:00

In reply to nevent1q…j679
_________________________

📅 Original date posted:2015-10-22
📝 Original message:On Thu, Oct 22, 2015 at 8:26 AM, Christian Decker via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Normalized transaction IDs do help in the case that the single signer wants
> to immediately follow up its transaction with another transaction spending
> the first one's change output, and it prevents any modification in the
> multi-signer scenario.

For ordinary transactions which are not performing interesting smart
contracts that particular is better addressed via canonical encoding,
which is immediately available and doesn't have the associated costs
(new pubkey type adoption, 20%-30% UTXO size increase, need for nodes
to fixup txid references, etc.).

Please, as I said up-thread: this is good and importantstuff to work
on, but it shouldn't be oversold.

📅 Original date posted:2015-10-21 📝 Original message:On ...

2023-06-07T19:43:44+02:00

In reply to nevent1q…xssp
_________________________

📅 Original date posted:2015-10-21
📝 Original message:On Wed, Oct 21, 2015 at 6:22 PM, Danny Thorpe via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> outputs) seems like quite a different hazard than a malicious third party
> modifying a transaction in the mempool by twiddling opcodes in the signature
> scripts. The former seems like more a matter of keeping your own house in

Indeed they are different, but canonical encoding enforcement prevents
the third party malleability completely on ordinary transactions.

It is an an _immediate_ solution which is already deployed as a
standardness rule-- once miners update to 0.11.1 or 0.10.3 (or
equivalent) only miners will be able to malleable ordinary payments,
to the best of our current understanding.

[snip]
> proposal. Baby steps. Normalized transaction IDs provide an immediate
> benefit against the hazard of third party manipulation of transactions in
> the mempool, even without canonical ordering.

The thing being discussed here does not provide an immediate benefit
to that particular issue. It addresses multistep contracts and other
cases.

But it does not prevent third party mutation until people change their
public keys to new scheme (which based on p2sh we should expect a well
over a year deployment), which they cannot being doing until a soft
fork is made and settled in the network, for which the code is not yet
written. CLTV suggests that the current timeframe for a soft fork is
around a year and though I'd like to see that improved.

So canonical encoding is both sufficient (to the best of our current
understanding) for preventing third party malleability on ordinary
transactions, and the _only_ option for to have an actually immediate
benefit.

Please don't mix up third party malleability with this work which is
important in its own right.

📅 Original date posted:2015-10-05 📝 Original message:On ...

2023-06-07T19:42:48+02:00

In reply to nevent1q…nk22
_________________________

📅 Original date posted:2015-10-05
📝 Original message:On Mon, Oct 5, 2015 at 9:08 PM, Tom Zander via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Monday 5. October 2015 20.56.34 Gregory Maxwell wrote:
>> (In this case, I don't even believe we have any regulator
>> contributors that disagree).
>
> Regular contributor?
>
> Please explain how for a fork in the protocol should you only listen to
> regular Bitcoin Core contributors?

I'm providing some perspective and scope-- referencing again your
comment about following actions-- what element of the many dozens of
responses suggests to you that _anyone_ is not being listened to?

While I'm sure its not intended; your selective editing ends up
butchering the meaning---- I pointed out that there have been
disputes, even ones involving regular contributors (and, implicitly,
that I'm not lying by omission in not mentioning that the dispute was
a joke or from someone well known to attack Bitcoin) or-- in other
words, evidence that the disagreement was not less meaningful than
what you're talking about here. That's all, sorry I was unclear again.

Did you see in my message that I invited you to take a look for
examples-- I think they're easily found and you would find it
informative. I really recommend spending some time looking.

📅 Original date posted:2015-10-05 📝 Original message:On ...

2023-06-07T19:42:44+02:00

In reply to nevent1q…taqt
_________________________

📅 Original date posted:2015-10-05
📝 Original message:On Mon, Oct 5, 2015 at 7:13 PM, Tom Zander via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> It is an eloquent change, but not really the topic we were discussing. It also
> makes you attack Mike (calling him out as having a strawman) without basis.
> For the second time in this thread.
> I would suggest arguing on the topic, not on the man.

Such a shame you appear to reserve that wisdom for those you disagree
with, biting your tongue when others emit all forms of ad hominem--
such as suggesting we've spent less volunteer time on Bitcoin and thus
our opinion has less merit (or that we haven't written certian kinds
of software (even when, ironically, we have!), and thus our opinion
doesn't have merit, and so on). I think everyone would benefit from
it, especially as that kind of correction is best received from
someone who agrees with you.

In this case, I think, however your correction is also misplaced at
least on this message; though I would otherwise welcome it. I'm not
complaining about the man; but pointing out the behavior of stating an
opinion no one as held as theirs and attacking it is not a productive
way to hold a discussion. It's an argument or a behavior, not a
person, and beyond calling it bad I attempted to explaining (perhaps
poorly) why its bad.

What Sergio is saying is not the same; Mike argued some established
criteria existed where it didn't-- and I was pointing that out; and
talking about how the situation here is not very similar to the one
that Mike was trying to draw a parallel to. I enumerated a number of
specific reasons why this is the case. If the differences between
Sergio's comments and mine are still unclear after this clarification,
I'd be glad to talk it through with you off-list-- in spite of your
(welcome) compliments, communication is just fundamentally difficult,
and no amount eloquence changes that. If there is continued
misunderstanding, I do not doubt its my fault; but it's probably not a
good use of hundreds/thousands of people's time for you to help me
interactively improve my explanation on list. :)

📅 Original date posted:2015-10-05 📝 Original message:On ...

2023-06-07T19:42:42+02:00

In reply to nevent1q…76rm
_________________________

📅 Original date posted:2015-10-05
📝 Original message:On Mon, Oct 5, 2015 at 5:26 PM, Tom Zander via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Monday 5. October 2015 18.03.05 Btc Drak via bitcoin-dev wrote:
>> However, I would like to challenge your assumption of point 1 that that by
>> Mike making a rabble, it somehow makes CLTV deployment controversial. His
>> arguments have been refuted.
>
> Unsuccessfully.

I think rather successfully. That Mike himself continues to misexplain
things is not surprising since he has all but outright said that his
motivation here is to disrupt Bitcoin in order to try to force his
blocksize hardfork on people. Since this motivation is uncorrelated
with any property of soft-forks or CLTV we should not expect his
position to change.

> The point is that Bitcoin Core claims to have a consensus mechanism and sticks
> to "no change" on not reaching a consensus. And that rule is the reason why
> bigger blocks were blocked for years.

You're repeating Mike's claims there-- not anyone elses. Take your
complaint up with him-- not the list.

📅 Original date posted:2015-09-30 📝 Original message:On ...

2023-06-07T19:41:41+02:00

In reply to nevent1q…psmy
_________________________

📅 Original date posted:2015-09-30
📝 Original message:On Wed, Sep 30, 2015 at 10:17 PM, Jeff Garzik <jgarzik at gmail.com> wrote:
> It is correct that security is slightly reduced for full nodes that have not
> upgraded. It is not correct that the choice is binary, full node or SPV.
>
> Any user running a not-upgraded full node still retains protection against
> many attacks outside the subset related to the feature being introduced.

An extra way to look at this is that even absent any rule changes--
users who are asleep at the switch may lose effective security over
time because attackers learn new tricks against existing
vulnerabilities. Security requires a bit of vigilance, inherently.

In many specific cases I think it's hard-to-impossible to articulate a
concrete way that security is lost by users at all, excluding some
small amplification of orphan blocks.

On Wed, Sep 30, 2015 at 9:06 PM, Mike Hearn via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> and is trying to mine it, will keep producing invalid blocks forever until
> the owner shuts it down and upgrades.

This is the outcome guaranteed for absentee miners with a hard fork,
but it is not guaranteed for a soft fork.

> For instance, any miner that has modified/bypassed IsStandard() can do this,

Miners who have changed their code in inadvisable ways can produce
invalid blocks as a result. There are many seemingly innocuous ways
one can produce invalid blocks, and miners have stumbled on a few of
them over the years.

Pedantically, modifying IsStandard() will not have this effect:
Unknown NOPs are now handled via a script validation flag--
SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS. Experience (e.g. with
STRICTDER) has show that script validation flags are much more robust
to casual twiddling than IsStandard is.

The only way that script validation flags have been observed getting
bypassed in the field was a miner that had disabled all signature
validation completely (and whom had a not-completely-negligible amount
of hashpower. :( )... as it's a lot more clear that you might be
exposing yourself to trouble if you mess with the validation flags.

> runs an old node from before OP_NOPs were made non-standard.

IIRC; There is no released version of Bitcoin that has IsStandard
which has failed failed to treat the NOPs as non-standard.

There was a brief time in git master between when IsStandardness was
relaxed and NOPs were addressed via a validation flag but I am
reasonably confident that didn't make it into a release.

Regardless, anyone actually running that code of that vintage would
already be incompatible with the current network already due to prior
soft forks.

And as a matter of fact, invalid CLTVs don't currently appear to get
mined. Checking this again pre-release would be a good checklist item.
For prior soft-forks we've monitored and tested for this (with the
goal of going and yelling at any broken miners to fix their behavior).

📅 Original date posted:2015-09-18 📝 Original message:On ...

2023-06-07T19:40:52+02:00

In reply to nevent1q…2k9w
_________________________

📅 Original date posted:2015-09-18
📝 Original message:On Fri, Sep 18, 2015 at 8:27 PM, Matt Corallo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Google Calendar is localized, but has an option to change the timezone
> of an event, it just doesnt have UTC in its options. So, yes, we should
> use something that observes DST in roughly the same way as everyone else
> - CEST/PDT/EST/etc.

uh. There is fairly little global consistency in DST usage. Lots of
places do dst on different dates.

So if it's in some DST timezone it's likely to move twice each change
for some subset of the people who do it.

E.g. europe and US end DST one week apart.

📅 Original date posted:2015-09-03 📝 Original message:On ...

2023-06-07T19:39:25+02:00

In reply to nevent1q…xpgn
_________________________

📅 Original date posted:2015-09-03
📝 Original message:On Thu, Sep 3, 2015 at 4:05 AM, Jeff Garzik via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> (b) requiring miners to have idle
> hashpower on hand to change block size are both unrealistic and potentially

I really cannot figure out how you could characterize pay with
difficty has in any way involving idle hashpower.

Can you walk me through this?

📅 Original date posted:2015-08-30 📝 Original message:On ...

2023-06-07T19:38:37+02:00

In reply to nevent1q…80t4
_________________________

📅 Original date posted:2015-08-30
📝 Original message:On Sun, Aug 30, 2015 at 4:13 AM, Peter R <peter_r at gmx.com> wrote:
> I agree that miners may change their level of centralization. This neither
> affects the model nor the results presented in the paper.

It has tremdous significance to the real-world impact of your results.

If not for the other errors in your work, this point would make the
take away of your work not "a healthy transaction fee market exists
without a block size limit" but rather "a decenteralized bitcoin
cannot exist"-- as, accepting the other errors as fact your model
shows that centralizing mining is always strictly more profitable at
any level of fee demand; because your model equivilent shows that for
any level of fee demand and gamma miners could increase their income
by centeralizing further.

I absolutely agree that simplifications are useful and essential, but
it is critically important to call them out before someone mistakes
theoretical work as useful motivation for policy in the non-simplified
system.

> -- Instead the same information can be transmitted _in advance_, as
> has been previously proposed, and various techniques can make doing
> so arbitrarily efficient.
>
> I assume, very reasonably, that the block solutions contain information
> about the transactions included in the block. This is the case today, this
> is the case using the relay network, and this would be the case using any
> compression scheme I can personally imagine actually occurring in the
> future.

This assumption is unreasonable, and does not-- in fact-- accurately
reflect the situation today.

For example it does not reflect how hashers return work to pools
_today_ (and since 2011) as they so to only by referencing the merkel
root... the pool already knows the transaction set. In that
particular case it knows it because it selected it to begin with, but
the same behavior holds if the hasher selects the transaction set and
sends it first.

It only _very_ weakly reflects how the relay protocol works (only the
selection and permutation is communicated; not the transaction data
itself; for already known transactions). Even if you assume nothing
more than that (in spite of the existing reality) you have not shown
that the compressed data must be linear in the size of the block.

It does not reflect how P2Pool works (which also sends the
transactions in advance).

There is a simple, and intuitive understanding that does not require
any complex supposition: You argue that the information must be
transfered when a block is found, thus delaying it. I point out, no,
any required information (to the extent that there is any at all after
efficient encoding) can be sent in advance of the block.

I believe that you've allowed the fact that the specifc example block
relay protocol doesn't bother sending _all_ information in advance to
confuse it for mere compression.

> My public comments have been factual. I've even gone out of my way in
> several public threads to point out your objection that the coding gain
> could be zero (even though I think it is flawed "black-and-white thinking"
> about an academic scenario that will never unfold and might actually be
> physically impossible without Bitcoin already being centralized).

I believe my reponses are firmly grounded in the physical reality of
actually deployed systems and constructable protocols.

By comparison, even if I were to agree that the bound is not actually
exactly 0 proporionality you have already agreed that with
"compression" the amount sent could be arbritarily low. The result
being that the behavior you're describing would only be asymptoic and
have no relationship to the actual Bitcoin system that exists in a
finite universe.

But you continue to demand debate over this meaningless point.

> I'll end by saying that I am the one describing things as the presently are.
> You are talking about a hypothetical future that may or may not exist (and
> may not even be possible). The results of my paper logically follow from
> the assumptions made. You think the assumption that "block solutions contain
> information about the transactions included in the block" will not hold in
> the future. Can you show:
>
> (a) Under what assumptions/requirements your communication scheme is
> physically possible.

Pratically every block today is mined under a protocol which does not
need to communicate anything but constant data when a block is found.

I am getting a little tired of people suggesting things which are
widely deployed are not physically possible.

Yes, that particular example is not the most powerful form of that
idea-- but it has the benefit of _universal_ use.

> (b) That such a configuration is not equivalent to a single entity[1]
> controlling >50% of the hash power.

I find this a little amusing. Even in this messsage you defend
ignoring of centeralization considerations in your paper. But here ask
that I address concerns which you refused to suggest. Why do you
demand my correction use weaker assumptions than your work?

That said-- I already gave you a fairly concrete description of a
pratical protocol which would accomplish your requirement ( (a) reduce
the information transmitted in a latency critical way at block
discovery time to O(1) network wide, (b) without creating
centeralization in chain or transaction selection). I believe my
description in the messages was adequate that anyone working on
Bitcoin Core could go implement a version of it, at least. You appear
to have simply ignrored it.

If the actual technical details made your eyes glaze over I also
offered a simple intutive understanding: The no proportional
information need be transfered at the latency critical time, because
it can be transfered in _advance_. Everything beyond that is just
efficiency optimizations to reduce the cost of doing the advanced
transmission.

> (c) That the network moving into such a configuration is plausible.

That it already uses advanced information techniques in every widely
used mining protocol, that the relay protocol was rapidly adopted, and
that your own model would suggest significant profits from any such
improvement would seem to remove any doubt related to (c)... and again
here you hold me to a higher bar than your own work: as nowhere do you
show that the "limits" your model erroniously extracts are plausable
as limits, and in private you seemed to admit to me that they may well
not be.

📅 Original date posted:2015-08-21 📝 Original message:On ...

2023-06-07T19:36:49+02:00

In reply to nevent1q…w58d
_________________________

📅 Original date posted:2015-08-21
📝 Original message:On Wed, Aug 19, 2015 at 4:57 AM, Nicolas Dorier via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I created a small website which show a chart of your approvals about various
> BIPs (which you must fill by yourself with a signed pgp message)
> For each BIP, you can fill if you approve or not, and give comments. (HTML
> accepted, so you can link stuff you your posts)
> It would help the community a lot, so I hope you will do it !
> I'm open to add other important devs, big miners, or other proposal that I
> missed.

I think this is a bit well, sad, at the moment-- a basic principle in
sound decision making is that one should try to withhold judgement
until after the analysis and options are laid out to avoid prematurely
laying down "battle lines" which then they're socially and politically
committed to a particular answer.

There are several other BIPs in the works right now that aren't out
there yet, as well (as presumably) new insight from the workshop. It
would be a shame if these things would be for naught because of being
decided prematurely.

📅 Original date posted:2015-08-17 📝 Original message:On ...

2023-06-07T19:35:44+02:00

In reply to nevent1q…jg2c
_________________________

📅 Original date posted:2015-08-17
📝 Original message:On Mon, Aug 17, 2015 at 7:16 PM, Hector Chu via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> I suspect we need a better incentive for users to run nodes instead of
>> relying solely on altruism.
>
>
> Is he talking about "full nodes" i.e. validating-only, or nodes in the sense
> of the original whitepaper (i.e. miners)? Because there is already plenty of
> incentive for running a node (i.e. the coinbase).

One can mine without running a node, unfortunately, thats where the
comments about pooled mining come from.

Also, this distionction between full nodes that "Validate" and
(presumably) SPV wallets that don't validate isn't consistent with the
design of Bitcoin.

> enter the mining game. A bit like making P2Pool the one and only pool
> allowed on the network.

Thats been suggested, though scalablity reasons make this hard: in the
P2Pool design there is a substantial tradeoff in variance reduction vs
communicatoin costs.

📅 Original date posted:2015-08-18 📝 Original message:On ...

2023-06-07T19:35:41+02:00

In reply to nevent1q…fru0
_________________________

📅 Original date posted:2015-08-18
📝 Original message:On Mon, Aug 17, 2015 at 8:37 PM, Oliver Egginger via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Would we discuss his
> posting if he would not claim to be Satoshi? There are a lot of smart
> people on this list, which publish occasionally quite useful ideas.

I actually learned something important and infulential in my thinking
from the post. So I am happy it happened regardless of the other
things around it. Because of the _very_ poor SNR on the list right
now I'm not sure if I would have seen it if it were sent by JoeBob.
(This is a greater issue, and I'm not suggesting that people start
posting with fake identities to get over the noise floor... but I'm
just presenting the facts of it as I see them here).

The rest of the traffic, not so useful, thank heavens for threaded
mail user agents.

📅 Original date posted:2015-08-23 📝 Original message:On ...

2023-06-07T19:34:58+02:00

In reply to nevent1q…02tv
_________________________

📅 Original date posted:2015-08-23
📝 Original message:On Mon, Aug 24, 2015 at 12:25 AM, Tom Harding via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> ack no inversion. This can actually allow more direct preservation of
> existing semantics.
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009350.html

I can't follow this logic. Can you help? The existing semantics, to
the extent that they exist at all is that the earliest version starts
with the lowest sequence number then counts up (and if it makes its
way to the highest number, the result is final-- because it could go
no higher).

Thats the semantics 'the inversion' accomplishes for CSV: the that the
first version of a transaction begins with a smaller number which
successful versions increase, and the highest possible number is final
(no delay, because no delay is the shortest delay).

Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
discussion has any thought been given to represent one block with more
than one increment? This would leave additional space for future
signaling, or allow, for example, higher resolution numbers for a
sharechain commitement.

📅 Original date posted:2015-08-13 📝 Original message:On ...

2023-06-07T19:34:54+02:00

In reply to nevent1q…thsg
_________________________

📅 Original date posted:2015-08-13
📝 Original message:On Thu, Aug 13, 2015 at 6:12 PM, Mark Friedenbach <mark at friedenbach.org> wrote:
> As per the rules of BIP 1, I hereby request that the BIP editor please
> assign an official number to this work. The idea has been discussed before
> on the bitcoin-dev mailing list:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008452.html
>
> And a reference implementation is available here:
>
> https://github.com/maaku/bitcoin/tree/checksequenceverify

I think it's important to allow some time for discussion with the
actual proposed text up; as understandings can shift significantly. :)
Btcdrak already asked me for numbers prior to posting text at all and
I asked him to post text...

📅 Original date posted:2015-08-05 📝 Original message:On ...

2023-06-07T19:33:17+02:00

In reply to nevent1q…a2nn
_________________________

📅 Original date posted:2015-08-05
📝 Original message:On Wed, Aug 5, 2015 at 7:53 PM, Arnoud Kouwenhoven - Pukaki Corp via
bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Thanks for the reply. My understanding is that the bitcoin relay network is
> a backbone of connected high speed servers to increase the rate at which
> transactions and new blocks propagate - and remove a number of delays in
> processing. But it would still require the miners to download the entire
> block before building on top of it with any degree of confidence.

Your understanding is outdated.

The relay network includes an optimized transmission protocol which
enables sending the "entire" block typically in just a smal number of
bytes (much smaller than the summaries you suggest, which still leave
the participants needing to send the block).

E.g. block 000ce90846 was 999950 bytes and the relay network protocol
sent it using at most 4906 bytes.

No trust is required in this scheme because the entire block is
communicated using only a couple packets.

The current scheme is highly simplified and its efficiency could be
increased greatly with small improvements, or if miners created blocks
in an aware manner.... but with a maximum size blocks turning into 5kb
with the current setup, there hardly appears to be a reason to do so
right now.

Ultimately there is no need for information communicated with a block
at discovery time proportional to the size of the block; with the
right affordances it can be accomplished with a small constant amount
of data.

If not for this already being deployed I personally believe the
network would have already fallen into complete centeralization as a
response to larger blocks: this was constructed and deployed in order
to pull the network back from having a single pool with more than half
the hashrate.

📅 Original date posted:2015-07-31 📝 Original message:On ...

2023-06-07T19:32:04+02:00

In reply to nevent1q…hs48
_________________________

📅 Original date posted:2015-07-31
📝 Original message:On Sat, Aug 1, 2015 at 12:05 AM, Hector Chu via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> There is nothing tying
> transactions to the blocks they appear in.

Transactions can be recieved or accepted in different orders by
different nodes. The purpose of the blockchain is to resolve any
potential conflicting transactions by providing a globally agreed
total ordering.

As soon as one of the forks accepts a different transaction in a
conflicting set then there will be transactions which exist on one
chain which cannot exist on the other.

One can quite easily transact in a way to intentionally produce such a
split to seperate the existance of your coins onto the seperate forks;
just as anyone would need to do to perform a reorg-and-respend attack
on a single blockchain.

Additionally, new coins will be issued, along with fees, on both
chains. These new outputs become spendable after 100 blocks, and any
transaction spending them can exist exclusively on one chain.

Also any transaction whos casual history extends from one of the above
cases can exist only on one chain. This also means that someone who
has single-chain coins (via a conflict or from coinbase outputs) can
pay small amount to many users to get their wallets to consume them
and make more of the transactions single chain only-- if they wanted
the process to happen faster.

> Miners will migrate to the bigger chain in search of higher profits due to higher volume of fees

The migration remark is a considerable oversimplification. Imagine if
I released a version of the software programmed to reassign ownership
of a million of the earliest created unmoved coins to me at block
400k, and then after that I made transaction to pay 5 coin/block in
fees. Would miners move to this chain? It pays more in fees!

📅 Original date posted:2015-08-21 📝 Original message:On ...

2023-06-07T17:48:22+02:00

In reply to nevent1q…57ag
_________________________

📅 Original date posted:2015-08-21
📝 Original message:On Wed, Aug 19, 2015 at 4:57 AM, Nicolas Dorier via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I created a small website which show a chart of your approvals about various
> BIPs (which you must fill by yourself with a signed pgp message)
> For each BIP, you can fill if you approve or not, and give comments. (HTML
> accepted, so you can link stuff you your posts)
> It would help the community a lot, so I hope you will do it !
> I'm open to add other important devs, big miners, or other proposal that I
> missed.

I think this is a bit well, sad, at the moment-- a basic principle in
sound decision making is that one should try to withhold judgement
until after the analysis and options are laid out to avoid prematurely
laying down "battle lines" which then they're socially and politically
committed to a particular answer.

There are several other BIPs in the works right now that aren't out
there yet, as well (as presumably) new insight from the workshop. It
would be a shame if these things would be for naught because of being
decided prematurely.

📅 Original date posted:2015-08-17 📝 Original message:On ...

2023-06-07T17:47:27+02:00

In reply to nevent1q…ffad
_________________________

📅 Original date posted:2015-08-17
📝 Original message:On Mon, Aug 17, 2015 at 7:16 PM, Hector Chu via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> I suspect we need a better incentive for users to run nodes instead of
>> relying solely on altruism.
>
>
> Is he talking about "full nodes" i.e. validating-only, or nodes in the sense
> of the original whitepaper (i.e. miners)? Because there is already plenty of
> incentive for running a node (i.e. the coinbase).

One can mine without running a node, unfortunately, thats where the
comments about pooled mining come from.

Also, this distionction between full nodes that "Validate" and
(presumably) SPV wallets that don't validate isn't consistent with the
design of Bitcoin.

> enter the mining game. A bit like making P2Pool the one and only pool
> allowed on the network.

Thats been suggested, though scalablity reasons make this hard: in the
P2Pool design there is a substantial tradeoff in variance reduction vs
communicatoin costs.

📅 Original date posted:2015-08-17 📝 Original message:On ...

2023-06-07T17:47:24+02:00

In reply to nevent1q…3dtn
_________________________

📅 Original date posted:2015-08-17
📝 Original message:On Mon, Aug 17, 2015 at 11:51 AM, Oliver Egginger via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> To avoid such discussions.

You seem to be assuming that there is specific reason to believe the
message is unauthentic. This is not the case.

Contrary to other poster's claims, if the message had been PGP signed
that might, in fact, have arguably been weak evidence that it was
unauthentic: no message from the system's creator that I (or
apparently anyone) was aware of was ever signed with that key.

The headers on the message check out. The mail server in question is
also not an open relay. At the moment the only reason I have to doubt
the authenticity of it is merely the fact that it exists after so much
air silence, but that isn't especially strong.

In the presence of doubt, it's better to take it just for its content.
And on that front it is more on-topic, civil, and productively
directed than a substantial fraction of new messages on the list. I
certainly do not see a reason to hide it.

A focus on the content is especially relevant because one of the core
messages in the content is a request to eschew arguments from
authority; which is perhaps the greatest challenge here: How can the
founder of a system speak up to ask people to reject that kind of
argument without implicitly endorsing that approach through their own
act?

This whole tangest is a waste of time. If you believe the message is
unauthentic or not the best response is the same as if it is
authentic. Focus on the content. If its worth responding to, do. If
it's not don't. Then move on with life.

📅 Original date posted:2015-08-05 📝 Original message:On ...

2023-06-07T17:45:26+02:00

In reply to nevent1q…866l
_________________________

📅 Original date posted:2015-08-05
📝 Original message:On Wed, Aug 5, 2015 at 7:53 PM, Arnoud Kouwenhoven - Pukaki Corp via
bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Thanks for the reply. My understanding is that the bitcoin relay network is
> a backbone of connected high speed servers to increase the rate at which
> transactions and new blocks propagate - and remove a number of delays in
> processing. But it would still require the miners to download the entire
> block before building on top of it with any degree of confidence.

Your understanding is outdated.

The relay network includes an optimized transmission protocol which
enables sending the "entire" block typically in just a smal number of
bytes (much smaller than the summaries you suggest, which still leave
the participants needing to send the block).

E.g. block 000ce90846 was 999950 bytes and the relay network protocol
sent it using at most 4906 bytes.

No trust is required in this scheme because the entire block is
communicated using only a couple packets.

The current scheme is highly simplified and its efficiency could be
increased greatly with small improvements, or if miners created blocks
in an aware manner.... but with a maximum size blocks turning into 5kb
with the current setup, there hardly appears to be a reason to do so
right now.

Ultimately there is no need for information communicated with a block
at discovery time proportional to the size of the block; with the
right affordances it can be accomplished with a small constant amount
of data.

If not for this already being deployed I personally believe the
network would have already fallen into complete centeralization as a
response to larger blocks: this was constructed and deployed in order
to pull the network back from having a single pool with more than half
the hashrate.

📅 Original date posted:2015-07-29 📝 Original message:On ...

2023-06-07T17:43:52+02:00

In reply to nevent1q…xe62
_________________________

📅 Original date posted:2015-07-29
📝 Original message:On Wed, Jul 29, 2015 at 9:59 AM, Mike Hearn via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I do love history lessons from people who weren't actually there.

I doubt the rest of us really enjoy hearing these "lessons" from from
you where you wildly distort history to reflect your views.

> Satoshi explicitly envisioned a future where only miners ran nodes, so it
> had nothing to do with this either.

As others have pointed out-- even if this were true, --- so what?
Many errors were made early on in Bitcoin.

But in this case it's not actually true and I'm really getting fed up
with this continued self-appointment of all that the creator of the
system thought. Your position and knoweldge is not special or
priveleged compared to many of the people that you are arguing with.

It was _well_ understood while the creator of the system was around
that putting every consensus decision into the world into one system
would not scale; and also understood that the users of Bitcoin would
wish to protect its decenteralization by limiting the size of the
chain to keep it verifyable on small devices.

Don't think you can claim otherwise, because doing so is flat out wrong.

In the above statement you're outright backwards-- there was a clear
expectation that all who ran nodes would mine. The delegation of
consensus to third parties was unforseen. Presumably Bitcoin core
making mining inaccessable to users in software was also unforseen.

> Validators validate for themselves. Calculating a local UTXO set and then
> not using it for anything doesn't help anyone. SPV wallets need filtering
> and serving capability, but a computer can filter and serve the chain
> without validating it.
>
> The only purposes non-mining, non-rpc-serving, non-Qt-wallet-sustaining full
> nodes are needed for with today's network are:
[...]
> Outside of serving lightweight P2P wallets there's no purpose in running a
> P2P node if you aren't mining, or using it as a **trusted node for your own
> operations**.

You wrote a long list of activities that are actually irrelevant to
many node users with the result of burrying the main reason any party
should be running a node (emphasis mine).

The incentives of the system demand as it exist today that many other
economically significant parties run nodes in order to keep the half
dozen miners from having a blank check to do whatever they want
(including supporting their operations through inflation)-- do not
think they wouldn't, as we've seen their happy to skip verification
entirely.

(Which, incidentially, is insanely toxic to any security argument for
SPV; ---- and now we see the market failure that results from your and
Gavin years long campaign to ignore problems in the mining ecosystem:
The SPV model which you've fixated on as the true nature of bitcoin
has been demonstrated in practice to have a potentially empty security
claim.)

> Miners who don't validate have a habit of bleeding money: that's the
> system working as designed.

The information I have currently is that the parties engaging in that
activity found it to be tremendously profitable, even including losses
from issues.

📅 Original date posted:2015-07-29 📝 Original message:On ...

2023-06-07T17:43:46+02:00

In reply to nevent1q…4kgr
_________________________

📅 Original date posted:2015-07-29
📝 Original message:On Wed, Jul 29, 2015 at 7:56 PM, Owen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On July 29, 2015 7:15:49 AM EDT, Mike Hearn via bitcoin-dev:
>>Consider this: the highest Bitcoin tx fees can possibly go is perhaps
>>a
>>little higher than what our competition charges. Too much higher than
>>that,
>>and people will just say, you know what .... I'll make a bank transfer.
>>It's cheaper and not much slower, sometimes no slower at all.
>
> I respectfully disagree with this analysis. The implication is that bitcoin is merely one of a number of payment technologies. It's much more than that. It's sound money, censorship resistance, personal control over money, programmable money, and more. Without these attributes it's merely a really inefficient way to do payments.
>
> Given these advantages, there is no reason to believe the marginal cost of a transaction can't far surpass that of a PayPal or bank transfer. I personally would pay several multiples of the competitors' fees to continue using bitcoin.
>
> Sure, some marginal use cases will drop off with greater fees, but that's normal and expected. These will be use cases where the user doesn't care about bitcoin's advantages. We must be willing to let these use cases go anyway, because we unfortunately don't have room on chain for everything anyone might want to do.
>
> Therefore, bitcoin tx fees can go much higher than the competition.
>
> Remember how Satoshi referenced the banking crisis in his early work? The 2008 banking crisis was about a lot of things, but high credit card and paypal fees wasnt one of them. There's more going on here than just payments. Any speculative economic analysis would do better to include this fact.

Precisely. And as "just a payment system" Bitcoin is not an
especially great one: The design requirements for decenteralization
impose considerable costs. To the extent that the technology in
Bitcoin is useful at all for building "just another payment system"
this technology in in the process of being agressively copied by
parties with deep fiat relationships (including in partnership with
centeral banks). If the focus for Bitcoin's competative advantage
becomes exclusively "better" payments then it will almost certinatly
fail in the market-place against competing systems which avoid the
Bitcoin currency adoption related obsticles (but also gain none of
Bitcoin's important social/political promise).

Also, critically, if Bitcoin's security properties are manintained and
enhanced then Bitcoin can be used to build secure systems which _also_
accomidate those applications and we can have both. But if Bitcoin's
security properties are not strong then then advanced tools cannot be
built for it. E.g. atomic swaps make trustless trades with external
systems possible; but they are especially sensitive to long
reorginizations by miners... so they can only be securely used where
those reorgs are infeasable. So while I agree that we must be willing
to tolerate not catching every conceivable use case; most of the time
all that means is addressing them via a less direct but more focused
solution rather than ignoring them completely.

📅 Original date posted:2015-07-20 📝 Original message:On ...

2023-06-07T17:42:40+02:00

In reply to nevent1q…dhqh
_________________________

📅 Original date posted:2015-07-20
📝 Original message:On Mon, Jul 20, 2015 at 7:10 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Mitigate a potential CPU exhaustion denial-of-service attack by limiting
> the maximum size of a transaction included in a block.

This seems like a fairly indirect approach. The resource being watched
for is not the size (otherwise two transactions for 200k would be
strictly worse than one 200k transactions) but the potential of N^2
costs related to repeated hashing in checksig; which this ignores.

The cost of the indirection is forclosing future applications which
involve larger signatures but have no quadratic component and are thus
fast to verify-- or requring yet another hard fork to remove the
limit, or a kludgy soft fork that splits the same data across two
"transactions" which get processed as a unit... all would be
unfortunate.

Alternative 1 sounds more attractive to be for this reason as it's more direct.

📅 Original date posted:2015-06-18 📝 Original message:On ...

2023-06-07T17:38:40+02:00

In reply to nevent1q…5vjr
_________________________

📅 Original date posted:2015-06-18
📝 Original message:On Thu, Jun 18, 2015 at 7:24 PM, Matt Corallo <bitcoin-list at bluematt.me> wrote:
> Ive been trying to stay out of these increasingly useless shit-throwing contests, but I wanted to take objection to this... I highly, highly doubt any seriously technical person is making any kind of decision on block size issues based on their own personal network. If you're assuming this is a serious motivating factor for anyone, then I'm not sure you've even been reading your email or listening to the conversations you've had with people over the last year or more.

It's probably due to me: When I point to trends and broadband
_distribution_ in the US (much less the less developed parts of the
world), I'm being "hypothetical", and when I point to my _own_
connectivity as a concrete example it's "personal". It's no joke that
communication is _hard_ but it's a shared responsibility however, and
no need to assume anyone isn't reading.,

📅 Original date posted:2015-05-08 📝 Original message:On ...

2023-06-07T17:34:19+02:00

In reply to nevent1q…xtkz
_________________________

📅 Original date posted:2015-05-08
📝 Original message:On Sat, May 9, 2015 at 12:00 AM, Damian Gomez <dgomez1092 at gmail.com> wrote:
>
> ...of the following:
>
> the DH_GENERATION would in effect calculate the reponses for a total
> overage of the public component, by addding a ternary option in the actual
> DH key (which I have attached to sse if you can iunderstand my logic)
[snip code]

Intriguing; and certainly a change of the normal pace around here.

> where w represents the weight of the total number of semantical
> constraints that an idivdual has expressed throught emotivoe packets that I
> am working on (implementation os difficutlt). I think this is the
> appropriate route to implemeting a greating block size that will be used in
> preventing interception of bundled informations and replace value. Client
> side implmentation will cut down transaction fees for the additional 264 bit
> implementation and greatly reduce need for ewallet providers to do so.

In these posts I am reminded of and sense some qualitative
similarities with a 2012 proposal by Mr. NASDAQEnema of Bitcointalk
with respect to multigenerational token architectures. In particula,r
your AES ModuleK Hashcodes (especially in light of Winternitz
compression) may constitute an L_2 norm attractor similar to the
motherbase birthpoint metric presented in that prior work. Rethaw and
I provided a number of points for consideration which may be equally
applicable to your work:
https://bitcointalk.org/index.php?topic=57253.msg682056#msg682056

Your invocation of emotive packets suggests that you may be a
colleague of Mr. Virtuli Beatnik? While not (yet) recognized as a
star developer himself; his eloquent language and his mastery of skb
crypto-calculus and differential-kernel number-ontologies demonstrated
in his latest publication ( https://archive.org/details/EtherealVerses
) makes me think that he'd be an ideal collaborator for your work in
this area.

📅 Original date posted:2015-05-10 📝 Original message:On ...

2023-06-07T17:34:01+02:00

In reply to nevent1q…t5et
_________________________

📅 Original date posted:2015-05-10
📝 Original message:On Sun, May 10, 2015 at 9:21 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
> a while I think any algorithm that ties difficulty to block size is just a
> complicated way of dictating minimum fees.

Thats not the long term effect or the motivation-- what you're seeing
is that the subsidy gets in the way here. Consider how the procedure
behaves with subsidy being negligible compared to fees. What it
accomplishes in that case is that it incentivizes increasing the size
until the marginal "value" to miners of the transaction-data being
left out is not enormously smaller than the "value" of the data in the
block on average. Value in quotes because it's blind to the "fees"
the transaction claims.

With a large subsidy, the marginal value of the first byte in the
block is HUGE; and so that pushes up the average-- and creates the
"base fee effect" that you're looking at. It's not that anyone is
picking a fee there, it's that someone picked the subsidy there. :)
As the subsidy goes down the only thing fees are relative to is fees.

An earlier version of the proposal took subsidy out of the picture
completely by increasing it linearly with the increased difficulty;
but that creates additional complexity both to implement and to
explain to people (e.g. that the setup doesn't change the supply of
coins); ... I suppose without it that starting disadvantage parameter
(the offset that reduces the size if you're indifferent) needs to be
much smaller, unfortunately.

📅 Original date posted:2015-05-09 📝 Original message:On ...

2023-06-07T17:33:59+02:00

In reply to nevent1q…y8kd
_________________________

📅 Original date posted:2015-05-09
📝 Original message:On Fri, May 8, 2015 at 8:33 PM, Mark Friedenbach <mark at friedenbach.org> wrote:
> These rules create an incentive environment where raising the block size has
> a real cost associated with it: a more difficult hashcash target for the
> same subsidy reward. For rational miners that cost must be counter-balanced
> by additional fees provided in the larger block. This allows block size to
> increase, but only within the confines of a self-supporting fee economy.
>
> When the subsidy goes away or is reduced to an insignificant fraction of the
> block reward, this incentive structure goes away. Hopefully at that time we
> would have sufficient information to soft-fork set a hard block size
> maximum. But in the mean time, the block size limit controller constrains
> the maximum allowed block size to be within a range supported by fees on the
> network, providing an emergency relief valve that we can be assured will
> only be used at significant cost.

Though I'm a fan of this class of techniques(*) and think using something
in this space is strictly superior to not, and I think it makes larger
sizes safer long term; I do not think it adequately obviates the need
for a hard upper limit for two reasons:

(1) for software engineering and operational reasons it is very
difficult to develop, test for, or provision for something without
knowing limits. There would in fact be hard limits on real deployments
but they'd be opaque to their operators and you could easily imagine
the network forking by surprise as hosts crossed those limits.

(2) At best this approach mitigates the collective action problem between
miners around fees; it does not correct the incentive alignment between
miners and everyone else (miners can afford huge node costs because they
have income; but the full-node-using-users that need to exist in plenty
to keep miners honest do not), or the centralization pressures (N miners
can reduce their storage/bandwidth/cpu costs N fold by centralizing).

A dynamic limit can be combined with a hard upper to at least be no
worse than a hard upper with respect to those two points.

Another related point which has been tendered before but seems to have
been ignored is that changing how the size limit is computed can help
better align incentives and thus reduce risk. E.g. a major cost to the
network is the UTXO impact of transactions, but since the limit is blind
to UTXO impact a miner would gain less income if substantially factoring
UTXO impact into its fee calculations; and without fee impact users have
little reason to optimize their UTXO behavior. This can be corrected
by augmenting the "size" used for limit calculations. An example would
be tx_size = MAX( real_size >> 1, real_size + 4*utxo_created_size -
3*utxo_consumed_size). The reason for the MAX is so that a block
which cleaned a bunch of big UTXO could not break software by being
super large, the utxo_consumed basically lets you credit your fees by
cleaning the utxo set; but since you get less credit than you cost the
pressure should be downward but not hugely so. The 1/2, 4, 3 I regard
as parameters which I don't have very strong opinions on which could be
set based on observations in the network today (e.g. adjusted so that a
normal cleaning transaction can hit the minimum size). One way to think
about this is that it makes it so that every output you create "prepays"
the transaction fees needed to spend it by shifting "space" from the
current block to a future block. The fact that the prepayment is not
perfectly efficient reduces the incentive for miners to create lots of
extra outputs when they have room left in their block in order to store
space to use later [an issue that is potentially less of a concern with a
dynamic size limit]. With the right parameters there would never be such
at thing as a dust output (one which costs more to spend than its worth).

(likewise the sigops limit should be counted correctly and turned into
size augmentation (ones that get run by the txn); which would greatly
simplify selection rules: maximize income within a single scalar limit)

(*) I believe my currently favored formulation of general dynamic control
idea is that each miner expresses in their coinbase a preferred size
between some minimum (e.g. 500k) and the miner's effective-maximum;
the actual block size can be up to the effective maximum even if the
preference is lower (you're not forced to make a lower block because you
stated you wished the limit were lower). There is a computed maximum
which is the 33-rd percentile of the last 2016 coinbase preferences
minus computed_max/52 (rounding up to 1) bytes-- or 500k if thats
larger. The effective maximum is X bytes more, where X on the range
[0, computed_maximum] e.g. the miner can double the size of their
block at most. If X > 0, then the miners must also reach a target
F(x/computed_maximum) times the bits-difficulty; with F(x) = x^2+1 ---
so the maximum penalty is 2, with a quadratic shape; for a given mempool
there will be some value that maximizes expected income. (obviously all
implemented with precise fixed point arithmetic). The percentile is
intended to give the preferences of the 33% least preferring miners a
veto on increases (unless a majority chooses to soft-fork them out). The
minus-comp_max/52 provides an incentive to slowly shrink the maximum
if its too large-- x/52 would halve the size in one year if miners
were doing the lowest difficulty mining. The parameters 500k/33rd,
-computed_max/52 bytes, and f(x) I have less strong opinions about;
and would love to hear reasoned arguments for particular parameters.

📅 Original date posted:2015-05-06 📝 Original message:On ...

2023-06-07T17:33:03+02:00

In reply to nevent1q…zw33
_________________________

📅 Original date posted:2015-05-06
📝 Original message:On Wed, May 6, 2015 at 10:12 PM, Matt Corallo <bitcoin-list at bluematt.me>
wrote: > Recently there has been a flurry of posts by Gavin at >
http://gavinandresen.svbtle.com/ which advocate strongly for increasing >
the maximum block size. However, there hasnt been any discussion on this >
mailing list in several years as far as I can tell.

Thanks Matt; I was actually really confused by this sudden push with
not a word here or on Github--so much so that I responded on Reddit to
people pointing to commits in Gavin's personal repository saying they
were reading too much into it.

So please forgive me for the more than typical disorganization in this
message; I've been caught a bit flatfooted on this and I'm trying to
catch up. I'm juggling a fair amount of sudden pressure in my mailbox,
and trying to navigate complex discussions in about eight different
forums concurrently.

There have been about a kazillion pages of discussion elsewhere
(e.g. public IRC and Bitcointalk; private discussions in the past),
not all of which is well known, and I can't hope to summarize even a
tiny fraction of it in a single message-- but that's no reason to not
start on it.

> Block size is a question to which there is no answer, but which >
certainly has a LOT of technical tradeoffs to consider.

There are several orthogonal angles from which block size is a concern
(both increases and non-increases). Most of them have subtle implications
and each are worth its own research paper or six, so it can be difficult
to only touch them slightly without creating a gish gallop that is hard
to respond to.

We're talking about tuning one of the fundamental scarcities of the
Bitcoin Economy and cryptosystem--leaving the comfort of "rule by
math" and venturing into the space of political decisions; elsewhere
you'd expect to see really in-depth neutral analysis of the risks and
tradeoffs, technically and economically. And make no mistake: there
are real tradeoffs here, though we don't know their exact contours.

Fundamentally this question exposes ideological differences between people
interested in Bitcoin. Is Bitcoin more of a digital gold or is it more
of a competitor to Square? Is Bitcoin something that should improve
personal and commercial autonomy from central banks? From commercial
banks? Or from just the existing status-quo commercial banks? What are
people's fundamental rights with Bitcoin? Do participants have a
right to mine? How much control should third parties have over their
transactions? How much security must be provided? Is there a deadline
for world domination or bust? Is Bitcoin only for the developed world?
Must it be totally limited by the most impoverished parts of the world?

Bitcoin exists at the intersection of many somewhat overlapping belief
systems--and people of many views can find that Bitcoin meets their
needs even when they don't completely agree politically. When Bitcoin
is changed fundamentally, via a hard fork, to have different properties,
the change can create winners or losers (if nothing else, then in terms
of the kind of ideology supported by it).

There are non-trivial number of people who hold extremes on any of
these general belief patterns; Even among the core developers there is
not a consensus on Bitcoin's optimal role in society and the commercial
marketplace.

To make it clear how broad the views go, even without getting into
monetary policy... some people even argue that Bitcoin should act
as censor-resistant storage system for outlawed content; -- I think
this view is unsound, not achievable with the technology, and largely
incompatible with Bitcoin's use as a money (because it potentially
creates an externalized legal/harassment liability for node operators);
but these are my personal value judgments; the view is earnestly held
by more than a few; and that's a group that certainly wants the largest
possible blocksizes (though even then that won't be enough).

The subject is complicated even more purely on the technical side
by the fact that Bitcoin has a layered security model which is not
completely defined or understood: Bitcoin is secure if a majority of
hashrate is "honest" (where "honesty" is a technical term which means
"follows the right rules" without fail, even at a loss), but why might
it be honest? That sends us into complex economic and social arguments,
and the security thresholds start becoming worse when we assume some
miners are economically rational instead of "honest".

> increase in the near future. Long-term incentive compatibility requires
> that there be some fee pressure, and that blocks be relatively >
consistently full or very nearly full. What we see today are

To elaborate, in my view there is a at least a two fold concern on this
particular ("Long term Mining incentives") front:

One is that the long-held argument is that security of the Bitcoin system
in the long term depends on fee income funding autonomous, anonymous,
decentralized miners profitably applying enough hash-power to make
reorganizations infeasible.

For fees to achieve this purpose, there seemingly must be an effective
scarcity of capacity. The fact that verifying and transmitting
transactions has a cost isn't enough, because all the funds go to pay
that cost and none to the POW "artificial" cost; e.g., if verification
costs 1 then the market price for fees should converge to 1, and POW
cost will converge towards zero because they adapt to whatever is
being applied. Moreover, the transmission and verification costs can
be perfectly amortized by using large centralized pools (and efficient
differential block transmission like the "O(1)" idea) as you can verify
one time instead of N times, so to the extent that verification/bandwidth
is a non-negligible cost to miners at all, it's a strong pressure to
centralize. You can understand this intuitively: think for example of
carbon credit cap-and-trade: the trade part doesn't work without an
actual cap; if everyone was born with a 1000 petaton carbon balance,
the market price for credits would be zero and the program couldn't hope
to share behavior. In the case of mining, we're trying to optimize the
social good of POW security. (But the analogy applies in other ways too:
increases to the chain side are largely an externality; miners enjoy the
benefits, everyone else takes the costs--either in reduced security or
higher node operating else.)

This area has been subject to a small amount of academic research
(e.g. http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2400519). But
there is still much that is unclear.

The second is that when subsidy has fallen well below fees, the incentive
to move the blockchain forward goes away. An optimal rational miner
would be best off forking off the current best block in order to capture
its fees, rather than moving the blockchain forward, until they hit
the maximum. That's where the "backlog" comment comes from, since when
there is a sufficient backlog it's better to go forward. I'm not aware
of specific research into this subquestion; it's somewhat fuzzy because
of uncertainty about the security model. If we try to say that Bitcoin
should work even in the face of most miners being profit-maximizing
instead of altruistically-honest, we must assume the chain will not
more forward so long as a block isn't full. In reality there is more
altruism than zero; there are public pressures; there is laziness, etc.

One potential argument is that maybe miners would be _regulated_ to
behave correctly. But this would require undermining the openness of the
system--where anyone can mine anonymously--in order to enforce behavior,
and that same enforcement mechanism would leave a political level to
impose additional rules that violate the extra properties of the system.

So far the mining ecosystem has become incredibly centralized over time.
I believe I am the only remaining committer who mines, and only a few
of the regular contributors to Bitcoin Core do. Many participants
have never mined or only did back in 2010/2011... we've basically
ignored the mining ecosystem, and this has had devastating effects,
causing a latent undermining of the security model: hacking a dozen or
so computers--operated under totally unknown and probably not strong
security policies--could compromise the network at least at the tip...
Rightfully we should be regarding this an an emergency, and probably
should have been have since 2011. This doesn't bode well for our ability
to respond if a larger blocksize goes poorly. In kicking the can with
the trivial change to just bump the size, are we making an implicit
decision to go down a path that has a conclusion we don't want?

(There are also shorter term mining incentives concerns; which Peter
Todd has written more about, that I'll omit for now)

> pretending these systems scale. Thus, instead of working on technologies
> which bring Bitcoin's trustlessness to systems which scale beyond a

I made a few relevant points back in 2011
(https://en.bitcoin.it/w/index.php?title=Scalability&action=historysubmit&diff=14273&oldid=14112)
after Dan Kaminsky argued that Bitcoin's decentralization was pretext:
that it was patently centralized since scaling directly in the network
would undermine decentralization, that the Bitcoin network necessarily
makes particular tradeoffs which prevent it from concurrently being all
things to all people. But tools like the Lightning network proposal could
well allow us to hit a greater spectrum of demands at once--including
secure zero-confirmation (something that larger blocksizes reduce if
anything), which is important for many applications. With the right
technology I believe we can have our cake and eat it too, but there needs
to be a reason to build it; the security and decentralization level of
Bitcoin imposes a _hard_ upper limit on anything that can be based on it.

Another key point here is that the small bumps in blocksize which
wouldn't clearly knock the system into a largely centralized mode--small
constants--are small enough that they don't quantitatively change the
operation of the system; they don't open up new applications that aren't
possible today. Deathandtaxes on the forum argued that Bitcoin needs
a several hundred megabyte blocksize to directly meet the worldwide
transaction needs _without retail_... Why without retail? Retail needs
near instant soft security, which cannot be achieved directly with a
global decentralized blockchain.

I don't think 1MB is magic; it always exists relative to widely-deployed
technology, sociology, and economics. But these factors aren't a simple
function; the procedure I'd prefer would be something like this: if there
is a standing backlog, we-the-community of users look to indicators to
gauge if the network is losing decentralization and then double the
hard limit with proper controls to allow smooth adjustment without
fees going to zero (see the past proposals for automatic block size
controls that let miners increase up to a hard maximum over the median
if they mine at quadratically harder difficulty), and we don't increase
if it appears it would be at a substantial increase in centralization
risk. Hardfork changes should only be made if they're almost completely
uncontroversial--where virtually everyone can look at the available data
and say "yea, that isn't undermining my property rights or future use
of Bitcoin; it's no big deal". Unfortunately, every indicator I can
think of except fee totals has been going in the wrong direction almost
monotonically along with the blockchain size increase since 2012 when
we started hitting full blocks and responded by increasing the default
soft target. This is frustrating; from a clean slate analysis of network
health I think my conclusion would be to _decrease_ the limit below the
current 300k/txn/day level.

This is obviously not acceptable, so instead many people--myself
included--have been working feverishly hard behind the scenes on Bitcoin
Core to increase the scalability. This work isn't small-potatoes
boring software engineering stuff; I mean even my personal contributions
include things like inventing a wholly new generic algebraic optimization
applicable to all EC signature schemes that increases performance by 4%,
and that is before getting into the R&D stuff that hasn't really borne
fruit yet, like fraud proofs. Today Bitcoin Core is easily >100 times
faster to synchronize and relay than when I first got involved on the
same hardware, but these improvements have been swallowed by the growth.
The ironic thing is that our frantic efforts to keep ahead and not
lose decentralization have both not been enough (by the best measures,
full node usage is the lowest its been since 2011 even though the user
base is huge now) and yet also so much that people could seriously talk
about increasing the block size to something gigantic like 20MB. This
sounds less reasonable when you realize that even at 1MB we'd likely
have a smoking hole in the ground if not for existing enormous efforts
to make scaling not come at a loss of decentralization.

I'm curious as to what discussions people have seen; e.g., are people
even here aware of these concerns? Are you aware of things like the
hashcash mediated dynamic blocksize limiting? About proposals like
lightning network (instant transactions and massive scale, in exchange
for some short term DOS risk if a counterparty opts out)? Do people
(other than Mike Hearn; I guess) think a future where everyone depends
on a small number of "Google scale" node operations for the system is
actually okay? (I think not, and if so we're never going to agree--but
it can be helpful to understand when a disagreement is ideological).