Mike Hearn [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-06-14 to 2015-10-28
💬 Posted a total of 981 messages
📚 Participated in the following categories: Bitcoin-development, PULL, ANNOUNCE, RFC, BIP 15, bitcoin-list, ANN, BIP proposal, BIP draft, Libbitcoin, bitcoin-dev, Was: Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd

Profile Code

nprofile1qqs09j2a7dmx2chrh94hngp9fzqut85x88ernpuyd9su742p9fmldusprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskuequup97x

Publishing to

relay.noswhere.com

relay.nostr.band

Author Public Key

npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd

Show more details

Last Notes

2023-06-07 17:43:48

- reply

📅 Original date posted:2015-10-28
📝 Original message:This post by Gavin got rejected by the moderators.
Without a doubt this moderation policy is already a disaster. I'm fully
expecting this message to get rejected too, but so you can see it Rusty: so
far in the reject bin there are messages from:
- Well known uber-troll Gavin Andresen
- And his partner in crime, Sergio Damian Lerner
- Someone discussing a bug
- Someone who wants to discuss CLTV
- Someone pointing out that censorship of technical discussion is rarely
a good idea
- Someone pointing out that censorship of people complaining about
censorship is also taking place.
WTF?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151028/254d91ec/attachment.html>

2023-06-07 17:43:47

- reply

📅 Original date posted:2015-10-23
📝 Original message:>
> - Posts must concern the near-term development of the bitcoin core
> code or bitcoin protocol.
>
Are block size discussions considered acceptable, then?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151023/8d456d44/attachment.html>

2023-06-07 17:43:20

- reply

📅 Original date posted:2015-10-20
📝 Original message:OK, then running under Valgrind whilst sending gbt RPCs would be the next
step.
On Mon, Oct 19, 2015 at 9:17 PM, Multipool Admin <admin at multipool.us> wrote:
> My nodes are continuously running getblocktemplate and getinfo, and I also
> suspected the issue is in either gbt or the rpc server.
>
> The instance only takes a few hours to get up to that memory usage.
> On Oct 18, 2015 8:59 AM, "Jonathan Toomim via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Oct 14, 2015, at 2:39 AM, Wladimir J. van der Laan <laanwj at gmail.com>
>> wrote:
>>
>> This is *most likely* the mempool, but is just not reported correctly.
>>
>>
>> I did some testing with PR #6410's better mempool reporting. The improved
>> reporting suggests that actual in-memory usage ("usage":) by CTxMemPool is
>> about 2.5x to 3x higher than the serialized transaction sizes ("bytes":).
>> The excess memory usage that I'm seeing is on the order of 100x higher than
>> the mempool "bytes": value. As such, I think it's unlikely that this is the
>> mempool, or at least not normal/correct mempool behavior.
>>
>> Another user (admin at multipool.us) reported 35 GB of RSS usage. I'm
>> guessing his bitcoind has been running longer than any of mine. His server
>> definitely has more RAM. I don't know which email list he is subscribed to
>> (probably XT), so I'm sharing it with both lists to make sure you're all
>> aware of how big an issue this can be.
>>
>> In the meantime you can mitigate the mempool growth by setting
>> `-mintxfee`, see
>>
>> https://github.com/bitcoin/bitcoin/blob/v0.11.0/doc/release-notes.md#transaction-flooding
>>
>>
>> I have mintxfee and minrelaytxfee set to about 0.00003, which is high
>> enough to exclude essentially all of the of the 14700-14800 byte flood
>> transactions. My nodes' mempools only contain about one or two blocks'
>> worth of transactions. So I don't think this is correct either.
>>
>>
>>
>> Some additional notes on this issue:
>>
>> 1. I think it's related to CreateNewBlock() and getblocktemplate. I ran a
>> Core bitcoind process (commit d78a880) overnight with no mining connected
>> to it, and (IIRC -- my memory is fuzzy) when I woke up it was using around
>> 400 MB of RSS and the mempool was at around "bytes":10MB, "usage": 25MB. I
>> ran ./bitcoin-cli getblocktemplate once, and IIRC the RSS shot up to around
>> 800 MB. I then ran getblocktemplate every 5 seconds for about 30 minutes,
>> and RSS climbed to 1180 MB. An hour after that with more getblocktemplates,
>> and now RSS is at 1350 MB. [Edit: 1490 MB about 30 minutes later.]
>> getmempoolinfo is still showing "usage" around 25MB or less.
>>
>> I'll do some more testing with this and see if I can make it repeatable,
>> and record the results more carefully. Expect a follow-up from me in a day
>> or two.
>>
>> 2. valgrind did not show anything super promising. It did report this:
>>
>> ==6880== LEAK SUMMARY:
>> ==6880== definitely lost: 0 bytes in 0 blocks
>> ==6880== indirectly lost: 0 bytes in 0 blocks
>> ==6880== possibly lost: 288 bytes in 1 blocks
>> ==6880== still reachable: 10,552 bytes in 39 blocks
>> ==6880== suppressed: 0 bytes in 0 blocks
>> (Bitcoin Core commit d78a880)
>>
>> and this:
>> ==6778== LEAK SUMMARY:
>> ==6778== definitely lost: 0 bytes in 0 blocks
>> ==6778== indirectly lost: 0 bytes in 0 blocks
>> ==6778== possibly lost: 320 bytes in 1 blocks
>> ==6778== still reachable: 10,080 bytes in 32 blocks
>> ==6778== suppressed: 0 bytes in 0 blocks
>> (Bitcoin XT commit fe446d)
>>
>> I haven't found anything in there yet that I think would produce the
>> multi-GB memory usage after running for a few days, but I could be missing
>> it. Email me if you want the full log.
>>
>> I did not try running getblocktemplate while valgrind was running. I'll
>> have to try that. I also have not let valgrind run for more than an hour.
>>
>>
>>
>> P.S.: Sorry for all the cross-post confusion and consequent flamewar
>> fallout. While it's probably too late for this thread, I'll make sure to
>> post in a manner that keeps the threads clearly separate in the future
>> (e.g. different subject lines).
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "bitcoin-xt" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoin-xt+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151020/c71ef434/attachment-0001.html>

2023-06-07 17:43:18

- reply

📅 Original date posted:2015-10-14
📝 Original message:Leaks are not the only explanation possible. Caches and fragmentation can
also give this sort of effect. Unfortunately the tools to debug this aren't
great. You could try a build with tcmalloc and use it to investigate heap
stats.
Odinn, trolling like a 3 year old will get you swiftly banned. Last warning.
On 14 Oct 2015 9:58 am, "Tom Zander" <tomz at freedommail.ch> wrote:
> On Tuesday 13 Oct 2015 14:56:08 Jonathan Toomim via bitcoin-dev wrote:
> > Does anybody have any guesses where we might be leaking memory, or what
> is
> > using the additional 2.4 GB? I've been using minrelaytxfee=0.00003 or
> > similar on my nodes. Maybe there's a leak in the minrelaytxfee code path?
> > Has anyone else seen something similar?
>
> I suggest running it in valgrind with --leak-check=full for 10 minutes.
>
> valgrind --leak-check=full src/bitcoind 2>&1 | tee out
>
> This at least will show you any memory leaks at exit.
> Naturally, the leaks you observe may just be design issues where cache can
> grow to much and when the cache is cleaned on shutdown you won't see it in
> the
> valgrind output.
>
> --
> You received this message because you are subscribed to the Google Groups
> "bitcoin-xt" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoin-xt+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151014/57de61ea/attachment.html>

2023-06-07 17:42:38

- reply

📅 Original date posted:2015-10-05
📝 Original message:Hey Sergio,
To clarify: my *single* objection is that CLTV should be a hard fork. I
haven't been raising never-ending technical objections, there's only one.
I *have* been answering all the various reasons being brought up why I'm
wrong and soft forks are awesome .... and there do seem to be a limitless
number of such emails .... but on my side it's still just a single
objection. If CLTV is a hard fork then I won't be objecting anymore, right?
CLTV deployment is clearly controversial. Many developers other than me
have noted that hard forks are cleaner, and have other desirable
properties. I'm not the only one who sees a big question mark over soft
forks.
As everyone in the Bitcoin community has been clearly told that
controversial changes to the consensus rules must not happen, it's clear
that CLTV cannot happen in its current form.
Now I'll be frank - you are quite correct that I fully expect the Core
maintainers to ignore this controversy and do CLTV as a soft fork anyway.
I'm a cynic. I don't think "everyone must agree" is workable and have said
so from the start. Faced with a choice of going back on their public
statements or having to make changes to something they clearly want, I
expect them to redefine what "real consensus" means. I hope I'm wrong, but
if I'm not ..... well, at least everyone will see what Gavin and I have
been talking about for so many months.
But I'd rather the opcode is tweaked. There's real financial risks to a
soft fork.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/ea317e9d/attachment-0001.html>

2023-06-07 17:42:10

- reply

📅 Original date posted:2015-10-02
📝 Original message:FWIW the "coining" I am referring to is here:
https://bitcointalk.org/index.php?topic=7972.msg116285#msg116285
OK, with that, here goes. Firstly some terminology. I'm going to call these
things SPV clients for "simplified payment verification". Headers-only is
kind of a mouthful and "lightweight client" is too vague, as there are
several other designs that could be described as lightweight like RPC
frontend and Stefans WebCoin API approach
At that time nobody used the term "SPV wallet" to refer to what apps like
BreadWallet or libraries like bitcoinj do. Satoshi used the term "client
only mode", Jeff was calling them "headers only client" etc. So I said, I'm
going to call them SPV wallets after the section of the whitepaper that
most precisely describes their operation.
On Thu, Oct 1, 2015 at 6:39 PM, Jeff Garzik <jgarzik at gmail.com> wrote:
> To reduce the list noise level, drama level and promote inclusion, my own
> personal preference (list admin hat: off, community member hat: on) is for
> temporal bans based on temporal circumstances. Default to
> pro-forgiveness. Also, focus on disruption of the list as a metric, rather
> than focusing on a specific personality.
>
> I do think we're at a bit of a point where we're going around in circles.
>
> Given the current reddit hubbub, a bit of a cooling off period is IMO
> advisable before taking any further action.
>
>
>
> On Thu, Oct 1, 2015 at 12:08 AM, Tao Effect via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Dear list,
>>
>> Mike has made a variety of false and damaging statements about Bitcoin,
>> of which this is but one:
>>
>> On Sep 30, 2015, at 2:01 PM, Mike Hearn via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> I coined the term SPV so I know exactly what it means, and bitcoinj
>> implements it, as does BreadWallet (the other big SPV implementation).
>>
>>
>> On his website Vinumeris.com he writes:
>>
>> Vinumeris was founded in 2014 by Mike Hearn, one of the developers of the
>> Bitcoin digital currency system.
>>
>>
>> On plan99.net there are several embedded videos that refer to him a
>> “core developer” of Bitcoin. And now it seems he is claiming to be Satoshi.
>>
>> It seems to me that Mike’s emails, false statements (like the one above
>> about coining SPV), arguments, and his attempts to steal control of Bitcoin
>> via the contentious Bitcoin XT fork, represent actions that have been
>> harming and dividing this community for several years now.
>>
>> In many communities/tribes, there exists a line that, once crossed,
>> results in the expulsion of a member from the community.
>>
>> So, two questions:
>>
>> 1. Does the Bitcoin-devs mailing list have such a line?
>> 2. If so, does the community feel that Mike Hearn has crossed it? (I
>> personally feel he has. Multiple times.)
>>
>> Thanks for your thoughts,
>> Greg Slepak
>>
>> --
>> Please do not email me anything that you are not comfortable also sharing with
>> the NSA.
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151002/00bedf3f/attachment.html>

2023-06-07 17:42:01

- reply

📅 Original date posted:2015-10-05
📝 Original message:Hi Jorge,
I'm glad we seem to be reaching agreement that hard forks aren't so bad
really and can even have advantages. It seems the remaining area of
disagreement is this rollout specifically.
> a non-upgraded full node and an upgraded full will converge on what they
> see: "the most-work valid chain" will be the same for both.
>
Indeed it will, but the point of fully verifying is to *not* converge with
the miner majority, if something goes wrong and they aren't following the
same rules as you. Defining "work" as "converge with miner majority" is
fine for SPV wallets and a correct or at least reasonable definition. But
not for fully verifying nodes, where non-convergence is an explicit design
goal! That's the only thing that stops miners awarding themselves infinite
free money!
> Are you going to produce a bip65 hardfork alternative to try to convince
> people of its advantages over bip65 (it is not clear to me how you include
> a new script operand via hardfork)?
>
No, I'm focused on the block size issue right now. I don't think there's
much point in improving the block chain protocol if most users are going to
be unable to use it. But the modification is simple, right? You just
replace this bit:
CHECKLOCKTIMEVERIFY redefines the existing NOP2 opcode
with this
CHECKLOCKTIMEVERIFY defines a new opcode (0xc0)
and that's it. The section *upgrade and testing plan* only says TBD so that
part doesn't even need to change at all, as it's not written yet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/46cc6d47/attachment.html>

2023-06-07 17:41:58

- reply

📅 Original date posted:2015-10-05
📝 Original message:Putting aside stupid arguments about who is older or who starting using the
term SPV wallet first, let me try and make a better suggestion than what's
in the BIP. How about the following:
A new flag is introduced to Core, --scriptchecks=[all,standardonly,none].
The default is all. When set to "standardonly", non-standard scripts are
not checked but others are. This is similar to the behaviour during a soft
fork. In "none" you have something a bit like SPV mode, but still
calculating the UTXO set. This flag is simple and can be implemented in a
few lines of code. Then an unused opcode is used for CLTV, so making it a
hard fork.
This has the following advantages:
- Nodes that want the pseudo-SPV behaviour of a soft fork can opt in to
it if they want it. This prioritises availability (in a sense) over
correctness.
- But otherwise, nodes will prioritise correctness by default, which is
how it should be. This isn't PHP where nonsensical code the interpreter
doesn't understand just does ...... something. This is financial software
where money is at risk. I feel very strongly about this: undefined
behaviour is fine *if you opted into getting it. *Otherwise it should be
avoided whenever possible.
- SPV wallets do the right thing by default.
- IsStandard doesn't silently become a part of the consensus rules.
- All other software gets simpler. It's not just SPV wallets. Block
explorers, for example, can just add a single line to their opcode map.
With a soft fork they have to implement the entire soft fork logic just to
figure out when an opcode transitioned from OP_NOP to CLTV and make sure
they render old scripts differently to new scripts. And they face tricky
questions - do they render an opcode as a NOP if the miner who built it was
un-upgraded, or do they calculate the flag day and change all of them after
that? It's just an explosion of complexity.
Many people by now have accepted that hard forks are simpler, conceptually
cleaner, and prioritise correctness of results over availability of
results. I think these arguments are strong.
So let me try addressing the counter-arguments one more time:
- Hard forks require everyone to upgrade and soft forks don't. I still
feel this one has never actually been explained. There is no difference to
the level of support required to trigger the change. With the suggestion
above, if someone can't or won't upgrade their full node but can no longer
verify the change, they can simply restart with -scriptchecks=standardonly
and get the soft fork behaviour. Or they can upgrade and get their old
security level back.
- Hard forks are somehow bad or immoral or can lead to "schisms". This
is just saying, if we hold a vote, the people who lose the vote might try
starting a civil war and refuse to accept the change. That's not a reason
to not hold votes.
But at any rate, they can do that with soft forks too: just decide that
any output that contains OP_CLTV doesn't make it into the UTXO set.
Eventually coins that trace back to such an output will become unusable in
the section of the economy that decided to pick a fight.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/563a298c/attachment-0001.html>

2023-06-07 17:41:58

- reply

📅 Original date posted:2015-10-05
📝 Original message:Well, let's agree to disagree on these two things:
- I define "working" for a full node as verifying everything; if a node
starts skipping bits then I'd say it's not really "working" according to
its original design goals
- Saying the pre-fork behaviour is defined and deterministic is true, but
only in the sense that reading an uninitialised variable in C is defined
and deterministic. It reads whatever happens to be at that stack position:
easily defined. For many programs, that may be the same value each time:
deterministic. Nonetheless, it's considered undefined behaviour by the C
specification and programmers that rely on it can easily create security
holes.
In the same way, I'd consider a node running a script with a NOP and
reaching the opposite conclusion from other nodes to be a case of undefined
behaviour leading to a non-fully-working node.
But these are arguments about the semantics of words. I think we both know
what each other is getting at.
On Mon, Oct 5, 2015 at 1:23 PM, Jeff Garzik <jgarzik at gmail.com> wrote:
>
> - It is true that hard forks produce a much cleaner outcome, in terms of
> well defined behavior across the entire network.
>
> - Replacing an opcode should not result in undefined behavior. The
> non-upgraded behavior is defined and deterministic.
>
> - IsStandard remains an assistant. Miners may mine non-standard
> transactions.
>
> - "Hard forks require everyone to upgrade and soft forks don't" Doesn't
> require tons of explanation: Non upgraded clients continue working on the
> network even after the rules are upgraded.
>
> All those corrections aside, I do think there has been too much hysteria
> surrounding hard forks. Hard forks, when done right, produce a much
> cleaner system for users.
>
>
>
>
>
>
>
>
> On Mon, Oct 5, 2015 at 6:59 AM, Mike Hearn via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Putting aside stupid arguments about who is older or who starting using
>> the term SPV wallet first, let me try and make a better suggestion than
>> what's in the BIP. How about the following:
>>
>> A new flag is introduced to Core, --scriptchecks=[all,standardonly,none].
>> The default is all. When set to "standardonly", non-standard scripts are
>> not checked but others are. This is similar to the behaviour during a soft
>> fork. In "none" you have something a bit like SPV mode, but still
>> calculating the UTXO set. This flag is simple and can be implemented in a
>> few lines of code. Then an unused opcode is used for CLTV, so making it a
>> hard fork.
>>
>> This has the following advantages:
>>
>> - Nodes that want the pseudo-SPV behaviour of a soft fork can opt in
>> to it if they want it. This prioritises availability (in a sense) over
>> correctness.
>>
>> - But otherwise, nodes will prioritise correctness by default, which
>> is how it should be. This isn't PHP where nonsensical code the interpreter
>> doesn't understand just does ...... something. This is financial software
>> where money is at risk. I feel very strongly about this: undefined
>> behaviour is fine *if you opted into getting it. *Otherwise it should
>> be avoided whenever possible.
>>
>> - SPV wallets do the right thing by default.
>>
>> - IsStandard doesn't silently become a part of the consensus rules.
>>
>> - All other software gets simpler. It's not just SPV wallets. Block
>> explorers, for example, can just add a single line to their opcode map.
>> With a soft fork they have to implement the entire soft fork logic just to
>> figure out when an opcode transitioned from OP_NOP to CLTV and make sure
>> they render old scripts differently to new scripts. And they face tricky
>> questions - do they render an opcode as a NOP if the miner who built it was
>> un-upgraded, or do they calculate the flag day and change all of them after
>> that? It's just an explosion of complexity.
>>
>> Many people by now have accepted that hard forks are simpler,
>> conceptually cleaner, and prioritise correctness of results over
>> availability of results. I think these arguments are strong.
>>
>> So let me try addressing the counter-arguments one more time:
>>
>> - Hard forks require everyone to upgrade and soft forks don't. I
>> still feel this one has never actually been explained. There is no
>> difference to the level of support required to trigger the change. With the
>> suggestion above, if someone can't or won't upgrade their full node but can
>> no longer verify the change, they can simply restart with
>> -scriptchecks=standardonly and get the soft fork behaviour. Or they can
>> upgrade and get their old security level back.
>>
>> - Hard forks are somehow bad or immoral or can lead to "schisms".
>> This is just saying, if we hold a vote, the people who lose the vote might
>> try starting a civil war and refuse to accept the change. That's not a
>> reason to not hold votes.
>>
>> But at any rate, they can do that with soft forks too: just decide
>> that any output that contains OP_CLTV doesn't make it into the UTXO set.
>> Eventually coins that trace back to such an output will become unusable in
>> the section of the economy that decided to pick a fight.
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/1aabb5c5/attachment.html>

2023-06-07 17:41:51

- reply

📅 Original date posted:2015-09-29
📝 Original message:There's a simple way to cut down on "noise" that doesn't involve people
shouting OFFTOPIC at each other: the maintainer needs to resolve
discussions by making decisions and saying, this is how Core does it. If
you disagree, go make/join a fork because there's no point in discussing
this any further here. People would get the picture pretty fast.
Wladimir doesn't do this. That is something he should fix. Clearly ending
debates so they don't run in circles forever is a basic management
technique.
Allowing random people to give each other red cards is merely a great way
to piss off users even further, because anyone who objects to a clearly
bone-headed decision will be told they're discussing philosophy and to go
away (this is meaningless).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150929/21ce6628/attachment.html>

2023-06-07 17:41:44

- reply

📅 Original date posted:2015-09-30
📝 Original message:>
> I think from discussion with Gavin sometime during the montreal
> scaling bitcoin workshop, XT maybe willing to make things easy and
> adapt what it's doing.
If Core ships CLTV as is, then XT will have to adopt it - such is the
nature of a consensus system.
This will not change the fact that the rollout strategy is bad and nobody
has answered my extremely basic question: *why* is it being done in this
way, given the numerous downsides?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150930/a5fc7897/attachment.html>

2023-06-07 17:41:42

- reply

📅 Original date posted:2015-09-30
📝 Original message:tl;dr Nothing I have read here has changed my mind. There is still no
consensus to deploy CLTV in this way.
> Yes, your article contained numerous factual and logical inaccuracies
> which I corrected
>
I responded to your response several times. It was not convincing, and I do
not think you corrected factual inaccuracies. I mean, you said yourself you
once used the correct terminology of forwards compatibility but stopped
only because the term "backwards compatibility" is more common. But that's
not a good reason to use a term with the opposite meaning and is certainly
not a factual correction!
> Yes, because what 101 does is not a hard-fork from the perspective of
> BitcoinJ clients. Please do not conflate BitcoinJ with all of SPV;
I coined the term SPV so I know exactly what it means, and bitcoinj
implements it, as does BreadWallet (the other big SPV implementation).
Yes, SPV wallets will follow the mining hashpower instead of doing a hard
reject for bigger blocks, because they deliberately check a subset of the
rules: block size is not and never has been one of them. Indeed it's not
even included in the protocol messages. Users have no expectation that SPV
wallets would check that, as it's never been claimed they do.
On the other hand, full nodes all claim they run scripts. Users expect that
and may be relying on it. The unstated assumption here is that the nodes
run them correctly. A soft fork breaks this assumption.
I'm going to ignore the rest of the stuff you wrote about "design decisions
to lack security" or "cheaply avoidable lack of validation". When you have
sat down and written an SPV implementation by yourself, then shipped it to
a couple of million users, you might have better insight into basic
engineering costs. Until then, I find your criticisms of code you think was
missing due to "stonewalling" and so on to be seriously lacking real world
experience.
Yes, a hypothetical full node could fork on the version bits. I would be
quite happy with the version number in the header being an enforced
consensus rule: it'd make hard forks easier to trigger. But it hasn't been
done that way, and wishing away the behaviour of existing software in the
field is no good. Luckily, for introducing a new opcode, the same effect
can be achieved by using a non-allocated opcode number.
> For many changes, including CLTV the actual soft fork change is by far
> the most natural way of implementing the change itself.
This is subjective. I'd say picking an entirely new opcode number is most
natural.
The rest of your argument boils down to "people don't have to upgrade if
they don't want to", which is addressed in the article I wrote already, and
multiple responses on this thread. Yes, they do, otherwise they aren't
getting the security level they were before.
> Could [P2SH] have been done as a hard-fork? Likely not: you would have
> prevented it.
What? This is nonsensical. P2SH was added to the full verification code
quite quickly, but it didn't matter much because nobody uses bitcoinj for
mining. The docs explicitly tell people, in fact, not to mine on top of
bitcoinj:
https://bitcoinj.github.io/full-verification
So no, bitcoinj+P2SH was irrelevant from a fork type perspective. It just
had no effect at all. This entire section of your message is completely
wrong.
The code that did take longer was for wallet support. And the reason it
came later was resource prioritisation: there were more important issues to
resolve. Like I said - write the amount of code I've written, unpaid in
your evenings and weekends, and then you can criticise bitcoinj for lacking
features.
75% is a fine activation threshold. By definition if support is at 75% then
bigger blocks is "winning", but if support fell, then the SPV wallets would
just reorg back onto the 1mb-blocks chain.
Re: demonstrated track record. They "work" only if you ignore the actual
problems that have resulted. P2SH-invalid blocks were being mined for weeks
after the flag day. That's not good no matter how you slice it: even if you
didn't hear about any fraud resulting, it is still risk that can be avoided.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150930/5774e38f/attachment.html>

2023-06-07 17:41:40

- reply

📅 Original date posted:2015-09-30
📝 Original message:>
> Exactly, all those "mini divergences" eventually disappear
>
A miner that has accepted a newly invalid transaction into its memory pool
and is trying to mine it, will keep producing invalid blocks forever until
the owner shuts it down and upgrades. This was happening for weeks after
P2SH triggered.
For instance, any miner that has modified/bypassed IsStandard() can do
this, or any miner that accepts direct transaction submission, or any miner
that runs an old node from before OP_NOPs were made non-standard.
> On the other hand, the "single divergence" in the hardfork keeps growing
> forever (unless all miners evetually upgrade.
>
Which they do, because they will eventually notice they are burning money.
Sorry Jorge, but I don't think your argument makes sense.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150930/e6e4693e/attachment.html>

2023-06-07 17:41:39

- reply

📅 Original date posted:2015-09-30
📝 Original message:>
> Field experience shows it successfully delivers new features to end users
> without a global software upgrade.
>
The global upgrade is required for all full nodes in both types. If a full
node doesn't upgrade then it no longer does what it was designed to do; if
the user is OK with that, they should just run an SPV wallet or use
blockchain.info or some other mechanism that consumes way fewer resources.
But if you want the software you installed to achieve its stated goal, you
*must* upgrade. There is no way around that.
Jorge has said soft forks always lead to network convergence. No, they
don't. You get constant mini divergences until everyone has upgraded, as
opposed to a single divergence with a hard fork (until everyone has
upgraded). The quantity of invalid blocks mined, on the other hand, is
identical in both types.
Adam has said "there is actually consensus", although I just said there
isn't. Feel free to say what you really mean here Adam - there's consensus
if you ignore people who don't agree, i.e. the concept of "developer
consensus" doesn't actually mean anything. This would contradict your prior
statements about how Bitcoin Core makes decisions, but alright ....
Finally John, I fully agree with what you wrote. Debates that never end are
bad news all round. Bitcoin Core has told the world it uses "developer
consensus" to make decisions. I don't agree that's a good way to do things,
but if Core wants to stick with it then there is no choice - as I am a
developer, and I do not agree with the change, there is no consensus and
the debate is over.
Hey, I have an idea. Maybe we should organise a conference about soft vs
hard forks. Let's have it down the road from where I live, a couple of
weeks from now. Please submit your talk titles to me so I can vet them to
ensure nobody does an offtopic talk ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150930/5e0bab14/attachment.html>

2023-06-07 17:41:38

- reply

📅 Original date posted:2015-09-30
📝 Original message:Hi Gregory,
> I'm surprised to see this response
Why? I have objected to the idea of soft forks many times. I wrote an
entire article about it in August. I also objected in April 2014, for
instance, where Pieter agreed with me that soft forks can result in ugly
hacks, and that they are "not nice philosophically because they reduce the
security model of former full nodes to SPV without their knowledge" (he
thought they were worth it anyway).
This is not a new debate. If you're surprised, it means only you weren't
paying attention to all the previous times people raised this issue.
> Have I missed a proposal to change BIP101 to be a real hardfork
There's no such thing as a "real" hard fork - don't try and move the goal
posts. SPV clients do not need any changes to do the right thing with BIP
101, they will follow the new chain automatically, so it needs no changes.
Several people have asked several times now: given the very real and widely
acknowledged downsides that come with a soft fork, *what* is the specific
benefit to end users of doing them?
Until that question is answered to my satisfaction I continue to object to
this BIP on the grounds that the deployment creates financial risk
unnecessarily. To repeat: *CLTV does not have consensus at the moment*.
BTW, in the April 2014 thread Pieter's argument was that hard forks are
more risky, which is at least an answer to my question. But he didn't
explain why he thought that. I disagree: the risk level seems lower with a
hard fork because it doesn't lower anyone's security level.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150930/9962a0a6/attachment-0001.html>

2023-06-07 17:41:36

- reply

📅 Original date posted:2015-09-29
📝 Original message:Hi Jorge,
Yes, there is a difference. Assuming the hashrate majority upgrades, in the
> case of a softfork [snip] ...... In the case of a hardfork [snip]
>
Yes, I know what the difference between them is at a technical level. You
didn't explain why this would make any difference to how fast miners
upgrade. The amount of money they lose in both cases is identical: they are
equally incentivised to upgrade with both fork types.
Additionally, you say in a hard fork the other chain may "continue
forever". Why do you think this is not true for miners building invalid
blocks on top of the main chain? Why would that not continue forever?
There just isn't any difference between the two fork types in terms of how
fast miners would upgrade. Heck if anything, a hard fork should promote
faster upgrades, because if a miner isn't paying attention to their
debug.log they might miss the warnings. A soft fork would then look
identical to a run of really bad luck, which can legitimately happen from
time to time. A hard fork results in your node having a different height to
everyone else, which is easily detectable by just checking a block explorer.
> This discussion about the general desirability of softforks seems offtopic
> for the concrete cltv deployment discussion, which assumes softforks as
> deployment mechanism (just like bip66 assumed it).
>
Isn't that circular? This thread is about deployment of CLTV, but the BIP
assumes a particular mechanism, so pointing out problems with it is off
topic? Why have a thread at all?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150929/09aeae3b/attachment.html>

2023-06-07 17:41:36

- reply

📅 Original date posted:2015-09-28
📝 Original message:>
> Let me try to answer this question. Softfork is beneficial to non-mining
> full nodes as they will follow the majority chain.
That is not a benefit. That is a description of what the software will do,
but not why you would want it.
In case this seems like a pedantic point, consider the consequences of
following a chain you aren't checking properly. You get SPV level security
and might calculate a corrupted ledger.
In the case of P2SH, I could make a transaction that spends someone elses
money to myself. In the case of CLTV, I could ignore the locktime
requirement.
Now yes, eventually, the miner majority will correct and uncorrupt your
ledger for you. But by then it might be too late, you may have already
acted upon the incorrect data by e.g. selling me lots of stuff that I paid
for with somebody else's coins. If you don't care about that risk, hey,
switch to an SPV wallet and save yourself a lot of disk space.
> In a hardfork, however, there is no mechanism to stop the old fork and we
> may have 2 chains co-exist for a long time.
>
There isn't any difference in how long the divergent state exists for. That
depends only on how fast people upgrade, which is unaffected by the rollout
strategy used.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/345ac195/attachment.html>

2023-06-07 17:41:35

- reply

📅 Original date posted:2015-09-28
📝 Original message:>
> Can you explain exactly how you think wallets will "know" how to ignore
> the invalid chain?
>
I'm confused - I already said this. For a fork to work, hard or soft, there
must be support from a majority of the hash power.
Therefore, the usual SPV technique of following the highest work chain
results in ignoring the minority chain produced by the hard fork.
BIP 101 is SPV friendly because the wallets would simply follow the 75%
chain and never even be aware anything has changed. It's backwards
compatible with them in this respect: they already know how to ignore the
no-bigger-blocks fork that'd be created if some miners didn't upgrade
during the grace period.
My point about IsStandard is that miners can and do bypass it, without
expecting that to carry financial consequences or lower the security of
other users. By making it so a block which includes non-standard
transactions can end up being seen as invalid, you are increasing the risk
of accidents that carry financial consequences.
That's incorrect: Miners bypassing IsStandard() risk creating invalid
> blocks in the event of a soft-fork. Equally, we design soft-forks to
> take advantage of this.
>
Gah. You repeated what I just said. Yes, I know miners face that risk, my
point is that they do NOT face such a risk when there's no soft fork in
action and have historically NOT faced that risk at all, hence the
widespread practice of bypassing or modifying this function.
All this approach does is make changing IsStandard() the same as changing
AcceptBlock(), except without the advantage of telling anyone about it.
> > So I'll repeat the question that I posed before - given that there are
> > clear, explicit downsides, what is the purpose of doing things this way?
> > Where is the gain for ordinary Bitcoin users?
>
> We seem to be in strong disagreement about which option has "clear,
> explicit downsides"
Obviously. So please enlighten me.
How do ordinary Bitcoin users benefit from this rollout strategy? Put
simply, what is the point of this whole complex soft fork endeavour?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/37024596/attachment.html>

2023-06-07 17:41:34

- reply

📅 Original date posted:2015-09-28
📝 Original message:>
> SPV wallets can't detect hard-forks
They don't have to - they pick the highest work chain. Any miner who hasn't
upgraded makes blocks on the shorter chain that are then ignored (or
rather, stored for future reorgs). After the fork point, there won't be any
blocks in the main chain that violate the rules and end up being doomed to
being orphaned, which is the underlying problem.
And I think you know this already. There is no "flaw" in bitcoinj in this
respect. It works exactly as it was designed to work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/10e73edb/attachment-0001.html>

2023-06-07 17:41:33

- reply

📅 Original date posted:2015-09-28
📝 Original message:>
> 1) Do you agree that CLTV should be added to the Bitcoin protocol?
>
> Ignoring the question how exactly it is added, hard-fork or soft-fork.
>
The opcode definition seems OK.
> 2) Will you add a IsSuperMajority() CLTV soft-fork to Bitcoin XT if it
> is added to Bitcoin Core?
>
Yes. It might be worth putting the version bit change behind a command line
flag though: the BIP, as written, has problems (with deployment).
> 3) Will you add soft-fork detection to bitcoinj, to allow SPV clients to
detect advertised soft-forks and correctly handle them?
>
I'd really hate to do that. It'd be a Rube Goldberg machine:
https://krypt3ia.files.wordpress.com/2011/11/rube.jpg
There's no really good way to do what you propose, and we already have a
perfectly workable mechanism to tell SPV clients about chain forks: the
block chain itself. This has the advantage of being already implemented,
already deployed, and it works correctly.
Attempting to strap a different mechanism on top to try and make soft forks
more like hard forks would be a large and pointless waste of people's time
and effort, not just mine (bitcoinj is not the only widely used SPV
implementation nowadays). You may as well go straight to the correct
outcome instead of trying to simulate it with ever more complex mechanisms.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/2f74bd22/attachment.html>

2023-06-07 17:41:30

- reply

📅 Original date posted:2015-09-28
📝 Original message:>
> 2. As for SPV wallets need to handle awareness of the new blocks.
>
There is simply no need for any wallets to change. Making the spec a hard
fork instead of a soft fork means all existing software does the right
thing automatically.
To repeat, please bear in mind that bitcoinj is no longer the only SPV
wallet implementation. BreadWallet has its own code in Objective-C and is
the second most popular SPV implementation (and growing). Additionally,
bitcoinj is incorporated into lots of apps that'd have to have new versions
released, some of which don't have any way to force a user to update.
So it's not just my time you'd waste: it's lots of different people's.
One thing I haven't seen yet is the justification for why a soft fork
should be used here. There's no requirement that it be so, and there are
real downsides. As Eric said, the fact that the mechanism has issues is not
under dispute.
The normal justification for this it's that it's forwards compatible. But
that's not a justification, that's a description.
Re: XT, I already addressed this above.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/be6a8d45/attachment.html>

2023-06-07 17:41:29

- reply

📅 Original date posted:2015-09-28
📝 Original message:>
> we have NO hard fork mechanism in place that isn't highly prone to
> systemic consensus failure.
>
Just use an opcode that isn't currently defined. Done. What about that
mechanism is prone to failure?
Re: coma. No need for insults. Please read my article and address the
points raised there, which, by the way, do not include any mention of SPV
wallets. Although your belief that SPV wallets are "inherently insecure"
seems needlessly trollish - I certainly would disagree, but it's a
different debate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/4e00a31e/attachment.html>

2023-06-07 17:41:29

- reply

📅 Original date posted:2015-09-29
📝 Original message:>
> Other than the fact that doing this as a soft fork requires an extra
> OP_DROP, how would doing this as a hard fork make any difference to SPV
> clients? If, as others have suggested, all clients warn the user on
> unrecognized nVersion
>
All clients do *not* do this. Why would they? What action would they take?
Try and simulate a hard fork in some complicated roundabout manner? Why not
just do the real thing and keep things simple?
> and make unknown noops nonstandard
>
They are already non-standard. That change was made last time I brought up
the problems with soft forks. It brought soft forks that use OP_NOPs a bit
closer to the ideal of a hard fork, but didn't go all the way. I pointed
that out above in my reply to Peter's mail.
So to answer your question, no, it wouldn't satisfy my concerns. My logic
is this:
Hard forks - simple, well understood, SPV friendly, old full nodes do not
calculate incorrect ledgers whilst telling their users (via UI, RPC) that
they are fully synced. Emphasis on simple: simple is good.
Soft forks - to get the benefits of a hard fork back requires lots of extra
code, silently makes IsStandard() effectively a part of the consensus rules
when in the past it hasn't been, SPV unfriendly. Benefits? As far as I can
tell, there are none.
If someone could elucidate *what* the benefits actually are, that would be
a good next step. So far everyone who tried to answer this question gave a
circular answer of the form "soft forks are good because they are soft
forks".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150929/6cc51d05/attachment.html>

2023-06-07 17:41:28

- reply

📅 Original date posted:2015-09-28
📝 Original message:>
> Go ahead and object to soft forks...but at least try not to make arguments
> based on changing the definitions of terms we all generally agree upon.
>
I don't intend to do that, and I don't think I am - I know what the
difference between a soft and hard fork is and am not trying to confuse or
blur the two.
To reiterate: this current BIP implements a soft fork. I am not debating
that. I am saying it should use a hard fork instead. This will ensure no
repeat of the P2SH case where invalid blocks were being found for weeks (or
was it months?) after the new rules kicked in, thus exposing SPV wallets
and old nodes to unnecessary risk for no benefit.
Additionally, I am making it clear that there's no consensus for rolling
out the new opcode in this way. As you say, the mechanism has issues. If
you read the comments when I wrote my article, you can see that others
share the same concerns:
https://www.reddit.com/r/Bitcoin/comments/3griiv/on_consensus_and_forks_by_mike_hearn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/a7bdf845/attachment-0001.html>

2023-06-07 17:41:28

- reply

📅 Original date posted:2015-09-28
📝 Original message:>
> The rationale for soft vs hard-forks is well known, so I wont go over them.
>
The rationale of "backwards compatibility" is well known, yet wrong. I've
gone over the arguments here and explained why the concept makes no sense:
https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7
Eric - no, it's not sophisticated humour. I've been objecting to soft forks
since this idea first appeared.
There is no consensus. Now pick. Lose the requirement that everyone agree
for consensus changes, and tell people you've done it. Change the spec. Or
do nothing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/5dae3282/attachment.html>

2023-06-07 17:41:27

- reply

📅 Original date posted:2015-09-28
📝 Original message:There is *no* consensus on using a soft fork to deploy this feature. It
will result in the same problems as all the other soft forks - SPV wallets
will become less reliable during the rollout period. I am against that, as
it's entirely avoidable.
Make it a hard fork and my objection will be dropped.
Until then, as there is no consensus, you need to do one of two things:
1) Drop the "everyone must agree to make changes" idea that people here
like to peddle, and do it loudly, so everyone in the community is correctly
informed
2) Do nothing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/2ef01e42/attachment-0001.html>

2023-06-07 17:40:33

- reply

📅 Original date posted:2015-09-20
📝 Original message:>
> Also, in the US, despite overwhelming resistance on a broad scale,
> legislation continues to be presented which would violate the 2nd amendment
> right to keep and bear arms.
And yet the proposed legislation goes nowhere, and the USA continues to
stand alone in having the first world's weakest gun control laws.
You are just supporting my point with this example. Obama would like to
restrict guns, but can't, because they are too popular (in the USA).
The comparison to BitTorrent is likewise weak: governments hardly care
about piracy. They care enough to pass laws occasionally, but not enough to
put serious effort into enforcement. Wake me up when the USA establishes a
Copyright Enforcement Administration with the same budget and powers as the
DEA.
Internet based black markets exist only because governments tolerate them
(for now). A ban on Tor, Bitcoin or both would send them back to the
pre-2011 state where they were virtually non-existent. Governments tolerate
this sort of abuse only because they believe, I think correctly, that
Bitcoin can have great benefits for their ordinary voters and for now are
willing to let the tech industry experiment.
But for that state of affairs to continue, the benefits must actually
appear. That requires growth.
I think there's a difference between natural growth and the kind of growth
> that's being proposed by bank-backed start-ups and pro-censorship entities.
>
What difference? Are you saying the people who come to Bitcoin because of a
startup are somehow less "natural" than other users?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150920/52eca066/attachment.html>

2023-06-07 17:40:31

- reply

📅 Original date posted:2015-09-19
📝 Original message:>
> Your argument is that the state is not a threat to a system designed to
> deprive the state of seigniorage, because the state will see that system
> as too important?
>
And so we get to one of the hearts of the debate.
The axiom upon which you and NxtChg disagree is this: he/she believes
governments can crush Bitcoin if they want regardless of how decentralised
it is, and you don't.
If one believes governments have the power to end Bitcoin no matter what,
then the only true protection comes from popularity. Governments find it
hard to ban things that are wildly popular with their voters. This is the
Uber approach: grow fast, annoy governments, but be popular enough that
banning you is politically risky.
If you don't believe that governments can end Bitcoin because of
decentralisation, then the opposite conclusion is logical: growth can be
dangerous because stateless money will be inherently opposed by the state,
therefore if growth == less decentralisation, growth increases the risk of
state shutdown.
I don't think we have to choose between decentralisation and growth
actually - computers are just amazingly fast. But that's irrelevant here.
The point is, your disagreement is summed up by your statement:
> Bitcoin cannot be both decentralized and reliant on being, "too important
> to close". If it can be closed there is insufficient decentralization.
>
I believe this statement is wrong because governments can shut down Bitcoin
at any point regardless of its level of decentralisation. This is true
because:
- Most governments can easily spend enough money to do a 51% attack,
especially if they can compel chip fabs to cooperate for free. This attack
works regardless of how decentralised Bitcoin is.
- Any government can end Bitcoin usage in its territory by jailing
anyone who advertises acceptance/trading of bitcoins, or prices in BTC.
Because merchants *must* advertise in order to alert customers that
trades in BTC are possible, this is an attack which is unsolvable. If
ordinary people can find such merchants so can government agents.
It may appear that trade cannot be suppressed because merchants can all
become anonymous too, a la Silk Road. However, if use of Bitcoin is banned
then it becomes impossible to convert coins into local currency as that
requires cooperation of banks ..... making it useless for even anonymous
merchants. An outlaw currency is useless even to outlaws.
Because Bitcoin's existence ultimately relies on government cooperation and
acceptance, the best way to ensure its survival is growth. Lots of it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150919/67222559/attachment.html>

2023-06-07 17:40:29

- reply

📅 Original date posted:2015-09-19
📝 Original message:>
> Let me get this straight. You start this whole debate with a "kick the can
> down the road" proposal to increase the block size to 20MB, which obviously
> would require another hard fork in the future, but if someone else proposes
> a similar "kicka the can" proposal you will outright reject it?
>
Which part of "in the next few years" was unclear?
This seems to be a persistent problem in the block size debates: the
assumption that there are only two numbers, zero and infinity.
BIP101 tops out at 8 gigabyte blocks, which would represent extremely high
transaction rates compared to today. *If* Bitcoin ever became so popular,
it would be a long way in the future, and many things could have happened:
1. Bitcoin may have become as irrelevant as the Commodore 64 is.
2. We may have invented upgrades that make Bitcoin 100x more efficient
than today.
3. Hardware may have improved so much that it no longer matters.
4. The world may have been devastated by nuclear war and nobody gives a
shit about internet currencies anymore, because there is no internet.
It's silly to ignore the time dimension in these decisions. Bitcoin will
not last forever: even if it becomes very successful it will one day it
will be replaced by something better, so it does not have to handle
infinite usage.
But hey, as you bring it up, I'd have been happy with no upper limit at
all. There's nothing magic about 8 gigabytes. I go along with BIP 101
because it is still the only proposal that is both reasonable and
implemented, and I'm willing to compromise.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150919/ecf4ffe4/attachment.html>

2023-06-07 17:40:19

- reply

📅 Original date posted:2015-09-18
📝 Original message:>
> What one needs for that, I think, is a library that communicate with the
> node, and which offers functionality abstractly be similar to 'git pull':
> give me the tree path from my current known tip to the best tip, and supply
> the block hashes (and block data) along the way.
>
This is exactly what SPV libraries like bitcoinj do: they know how to build
a block locator, request the blocks forward from the common branch point,
and handle re-orgs onto whatever the current best chain are by downloading
data from a full node.
If your official position is people should all use bitcoinj to do things
like build extra indexes, then great. Send them our way. It already knows
how to calculate a UTXO set indexed by address.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/af7e248f/attachment.html>

2023-06-07 17:37:38

- reply

📅 Original date posted:2015-08-24
📝 Original message:NACK: stated rationales are invalid: both privacy and DoS (see below for
experimental data).
1 - Bloom filtering doesn't add privacy for node operators, it adds privacy
for lightweight wallets. And in fact, with a high FP rate it does do that.
Most users want both low bandwidth usage *and* query scrambling, which is
harder to do but not impossible. There is a clear roadmap for how to
implement that with smarter clients: no protocol changes are needed.
So the first stated rationale is spurious: disabling Bloom filtering
doesn't improve privacy for anyone. It can only hurt.
2 - SPV usage is rising, not falling.
Peter's data is flawed because he ignored the fact that SPV clients tend to
connect, sync, then disconnect. They don't remain connected all the time.
So merely examining a random snapshot of what's connected at a single point
in time will give wildly varying and almost random results.
A more scientifically valid approach is to check the number of actual
connections over a long span of time. Here's the data from my node:
mike at plan99:~/.bitcoin$ grep -Po 'receive version message: ([^:]*):'
debug.log |sort |uniq -c|sort -n|tac|head -n 10
11027 receive version message: /getaddr.bitnodes.io:
6264 receive version message: /bitcoinseeder:
4944 receive version message: /bitcoinj:
2531 receive version message: /Snoopy:
2362 receive version message: /breadwallet:
1127 receive version message: /Satoshi:
204 receive version message: /Bitcoin XT:
128 receive version message: /BitCoinJ:
97 receive version message: /Bither1.3.8/:
82 receive version message: /Bitaps:
Once crawlers are removed, SPV wallets (bitcoinj, breadwallet) make up the
bulk of all P2P clients. This is very far from 1% and falling, as Todd
wrongly suggests.
3 - It is said that there is a DoS attack possible. This claim does not
seem to have been researched.
I decided to test it out for real, so I implemented a DoS attack similar to
the one we've seen against XT nodes: it sends getdata for large (1mb)
filtered blocks over and over again as fast as possible.
As was reported and makes sense, CPU usage goes to 100%. However I couldn't
see any other effects. RPCs still react immediately, the Qt GUI is fully
responsive, I was even able to sync another SPV client to that node and it
proceeded at full speed. It's actually pretty nice to see how well it held
up.
Most importantly transactions and blocks continued to be relayed without
delay. I saw my VPS node receive a block only eight seconds after my local
node, which is well within normal propagation delays.
There's another very important point here: I profiled my local node whilst
it was under this attack. It turns out that Bloom filtering is extremely
fast. 90% of the CPU time is spent on loading and deserializing the data
from disk. Only 10% of the CPU time was spent actually filtering.
Thus you can easily trigger exactly the same DoS attack by just using
regular getdata requests on large blocks over and over. You don't need
Bloom filtering. If you don't want to actually download the blocks just
don't TCP ACK the packets and then FIN after a few seconds .... the data
will all have been loaded and be sitting in the send buffers.
So even if I refine the attack and find a way to actually deny service to
someone, the fix would have to apply to regular non-filtered block fetches
too, which cannot be disabled.
In summary: this BIP doesn't solve anything, but does create a big upgrade
headache.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150824/ece22a74/attachment.html>

2023-06-07 17:36:48

- reply

📅 Original date posted:2015-08-19
📝 Original message:The code was peer reviewed, in the XT project. I didn't bother submitting
other revisions to Core, obviously, as it was already rejected.
The quantity of incorrect statements in this thread is quite ridiculous.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/ebb081f7/attachment.html>

2023-06-07 17:35:57

- reply

📅 Original date posted:2015-08-20
📝 Original message:>
> It is just that no one else is reckless enough to bypass the review process
I keep seeing this notion crop up.
I want to kill this idea right now:
- There were months of public discussion leading to up the authoring of
BIP 101, both on this mailing list and elsewhere.
- BIP 101 was submitted for review via the normal process. Jeff Garzik
specifically called Gavin out on Twitter and thanked him for following the
process:
https://twitter.com/jgarzik/status/614412097359708160
https://github.com/bitcoin/bips/pull/163
As you can see, other than a few minor typo fixes and a comment by sipa,
there was no other review offered.
- The implementation for BIP 101 was submitted to Bitcoin Core as a pull
request, to invoke the code review process:
https://github.com/bitcoin/bitcoin/pull/6341
Some minor code layout suggestions were made by Cory and incorporated.
Peter popped up to say there was no chance it'd ever be accepted ..... and
no further review was done.
So the entire Bitcoin Core BIP process was followed to the letter. The net
result was this. There were, in fact, bugs in the implementation of BIP
101. They were found when Gavin submitted the code to the XT community
review process, which resulted in *actual* peer review. Additionally, there
was much discussion of technical details on the XT mailing list that
Bitcoin Core entirely ignored.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/e596b9c3/attachment.html>

2023-06-07 17:35:13

- reply

📅 Original date posted:2015-08-15
📝 Original message:>
> I use bitcoin heavily (not from time to time) but I don't mine - can I
> vote? The way I see it I cannot, and I am not saying it is a bad thing,
> but I missed the argument explaining why users don't matter and only
> miners do.
>
It is a reasonable question. Let me try and explain why it's done this way.
*In theory*, you do have a vote. If a majority of miners were to club
together and decide to change the protocol against the wishes of the wider
user base, then we'd get a fight between the hashpower majority and the
so-called economic majority. And because bitcoins only have value because
you can buy things with them, in theory, the wishes of the economic
majority should always win.
*In practice*, the code we have today doesn't let us measure what the
economic majority wants. It's not even really clear how that term is
defined. Intuitively we can understand that people who are trading real
goods and services for bitcoin have the final say, because they can always
just refuse to accept BTC. But defining it precisely enough to put in an
algorithm is tricky.
Then you have the question of how to express the vote? For miners, it's
easy: they express their vote by switching to a different full node
implementation that gives them different blocks.
For users, it'd mean switching to a different wallet. If their wallet is
fully validating and the decision is implemented via hard fork, this is
sufficient. If the wallet is *not* fully validating and cannot detect the
fork point by itself, then it'd need help in the form of checkpointing.
Some months ago I pointed out this possibility and a whole bunch of people
freaked out - then bitcoin.org decided to start censoring any wallet that
said it'd ignore what miners wanted.
So if you want a user vote, that's an issue that'd have to be tackled: the
people who admin the main communication channels Bitcoin users have vowed
to censor any program that doesn't slavishly follow 51%+ hash power. That
attempt to control the conversation is certainly not libertarian or
democratic in nature, but there you go.
We can also imagine voting via proof-of-stake. This might be useful as a
form of opinion poll, but wallet developers would have to actually add
support for such a protocol to their apps, and then we're back to the same
issue as with mining pools. Plus, of course, static wealth does not equal
economic importance.
Luckily the wallet market is a decentralisation success story. There are
wallets everywhere these days. Man+dog make their own wallet, it seems. So
it's not silly to think a coin voting protocol could one day happen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150815/feb8df3a/attachment.html>

2023-06-07 17:35:12

- reply

📅 Original date posted:2015-08-15
📝 Original message:Hello,
As promised, we have released Bitcoin XT 0.11A which includes the bigger
blocks patch set. You can get it from
https://bitcoinxt.software/
I feel sad that it's come to this, but there is no other way. The Bitcoin
Core project has drifted so far from the principles myself and many others
feel are important, that a fork is the only way to fix things.
Forking is a natural thing in the open source community, Bitcoin is not the
first and won't be the last project to go through this. Often in forks,
people say there was insufficient communication. So to ensure everything is
crystal clear I've written a blog post and a kind of "manifesto" to
describe why this is happening and how XT plans to be different from Core
(assuming adoption, of course).
The article is here:
https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1
It makes no attempt to be neutral: this explains things from our point of
view.
The manifesto is on the website.
I say to all developers on this list: if you also feel that Core is no
longer serving the interests of Bitcoin users, come join us. We don't bite.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150815/ce48d631/attachment.html>

2023-06-07 17:34:41

- reply

📅 Original date posted:2015-08-11
📝 Original message:Hey Jonas,
I think your analysis of what (some) users need is a good one.
We've discussed this before so I know you prefer your current approach, but
I personally would take a slightly different path to reach the same end:
1. Support serving of SPV wallets from pruned storage. This means some
protocol upgrades, BIPs, etc. It helps all SPV wallets, including on phones.
2. Then make a bitcoinj based desktop wallet app, that contains a
bundled bitcoind.
3. Make the app sync TWO wallets simultaneously, one from the P2P
network as today, and another from the local bitcoind via a local socket
(or even just passing buffers around internally)
4. The app should then switch from using the wallet synced to P2P to the
wallet synced to localhost when the latter is fully caught up, and back
again when the local node is behind.
5. If there's a discrepancy, alert the user.
There are big advantages of taking this path! They are:
- The switching back and forth between local full-security mode (which
may be behind) and remote SPV security (fully synced) is instant and
transparent to the user. This is important for laptop users who don't run a
local node all the time. The different audit levels can be reflected in the
UI in some way.
- The bitcoinj wallet code already has support for things like
multi-sig, BIP32, seed words, micropayment channels, etc. You can disable
Bloom filtering if you like (download full blocks).
- You can do a local RPC or JNI/JNA call to get fee estimates, if wanted.
- The modern JVM tools and languages are much, much more productive than
working with C++.
If you want a thing that runs a home server, then the best way to do that
IMO would be to bundle Tor and make it auto-register a Tor hidden service.
Then you can just define a QR code standard for 'pairing' a wallet to a
.onion address. Any bitcoinj based wallet can sync to it, and as it's your
own node, you can use a Bloom filter sized to give virtually no false
positives. No additional indexing is then required.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/87594257/attachment.html>

2023-06-07 17:34:31

- reply

📅 Original date posted:2015-08-10
📝 Original message:We're not modifying BIP 70, it's now immutable and can only be extended.
There's really not much point in having a dedicated chain ID for regtest
mode. You shouldn't be finding BIP70 requests for regtest outside of your
own developer machine, where the id doesn't matter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150810/09589c36/attachment.html>

2023-06-07 17:34:29

- reply

📅 Original date posted:2015-08-09
📝 Original message:>
> I'd appreciate initial feedback on the idea, and if there's no major
> objections I'll raise this as a BIP.
>
The reason BIP 70 doesn't do this is the assumption that alt coins are ...
well .... alt. They can vary in arbitrary ways from Bitcoin, and so things
in BIP70 that work for Bitcoin may or may not work for other coins.
If your alt coin is close enough to BIP 70 that you can reuse it "as is"
then IMO we should just define a new network string for your alt. network =
"dogecoin-main" or whatever.
You could also use the genesis hash as the network name. That works too.
But it's less clear and would involve lookups to figure out what the
request is for, if you find such a request in the wild. I don't care much
either way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150809/f471377b/attachment.html>

- reply

- reply

- reply

- reply

📅 Original date posted:2015-08-16
📝 Original message:Hi Eric,
Sorry you feel that way. I devoted a big part of the article to trying to
fairly represent the top 3 arguments made, but ultimately I can't link to a
clear statement of what Bitcoin Core thinks because there isn't one. Some
people think the block size should increase, but not now, or not by much.
Others think it should stay at 1mb forever, others think everyone should
migrate to Lightning, people who are actually *implementing* Lightning
think it's not a replacement for an increase ..... I think one or two
people even suggested shrinking the block size!
So I've done my best to sum up the top arguments. If you think I've done a
bad job, well, get writing and lay it out how you see it!
I don't think the position of "Bitcoin is open source but touching THESE
parts is completely bogus" is reasonable. Bitcoin is open source or it
isn't. You can't claim to be decentralised and open source, but then only
have 5 people who are allowed to edit the most important parts. That's
actually worse than central banking!
This isn’t a democracy - consensus is all or nothing.
>
This idea is one of the incorrect beliefs that will hopefully be disproven
in the coming months. Bitcoin cannot possibly be "all or nothing" because
as I pointed out before, that would give people a strong financial
incentive to try and hold the entire community to ransom: "I have 1
terahash/sec of mining power. Pay me 1000 BTC or I'll never agree to the
next upgrade".
Or indeed, me and Gavin could play the same trick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150816/1201647f/attachment.html>

- reply

- reply

- reply

- reply

📅 Original date posted:2015-07-31
📝 Original message:Hey Jorge,
He is not saying that. Whatever the reasons for centralization are, it
> is obvious that increasing the size won't help.
>
It's not obvious. Quite possibly bigger blocks == more users == more nodes
and more miners.
To repeat: it's not obvious to me at all that everything wrong with Bitcoin
can be solved by shrinking blocks. I don't think that's going to suddenly
make everything magically more decentralised.
The 8mb cap isn't quite arbitrary. It was picked through negotiation with
different stakeholders, in particular, Chinese miners. But it should be
high enough to ensure organic growth is not constrained, which is good
enough.
I think it would be nice to have some sort of simulation to calculate
> a "centralization heuristic" for different possible blocksize values
> so we can compare these arbitrary numbers somehow.
Centralization is not a single floating point value that is controlled by
block size. It's a multi-faceted and complex problem. You cannot "destroy
Bitcoin through centralization" by adjusting a single constant in the
source code.
To say once more: block size won't make much difference to how many
merchants rely on payment processors because they aren't using them due to
block processing overheads anyway. So trying to calculate such a formula
won't work. Ditto for end users on phones, ditto for developers who want
JSON/REST access to an indexed block chain, or hosted wallet services, or
miners who want to reduce variance.
None of these factors have anything to do with traffic levels.
What people like you are Pieter are doing is making a single number a kind
of proxy for all fears and concerns about the trend towards outsourcing in
the Bitcoin community. Everything gets compressed down to one number you
feel you can control, whether it is relevant or not.
> So why should anyone go through the massive hassle of setting up
> exchanges,
> > without the lure of large future profits?
>
> Are you suggesting that bitcoin consensus rules should be designed
> to maximize the profits of Bitcoin exchanges?
>
That isn't what I said at all Jorge. Let me try again.
Setting up an exchange is a lot of risky and expensive work. The motivation
is profit, and profits are higher when there are more users to sell to.
This is business 101.
If you remove the potential for future profit, you remove the motivation to
create the services that we now enjoy and take for granted. Because if you
think Bitcoin can be useful without exchanges then let me tell you, I was
around when there were none. Bitcoin was useless.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150731/ec8dafa6/attachment.html>

2023-06-07 15:43:52

- reply

📅 Original date posted:2015-07-29
📝 Original message:>
> It was _well_ .... 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.
>
No it wasn't. That is something you invented yourself much later. "Small
devices" isn't even defined anywhere, so there can't have been any such
understanding.
The actual understanding was the opposite. Satoshi's words:
"At first, most users would run network nodes, but as the network grows
beyond a certain point, it would be left more and more to specialists with
server farms of specialized hardware."
That is from 2008:
http://satoshi.nakamotoinstitute.org/emails/cryptography/2/#selection-75.16-83.14
Then he went on to talk about Moore's law and streaming HD videos and the
like. At no point did he ever talk about limiting the system for "small
devices".
I have been both working on and using Bitcoin for longer than you have been
around, Gregory. Please don't attempt to bullshit me about what the plan
was. And stop obscuring what this is about. It's not some personality cult
- the reason I keep beating you over the head with Satoshi's words is
because it's that founding vision of the project that brought everyone
together, and gave us all a shared goal.
If Satoshi had said from the start,
"Bitcoin cannot ever scale. So I intend it to be heavily limited and
used only by a handful of people for rare transactions. I picked 1mb as an
arbitrary limit to ensure it never gets popular."
... then I'd have not bothered getting involved. I'd have said, huh, I
don't really feel like putting effort into a system that is intended to NOT
be popular. And so would many other people.
Don't think you can claim otherwise, because doing so is flat out wrong.
>
I just did claim otherwise and no, I am not wrong at all.
(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:
>
Since when have we "campaigned" to "ignore problems" in the mining
ecosystem? What does that even mean? Was it not I who wrote this blog post?
http://blog.bitcoinfoundation.org/mining-decentralisation-the-low-hanging-fruit/
Gregory, you are getting really crazy now. Stop it. The trend towards
mining centralisation is not the fault of Gavin or myself, or anyone else.
And SPV is exactly what was always intended to be used. It's not something
I "fixated" on, it's right there in the white paper. Satoshi even
encouraged me to keep working on bitcoinj before he left!
Look, it's clear you have decided that the way Bitcoin was meant to evolve
isn't to your personal liking. That's fine. Go make an alt coin where your
founding documents state that it's intended to always run on a 2015
Raspberry Pi, or whatever it is you mean by "small device". Remove SPV
capability from the protocol so everyone has to fully validate. Make sure
that's the understanding that everyone has from day one about what your alt
coin is for. Then when someone says, gee, it'd be nice if we had some more
capacity, you or someone else can go point at the announcement emails and
say "no, GregCoin is meant to always be verifiable on small devices, that's
our social contract and it's written into the consensus rules for that
reason".
But your attempt to convert Bitcoin into that altcoin by exploiting a
temporary hack is desperate, and deeply upsetting to many people. Not many
quit their jobs and created companies to build products only for today's
tiny user base.
My list of "things a full node is useful for" wasn't ordered by importance,
by the way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150729/dc517511/attachment-0001.html>

2023-06-07 15:43:44

- reply

📅 Original date posted:2015-07-29
📝 Original message:>
> Irrelevant what term was used - and as brilliant as Satoshi might have
> been at some things, he obviously got this one wrong.
>
I don't think it's obvious. You may disagree, but don't pretend any of this
stuff is obvious.
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.
And now consider that in many parts of the world bank transfers are free.
They aren't actually free, of course, but they *appear* to be free because
the infrastructure for doing them is cross subsidised by the fees on other
products and services, or hidden in the prices of goods sold.
So that's a market reality Bitcoin has to handle. It's already more
expensive than the competition sometimes, but luckily not much more, and
anyway Bitcoin has some features those other systems lack (and vice versa).
So it can still be competitive.
But your extremely vague notion of a "fee market" neglects to consider that
it already exists, and it's not a market of "Bitcoin users buying space in
Bitcoin blocks". It's "users paying to move money".
You can argue with this sort of economic logic if you like, but don't claim
this stuff is obvious.
Nobody threatened to start mining huge blocks given how relatively
> inexpensive it was to mine back then?
>
Not that I recall. It wasn't a response to any actual event, I think, but
rather a growing realisation that the code was full of DoS attacks.
> Guess what? SPV wallets are still not particularly widespread…and those
> that are out there are notoriously terrible at detecting network forks and
> making sure they are on the right one.
>
The most popular mobile wallet (measured by installs) on Android is SPV. It
has between 500,000 and 1 million installs, whilst Coinbase has not yet
crossed the 500,000 mark. One of the most popular wallets on iOS is SPV. If
we had SPV wallets with better user interfaces on desktops, they'd be more
popular there too (perhaps MultiBit HD can recapture some lost ground).
So I would argue that they are in fact very widespread.
Likewise, they are not "notoriously terrible" at detecting chain forks.
That's a spurious idea that you and Patrick have been pushing lately, but
they detect them and follow reorgs across them according to the SPV
algorithm, which is based on most work done. This is exactly what they are
designed to do.
Contrast this with other lightweight wallets which either don't examine the
block chain or implement the algorithm incorrectly, and I fail to see how
this can be described as "notoriously terrible".
> I understand that initially it was desirable that transactions be free…but
> surely even Satoshi understood this couldn’t be perpetually
> self-sustaining…and that the ability to bid for inclusion in blocks would
> eventually become a crucial component of the network. Or were fees just
> added for decoration?
>
Fees were added as a way to get money to miners in a fair and decentralised
way.
Attaching fees directly to all transactions is certainly one way to use
that, but it's not the only way. As noted above, our competitors prefer a
combination of price-hiding and cross subsidisation. Both of these can be
implemented with tx fees, but not necessarily by trying to artificially
limit supply, which is economically nonsensical.
> We’re already more than six years into this. When were these mechanisms
> going to be developed and tested? After 10 years? 20? Perhaps after 1024
> years?(https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki)
>
Maybe when there is a need? I already discussed this topic of need here:
https://medium.com/@octskyward/hashing-7d04a887acc8
Right. Turns out the ledger structure is terrible for constructing the
> kinds of proofs that are most important to validators - i.e. whether an
> output exists, what its script and amounts are, whether it’s been spent,
> etc…
>
Validators don't require proofs. That's why they are validators.
I think you're trying to say the block chain doesn't provide the kinds of
proofs that are most important to lightweight wallets. But I would
disagree. Even with UTXO commitments, there can still be double spends out
there in the networks memory pools you are unaware of. Merely being
presented with a correctly signed transaction doesn't tell you a whole lot
..... if you wait for a block, you get the same level of proof regardless
of whether there are UTXO commitments or not. If you don't then you still
have to have some trust in your peers that you are seeing an accurate and
full view of network traffic.
So whilst there are ways to make the protocol incrementally better, when
you work through the use cases for these sorts of data structures and ask
"how will this impact the user experience", the primary candidates so far
don't seem to make much difference.
Remote attestation from secure hardware would make a big difference though.
Then you could get rid of the waiting times entirely because you know the
sending wallet won't double spend.
Yes, let’s wait until things are about to break before even beginning to
> address the issue…because we can “easily create” anything we haven’t
> invented yet at the last minute.
>
bitcoinj already has a micropayment channel implementation in it. There's a
bit of work required to glue everything together, but it's not a massive
project to start using this to pay nodes for their services.
But it's not needed right now: serving these clients is so darn cheap. And
there is plenty of room for optimising things still further!
> I’m one of the very few developers in this space that has actually tried
> *hard* to make your BIP37 work. Amongst the desktop wallets listed on
> bitcoin.org, there are only two that have always supported SPV (or at
> least I think MultiBit has always supported it, perhaps I’m wrong). One is
> MultiBit, the other one is mine. I give you credit for your work…perhaps
> you could be generous enough to extend me some credit too?
>
MultiBit has always supported it. I apologise for implying you have not
built a wallet. I think yours is mSIGNA, right? Did it used to be called
something else? I recognise the website design but must admit, I have not
heard of mSIGNA before.
Regardless, as a fellow implementor, I would appreciate it more if you
designed and implemented upgrades, rather than just trashing the work done
so far as "notoriously terrible", Satoshi as "not a systems architect" and
so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150729/29ef9231/attachment-0001.html>

2023-06-07 15:43:43

- reply

📅 Original date posted:2015-07-29
📝 Original message:I do love history lessons from people who weren't actually there.
Let me correct your misconceptions.
Initially there was no block size limit - it was thought that the fee
> market would naturally develop and would impose economic constraints on
> growth.
The term "fee market" was never used back then, and Satoshi did not ever
postulate economic constraints on growth. Back then the talk was (quite
sensibly) how to grow faster, not how to slow things down!
> But this hypothesis failed after a sudden influx of new uses. It was still
> too easy to attack the network. This idea had to wait until the network was
> more mature to handle things.
>
No such event happened, and the hypothesis of which you talk never existed.
> Enter a “temporary” anti-spam measure - a one megabyte block size limit.
The one megabyte limit was nothing to do with anti spam. It was a quick
kludge to try and avoid the user experience degrading significantly in the
event of a "DoS block", back when everyone used Bitcoin-Qt. The fear was
that some malicious miner would generate massive blocks and make the wallet
too painful to use, before there were any alternatives.
The plan was to remove it once SPV wallets were widespread. But Satoshi
left before that happened.
Now on to your claims:
1) We never really got to test things out…a fee market never really got
> created, we never got to see how fees would really work in practice.
>
The limit had nothing to do with fees. Satoshi explicitly wanted free
transactions to last as long as possible.
> 2) Turns out the vast majority of validation nodes have little if anything
> to do with mining - validators do not get compensated…validation cost is
> externalized to the entire network.
>
Satoshi explicitly envisioned a future where only miners ran nodes, so it
had nothing to do with this either.
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:
1. Filtering the chain for bandwidth constrained SPV wallets (nb: you
can run an SPV wallet that downloads all transactions if you want). But
this could be handled by specialised nodes, just like we always imagined in
future not every node will serve the entire chain but only special
"archival nodes"
2. Relaying validated transactions so SPV wallets can stick a thumb into
the wind and heuristically guess whether a transaction is valid or not.
This is useful for a better user interface.
3. Storing the mempool and filtering/serving it so SPV wallets can find
transactions that were broadcast before they started, but not yet included
in a block. This is useful for a better user interface.
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.
And if one day there aren't enough network nodes being run by volunteers to
service all the lightweight wallets, then we can easily create an incentive
scheme to fix that.
3) Miners don’t even properly validate blocks. And the bigger the blocks
> get, the greater the propensity to skip this step. Oops!
>
Miners who don't validate have a habit of bleeding money: that's the
system working as designed.
> 4) A satisfactory mechanism for thin clients to be able to securely obtain
> reasonably secure, short proofs for their transactions never materialized.
>
It did. I designed it. The proofs are short and "reasonably secure" in that
it would be a difficult and expensive attack to mount.
But as is so often the case with Bitcoin Core these days, someone who came
along much later has retroactively decided that the work done so far fails
to meet some arbitrary and undefined level of perfection. "Satisfactory"
and "reasonably secure" don't mean anything, especially not coming from
someone who hasn't done the work, so why should anyone care about that
opinion of yours?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150729/79c8c15d/attachment-0001.html>

2023-06-07 15:43:39

- reply

📅 Original date posted:2015-07-29
📝 Original message:>
> This solved the vulnerability, and opens the door to using non-OpenSSL
> signature verification in the near future.
Great work!
It also means the remaining usages of OpenSSL can be safely replaced with
something like LibreSSL or (perhaps better) BoringSSL.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150729/79e82a36/attachment.html>

2023-06-07 15:43:04

- reply

📅 Original date posted:2015-07-22
📝 Original message:>
> Until we’re able to merge blockchain forks like we’re able to merge git
> repo forks, the safest option is no fork.
>
Block chain forks merge in the same way as git forks all the time, that's
how the reorg algorithm works. Transactions that didn't make it into the
post-reorg chain go back into the mempool and miners attempt to reinclude
them: this is the "merge" process. If they now conflict with other
transactions they are dropped and this is "resolving merge conflicts".
However you have to want to merge with the new chain. If your software is
programmed not to do that out of some bizarre belief that throttling your
own user base is a good idea, then of course, no merge happens. Once you
stop telling your computer to do that, you can then merge (reorg) back onto
the main chain again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/88e446a6/attachment.html>

2023-06-07 15:43:04

- reply

📅 Original date posted:2015-07-22
📝 Original message:Hi Pieter,
I think a core area of disagreement is this:
> Bitcoin Core is not running the Bitcoin economy, and its developers have
> no authority to set its rules.
>
In fact Bitcoin Core is running the Bitcoin economy, and its developers do
have the authority to set its rules. This is enforced by the reality of
~100% market share and limited github commit access.
You may not like this situation, but it is what it is. By refusing to make
a release with different rules, people who disagree are faced with only two
options:
1. Swallow it even if they hate it
2. Fork the project and fork the block chain with it (XT)
There are no alternatives. People who object to (2) are inherently
suggesting (1) is the only acceptable path, which not surprisingly, makes a
lot of people very angry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/36316a52/attachment.html>

2023-06-07 15:43:01

- reply

📅 Original date posted:2015-07-23
📝 Original message:>
> You complained about the lack of quantitative analysis being used, I gave
> it to you. There's nothing "negative" about displaying data which doesn't
> completely back up what your position is, I made a sensible conclusion
> based on the facts I have in front of me. Ignoring the information I
> collected and presented for you is incredibly childish.
>
He hasn't ignored you, and he wasn't responding to your email specifically
but rather the general attitude displayed in this forum for the last
several months (and I'd argue the last year or so).
Your data is interesting but ultimately tell us what we already know - that
the next bottleneck after the hard coded limit could easily be propagation
speed. The solution is likely to be a better protocol. Matt's custom
network already has optimised things, rolling some of those ideas into the
P2P protocol may be a good place to start, or something fancier like IBLTs.
Regardless, the *next* bottleneck is not the protocol, it's the hard cap.
So the conclusion remains unchanged: Bitcoin must grow, and solutions for
scaling it up will be found as the need arises.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/23883077/attachment.html>

2023-06-07 15:42:45

- reply

📅 Original date posted:2015-07-22
📝 Original message:>
> One solution would be for the client to combine all the addresses they are
> interested in into a single bloom filter and send that to the server.
>
<snip extra ideas>
Hey Joseph,
All those ideas are ones we had years ago and they are implemented in the
current Bitcoin protocol.
The trick, as you may know, is this bit:
The client would also need to be fairly clever
>
It turns out making a sufficiently clever client to fool even advanced
observers is a lot of programming work, assuming you wish for the Ultimate
Solution which lets you allocate a desired quantity of bandwidth and then
use it to maximize privacy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/0c849b21/attachment.html>

2023-06-07 15:42:38

- reply

📅 Original date posted:2015-07-21
📝 Original message:Thanks Clement!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150721/85e320fc/attachment.html>

2023-06-07 15:42:37

- reply

📅 Original date posted:2015-07-20
📝 Original message:Hey Thomas,
Here are some thoughts on a third way we can tackle our BIP 70 usability
problem sans servers: by finding an upgrade to QR codes that give us more
space and then optimising the hell out of BIP70 to make it fit.
*Better QR codes*
Let's start with this paper, High Capacity Colored Two Dimensional Codes
<http://proceedings2010.imcsit.org/pliks/79.pdf>. It develops an upgrade to
standard QR codes that extend them with the use of colour. The resulting
codes have ~4x the capacity but similar levels of scanning robustness.
This paper is also interesting: DualCodes
<https://books.google.at/books?id=O5a6BQAAQBAJ&pg=PA25&lpg=PA25&dq=%22DualCodes:+Backward+Compatible+Multi-layer+2D-Barcodes%22&source=bl&ots=ql_G8iyXXi&sig=9-VwhFLbkfgh2Fi0tdM3AWOyajA&hl=en&sa=X&redir_esc=y#v=onepage&q=%22DualCodes%3A%20Backward%20Compatible%20Multi-layer%202D-Barcodes%22&f=false>
It works by overlaying one QR code on top of another using shades of grey.
The resulting code is still scannable by older applications (backwards
compatibility!) but an enhanced reader can also extract the second code.
They explicitly mention digital signatures as a possible use case.
In both cases the code does not appear to be available but the same
approach was used: extend libqrcode for creation and ZXing for decoding
(Android). We could ask the authors and see if they're willing to open
source their work.
BIP 70 has the potential to add many features. But most of them, even the
extensions currently proposed only as ideas, can be expressed with
relatively few bytes.
So with a 4x boost in capacity, or a 2x boost with backwards compat, what
could we do?
*Optimised BIP70*
If we define our own certificate formats and by implication our own CAs,
then we can easily make a certificate be 32 bytes for the ECC
signature+length of the asserted textual identity, e.g. email address.
Can we go smaller? Arguably, yes. 32 bytes for a signature is for Really
Strong Security™ (a 256 bit curve), which gives 128 bits of security. If we
are willing to accept that a strong adversary could eventually forge a
certificate, we can drop down to a weaker curve, like a 128 bit cure with
64 bits of security. This is well within reach of, say, an academic team
but would still pose a significant hurdle for run of the mill payment
fraudsters. If these short CA keys expired frequently, like once a month,
the system could still be secure enough.
As we are defining our own PKI we can make CA keys expire however
frequently we like, up to the expiry period of the BIP70 request itself.
Thus certificates that expire monthly is not an issue if the wallet has a
way to automatically refresh the certificate by using a longer term
stronger credential that it keeps around on disk.
If we accept a single payment address i.e. no clever tricks around merge
avoidance, such a QR code could look like this:
bitcoin:1aBcD1234....?x=serialized_payment_request
However this requires text mode and wastes bytes at the front for the URI
type.
If we're willing to accept QR codes that can't be read by a standalone app
and which requires an embedded reader, then we can just scrap the legacy
and serialise a binary BIP70 request directly into the QR code. Andreas'
wallet, for example, can already handle this because it has an embedded QR
reader. I don't know what the situation on iOS is like.
If we were to use the DualCodes system we could define the primary QR code
as being an unsigned payment request, and the second layer as being the
signature/pki data.
*Getting response data back to the recipient*
One reason to have a store/forward network is the "forward" part: we don't
only want to host a static PaymentRequest, but also receive a private
response e.g. for the memo field, or to implement the well known "Stealth
Address" / ECDH in the payment protocol proposals:
https://medium.com/@octskyward/ecdh-in-the-payment-protocol-cb2f81962c1b
Stealth addresses try and (ab)use the block chain as a store/forward layer
and break SPV in the process as well as wasting lots of resources. ECDH in
BIP70 avoids those issues but at the cost of requiring a separate
store-and-forward network with some notion of account privacy.
These ideas come with another steep price: restoring a wallet from seed
words is no longer possible. You must have the extra random data to
calculate the private keys for money sent to you :( If you lose the extra
data you lose the money. It can be fixed but only by having wallets
regularly sweep the sent money to keys derived from the BIP32 seed, meaning
privacy-hurting merging and extra traffic.
I don't know of any way to solve this except by using some servers,
somewhere, that store the Payment messages for people: potentially for a
long period of time. If we have such servers, then having them host BIP70
requests is not a big extra requirement.
I have imagined this being a p2p-ish network of HTTPS servers that accept
POSTs and GETs. But if we are thinking about alternatives, it could also be
a separate service of the existing Bitcoin P2P network. That's what
OP_RETURN (ab)use effectively does. But as these messages don't really have
to be kept forever, a different system could be used: Payment messages
could be broadcast along with their transactions and stored at every node,
waiting for download. But unlike regular transactions, they are not stored
forever in a block chain. They are just written to disk and eventually
erased, perhaps, ordered in a mempool like way where more fee attached ==
stored for longer, even though the nodes storing the data aren't actually
receiving the fee.
A signature over the Payment metadata using the same output keys as the
transaction would bind them together for the purposes of broadcast, but
doesn't need to be stored after that.
As the data storage is just a helpful service but not fundamentally
required, nodes could shard themselves by announcing in their addr messages
that they only store Payment metadata for e.g. the half which have a hash
starting with a one bit. And when outputs are seen being spent, the
associated Payment metadata can be erased too, as by then it's fair to
assume that the users wallet has downloaded the metadata and no longer
cares about it.
Of course you have then all the regular DoS issues. But any P2P network
that stores data on the behalf of others has these.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150720/7b5c3cb0/attachment-0001.html>

2023-06-07 15:42:25

- reply

📅 Original date posted:2015-07-18
📝 Original message:>
> What are these pre- and post-Hearn-relay drop rules you are speaking
> about?
He's talking about patches I didn't even write (Gavin and Tom did), but
have included in Bitcoin XT:
https://github.com/bitcoinxt/bitcoinxt
See the README section starting with "Relaying of double spends"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150718/b7e23feb/attachment.html>

2023-06-07 15:42:16

- reply

📅 Original date posted:2015-07-18
📝 Original message:It is worth noting that DNS lookups can be done via Tor. In effect that
gives you 1000+ proxies instead of 56 or 4. BitcoinJ already has code that
can do this.
I would agree that it makes sense for proxying of DNS requests to be an
optional part of the protocol. Wallet developers can then compete on
privacy vs robustness vs whatever other issues there may be.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150718/fac4423c/attachment.html>

2023-06-07 15:42:16

- reply

📅 Original date posted:2015-07-18
📝 Original message:>
> Agreed, although I guess the bootstrap time for that is a little on
> the high side, and maybe a little too chunky on mobile devices
With warm Tor directory caches it's surprisingly fast - fast enough to be
usable and I'm a notorious stickler for low latency UX. If you want to do
LOTS of lookups so you can cross-check and merge their answers, that's
slower of course.
With cold Tor caches it's indeed too slow. However, reaching "tor by
default" is a part time hobby of the bitcoinj project for a while now and
there are plenty of ideas for how to make things fast enough. For instance,
using a cold cache whilst simultaneously refreshing it in the background,
doing nightly refreshes when charging, lengthening the expiry time, and the
Tor guys I believe want to implement directory differentials too which
would also help.
> My current thinking with Electrum (that ThomasV and I have bounced
> around) is to make the default policy DNSCrypt -> fallback to
> OpenAlias API pool (which can return DNSSEC data for verification) ->
> fallback to default resolver.
That seems reasonable for Electrum. I don't strongly care about these
protocols myself (and Justin knows this already), but whatever is decided
should give maximum freedom to wallet developers who disagree with you and
wish to explore other tradeoffs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150718/22387d55/attachment.html>

2023-06-07 15:42:08

- reply

📅 Original date posted:2015-07-20
📝 Original message:>
> In my previous post, I was suggesting to *not* include the proof in the
> request, because the payer can download it independently. Only the final
> signature is needed. What makes DNSSEC interesting is not the size of
> the proof, but rather the fact that you can request it easily, and in a
> canonical way.
>
Yes, but you still need the final signature. Is it possible to use an EC
signature with DNSSEC? I thought it was an all-RSA system. If I'm wrong
about that, and all you need is 32 bytes, then my argument does not hold.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150720/7c3a721f/attachment.html>

2023-06-07 15:42:08

- reply

📅 Original date posted:2015-07-20
📝 Original message:>
> The final signature is a signature of the payment request, it is not
> part of DNSSEC. So, yes, that signature can be EC.
>
Right, got it. I think we've been talking about two related but separate
issues (DNSSEC vs squeezing payment requests into URIs/qrcodes somehow).
So: DNSSEC attests via an RSA chain to some EC key stored in the wallet
which is then used to sign the payment request or URI, which also contains
a domain name.
> The payment requests I am currently playing with have the following values:
>
> pki_type = "dnssec+btc" (btc means that the signature is checked against
> a Bitcoin address stored in DNS)
> pki_data = the user's alias (DNS key)
By "alias" you mean domain name? I'm not sure what DNS key means in this
context.
I'm still not really convinced that a domain name under some new roots is
an identity people will want to use, but yes, I guess your approach would
work for those who do want it.
It still may be worth exploring the compact cert+optimized BIP70 (no
DNSSEC) in a qrcode if making a network that stores small bits of data
really is beyond us :(
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150720/cbf39169/attachment.html>

2023-06-07 15:42:08

- reply

📅 Original date posted:2015-07-20
📝 Original message:>
> What do you mean by "under some new roots" ?
>
I mean, most users will need to sign up for some new identity under a DNS
tree that they don't currently use (whether that's netki.com or whatever).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150720/b04b987a/attachment.html>

2023-06-07 15:42:07

- reply

📅 Original date posted:2015-07-20
📝 Original message:Hey Thomas,
Was great to hang out with you in Berlin last week!
> Bitcoin addresses do not require a webserver. If we want to build
> something that competes with that, we should have at least that level of
> convenience.
>
Absolutely agree! Convenience for the user is an absolute must. I just
don't know how to let users exchange large data packets without some kind
of server acting as a dropbox in the middle. That leaves two solutions:
1) Set up a way for users to exchange large data packets by using other
people's web servers, e.g. with no user visible signup flow (pure p2p/done
automatically in the background by user wallets)
2) Make the data packets small instead.
We can debate better signing methods that work towards (2). The reason I am
unsure about this is that the point of BIP70 is to be extended with useful
features. Even if we find a way to squeeze a human-meaningful
signature/cert into a URI, that's only one of BIP70s features. The next set
we want to add might end up running out of space again.
A lot of the problems come from how limited QR codes are. So perhaps there
is also a third approach: either find a better replacement for QR codes
(maybe something that uses colour like Microsoft Tag
<http://tag.microsoft.com/what-is-tag/home.aspx>), or drop them as a design
constraint.
Calling Jeff Garzik, Jeff, are you there? I recall BitPay did some
experiments to find out how much data you can stuff into a QR code before
it hurts scannability too much, do you have a writeup anywhere?
This is the main reason I feel uneasy about anything that isn't "build a
store+forward network". QR codes are so fundamental to our ecosystem, but
sooooooo limited, that I'm not sure how else to move forward. We were told
when designing BIP70 that even putting a URL in the QR code is pushing it!
There was talk of compressing the URL in some way. So adding even an ECC
signature which is much longer seems risky.
We can imagine a parallel universe where our societies technology was more
NFC oriented: laptops had NFC tags in them, phones had better NFC support
etc. Then we would have more bytes to play with and we wouldn't face this
pointer-indirection problem :( But laptops don't have the hardware and
Apple sits on their NFC API because they can't imagine any use case that
isn't credit cards :( :(
To get more specific, DNSSEC uses RSA 1024 bit. This causes two problems:
1. A DNSSEC proof is large, bytes wise. Even a single RSA signature
won't fit nicely in a QR code, I think.
2. 1024 bit is the absolute minimum strength you can get away with,
really. DNSSEC assumes frequent key rotations to try and help, which
complicates things.
So I'm not sure using DNSSEC fixes the usability problem we want to fix.
I will do a separate reply to break out some thoughts on replacing QR codes.
Would it be possible to create the same kind of "lightweight payment
> requests" using SSL certificates? Probably, if the final signing key is
> a EC key, and if the payment request does not include the whole chain of
> certificates.
Given that the pre-existing value of the PKI is much lower for individuals
than for companies/websites, where they all have certs already, building a
Bitcoin-specific or entirely new/independent PKI for people is not so
unthinkable, I agree.
In theory such a cert could be as minimal as:
<ECC signature>thomasv at electrum.org
so literally just a signature + a UTF-8 string, and that's it! You don't
need anything more if you're willing to sacrifice extensibility,
revocability, etc.
The pubkey of the CA would be obtained by running the pubkey recovery
algorithm on the signature, and then checked against a table of trusted
pubkeys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150720/5d80acee/attachment.html>

2023-06-07 15:42:06

- reply

📅 Original date posted:2015-07-14
📝 Original message:Hi Thomas,
Re: NetKi, I think any proposal in this space has to be an open standard,
almost by the definition of what it is. At any rate, it may be worth
talking to them. They have signed up to implement their system at least.
I did understand that your proposal does not rely on email - for instance a
web forum could issue username at reddit.com type aliases, even if those are
not also email accounts. I am just continuing the comparison against email
address certs.
It's also the case that a domain can use the DKIM setup without actually
offering email accounts. They can just have a web form or API that triggers
sending of the signed email (or simply, providing the signed headers
themselves). Thus the same system can be used transparently by both email
providers and other sites that don't give their users email addresses, but
would still like to use the same system.
Hardly anyone uses email certificates today, so I don't think it would
> affect a lot of users.
No, but obviously we'd like to change that! The holdup is not the
certificate side of things, really, but rather the lack of a
store-and-forward network for signed payment requests. I keep asking
someone to build one but I fear the problem is almost too simple ......
everyone who looks at this decides to solve 12 other problems
simultaneously, it gets complicated, then they never launch :(
Once there's a simple and robust way to get PaymentRequest's from one end
user to another, even when that first user is offline, then getting an
email cert issued is no big deal.
That does not look so... not until (1) BIP70 wallets integrate with
> https://crt.sh, (2) you convince that service to index email certs (3)
> you convince all CAs to report all email certs they issue to crt.sh.
>
Any solution that separates identity providers from certificate issuers
would have these requirements, though. And as many identity providers today
do not wish to become CAs too, it seems fundamental.
I don't think it's such a problem, mind you. The crt.sh website is actually
a frontend to the CT protocol, which is a somewhat blockchain like audit
log that's eventually intended to contain all issued certificates. Right
now, of course, they focus on SSL certs because those are the most common
and important. If other kinds of certs became more widely used, support in
the infrastructure would follow.
Don't get me wrong - I would like to see a way for a domain to delegate
BIP70 signing power to a third party. For instance, this would mean payment
processors like BitPay could sign on the behalf of the merchant, and the
merchant identity would then show up in wallets. The "chain a cert off a
domain cert" trick would be a good way to do that, though rather than
hacking the X.509 stack to validate invalid stuff, at this point it may as
well be a custom (better) cert format. There's little reason to use X.509
beyond backwards compatibility.
But the most popular identity providers today either don't care about
Bitcoin at all, or worse, are developing competitors to it. So for real
adoption to occur, we must have solutions that do not require identity
provider cooperation. I realise this is a business reason rather than a
technical reason, but it's a very strong one - so bootstrapping off
existing infrastructure with a split CA/ID provider design still makes much
more sense to me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150714/ebdd5af6/attachment.html>

2023-06-07 15:42:05

- reply

📅 Original date posted:2015-07-13
📝 Original message:Hi Thomas,
FYI there is a company called Netki is also working on a kind of DNSSEC
integration with BIP70, there's a thread here about their efforts:
https://groups.google.com/forum/#!searchin/bitcoinj/dnssec/bitcoinj/QFAH1F2dEwE/36oWDwREEV4J
If you would like to work on this, perhaps it's worth teaming up with them?
Obviously they plan to have an open spec and open source implementation.
Now w.r.t. the other things - I think we have discussed this before, but to
reiterate: the biggest flaw with doing things the way you suggest is that
in practice, no email provider is going to implement your scheme any time
soon. Most obviously the big web mail providers won't. Therefore hardly
anyone will use it.
Whilst having an extension cannot really hurt, obviously, BIP70 will not be
amended to reduce the certificate types it allows in favour of a system
that has a very low chance of mainstream adoption. Restricting options like
that would just make no sense at all.
I think your primary concern is that if your email account is hacked,
someone could get a cert issued in your name, and you'd be unable to revoke
it? But that's not quite true. Every CA I know of allows you to revoke a
certificate that was issued for your email address if you have access to
that email address. Now, if you don't know that this issuance took place,
you cannot invoke that procedure of course .... but that's what certificate
transparency is already working on solving in a scalable manner:
https://crt.sh/
That site doesn't currently index email address certs, but it certainly
could with minimal extra effort by the creators as they're almost identical
to domain name certs.
So the existing infrastructure seems to have everything in place to solve
that issue.
Now, if you still want a mechanism that eliminates the CA entirely, I think
there's a better approach which is backwards compatible with existing email
providers. It works like this:
1. User sends a public key in the subject line to a one-time collector
address like <random-number>@publish-email-headers.net (who runs this
service is arbitrary as they do not need to be trusted). On receiving the
email, the headers are made available via
https://publish-email-headers.net/<random-number> for download by the
users wallet.
2. The act of sending the email triggers DKIM signing of the subject
line and From header, and thus, the public key and email address are bound
together via the ESP's own signing key.
3. The textual email headers can be run through the DKIM validation
algorithm in combination with the domain key retrieved via DNS.
With this scheme, setup is largely automatic and involves the wallet asking
the operating system to open a mailto: URL. The user just has to press
"send" and the wallet can then sit on a long-lived HTTPS connection waiting
for the headers to turn up. Once the headers are downloaded, they can be
saved to disk and this becomes your "DKIM certificate" which can then be
used with a new pki_type in BIP70.
Note the following useful characteristics of this approach:
1. It does not require the email provider to know/care about Bitcoin.
DKIM is already widely deployed by major email providers due to its
benefits for spam and phishing protection: the majority of all email on the
internet is DKIM signed. So you automatically have a system that works with
nearly all consumer email accounts.
2. The enrolment UI is straightforward, assuming the user has a working
mailto: handler on their system. Even webmail services like Gmail can
attach themselves to mailto: handling these days.
3. There are DKIM validation libraries already in existence, so new code
required is minimal.
And the downsides:
1. There is no way to revoke such a "certificate" because you have, of
course, abandoned the PKI which specifies how to handle all these details.
You could potentially hijack/reuse OCSP to allow such a custom cert to be
revoked, but then the question is, who actually runs such a revocation
server. Doing things like this is why we have CAs in the first place.
2. The UX leaves a bit of binary nonsense in the users sent folder that
clutters up their account.
3. Does it even solve the right problem? A lot of users don't actually
use emails as identifiers anymore. In the modern world people are using
their social networking profiles (i.e. Facebook) and phone numbers (e.g.
for WhatsApp) as the personal identifier of choice. Email address support
might be solving yesterdays problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150714/58de7de1/attachment.html>

2023-06-07 15:38:52

- reply

📅 Original date posted:2015-06-19
📝 Original message:>
> Mailman isn't resigning it. Should it be? Does other mailing list
> software?
>
Mailman must take responsibility for the mail itself. It doesn't have to
actually sign with DKIM to do so: for backwards compatibility, spam filters
fall back to other heuristics to try and figure out the 'owner' of the mail
if it doesn't use DKIM. Those heuristics can go wrong of course. Ideally
all mail would be DKIM signed. There's no reason not to do it, really.
Yes mailing lists that edit people's emails resign. For example, from a
recent message to the bitcoinj list
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
*d=googlegroups.com <http://googlegroups.com>*; s=20120806;
h=to:from:subject:date:lines:message-id:references:mime-version
:content-type:user-agent:in-reply-to:x-original-sender
:x-original-authentication-results:reply-to:precedence:mailing-list
:list-id:list-post:list-help:list-archive:sender:list-subscribe
:list-unsubscribe;
> I suppose it is somewhat acceptable for us to remove subject tags and
> footers if we have no choice...
>
Good email clients can extract the same information from the headers
anyway. I filter all my mail based on them, and the headers also contain
unsubscribe instructions. Gmail is capable of using them programmatically.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/fd13cc68/attachment.html>

2023-06-07 15:38:52

- reply

📅 Original date posted:2015-06-19
📝 Original message:>
> The new list currently has footers removed during testing. I am not
> pleased with the need to remove the subject tag and footer to be more
> compatible with DKIM users.
>
Lists can do what are effectively MITM attacks on people's messages in any
way they like, if they resign for the messages themselves. That seems fair
to me! :)
> I'm guessing DKIM enforcement is not very common because of issues like
> this?
>
DKIM is used by most mail on the internet. DMARC rules that publish in DNS
statements like "All mail from bitpay.com is signed correctly so trash any
that isn't" are used on some of the worlds most heavily phished domains
like google.com, PayPal, eBay, and indeed BitPay.
These rules are understood and enforced by all major webmail providers
including Gmail. It's actually only rusty geek infrastructure that has
problems with this, I've never heard of DKIM/DMARC users having issues
outside of dealing with mailman. The vast majority of email users who never
post to technical mailing lists benefit from it significantly.
Really everyone should use them. Adding cryptographic integrity to email is
hardly a crazy idea :)
> It seems that Sourceforge silently drops DKIM enforced mail like jgarzik's.
>
It's not SourceForge, it's your spam filter. His mail gets through to me
but it's all in the spam folder.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/3aababa5/attachment.html>

2023-06-07 15:38:51

- reply

📅 Original date posted:2015-06-19
📝 Original message:>
> We already removed the footer because it was incompatible with DKIM
> signing. Keeping the "[Bitcoin-dev] " prepend tag in subject is compatible
> with DKIM header signing only if the poster manually prepends it in their
> subject header.
>
I still see footers being added to this list by SourceForge?
> Opinions?
>
I've asked Jeff to not use his @bitpay.com account for now.
The only real fix is to use a mailing list operator that is designed to
operate correctly with DKIM/DMARC, either by not modifying messages in
transit, or by re-sending (and ideally re-signing) under their own identity.
Though I'm sure this won't be an issue for the Linux Foundation, the latter
approach is dangerous because it means the list operator takes full
responsibility for any spamming that occurs from that domain. If the mail
server is ever hacked or spammers start posting to the lists themselves,
all that spam will be seen as originating from the listserv itself and the
reputation will be degraded. It can end with everyone's mail going to the
spam folder.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/14c0cfe4/attachment.html>

2023-06-07 15:38:49

- reply

📅 Original date posted:2015-06-19
📝 Original message:Hi Adam,
I am still confused about whether you actually support an increase in the
block size limit to happen right now. As you agree that this "layer 2" you
speak of doesn't exist yet, and won't within the next 10-12 months (do you
agree that actually?), can you please state clearly that you will support
Gavin's patch once posted? As Gavin's work takes some ideas from BIP100 but
does/soon will have some code associated with it.
But if we do no R&D on layer2, and insist that clients can never
> change to become layer2 aware, and layer2 is too hard etc
>
I think there's been some confusion here.
I, at least, have never argued that other systems can *never* happen. Never
is a long time, and I myself maintain a payment channels implementation.
These things have their place.
The argument is solely around the need to raise the block size *now* and
not allow the existing layer 1 to gum up and fall over.
If Stroem or Lightning or other block chains or Coinbase or secure hardware
tokens or whatever take off and people start moving bitcoins around that
way - fine. If they're choosing it of their own free will I have no issue
with that, nor does anyone else, I suspect.
However you don't seem fully confident that people actually will choose
whatever is being cooked up as "layer 2", if left to their own devices.
Indeed it's impossible for anyone to know that, as no "layer 2" actually
exists. Any such implementation could have all sorts of flaws that lead to
it not gaining traction.
> No offence but please find a way to gracefully stop and rejoin the
> constructive process. You can disagree on factors and points and be
> collaborative others disagree frequently and have done productive work
> cordially for years under the BIP process.
As you know from the discussion with myself and Gavin a few days ago on
IRC, neither of us believe any such constructive process exists. There is
another thread to discuss the lack of such a process.
> - Did you accept payment from companies to lobby for 20MB blocks?
Oh please. Conspiracy theories, now, Adam? My position has been consistent
for years. I don't care whether the figure is 20 or something else (looks
like it'll be lucky 8 instead), but I have always been clear that the limit
must rise.
But for the avoidance of doubt: the answer is no.
Gavin is paid by MIT. The MIT deal gives Gavin complete independence.
I am currently self employed and most of income comes from a client that is
actually interested in Lighthouse. Luckily they have given me some leeway
to do general Bitcoin development as well, which this business falls under.
I would *much* rather be working on Lighthouse than this, and so would they.
But seeing as you've gone there - let me flip this around. Blockstream has
a very serious conflict of interest in this situation. I am by no means the
first to observe this. You are building two major products:
1. Sidechains, a very complex approach to avoid changing the Bitcoin
consensus rules to add new features.
2. Lightning, a so-called "layer two" system for transaction routing
No surprise, the position of Blockstream employees is that hard forks must
never happen and that everyone's ordinary transactions should go via some
new network that doesn't yet exist.
The problem is that rather than letting the market decide between ordinary
Bitcoin and Lightning, you are attempting to strangle the regular Bitcoin
protocol because you don't trust people to spontaneously realise that they
should be using your companies products.
I know that many of you guys had these views before joining Blockstream. I
am not saying you are being paid to have views you didn't previously have.
I realise that birds of a feather flock together.
Regardless, that conflict of interest DOES exist, whether you like it or
not, because if you succeed in running Bitcoin out of capacity your own
company stands to benefit from selling consulting and services around your
preferred solutions.
With respect to user rights: all the polling done so far suggests users who
are paying attention strongly support increasing the block size. For
example:
Q: "Should the bitcoin block size be raised in the next two years"
A: 92% yes
http://www.poll-maker.com/results329839xee274Cb0-12#tab-2
Additionally, many Bitcoin users have explicitly delegated handling the
technical details to someone else, like a payment processor or their wallet
developers. Those people are nearly all sure that the block size limit
should rise too.
So please don't engage in idle speculation about "users vs companies". They
aren't some kind of opposing forces. Companies live for their users, and
many of those companies were formed by long time Bitcoin users.
And finally, the Bitcoin social contract is not defined by whatever random
state the code was in at the time Gavin decided to focus on research. Both
Gavin and I have been working on Bitcoin longer than you, Gregory or Peter
Todd. The social contract was and still is defined by the project's
founding vision - written down in words.
Heck, if Satoshi had spent another hour or two on his original size limiter
patch this entire dispute would never have happened. He'd have put in some
kind of automatic timeout or limit riser because the plan was to remove it
all along, and then it'd be you guys arguing for putting a limit in place,
Gavin would object, it'd be controversial and nothing would happen. But
Satoshi never anticipated this bizarre attempt to turn the project into
something else and so figured he'd just remove it himself later. Too bad.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/9daed28f/attachment.html>

2023-06-07 15:38:42

- reply

📅 Original date posted:2015-06-18
📝 Original message:>
> So then: make a proposal for a better process, post it to this list.
>
Alright. Here is a first cut of my proposal. It can be inserted into an
amended BIP 1 after "What belongs in a successful BIP?". Let me know what
you think.
The following section applies to BIPs that affect the block chain consensus
rules or the peer to peer protocol and thus require changes to Bitcoin
Core.
Once a draft BIP has been submitted to bitcoin-development for
consideration, the Bitcoin Core maintainer will deliver a preliminary
yes/no verdict within three weeks. This verdict may be informed by the
debate that has taken part in the previous three weeks. If more time is
required, the maintainer is required to request an extension from the BIP
author, who may then elect to force an immediate decision (risking a no),
or choosing to allow more time.
The verdict will meet the following criteria:
- It will address the latest version of the BIP at the time the verdict
is rendered.
- In case of a rejection, it will spell out and describe the technical
rationale for this decision. Opinions held by other people are not
considered technical rationales: if the maintainer agrees with a technical
point made during discussion, he must own that opinion for himself.
Therefore no BIP will be rejected on grounds of controversy, disagreement,
lack of consensus or otherwise.
- In case of rejection, the maintainer will provide a clear, specific
list of actionable steps the BIP author can take next. For example, a list
of what changes would address the technical objections raised. In case the
maintainer believes no change could ever make the BIP acceptable, the list
must consist of instructions for how to create a patch set and, in the case
of changes to the consensus rules, how to initiate a hard fork.
A BIP, even once rejected, may live on in the BIPS repository, though its
entry in the index may be sorted below others. The BIP author may update
the BIP with a summary of any resulting discussion. As such a summary may
be inherently contentious in case of a dispute, the authors wording of that
summary is final and may not be subject to meta-debate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/d9c01029/attachment.html>

2023-06-07 15:38:41

- reply

📅 Original date posted:2015-06-18
📝 Original message:OK, let's agree to unpack the two things.
The first issue is how are decisions made in Bitcoin Core? I struggle to
explain this to others because I don't understand it myself. Is it a vote
of people with commit access? Is it a 100% agreement of "core developers"
and if so, who are these people? Is it "whoever reverts the change last"?
Could I write down in a document a precise description of how decisions are
made? No, and that's been a fairly frustrating problem for a long time.
But let's leave it to one side for a moment.
Let's focus on the other issue: what happens if the Bitcoin Core decision
making process goes wrong?
For the sake of argument let's pretend we're discussing a different change,
let's imagine there is a proposal to change the block format to include a
Widget, where a Widget is some potentially desirable thing. And this change
means a hard fork. Let's put the block size to one side for a second to
avoid getting distracted.
Imagine that 90% of people in Bitcoin want their Widgets, but one of your
committers refuses to accept it. I am not saying the block size debate has
such proportions but pretend Widgets do.
What is the process for resolving this problem?
Gavin and I say - there is a process, and that process is a hard fork of
the block chain.
What you're saying is - there is no process because a contentious hard fork
must never happen. Such a change is simply impossible.
Now which is a better description of this situation? Is the "it must never
happen end of story" really the cuddly warm democracy that you seem to
suggest? Or is it more like a dictatorship where the opinions of one or two
people can override all the others?
The typical answer I'm seeing to this is that Bitcoin Core's own decision
making process is so fantastic that it never goes wrong, even though
"consensus" is not defined and "technical majority" is not defined and we
have serious long time contributors on this mailing list (such as wallet
developers) disagreeing with this consensus yet our feedback is being
ignored.
You guys *must* accept that your preferred process for resolving disputes
is, itself, in dispute. That leaves the block chain itself as the only
remaining method for bringing this saga to a close.
So this is why we keep disagreeing:
- If Bitcoin Core has reached a formal decision made by the maintainer
via whatever mechanism he likes to not accept the block size increase, then
alright, technical disputes will happen. But ....
- You should agree that the next step is a fork of both the software and
the block chain. And you should welcome such a thing because it is the ONLY
check on your own power. It's the one thing that allows the community to
reject the decision making process you are using in case it goes wrong.
I keep reading that Bitcoin cannot survive a hard fork. Well, we've
survived an accidental fork that happened without anyone being prepared,
and even with a planned soft fork "never upgrade" isn't really an option
for either miners or businesses, so ultimately node operators must know
about upgrades and make them. Both myself and Gavin think this process can
work out OK.
Do you at least understand where we're coming from here, even if you
disagree? And if you disagree, is it because you think a hard fork to
resolve a dispute can't work technically, or is it some other reason?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/de57a58c/attachment.html>

2023-06-07 15:38:37

- reply

📅 Original date posted:2015-06-19
📝 Original message:>
> Or alternatively, fix the reasons why users would have negative
> experiences with full blocks
>
It's impossible, Mark. *By definition* if Bitcoin does not have sufficient
capacity for everyone's transactions, some users who were using it will be
kicked out to make way for the others. Whether that happens in some kind of
stable organised way or (as with the current code) a fairly chaotic way
doesn't change the fundamental truth: *some users will find their bitcoin
savings have become uneconomic to spend*.
Here's a recent user complaint that provides a preview of coming
attractions:
https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/
Hello, I'm just trying to send my small Sarutobi-tips stash (12,159 bits)
> onto a paper wallet. When I try to send it, a window pops up stating
> "insufficient funds for bitcoin network fee, reduce payment amount by 1,389
> bits?" This would be a fee of $0.32 to send my $2.82, leaving me with $2.50.
These sorts of complaints will get more frequent and more extreme in the
coming months. I realise that nobody at Blockstream is in the position of
running an end user facing service, but many of us are .... and we will be
the ones that face the full anger of ordinary users as Bitcoin hits the
wall.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/94ba867c/attachment.html>

2023-06-07 15:38:29

- reply

📅 Original date posted:2015-06-18
📝 Original message:>
> If you think it's not clear enough, which may explain why you did not even
> attempt to follow it for your block size increase, feel free to make
> improvements.
>
As the outcome of a block size BIP would be a code change to Bitcoin Core,
I cannot make improvements, only ask for them. Which is what I'm doing.
I agree that BIP 1 is not clear enough. Gavin is writing a BIP to accompany
his patch, because BIPs are best when they describe working code, and BIP 1
*is* at least clear about that. Otherwise it can turn out during
implementation that something was different to what was anticipated. I'm
sure you agree with this.
So a BIP is coming. However, BIP 1 also says this:
Vetting an idea publicly before going as far as writing a BIP is meant to
> save the potential author time
and
BIP authors are responsible for collecting community feedback on a BIP
> before submitting it for review
OK. Gavin has been vetting the idea publicly and collecting community
feedback. Note that the entire Bitcoin community is not on this list, so he
published a series of blog posts to get wider feedback, and then was
criticised for not doing it all here instead.
But anyway - so far, so good. The procedure is being followed.
What happens once a BIP is written? The process says:
For a BIP to be accepted it must meet certain minimum criteria. It must be
> a clear and complete description of the proposed enhancement. The
> enhancement must represent a net improvement. The proposed implementation,
> if applicable, must be solid and must not complicate the protocol unduly.
> Once a BIP has been accepted, the reference implementation must be
> completed.
This is where the problem starts.
The BIP process you refer to *does not state how acceptance will happen*.
It merely sets out a few minimum requirements like making some sort of
sense, having code. It's also full of extremely vague descriptions like
"must represent a net improvement". Improvement according to who? That's
left unexplained.
And then it says what happens once a BIP is accepted.
The middle bit is missing. When there is disagreement over a consensus BIP,
how are decisions made?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/c0cc0fed/attachment.html>

2023-06-07 15:38:27

- reply

📅 Original date posted:2015-06-18
📝 Original message:>
> And allegations that the project is "run like wikipedia" or "an edit war"
> are verifyably untrue.
> Check the commit history.
>
This was a reference to a post by Gregory on Reddit where he said if Gavin
were to do a pull request for the block size change and then merge it, he
would revert it. And I fully believe he would do so!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/78f96bc5/attachment.html>

2023-06-07 15:38:26

- reply

📅 Original date posted:2015-06-18
📝 Original message:Dude, calm down. I don't have commit access to Bitcoin Core and Gavin
already said long ago he wouldn't just commit something, even though he has
the ability to do so.
So why did I say it? Because it's consistent with what I've always said:
you cannot run a codebase like Wikipedia. Maintainers have to take part in
debates, and then make a decision, and anyone else who was delegated commit
access for robustness or convenience must then respect that decision. It's
the only way to keep a project making progress at a reasonable pace.
This is not a radical position. That's how nearly all coding projects work.
I have been involved with open source for 15 years and the 'single
maintainer who makes decisions' model is normal, even if in some large
codebases subsystems have delegated submaintainers.
This is also how all my own projects are run. Bitcoinj has multiple people
with commit access. Regardless, if there were to be some design dispute or
whatever, I wouldn't tolerate the others with commit access starting some
kind of Wiki-style edit war in the code if they disagreed. Nor would I ever
expect to get my own way in other people's projects by threatening to
revert the maintainers changes.
Core is in the weird position where there's no decision making ability at
all, because anyone who shows up and shouts enough can generate
'controversy', then Wladimir sees there is disagreement and won't touch the
issue in question. So it just runs and runs and *anyone* with commit access
can then block any change.
I realise some people think this anti-process leads to better decision
making. I disagree. It leads to no decision making, which is not the same
thing at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/8e40d538/attachment.html>

2023-06-07 15:38:16

- reply

📅 Original date posted:2015-06-16
📝 Original message:Hi Bryan,
Specifically, when Adam mentioned your conversations with non-technical
> people, he did not mean "Mike has talked with people who have possibly not
> made pull requests to Bitcoin Core, so therefore Mike is a non-programmer".
>
Yes, my comment was prickly and grumpy. No surprises, I did not sleep well
last night.
I am upset about this constant insistence from Adam, Gregory and others
that the "technical community" or "technical majority" agree with them and
anyone who doesn't is "non technical" or "not a contributor" or not an
expert or not had things properly explained to them.
This is not true and needs to stop. Gavin and I have both been working on
Bitcoin in substantial ways for longer than Gregory and Adam have been in
the community at all. We are extremely technical, as are many of the people
who want us to release XT+larger blocks. We cannot make progress in any
kind of negotiation if one side constantly blows off the other and refuses
to take anything they say seriously, which has been a feature of this
"debate" from the start.
In contrast Gavin and I have written vast amounts of analysis on the
concerns raised by larger blocks. So many hours were spent, we could
probably fill a small book by now. We have carefully read and addressed
*dozens* of points raised by the 1mb camp. We have also done our best to
open this debate to the whole community.
So it would be nice if the people who are so keen on 1mb blocks show the
same respect to us.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/15732844/attachment.html>

2023-06-07 15:38:16

- reply

📅 Original date posted:2015-06-16
📝 Original message:>
> "How do you plan to deal with security & incident response for the
> duration you describe where you will have control while you are deploying
> the unilateral hard-fork and being in sole maintainership control?"
>
How do we plan to deal with security & incident response - exactly the same
way as before. Remember that XT is basically Core plus a few patches.
Gavin and myself are both on the bitcoin-security mailing list and have
been for years. Both of us have experience of responding to very serious
and tight-deadline security incidents, for example, the accidental bdb hard
fork and (in my case) when we discovered that Android phones had so little
entropy in them that different devices were actually generating the same
keys!
That one required co-ordinated crash rollouts of multiple wallets across
the Bitcoin ecosystem because there was a parallel investigation into key
collisions taking place in an open forum and they were not far from
discovering the truth about how badly the Android RNG was broken (I knew
because at the time I had access to the Google internal Android bug
tracker). I organised the whole thing.
So I think we'll manage. But I don't expect things to exist in a state of
disjointness for very long. XT will rebase on top of Core and follow it's
releases for as long as there seems to be interest in bigger blocks and as
long as I have the time/energy/interest. If the >1mb chain wins then Core
will have to adopt the new ruleset or simply stop being relevant, as it
will have no users. That wouldn't make much sense.
Now, there have been concerns raised that a hard fork is unbelievably
risky, the sky will fall, the value of Bitcoin will drop to zero, etc. I
don't believe it's anywhere near that risky. The patch Gavin is working on
requires both a miner majority *and* also has a date trigger in it. Much
like previous forks, in fact. So nobody should be taken by surprise if/when
bigger blocks appear, because it will have been known for a long time
beforehand that there was sufficiently strong consensus, there will have
been messages printed to the node logs, announcements in various places and
so on.
Does that help clear things up?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/abf446cc/attachment.html>

2023-06-07 15:38:11

- reply

📅 Original date posted:2015-06-15
📝 Original message:Hi Adam,
I replied publicly because your questions were sent to the mailing list.
I'd have been happy to reply in private if so asked.
I started to write up a much longer reply, but I'm tired - we've long since
been going in circles. I feel like I've written down answers to almost all
your questions before, including some in the email above.
Still, there are a few new ones. Let me work through them now.
Yes, I am on the bitcoin-security list. I have always been on it. I have
taken part in many threads there and started one or two myself. I guess
you're not though, otherwise you'd know that. You can ask, I'm sure Gavin
will add you if you like.
Re: BIP. Gavin is working on a BIP to go along with his patch. I hope that
will satisfy. I do not expect the resulting discussion to differ much from
the discussion so far, though.
Re: summit. No, I would not attend. I have been to several Bitcoin
conferences over the years where the block size issue was discussed. No
progress was ever made at these events.
Re: if some flaw or bug was found in the patch. Yes, of course if there was
some specific problem with the code then we would fix it. There will be
time to review Gavin's patches for these reasons.
Re: anyone who agrees with noted non-programmers Mike&Gavin must be
non-technical, stupid, uninformed, etc .... OK, go ahead and show them the
error of their ways. Anyone can write blogs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/89e2f0ee/attachment.html>

2023-06-07 15:38:09

- reply

📅 Original date posted:2015-06-15
📝 Original message:Hi Adam,
Provisional answers below!
- Are you releasing a BIP for that proposal for review?
>
The work splits like this:
- Gavin is writing the code and I think a BIP as well
- I will review both and mostly delegate to Gavin's good taste around
the details, unless there is some very strong disagreement. But that seems
unlikely.
- I have been handling gitian and the patch rebases, the code signing
and so on, so far. I've also been doing some work to setup the basic
infrastructure of the project (website etc).
- If the reviewers all say NACK will you take on board their suggestions?
>
Feedback will be read. There are no NACKS in Bitcoin XT. Patch requests
aren't scored in any way. The final decision rests with the maintainer as
in ~all open source projects.
> - On the idea of a non-consensus hard-fork at all, I think we can
> assume you will get a row of NACKs. Can you explain your rationale
> for going ahead anyway? The risks are well understood and enormous.
>
Yes, I have been working on an article that explains how we got to this
point from my perspective. It is quite long, but only because I want it to
be readable for people who weren't following the debate.
Anyway, I think I've laid out the gist of it over and over again, but to
summarise:
If Bitcoin runs out of capacity *it will break and many of our users will
leave*. That is not an acceptable outcome for myself or the many other
wallet, service and merchant developers who have worked for years to build
an ecosystem around this protocol.
> - How do you propose to deal with the extra risks that come from
> non-consensus hard-forks? Hard-forks themselves are quite risky, but
> non-consensus ones are extremely dangerous for consensus.
>
The approach is the same for other forks. Voting via block versions and
then when there's been >X% for Y time units the 1mb limit is
lifted/replaced.
> - If you're going it alone as it were, are you proposing that you will
> personally maintain bitcoin-XT? Or do you have a plan to later hand
> over maintenance to the bitcoin developers?
>
Good question! I have various thoughts on this, but let's wait and see
what happens first. Perhaps the new chain won't get the majority on it.
In the event that the >1mb chain does eventually win, I would expect Core
to apply the patch and rejoin the consensus rather than lose all its users.
That would take XT back to being a fairly small patchset to improve the
network protocol.
- Do you have contingency plans for what to do if the non-consensus
> hard-fork goes wrong and $3B is lost as a result?
>
Where did you get the $3B figure from? The fork either doesn't happen, or
it happens after quite a long period of people knowing it's going to happen
- for example because their full node is printing "You need to upgrade"
messages due to seeing the larger block version, or because they read the
news, or because they heard about it via some other mechanisms.
Let me flip the question around. Do you have a contingency plan if Bitcoin
runs out of capacity and significant user disruption occurs that results in
exodus, followed by fall in BTC price? The only one I've seen is "we can
perform an emergency hard fork in a few weeks"!
> As you can probably tell I think a unilateral fork without wide-scale
> consensus from the technical and business communities is a deeply
> inadvisable.
Gavin and I have been polling many key players in the ecosystem. The
consensus you seek does exist. All wallet developers (except Lawrence), all
the major exchanges, all the major payment processors and many of the major
mining pools want to see the limit lifted (I haven't been talking to pools,
Gavin has).
This notion that the change has no consensus is based on you polling the
people directly around you and people who like to spend all day on this
mailing list. It's not an accurate reflection of the wider Bitcoin
community and that is one of the leading reasons there is going to be a
fork. A small number of people have been flatly ignoring LOTS of highly
technical and passionate developers who have written vast amounts of code,
built up the Bitcoin user base, designed hardware and software, and yes
built companies.
How do you think that makes Bitcoin Core look to the rest of the Bitcoin
world? How much confidence does that give people?
Of the overall process, I think you can agree we should not be making
> technical decisions with this level of complexity and consensus risk
> with financial implications of this magnitude under duress of haste?
>
This debate will never end until a fork makes it irrelevant. There is no
process for ending it, despite me begging Wladimir to make one.
And there is no haste. We have been debating the block size limit for
*years*. We have known it must be lifted for *years*. I kicked off this
current round of debates after realising that Wladimir's release timeline
wouldn't allow a block size limit to be released before the end of the
year. The reason we're talking about it now and not next year is exactly to
ensure there is plenty of time.
> I can sincerely assure you everyone does want to scale bitcoin and
> shares your long term objective on that
I really wish you were right, and I definitely feel you are one of the more
reasonable ones Adam. But the overwhelming impression I get from a few
others here is that no, they don't want to scale Bitcoin. They already
decided it's a technological dead end. They want to kick end users out in
order to "incentivise" (force) the creation of some other alternative,
claiming that it's still Bitcoin whilst ignoring basic details ... like the
fact that no existing wallets or services would work.
Scaling Bitcoin can only be achieved by letting it grow, and letting people
tackle each bottleneck as it arises at the right times. Not by convincing
ourselves that success is failure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/892471da/attachment.html>

2023-06-07 15:38:00

- reply

📅 Original date posted:2015-06-15
📝 Original message:>
> The fact that using a centralized service is easier isn't a good reason
> IMHO. It disregards the long-term, and introduces systemic risk.
>
Well sure, that's easy for you to say, but you have a salary :) Other
developers may find the incremental benefits of decentralisation low vs
adding additional features, for instance, and who is to say they are wrong?
> But in cases where using a decentralized approach doesn't *add* anything,
> I cannot reasonably promote it, and that's why I was against getutxos in
> the P2P protocol.
>
It does add something though! It means, amongst other things, I can switch
of all my servers, walk away for good, discard this Mike Hearn pseudonym I
invented for Bitcoin and the app will still work :) Surely that is an
important part of being decentralised?
It also means that as the underlying protocol evolves over time, getutxos
can evolve along side it. P2P protocol gets encrypted/authenticated? Great,
one more additional bit of security. If one day miners commit to UTXO sets,
great, one more additional bit of security. When we start including input
values in the signature hash, great ... one more step up in security.
Anyway, I didn't really want to reopen this debate. I just point out that
third party services are quite happy to provide whatever developers need to
build great apps, even if doing so fails to meet some kind of perfect
cryptographic ideal. And that's why they're winning devs.
Now back to your regularly scheduled block size debates ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/ebebaacc/attachment.html>

2023-06-07 15:37:59

- reply

📅 Original date posted:2015-06-15
📝 Original message:>
> Since you keep bringing this up, I'll try to clarify this once again.
>
I understand the arguments against it. And I think you are agreeing with me
- Adam is bemoaning the way developers outsource stuff to third party
services, and suggesting it is relevant to the block size debate. And we
are saying, no, it's happening because it's easier than doing things in a
decentralised way.
> If you can't do that, and are just aiming for removing central points of
> failure, run a bunch of servers yourself, and let others run their own.
> That sounds remarkably close to what you actually did, actually...
>
Right. There's a deeper issue here. The sort of 'trustless' querying of the
UTXO set that was demanded from me is impossible even with commitments,
because the answer can change the moment you receive it. All it takes is a
new block or new transaction to be broadcast a split second after you
download and use the data, and suddenly what you did is incorrect no matter
how many proofs you verified!
The only way to know this has happened is to be a full node and download
all transactions yourself ... and even then, you are trusting your peers to
actually relay you all transactions and not a subset. So in the end you can
never achieve perfection, only get closer to it.
But that situation is *fine* for many use cases, like showing someone a
snapshot of their crowdfund in a user interface. We just accept that what
we see on the screen may lag behind reality. It happens all the time with
all kinds of non-Bitcoin apps. We accept that there may be cases where the
answer we get is wrong. The software can nevertheless still be useful.
So Lighthouse compromises. It queries multiple peers and cross-references
their answers. If their answers don't match it shows an error on the screen
and won't show the user any status for their crowdfund at all. This error
has never occurred. Maybe one day it will. So the app gets more
decentralisation, more robustness, and accepts that the user interface
might one day show a wrong answer if the P2P network starts lying (or your
internet connection is hacked, but the right fix for that is P2P
encryption).
Unfortunately this sort of balance-of-risks approach is considered a
non-starter in Bitcoin Core. So why would developers even try? The message
sent was clear: even if you have an approach you think will work, don't
bother.
Much easier to just outsource to a trusted service indeed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/4fcbdae8/attachment.html>

2023-06-07 15:37:56

- reply

📅 Original date posted:2015-06-14
📝 Original message:>
> One thing that is concerning is that few in industry seem inclined to
> take any development initiatives or even integrate a library.
Um, you mean except all the people who have built more scalable wallets
over the past few years, which is the only reason anyone can even use
Bitcoin from their phone? Or maybe you mean initiatives like Lightning ....
except StrawPay already developed something similar to the Lightning
network (complete with a working GUI wallet) and were ignored by
Blockstream as you prefer to write your own from scratch?
Sure, people in the industry take development initiatives. That doesn't
mean their work will be recognised on this mailing list.
> I suppose eventually that problem would self-correct as new startups would
> make a more scalable wallet and services that are layer2 aware and eat the
> lunch of the laggards.
"The laggards" being *everyone* who has already invested in building
Bitcoin software so far. Not a great way to frame things. Many of those
"laggards" have written orders of magnitude more code than you or Gregory
or Jeff, for instance.
I still think you guys don't recognise what you are actually asking for
here - scrapping virtually the entire existing investment in software,
wallets and tools.
> But it will be helpful if we expose companies to the back-pressure
> actually implied by an O(n^2) scaling protocol and don't just immediately
> increase the block-size to levels that are dangerous for decentralisation
> security
Bitcoin does not have n-squared scaling. I really don't get where this idea
comes from. Computational complexity for the entire network is O(nm) where
n=transactions and m=fully validating nodes. There is no fixed
relationships between those two variables.
"Exposing the companies to back-pressure" sounds quite nice and gentle. Let
me rephrase it to be equivalent but perhaps more direct: you mean "breaking
the current software ecosystem to force people into a new, fictional system
that bears little resemblance to the Bitcoin we use today, whether they
want that or not".
As nothing that has been proposed so far (Lightning, merge mined chains,
extension blocks etc) has much chance of actual deployment any time soon,
that leaves raising the block size limit as the only possible path left.
Which is why there will soon be a fork that does it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/a4acdd2d/attachment.html>

2023-06-07 15:37:55

- reply

📅 Original date posted:2015-06-15
📝 Original message:Bear in mind the problem that stops Jeff's messages getting through is that
mailman 1.0 doesn't know how to handle DKIM properly. Switching to a
different mailman provider won't fix that.
Does mailman 3.0 even fix this? I found it difficult to tell from their
website. There's a big page on the mailman wiki that suggests they "fixed"
it by simply deleting the signatures entirely, which won't work. DMARC
policies state that mail *must* be signed and unsigned/incorrectly signed
message should be discarded.
The user documentation for mailman 3 doesn't seem to exist? The links on
the website are docs for 2.1, perhaps they released mailman 3 without
refreshing the docs.
Google Groups may be "controversial" but if I recall correctly the main
issue was the question of whether you needed a Google account or not. I'm
pretty sure you can just send an email to
groupname+subscribe at googlegroups.com even if you don't have a Google
account. But of course this is a bizarre standard to hold mailing list
software to: mailman asks users to create an account for each listserv in
order to manage a subscription too!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/1ada10c5/attachment.html>

2023-06-07 15:37:48

- reply

📅 Original date posted:2015-06-15
📝 Original message:>
> It's simple: either you care about validation, and you must validate
> everything, or you don't, and you don't validate anything.
>
Pedantically: you could validate a random subset of all scripts, to give
yourself probabilistic verification rather than full vs SPV. If enough
people do it with a large enough subset the probability of a problem being
detected goes up a lot. You still pay the cost of the database updates.
But your main point is of course completely right, that side chains are not
a way to scale up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/887958ae/attachment.html>

2023-06-07 15:37:36

- reply

📅 Original date posted:2015-06-14
📝 Original message:On Sun, Jun 14, 2015 at 4:42 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> Since you missed it, here is the suggestion again:
> http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
>
Reposting as Jeff's mail got eaten by the anti-phishing filters, due to
SourceForge's obsolete mailman setup.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/ba5aa579/attachment.html>

2023-06-07 15:37:24

- reply

📅 Original date posted:2015-06-12
📝 Original message:>
> are only connected to each other through a slow 2 Mbit/s link.
>
That's very slow indeed. For comparison, plain old 3G connections routinely
cruise around 7-8 Mbit/sec.
So this simulation is assuming a speed dramatically worse than a mobile
phone can get!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150612/8cf55d02/attachment.html>

2023-06-07 15:37:24

- reply

📅 Original date posted:2015-06-12
📝 Original message:Sure, and you did indeed say that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150612/036c4473/attachment.html>

2023-06-07 15:37:19

- reply

📅 Original date posted:2015-06-10
📝 Original message:I described an alternative way for SPV wallets to learn about fees some
time ago. It requires a new transaction version that embeds output values
into the signed data. Then an upgrade to the P2P protocol to send UTXO data
along with transactions when they are relayed.
The idea is that the wallet sets a Bloom filter with an FP rate that
ensures it will see some random subset of all transactions being broadcast
on the network, and with the extra data, it can calculate the fee paid.
Once a transaction broadcast is observed the wallet includes that tx hash
in its next Bloom filter, thus it can see which block the tx confirmed in.
By measuring the amount of time that passed between a broadcast and it
appearing in a block, it can calculate its own tables of fee paid:time
taken.
This has the advantage that you don't have to trust miners to publish data
accurately. However it requires some protocol upgrades and of course, a lot
of new code in SPV wallets.
The way Bitcoin Wallet for Android handles fees currently is to just update
a hard coded value every so often.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150610/195f8f71/attachment.html>

2023-06-07 15:36:31

- reply

📅 Original date posted:2015-06-02
📝 Original message:>
> But the majority of the hashrate can now perform double spends on your
> chain! They can send bitcoins to exchanges, sell it, extract the money and
> build a new longer chain to get their bitcoins back.
>
Obviously if the majority of the mining hash rate is doing double spending
attacks on exchanges then the Bitcoin experiment is resolved as a failure
and it will become abandoned. This has been known since day one: it's in
the white paper. The basic assumption behind Bitcoin is that only a
minority of actors are dishonest - if the majority are then Satoshi's
scheme does not work.
So you are not stating anything new here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150602/385eabc4/attachment.html>

2023-06-07 15:36:17

- reply

📅 Original date posted:2015-06-01
📝 Original message:>
> (at reduced security if it has software that doesnt understand it)
Well, yes. Isn't that rather key to the issue? Whereas by simply
increasing the block size, SPV wallets don't care (same security and
protocol as before) and fully validating wallets can be updated with a very
small code change.
> A 1MB client wont even understand the difference between a 1MB and 8MB
> out payment.
Let's say an old client makes a payment that only gets confirmed in an
extension block. The wallet will think the payment is unconfirmed and show
that to the user forever, no?
Can you walk through the UX for each case?
> If I am not misremembering, I think you've sided typically
> with the huge block, big data center only end of the spectrum.
It would be Satoshi, that argued that.
I think there must be a communication issue here somewhere. I'm not sure
how this meme has taken hold amongst you guys, as I am the guy who wrote
the scalability page back in 2011:
https://en.bitcoin.it/wiki/Scalability
It says:
*The core Bitcoin network can scale to much higher transaction rates than
are seen today, assuming that nodes in the network are primarily running on
high end servers rather than desktops. *
By "much higher rates" I meant VISA scale and by "high end server" I meant
high end by today's standards not tomorrows. There's a big difference
between a datacenter and a single server! By definition a single server is
not a datacenter, although it would be conventional to place it in
one. But even
with the most wildly optimistic growth imaginable, I couldn't foresee a
time when you needed more than a single machine to keep up with the
transaction stream.
And we're not going to get to VISA scale any time soon: I don't think I've
ever argued we will. If it does happen it would presumably be decades away.
Again, short of some currently unimagined killer app.
So I don't believe I've ever argued this, and honestly I kinda feel people
are putting words in my mouth.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/a93d6e3d/attachment.html>

2023-06-07 15:36:16

- reply

📅 Original date posted:2015-06-01
📝 Original message:Hi Adam,
I have more experience than Gavin of building consumer wallets, so I'll
make an attempt to answer your questions.
> Then ask the various wallet developer how long it would take them to
> update
> > their software to support something like this,
>
> I don't think thats any particular concern
I am a wallet developer and I am telling you that it is.
> Businesses who are keen to
> have more transactions, would make it their problem to implement in
> their wallet, or ask the wallet vendor/maintainer they're working with
> to do it. Nothing breaks if they dont use it.
I don't see how this is the case. If an exchange supports extension blocks
and I withdraw from that to a wallet that doesn't, the money will never
arrive from my perspective. Yet the exchange will claim they sent it and
they will wash their hands of the matter. Disaster.
I am not a UX guy
>
But I am. I've designed both consumer and engineering UI's at Google, and
also more recently for Lighthouse.
Attempting to explain to a user why they sent money that didn't show up on
the other end is a non starter. It's bad enough when things take a long
time to confirm or bugs cause propagation failures. Doing it
deliberately is not going to work. Payments *must* be reliable and wallets
*must* be compatible with each other.
This is one reason why a Lightning style approach also isn't going to work
any time soon. For example, it would require people to abandon Bitcoin
addresses. I pushed for that before, around the P2SH time, and Gavin
correctly intuited that the community wasn't ready for it yet. I'm not sure
much has changed.
> Because the more complex one is safer, more flexible, more future
> proof and better for decentralisation
I disagree with all of those points. I find Lightning/Stroem etc to be more
dangerous, less flexible, and worse for decentralisation. I explain why
here:
https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e
You mentioned decentralisation metrics. Gregory's post is ignoring one of
the most important decentralisation metrics, which is number of wallets
made by independent developers. That has got dramatically better over time.
It would get worse if wallets became more complex very suddenly.
> As an aside, a risk with using companies as a sounding board, is that
> you can get a misleading sense of consensus.
>From what I can tell Blockstream employees are just ignoring those
companies entirely, which will give you a radically more distorted view of
the consensus. As companies providing services to our community have
serious economic weight, it stands to reason that their opinions would
matter a great deal. Yet on this mailing list I see zero effort to even
recognise their concerns, let alone care about them.
<https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
Anyway, let me repeat again to make it clear - as someone who has spent
five years writing SPV wallets, I am not on board with extension blocks or
any other Rube Goldberg contraption that exists purely to work around
theoretical objections by Blockstream employees+Peter Todd, which is what
this feels like to me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/044693d8/attachment.html>

2023-06-07 15:36:14

- reply

📅 Original date posted:2015-06-02
📝 Original message:>
> 1,000 *people* in control vs. 10 is two orders of
magnitude more decentralized.
Yet Bitcoin has got worse by all these metrics: there was a time before
mining pools when there were ~thousands of people mining with their local
CPUs and GPUs. Now the number of full nodes that matter for block selection
number in the dozens, and all the other miners just follow their blocks
blindly.
If you really believe that decentralisation is, itself, the end, then why
not go use an "ASIC resistant" alt coin with no SPV or web wallets which
resembles Bitcoin at the end of 2009? That'd be a whole lot more
decentralised than what you have now.
The *percentage* of the community that mines is totally irrelevant, it's
> the absolute number of (independent) people that matters.
>
So usage does matter, then? You'd rather have a coin that has power
concentrated in a far smaller elite, proportionally, but has overall more
usage? If there are say, 5000 full nodes today, and in ten years there are
6000, and they all run in vast datacenters and are owned by large
companies, you'll feel like Bitcoin is more decentralised than ever?
(n.b. I do not think this situation will ever happen, it's just an example).
That's not the vibe I'm getting from most people on this list. What I'm
seeing is complaints about how in the good old days back when Core was the
only wallet and ASICs hadn't been made, there were lots of nodes and lots
of people mining solo and since then it's all been downhill and woe is us
... and let's throw on the brakes in case it gets worse.
Not for the first time, these discussions remind me very strongly of the
old desktop Linux/free software debates.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150602/0a67d49c/attachment.html>

2023-06-07 15:36:13

- reply

📅 Original date posted:2015-06-01
📝 Original message:>
> It's surprising to see a core dev going to the public to defend a proposal
> most other core devs disagree on, and then lobbying the Bitcoin ecosystem.
>
I agree that it is a waste of time. Many agree. The Bitcoin ecosystem
doesn't really need lobbying - my experience from talking to businesses and
wallet developers months ago is they virtually all see raising capacity as
a no brainer ... and some of them see this "debate" as despair-inducing
insanity.
What's happened here is that a small number of people have come to believe
they have veto power over changes to Bitcoin, and they have also become
*wildly* out of step with what the wider community wants. That cannot last.
So, short of some sudden change of heart that lets us kick the can down the
road a bit longer, a fork is inevitable.
Just be glad it's Gavin driving this and not me ... or a faceless coalition
of startups.
> Decentralization is the core of Bitcoin's security model and thus that's
> what gives Bitcoin its value.
>
No. Usage is what gives Bitcoin value.
It's kind of maddening that I have to point this out. Decentralisation is a
means to an end. I first used Bitcoin in April 2009 and it was perfectly
decentralised back then: every wallet was a full node and every computer
was capable of mining.
So if you believe what you just wrote, I guess Bitcoin's value has gone
down every day since.
On the other hand, if you believe the markets, Bitcoin's value has gone up.
Apparently the question of what gives Bitcoin its value is a bit more
complicated than that.
> : to incentive layer 2 and offchain solutions to scale Bitcoin : there are
> promising designs/solutions out there (LN, ChainDB, OtherCoin protocole,
> ...), but most don't get much attention, because there is right now no need
> for them. And, I am sure new solutions will be invented.
>
I have seen this notion a few times. I would like to dispose of it right
now.
I am one of the wallet developers you would be trying to "incentivise" by
letting Bitcoin break, and I say: get real. Developers are not some
bottomless fountain of work that will spit out whatever you like for free
if you twist their arms badly enough.
The problems that incentivised the creation of Bitcoin existed for decades
before Bitcoin was actually invented. Incentives are not enough. Someone
has to actually do the work, too. All proposals on the table would:
- Involve enormous amounts of effort from many different people
- Be technically risky (read: we don't know if they would even work)
- Not be Bitcoin
The last point is important: people who got interested in Bitcoin and
decided to devote their time to it might not feel the same way about some
network of payment hubs or whatever today's fashion is. Faced with their
work being broken by armchair developers on some mailing list, they might
just say screw it and walk away completely.
After all, as the arguments for these systems are not particularly logical,
they might slave over hot keyboards for a year to support the Lightning
Network or whatever and then discover that it's no longer the fashionable
thing ... and that suddenly an even more convoluted design is being
"incentivised".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/cfb40524/attachment.html>

2023-06-07 15:36:09

- reply

📅 Original date posted:2015-06-01
📝 Original message:I don't see this as an issue of sensitivity or not. Miners are businesses
that sell a service to Bitcoin users - the service of ordering transactions
chronologically. They aren't charities.
If some miners can't provide the service Bitcoin users need any more, then
OK, they should not/cannot mine. Lots of miners have come and gone since
Bitcoin started as different technology generations came and went. That's
just business.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/f2f7017a/attachment.html>

2023-06-07 15:36:07

- reply

📅 Original date posted:2015-06-01
📝 Original message:>
> Ignorant. You seem do not understand the current situation. We
> suffered from orphans a lot when we started in 2013. It is now your
> turn.
Then please enlighten me. You're unable to download block templates from a
trusted node outside of the country because the bandwidth requirements are
too high? Or due to some other problem?
With respect to "now it's your turn". Let's imagine the hard fork goes
ahead. Let us assume that almost all exchanges, payment processors and
other businesses go with larger blocks, but Chinese miners do not.
Then you will mine coins that will not be recognised on trading platforms
and cannot be sold. Your losses will be much larger than from orphans.
This can happen *even* if Chinese miners who can't/won't scale up are >50%
hashrate. SPV clients would need a forced checkpoint, which would be messy
and undesirable, but it's technically feasible. The smaller side of the
chain would cease to exist from the perspective of people actually trading
coins.
If your internet connectivity situation is really so poor that you cannot
handle one or two megabits out of the country then you're hanging on by
your fingernails anyway: your connection to the main internet could become
completely unusable at any time. If that's really the case, it seems to me
that Chinese Bitcoin is unsustainable and what you really need is a
China-specific alt coin that can run entirely within the Chinese internet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/cf20069e/attachment.html>

2023-06-07 15:36:05

- reply

📅 Original date posted:2015-06-01
📝 Original message:I'm OK with a smaller size + a formula that ramps it up over time. We are
far from having enough demand to fill 10MB blocks, let alone 20MB today.
To put it in perspective, to be feeling squeezed inside 10MB within two
years, we would need to double usage five times. I wish I knew a way to
make that happen. So the chances of us going to 20MB blocks full of real
transactions any time soon is close to zero short of some amazing killer
app that takes the world by storm (in which case: yay, nice problem to
have). As long as capacity significantly outpaces organic growth, we should
avoid problems.
The reason to pick 20MB then is merely one of expedience: we have to pick a
number, 20 is tested and seems to work, and we don't want to get caught by
surprise if demand does outstrip expectations.
Still, I question the underlying logic. We have no idea what connectivity
into China will look like a few years from now: it's seems to be a function
of politics rather than hardware trends. It might go down rather than up.
So 10 vs 20 feels a bit arbitrary. We can't let the Chinese government
dictate how Bitcoin is used, that would never be accepted by the rest of
the world. But if we optimistically assume things don't get worse, and 10
== more acceptance, then alright - it should make no difference in practice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/e1fcd67d/attachment.html>

2023-06-07 15:35:50

- reply

📅 Original date posted:2015-05-27
📝 Original message:>
> Mike, this proposal was purposefully constructed to maintain as well as
> possible the semantics of Satoshi's original construction. Higher sequence
> numbers -- chronologically later transactions -- are able to hit the chain
> earlier, and therefore it can be reasonably argued will be selected by
> miners before the later transactions mature. Did I fail in some way to
> capture that original intent?
>
Right, but the original protocol allowed for e.g. millions of revisions of
the transaction, hence for high frequency trading (that's actually how
Satoshi originally explained it to me - as a way to do HFT - back then the
channel concept didn't exist).
As you point out, with a careful construction of channels you should only
need to bump the sequence number when the channel reverses direction. If
your app only needs to do that rarely, it's a fine approach.And your
proposal does sounds better than sequence numbers being useless like at the
moment. I'm just wondering if we can get back to the original somehow or at
least leave a path open to it, as it seems to be a superset of all other
proposals, features-wise.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150527/8c096952/attachment.html>

2023-06-07 15:35:49

- reply

📅 Original date posted:2015-05-27
📝 Original message:>
> Sequence numbers appear to have been originally intended as a mechanism
> for transaction replacement within the context of multi-party transaction
> construction, e.g. a micropayment channel.
>
Yes indeed they were. Satoshis mechanism was more general than micropayment
channels and could do HFT between any set of parties.
> As it happens, this cannot be made safe in the bitcoin protocol as
> deployed today, as there is no enforcement of the rule that miners include
> the most recent transaction in their blocks.
>
Safe is relative - this is the same logic the original replace-by-fee
argument uses. There's no enforcement that miners use any particular
ordering of transactions.
As I believe out of all proposed protocols Satoshi's is still the most
powerful, I would suggest that any change to the semantics on nSequence be
gated by a high bit or something, so the original meaning remains available
if/when resource scheduling and update flood damping are implemented. That
way people can try it out and if miners are breaking things too frequently
by ignoring the chronological ordering people can abandon protocols that
rely on it, and if they aren't they can proceed and benefit from the
greater flexibility.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150527/4ed103cd/attachment.html>

2023-06-07 15:35:37

- reply

📅 Original date posted:2015-05-26
📝 Original message:Very interesting Matt.
For what it's worth, in future bitcoinj is very likely to bootstrap from
Cartographer nodes (signed HTTP) rather than DNS, and we're also steadily
working towards Tor by default. So this approach will probably stop working
at some point. As breaking PorcFest would kind of suck, we might want a
ZeroConf/Rendezvous solution in place so local LANs can capture Bitcoin
traffic away from Tor (with some notification to the user, presumably).
On Tue, May 26, 2015 at 7:47 AM, Matt Whitlock <bip at mattwhitlock.name>
wrote:
> On Tuesday, 26 May 2015, at 1:15 am, Peter Todd wrote:
> > On Tue, May 26, 2015 at 12:52:07AM -0400, Matt Whitlock wrote:
> > > On Monday, 25 May 2015, at 11:48 pm, Jim Phillips wrote:
> > > > Do any wallets actually do this yet?
> > >
> > > Not that I know of, but they do seed their address database via DNS,
> which you can poison if you control the LAN's DNS resolver. I did this for
> a Bitcoin-only Wi-Fi network I operated at a remote festival. We had well
> over a hundred lightweight wallets, all trying to connect to the Bitcoin
> P2P network over a very bandwidth-constrained Internet link, so I poisoned
> the DNS and rejected all outbound connection attempts on port 8333, to
> force all the wallets to connect to a single local full node, which had
> connectivity to a single remote node over the Internet. Thus, all the
> lightweight wallets at the festival had Bitcoin network connectivity, but
> we only needed to backhaul the Bitcoin network's transaction traffic once.
> >
> > Interesting!
> >
> > What festival was this?
>
> The Porcupine Freedom Festival ("PorcFest") in New Hampshire last summer.
> I strongly suspect that it's the largest gathering of Bitcoin users at any
> event that is not specifically Bitcoin-themed. There's a lot of overlap
> between the Bitcoin and liberty communities. PorcFest draws somewhere
> around 1000-2000 attendees, a solid quarter of whom have Bitcoin wallets on
> their mobile devices.
>
> The backhaul was a 3G cellular Internet connection, and the local Bitcoin
> node and network router were hosted on a Raspberry Pi with some Netfilter
> tricks to restrict connectivity. The net result was that all Bitcoin nodes
> (lightweight and heavyweight) on the local Wi-Fi network were unable to
> connect to any Bitcoin nodes except for the local node, which they
> discovered via DNS. I also had provisions in place to allow outbound
> connectivity to the API servers for Mycelium, Blockchain, and Coinbase
> wallets, by feeding the DNS resolver's results in real-time into a
> whitelisting Netfilter rule utilizing IP Sets.
>
> For your amusement, here's the graphic for the banner that I had made to
> advertise the network at the festival (*chuckle*):
> http://www.mattwhitlock.com/bitcoin_wifi.png
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150526/31cce561/attachment.html>

2023-06-07 15:35:31

- reply

📅 Original date posted:2015-05-25
📝 Original message:Very nice Emin! This could be very useful as a building block for oracle
based services. If only there were opcodes for working with X.509 ;)
I'd suggest at least documenting in the FAQ how to extract the data from
the certificate:
openssl pkcs12 -in virtual-notary-cert-stocks-16070.p12 -nodes -passin
pass:"" | openssl x509 -text|less
That's good enough to get started, but I note two issues:
1. X.509 is kind of annoying to work with: example code in popular
languages/frameworks to extract the statement would be useful.
2. The stock price plugin, at least, embeds the data as text inside the
X.509 certificate. That's also not terribly developer friendly and risks
parsing errors undermining security schemes built on it.
The way I'd solve this is to embed either a protocol buffer or DER
encoded structure inside the extension, so developers can extract the
notarised data directly, without needing to do any additional parsing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150525/eae53ab1/attachment.html>