<unnamed>

Public Key

npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd

Profile Code

nprofile1qqs09j2a7dmx2chrh94hngp9fzqut85x88ernpuyd9su742p9fmlduspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds7n2h95

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-07 19:42:38 CEST

- 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 19:42:01 CEST

- reply

📅 Original date posted:2015-10-05
📝 Original message:>
> As Greg explained to you repeatedly, a softfork won't cause a
> non-upgraded full node to start accepting blocks that create more
> subsidy than is valid.
>
It was an example. Adam Back's extension blocks proposal would, in fact,
allow for a soft forking change that creates more subsidy than is valid (or
does anything else) by hiding one block inside another.
Anyway, I think you got my point.
> That's very different security from an SPV node, and as Greg
> also explained, SPV nodes could be much more secure than bitcoinj
> nodes (they could, for example, validate the coinbase transaction of
> every block).
>
I'm pretty sure Gregory did not use such an example because it's dead
wrong. You cannot verify the size of a coinbase without being a fully
verifying node because you need to know the fees in the block, and
calculating that requires access to the entire UTXO set.
This sort of thing is why I get annoyed when people lecture me about SPV
wallets and the things they "should" do. None of you guys has built one. I
keep seeing wild statements about theoretical unicorn wallets that nobody
has even designed, and how all existing wallets are crappy and insecure
because they don't meet your ever shifting goal posts.
To everyone making such statements I say: go away and build an SPV wallet
of your own from scratch. Then you will understand the engineering
tradeoffs involved much better, and be in a much better position to debate
what they should or should not be doing.
And bear in mind if it weren't for the work myself and a few others did on
SPV wallets, everyone would be using web wallets instead. Then you'd all
just complain about that instead.
> Can you give an example of an attack in which a non-upgraded full node
> wallet is defrauded with BIP65 but could not with the hardfork
> alternative (that nobody seems to be willing to implement)?
>
Making it a hard fork instead is changing one line of code (ignoring the
code to set up the flag day, which can be based on the code for BIP101). If
it comes down to it, then I'll do the work to change that one line. But
obviously I'd need to see agreement from the maintainers that such a pull
req would be merged first.
The example is this: find someone that accepts 1-block confirmed
transactions in return for something valuable. There are plenty of them out
there. Once the soft fork starts, send a P2SH transaction that defines a
new output controlled by OP_CLTV. It will be incorporated into the UTXO set
by all miners because it's opaque (p2sh).
Now send a transaction that pays the merchant, and make it spend your
OP_CLTV output with an invalid script. New nodes will reject it as a rule
violator. Old nodes won't. So at some point an old miner will create a
block containing your invalid transaction, the merchant will think they got
paid, they'll give you the stuff and the fraud is done.
> Please, don't assume 0 confirmation transactions or similar
> unreasonable assumptions (ie see section 11 "Calculations" of the
> Bitcoin whitepaper).
>
This is just embarrassing - do any of you guys at Blockstream actually use
Bitcoin in the real world? Virtually all payments that aren't moving money
into/out of exchange wallets are 0-confirm in reality. I described a
1-confirm attack above, but really ... come on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/601a316d/attachment.html>

2023-06-07 19:42:01 CEST

- 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 19:41:58 CEST

- 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 19:41:58 CEST

- 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 19:41:36 CEST

- 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 19:41:36 CEST

- 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 19:41:35 CEST

- 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 19:41:34 CEST

- reply

📅 Original date posted:2015-09-28
📝 Original message:>
> Ok, so again, if that's your security criteria, what's the issue
> with soft-forks?
Please read my article as it's all explained there.
But to reiterate: the risk is that miners will build invalid blocks on top
of the best work chain, instead of an ignored lower work side chain. This
opens users to payment fraud. With a hard fork, all the blocks by miners
that aren't checking all the rules anymore get neatly collected together on
a side chain after the split, and wallets all know how to ignore that chain.
Yes, you made OP_NOPs be non-standard. So out of the box, miners won't
create invalid blocks, as long as they're running Core past that version.
But this makes the IsStandard function very much like a part of the
consensus rules, as bypassing it can result in invalid blocks being
created. Miners have always understood that they can modify this function,
or even bypass it entirely, without affecting the validity of their blocks.
And some miners do exactly that.
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/7c9e36e4/attachment.html>

2023-06-07 19:41:33 CEST

- 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 19:41:30 CEST

- 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 19:41:29 CEST

- 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 19:41:28 CEST

- 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 19:41:28 CEST

- 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 19:41:27 CEST

- 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 19:40:33 CEST

- 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 19:40:31 CEST

- 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 19:40:29 CEST

- 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 19:40:28 CEST

- reply

📅 Original date posted:2015-09-18
📝 Original message:Any change that results in this happening all over again in a few years
does not have consensus.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/04e0e9b6/attachment.html>

2023-06-07 19:38:38 CEST

- reply

📅 Original date posted:2015-08-31
📝 Original message:I think your summary of what people actually want from decentralisation is
pretty good, Justus.
> I don't believe that any Bitcoin user actually cares
> about decentralization, because none of them I've asked can define that
> term.
>
+1 Insightful
It's been quite impressive to see so many Bitcoin users and developers
saying, "Bitcoin is totally decentralised because it's open source and
nobody is in charge...... oh nooooooo we didn't mean you could change *those
lines! *If you want to change *those lines* then *we* must agree first!"
Believing simultaneously that:
1. Bitcoin is decentralised
2. Nobody should modify the code in certain ways without the agreement of
me and my buddies
is just doublethink.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150831/d0a2bac3/attachment.html>

2023-06-07 19:35:24 CEST

- 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>

2023-06-07 19:35:13 CEST

- 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 19:35:12 CEST

- 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 19:32:35 CEST

- reply

📅 Original date posted:2015-08-06
📝 Original message:Whilst 1mb to 8mb might seem irrelevant from a pure computer science
perspective payment demand is not really infinite, at least not if by
"payment" we mean something resembling how current Bitcoin users use the
network.
If we define "payment" to mean the kind of thing that Bitcoin users and
enthusiasts have been doing up until now, then suddenly 1mb to 8mb makes a
ton of sense and doesn't really seem that small: we'd have to increase
usage by nearly an order of magnitude before it becomes an issue again!
If we think of Bitcoin as a business that serves customers, growing our
user base by an order of magnitude would be a great and celebration worthy
achievement! Not at all a small constant factor :)
And keeping the current user base happy and buying things is extremely
interesting, both to me and Gavin. Without users Bitcoin is nothing at all.
Not a settlement network, not anything.
It's actually going to be quite hard to grow that much. As the white paper
says, "the system works well enough for most transactions". And despite a
lot of effort by many people, killer apps that use Bitcoin's unique
features are still hit and miss. Perhaps Streamium, Lighthouse, ChangeTip,
some distributed exchange or something else will stimulate huge new demand
for transactions in future ..... but if so we're not there yet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150806/e2ebb63a/attachment.html>

2023-06-07 17:49:04 CEST

- 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:47:12 CEST

- reply

2023-06-07 17:47:03 CEST

- reply

2023-06-07 17:47:03 CEST

- reply

2023-06-07 17:44:53 CEST

- reply

2023-06-07 17:43:44 CEST

- 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 17:43:43 CEST

- 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 17:43:04 CEST

- 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 17:43:04 CEST

- 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 17:43:01 CEST

- 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 17:42:45 CEST

- 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 17:38:41 CEST

- 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 17:38:38 CEST

- reply

📅 Original date posted:2015-06-19
📝 Original message:>
> Yeah, but increasing block-size is not a longterm solution.
Are you sure? That sort of statement is hard to answer because it doesn't
say what you think long term is, or how much you expect Bitcoin to grow.
Satoshi thought it was a perfectly fine long term solution because he
thought hardware would get cheaper as fast or faster than Bitcoin would
grow. You may disagree with him, but as we're talking about the future are
you 100% certain he was wrong? I did calculations a long time ago that
suggested even with today's hardware (+some software optimisations) it
would be feasible to keep up with Visa.
Hardware improvements can be unintuitive. There's a spreadsheet here that
lets you play with various parameters.
https://docs.google.com/spreadsheets/d/1PJvrAAOVYVszfRRLhKqd1R9lRiOAImzAfdeb6ajATEY/edit#gid=1451669128
(note: the spreadsheet says avg txn size is 250 bytes, but if you check the
formula for the middle column, it does actually use 500 bytes as the
multiplier hard coded).
> Necessary higher fees are a logical consequence of lower subsidies.
> Bitcoin was basically free to use at the beginning because miners got paid
> with new coins at the expense of those who already hold coins.
> Eventually there needs to be a mechanism which matches supply and demand.
>
That's not clear either, I'm afraid.
Remember that there's an upper limit on how high Bitcoin fees can go. When
fees become higher than what the banking system charges, many users won't
use Bitcoin for moving money around anymore. Fees cannot really go much
higher than that even if you assume the currency is still attractive for
other reasons, because people would just sell their coins for fiat, move
the fiat, and buy back the coins the other side.
The way mining will be funded in future is an open question. There are
differing proposals. Still, even with a higher hard block size limit,
miners can always refuse to mine transactions that don't include a
particular fee. So if you're worried about this, miners aren't being forced
into any particular policy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/e6f72ab6/attachment.html>

2023-06-07 17:38:37 CEST

- 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 17:38:29 CEST

- 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 17:38:28 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:Hi Pieter,
I believe Gavin plans to write a blog post about the hard fork process, but
I'd like to debate this with you now, if only to give him material to work
with :)
Your points look to me like the hard/soft fork debate in different clothes.
For example, we all agree that the rules of Bitcoin *can* be changed, and
have been before (e.g. P2SH), with software upgrades.
When such a fork happens, any user who does not upgrade their node isn't
fully verifying the block chain anymore. Their software might *think* it
is, but it's running NOPs that don't mean NOP to other nodes. So there is a
divergence in the consensus, it's merely been done in such a way that the
node won't stop and print "hard fork detected" to the logs. It'll happily
accept a block that violates the new rules, then wait to be corrected by
miners.
So with any fork, hard or soft, there is risk to those who don't upgrade.
They may accept a block, or even two blocks, that they believe are valid
according to their old rule set, but which other miners would reject. The
effect on double spending is much the same.
Now let's talk philosophy.
* Philosophy: Bitcoin is not a democracy.
>
This appears to be a key point of dispute. Bitcoin is a democracy, though
the analogy is not perfect. You can certainly believe whatever you like
about the true state of the ledger, but rubber hits the road the moment you
go and trade with other people.
If 90% of the people you trade with believe a coin exists, and you don't,
you're gonna discover you keep getting paid with that coin and its
descendents. You may hate it, you may feel your rights are being violated,
you may refuse to trade with those people but it will keep happening.
Money is about trade, and trade inherently involves the decisions of other
people. No man is an island.
With Bitcoin we have a great way to quickly find out what other people
believe about the ledger. If the vast majority of people are on ledger A
and you're on ledger B, then you've got a strong incentive to come into
line with the majority in order to keep trading.
> Changing the rules should be possible if there is wide consensus, but
> nobody should feel forced to change their code against their will.
>
Nobody, not even after a hard fork, is *forced* to change their code
against their will. It may be something that *other people require* as part
of trading with them though. Whether one considers this "forced" or not I
guess can be argued either way. Are you "forced" to buy oranges from the
single orange seller in town if the other goes bankrupt, or could you just
avoid oranges? Where does economic freedom begin and end?
> * Governance: being able to push for a controversial change to the system
> sets an incredibly dangerous precedent about who is in charge of the
> system's rules.
>
I think it's surely the opposite - *not* being able to push for
controversial changes sets an incredibly dangerous precedent. Namely,
whoever gets to decide that a change is controversial gets to veto anything
they like!
> I can promise you that I will say anything in mail to this list if someone
> points a gun at me
>
Indeed, me too! But it's worse than that: what if someone sockpuppets a
discussion to make it look like a change does or does not have consensus?
One reason I keep banging on about *process* and how Wladimir needs to be
The Decider is that the current attempt at "process" is so vague, not only
is it unexplainable, but it's wide open to manipulation.
Good thing we have a way to resolve this problem: the block chain. Now it
doesn't matter if someone points a gun at you or me. We can object to
whatever we like and that wouldn't bring Bitcoin to a halt, thus removing
the incentive to try and pressure individuals.
But if we don't have that ability to vote through choice of software and
rulesets, then us poor developers really are in charge and that's not a
place any of us should want to go. There must be a mechanism for people to
disagree with the consensus, even in major, controversial ways, and that
mechanism must have real force to it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/9f95c39c/attachment.html>

2023-06-07 17:38:27 CEST

- 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 17:38:26 CEST

- 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 17:38:16 CEST

- 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 17:38:16 CEST

- 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 17:38:11 CEST

- 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 17:38:09 CEST

- 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 17:36:13 CEST

- 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 17:35:18 CEST

- reply

📅 Original date posted:2015-05-25
📝 Original message:>
> If capacity grows, fewer individuals would be able to run full nodes.
>
Hardly. Nobody is currently exhausting the CPU capacity of even a normal
computer currently and even if we did a 20x increase in load overnight,
that still wouldn't even warm up most machines good enough to be always on.
The reasons full nodes are unpopular to run seem to be:
1. Uncontrollable bandwidth usage from sending people the chain
2. People don't run them all the time, then don't want to wait for them to
catch up
The first can be fixed with better code (you can already easily opt out of
uploading the chain, it's just not as fine-grained as desirable), and the
second is fundamental to what full nodes do and how people work. For
merchants, who are the most important demographic we want to be using full
nodes, they can just keep it running all the time. No biggie.
> Therefore miners and other full nodes would depend on
> it, which is rather critical as those nodes grow closer to data-center
> proportions.
>
This meme about datacenter-sized nodes has to die. The Bitcoin wiki is down
right now, but I showed years ago that you could keep up with VISA on a
single well specced server with today's technology. Only people living in a
dreamworld think that Bitcoin might actually have to match that level of
transaction demand with today's hardware. As noted previously, "too many
users" is simply not a problem Bitcoin has .... and may never have!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150525/2b8563b3/attachment.html>

2023-06-07 17:34:08 CEST

- reply

📅 Original date posted:2015-05-29
📝 Original message:>
> The measure is miner consensus. How do you intend to measure
> exchange/merchant acceptance?
>
Asking them.
In fact, we already have. I have been talking to well known people and CEOs
in the Bitcoin community for some time now. *All* of them support bigger
blocks, this includes:
- Every wallet developer I have asked (other than Bitcoin Core)
- So far, every payment processor and every exchange company
I know Gavin has also been talking to people about this.
There's a feeling on this list that there's no consensus, or that Gavin and
myself are on the wrong side of it. I'd put it differently - there's very
strong consensus out in the wider community and this list is something of
an aberration.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/d159d41b/attachment.html>

2023-06-07 17:34:07 CEST

- reply

📅 Original date posted:2015-05-29
📝 Original message:>
> And looking at the version (aka user-agent) strings of publicly reachable
> nodes on the network.
> (e.g. see the count at https://getaddr.bitnodes.io/nodes/ )
>
Yeah, though FYI Luke informed me last week that I somehow managed to take
out the change to the user-agent string in Bitcoin XT, presumably I made a
mistake during a rebase of the rebranding change. So the actual number of
XT nodes is a bit higher than counting user-agent strings would suggest.
I sort of neglected XT lately. If we go ahead with this then I'll fix
things like this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/83bc21bf/attachment.html>

2023-06-07 17:34:06 CEST

- reply

📅 Original date posted:2015-05-29
📝 Original message:>
> If the plan is a fix once and for all, then that should be changed too.
> It could be set so that it is at least some multiple of the max block size
> allowed.
>
Well, but RAM is not infinite :-) Effectively what these caps are doing is
setting the minimum hardware requirements for running a Bitcoin node.
That's OK by me - I don't think we are actually going to exhaust the
hardware abilities of any reasonable computer any time soon, but still,
having the software recognise the finite nature of a computing machine
doesn't seem unwise.
> That system can send a block of any size. It would require a change to
> the processing of any merkleblocks received.
>
Not "any" size because, again, the remote node must buffer things up and
have the transaction data actually in memory in order to digest it. But a
much larger size, yes.
However, that's a bigger change.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/6aebe66a/attachment.html>

2023-06-07 17:34:05 CEST

- reply

📅 Original date posted:2015-05-29
📝 Original message:>
> By the time a hard fork can happen, I expect average block size will be
> above 500K.
>
Yes, possibly.
> Would you support a rule that was "larger of 1MB or 2x average size" ?
> That is strictly better than the situation we're in today.
>
It is, but only by a trivial amount - hitting the limit is still very
likely. I don't want to see this issue come up over and over again. Ideally
never. We shouldn't be artificially throttling organic growth of the
network, especially not by accident.
IMO it's not even clear there needs to be a size limit at all. Currently
the 32mb message cap imposes one anyway, but if miners can always just
discourage blocks over some particular size if they want to.
But I can get behind a 20mb limit (or 20mb+N) as it represents a reasonable
compromise: the limit still exists, it's far below VISA capacity etc, but
it should also free up enough space that everyone can get back to what we
*should* be focusing on, which is user growth!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/9ca670f1/attachment.html>

2023-06-07 17:34:04 CEST

- reply

📅 Original date posted:2015-05-28
📝 Original message:>
> Even a 2x rule (implying 800K max blocks) would, today, be squeezing out
> transactions / putting pressure to increase fees .....
>
> So my straw-man proposal would be: max size 2x average size over last 144
> blocks, calculated at every block.
>
Isn't that a step backwards, then? I see no reason for fee pressure to
exist at the moment. All it's doing is turning away users for no purpose:
mining isn't supported by fees, and the tiny fees we use right now seem to
be good enough to stop penny flooding.
Why not set the max size to be 20x the average size? Why 2x, given you just
pointed out that'd result in blocks shrinking rather than growing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150528/1e8e17c3/attachment.html>

2023-06-07 17:34:04 CEST

- reply

📅 Original date posted:2015-05-28
📝 Original message:>
> Twenty is scary.
>
To whom? The only justification for the max size is DoS attacks, right?
Back when Bitcoin had an average block size of 10kb, the max block size was
100x the average. Things worked fine, nobody was scared.
The max block size is really a limit set by hardware capability, which is
something that's difficult to measure in software. I think I preferred your
original formula that guesstimated based on previous trends to one that
just tries to follow some average.
As noted, many miners just accept the defaults. With your proposed change
their target would effectively *drop* from 1mb to 800kb today, which seems
crazy. That's the exact opposite of what is needed right now.
I am very skeptical about this idea.
> I don't think us developers should be deciding things like whether or not
> fees are too high, too low,
>
Miners can already attempt to apply fee pressure by just not mining
transactions that they feel don't pay enough. Some sort of auto-cartel that
attempts to restrict supply based on everyone looking at everyone else
feels overly complex and prone to strange situations: it looks a lot like
some kind of Mexican standoff to me.
Additionally, the justification for the block size limit was DoS by someone
mining "troll blocks". It was never meant to be about fee pressure.
Resource management inside Bitcoin Core is certainly something to be
handled by developers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150528/3359ad4a/attachment.html>

2023-06-07 17:33:54 CEST

- reply

📅 Original date posted:2015-05-08
📝 Original message:There are certainly arguments to be made for and against all of these
proposals.
The fixed 20mb cap isn't actually my proposal at all, it is from Gavin. I
am supporting it because anything is better than nothing. Gavin originally
proposed the block size be a function of time. That got dropped, I suppose
to make the process of getting consensus easier. It is "the simplest thing
that can possibly work".
I would like to see the process of chain forking becoming less traumatic. I
remember Gavin, Jeff and I once considered (on stage at a conference??)
that maybe there should be a scheduled fork every year, so people know when
to expect them.
If everything goes well, I see no reason why 20mb would be the limit
forever.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/557fa94d/attachment.html>

2023-06-07 17:33:40 CEST

- reply

📅 Original date posted:2015-05-08
📝 Original message:>
> * Though there are many proposals floating around which could
> significantly decrease block propagation latency, none of them are
> implemented today.
With a 20mb cap, miners still have the option of the soft limit.
I would actually be quite surprised if there were no point along the road
from 1mb to 20mb where miners felt a need to throttle their block sizes
artificially, for the exact reason you point out: propagation delays.
But we don't *need* to have fancy protocol upgrades implemented right now.
All we need is to demolish one bottleneck (the hard cap) so we can then
move on and demolish the next one (whatever that is, probably faster
propagation). Scaling is a series of walls we punch through as we encounter
them. One down, onto the next. We don't have to tackle them all
simultaneously.
FWIW I don't think the GFW just triggers packet loss, these days. It's
blocked port 8333 entirely.
* I'd very much like to see someone working on better scaling
> technology ... I know StrawPay is working on development,
>
So this request is already satisfied, isn't it? As you point out, expecting
more at this stage in development is unreasonable, there's nothing for
anyone to experiment with or commit to.
They have code here, by the way:
https://github.com/strawpay
You can find their fork of MultiBit HD, their implementation library, etc.
They've contributed patches and improvements to the payment channels code
we wrote.
> * I'd like to see some better conclusions to the discussion around
> long-term incentives within the system.
>
What are your thoughts on using assurance contracts to fund network
security?
I don't *know* if hashing assurance contracts (HACs) will work. But I don't
know they won't work either. And right now I'm pretty sure that plain old
fee pressure won't work. Demand doesn't outstrip supply forever - people
find substitutes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/431f2412/attachment.html>

2023-06-07 17:33:16 CEST

- reply

📅 Original date posted:2015-05-07
📝 Original message:>
> I think you are rubbing against your own presupposition that people must
> find and alternative right now. Quite a lot here do not believe there is
> any urgency, nor that there is an immanent problem that has to be solved
> before the sky falls in.
>
I have explained why I believe there is some urgency, whereby "some
urgency" I mean, assuming it takes months to implement, merge, test,
release and for people to upgrade.
But if it makes you happy, imagine that this discussion happens all over
again next year and I ask the same question.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/90b46e94/attachment.html>

2023-06-07 17:33:15 CEST

- reply

📅 Original date posted:2015-05-07
📝 Original message:> The only answer to this that anyone with a clue should give is "it
> will very, very likely be able to support at least 1MB blocks roughly
> every 10 minutes on average for the next eleven years, and it seems
> likely that a block size increase of some form will happen at some point in
> the next eleven years", anything else is dishonest.
Matt, you know better than that. Gavin neither lacks clue nor is he
dishonest.
He has been working on the assumption that other developers are reasonable,
and some kind of compromise solution can be found that everyone can live
with. Hence trying to find a middle ground, hence considering and writing
articles in response to every single objection raised. Hence asking for
suggestions on what to change about the plan, to make it more acceptable.
What more do you want, exactly?
And I'll ask again. Do you have a *specific, credible alternative*? Because
so far I'm not seeing one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/55e48fed/attachment.html>

2023-06-07 17:33:13 CEST

- reply

📅 Original date posted:2015-05-07
📝 Original message:> These statements may even be true, but they're no logical conclusions
> even if they seem obvious to you.
> I don't think those claims are strictly true, specially because they
> involve predictions about what people will do.
> But if they're true they require some proof or at least some explanation.
>
Thank you for your patience, Jorge.
I have written up an explanation of what I think will happen if we run out
of capacity:
https://medium.com/@octskyward/crash-landing-f5cc19908e32
Now I'm going to go eat some dinner :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/d9fb7d51/attachment.html>

2023-06-07 17:33:12 CEST

- reply

📅 Original date posted:2015-05-07
📝 Original message:>
> It is a trivial *code* change. It is not a trivial change to the
> economics of a $3.2B system.
>
Hmm - again I'd argue the opposite.
Up until now Bitcoin has been unconstrained by the hard block size limit.
If we raise it, Bitcoin will continue to be unconstrained by it. That's the
default "continue as we are" position.
If it's not raised, then ....... well, then we're in new territory
entirely. Businesses built on the assumption that Bitcoin could become
popular will suddenly have their basic assumptions invalidated. Users will
leave. The technical code change would be zero, but the economic change
would be significant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/29da17a8/attachment.html>

2023-06-07 17:33:11 CEST

- reply

📅 Original date posted:2015-05-07
📝 Original message:>
> What gives Bitcoin value aren't its technical merits but the fact that
> people believe in it.
>
Much of the belief in Bitcoin is that it has a bright future. Certainly the
huge price spikes we've seen were not triggered by equally large spikes in
usage - it's speculation on that future.
I quite agree that if people stop believing in Bitcoin, that will be bad. A
fast way to bring that about will be to deliberately cripple the technology
in order to force people onto something quite different (which probably
won't be payment channel networks).
> I'd argue that if we didn't force through a 20MB fork now, and we ran into
> major network difficulties a year from now and had no other technical
> solutions, that maybe we would get nearly universal agreement
>
I doubt it. The disagreement seems more philosophical than technical. If
Bitcoin fell off a cliff then that'd just be taken as more evidence that
block chains don't work and we should all use some network of payment hubs,
or whatever the fashion of the day is. Or anyone who doesn't want to pay
high fees is unimportant. See all the other justifications Gavin is working
his way through on his blog.
That's why I conclude the opposite - if there is no fork, then people's
confidence in Bitcoin will be seriously damaged. If it's impossible to do
something as trivial as removing a temporary hack Satoshi put in place,
then what about bigger challenges? If the community is really willing to
drive itself off a cliff due to political deadlock, then why bother
building things that use Bitcoin at all?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/56a1fd00/attachment.html>

2023-06-07 17:33:09 CEST

- reply

📅 Original date posted:2015-05-07
📝 Original message:>
> If his explanation was "I will change my mind after we increase block
>
size", I guess the community should say "then we will just ignore your
> nack because it makes no sense".
>
Oh good! We can just kick anyone out of the consensus process if we think
they make no sense.
I guess that means me and Gavin can remove everyone else from the developer
consensus, because we think trying to stop Bitcoin growing makes no sense.
Do you see the problem with this whole notion? It cannot possibly work.
Whenever you try and make the idea of developer consensus work, what you
end up with is "I believe in consensus as long as it goes my way". Which is
worthless.
> One thing is the Bitcoin core project where you could argue that the 5
> committers decide (I don't know why Wladimir would have any more
> authority than the others).
>
Because he is formally the maintainer.
Maybe you dislike that idea. It's so .... centralised. So let's say Gavin
commits his patch, because his authority is equal to all other committers.
Someone else rolls it back. Gavin sets up a cron job to keep committing the
patch. Game over.
You cannot have committers fighting over what goes in and what doesn't.
That's madness. There must be a single decision maker for any given
codebase.
> Ok, so in simple terms, you expect people to have to pay enormous fees
> and/or wait thousands of blocks for their transactions to get included
> in the chain. Is that correct?
>
No. I'll write an article like the others, it's better than email for more
complicated discourse.
As others have said, if the answer is "forever, adoption is always the most
> important thing" then we will end up with an improved version of Visa.
>
This appears to be another one of those fundamental areas of disagreement.
I believe there is no chance of Bitcoin ending up like Visa, even if it is
wildly successful. I did the calculations years ago that show that won't
happen:
https://en.bitcoin.it/wiki/Scalability
Decentralisation is a spectrum and Bitcoin will move around on that
spectrum over time. But claiming we have to pick between 1mb blocks and
"Bitcoin = VISA" is silly.
Peter: your hypocrisy really is bottomless, isn't it? You constantly
claim to be a Righteous Defender of Privacy, but don't even hesitate before
publishing hacked private emails when it suits you.
Satoshi's hacker had no illusions about your horrible personality, which is
why he forwarded that email to you specifically. He knew you'd use it. You
should reflect on that fact. It says nothing good about you at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/2785795e/attachment.html>

2023-06-07 17:33:08 CEST

- reply

📅 Original date posted:2015-05-07
📝 Original message:>
> Can you please elaborate on what terrible things will happen if we
> don't increase the block size by winter this year?
>
I was referring to winter next year. 0.12 isn't scheduled until the end of
the year, according to Wladimir. I explained where this figure comes from
in this article:
https://medium.com/@octskyward/bitcoin-s-seasonal-affective-disorder-35733bab760d
It's a fairly simple estimate based on previous growth patterns.
Because I love wild guesses and mine is that full 1 MB blocks will not
> happen until June 2017.
>
OK, it could be. But do you think this debate will play out significantly
differently if you are right, I am wrong, and we have this discussion next
summer instead? Because in several years of watching these debates, I
haven't seen much change in them.
> We've successfully reached consensus for several softfork proposals
> already.
>
Are you sure about that?
What if Gavin popped up right now and said he disagreed with every current
proposal, he disagreed with side chains too, and there would be no
consensus on any of them until the block size limit was raised.
Would you say, oh, OK, guess that's it then. There's no consensus so might
as well scrap all those proposals, as they'll never happen anyway. Bye bye
side chains whitepaper.
> I just hope that by "What we need to see right now is leadership" you
> don't mean something like "when Gaving and Mike agree it's enough to
> deploy a hardfork" when you go from vague to concrete.
>
No. What I meant is that someone (theoretically Wladimir) needs to make a
clear decision. If that decision is "Bitcoin Core will wait and watch the
fireworks when blocks get full", that would be showing leadership .....
albeit I believe in the wrong direction. It would, however, let people know
what's what and let them start to make longer term plans.
This dillydallying around is an issue - people just make vague points that
can't really be disagreed with (more nodes would be nice, smaller pools
would also be nice etc), and nothing gets done.
> "no bitcoin long term it's broken long term but that's far away in the
> future so let's just worry about the present".
>
I never said Bitcoin is broken in the long term. Far from it - I laid out
my ideas for what will happen when the block subsidy dwindles years ago.
But yes, it's hard for me to care overly much about what happens 30 years
from now, for the same reason you probably care more about what happens
tomorrow than what happens after you are dead. The further into the future
you try and plan, the less likely your plans are to survive unscathed.
> What you want to avoid at all cost (the block size actually being
> used), I see as the best opportunity we have to look into the future.
>
I think I see one of the causes of disagreement now.
I will write more on the topic of what will happen if we hit the block size
limit soon, maybe this evening. I have some other tasks to do first.
Regardless, I don't believe we will get any useful data out of such an
event. I've seen distributed systems run out of capacity before. What will
happen instead is technological failure followed by rapid user abandonment
that pushes traffic back below the pressure threshold .... and those users
will most likely not come back any time soon.
> Ok, this is my plan: we wait 12 months, hope that your estimations are
> correct (in case that my guess was better than yours, we keep waiting
> until June 2017) and start having full blocks and people having to
> wait 2 blocks for their transactions to be confirmed some times.
>
I disagree that'd be the outcome, but good, this is progress. Now we need
to hear something like that from Wladimir, or whoever has the final say
around here.
With respect to the fee market: I think it's fairer to say Gavin wants a
market to exist, and he also wants supply to be plentiful. 20mb limit
doesn't actually mean every block will be 20mb the day after, no more than
they're all 1mb today. Miners may discover that if they go beyond 5mb they
have too many orphans and then propagation speed will have to be optimised
to break through the next bottleneck. Scaling is always about finding the
next bottleneck and removing it, ideally, before you hit it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/c1f84cb2/attachment.html>

2023-06-07 17:33:05 CEST

- reply

📅 Original date posted:2015-05-07
📝 Original message:Hey Matt,
OK, let's get started ....
However, there hasnt been any discussion on this
> mailing list in several years as far as I can tell.
>
Probably because this list is not a good place for making progress or
reaching decisions. Those are triggered by pull requests (sometimes).
If you're wondering "why now", that's probably my fault. A few days ago
Wladimir posted a release timeline. I observed to Wladimir and Gavin in
private that this timeline meant a change to the block size was unlikely to
get into 0.11, leaving only 0.12, which would give everyone only a few
months to upgrade in order to fork the chain by the end of the winter
growth season. That seemed tight.
Wladimir did not reply to this email, unfortunately. Perhaps he would like
the issue to go away. It won't - if Bitcoin continues on its current growth
trends it *will* run out of capacity, almost certainly by some time next
year.
What we need to see right now is leadership and a plan, that fits in the
available time window.
> Certainly a consensus in this kind of technical community should be a
> basic requirement for any serious commitment to blocksize increase.
>
I'm afraid I have come to disagree. I no longer believe this community can
reach consensus on anything protocol related. Some of these arguments have
dragged on for years. Consensus isn't even well defined - consensus of who?
Anyone who shows up? And what happens when, inevitably, no consensus is
reached? Stasis forever?
> Long-term incentive compatibility requires that there be some fee
> pressure, and that blocks be relatively consistently full or very nearly
> full.
I disagree. When the money supply eventually dwindles I doubt it will be
fee pressure that funds mining, but as that's a long time in the future,
it's very hard to predict what might happen.
> What we see today are
> transactions enjoying next-block confirmations with nearly zero pressure
> to include any fee at all (though many do because it makes wallet code
> simpler).
>
Many do because free transactions are broken - the relay limiter means
whether a free transaction actually makes it across the network or not is
basically pot luck and there's no way for a wallet to know, short of either
trying it or actually receiving every single transaction and repeating the
calculations. If free transactions weren't broken for all non-full nodes
they'd probably be used a lot more.
> This allows the well-funded Bitcoin ecosystem to continue building
> systems which rely on transactions moving quickly into blocks while
> pretending these systems scale.
I have two huge problems with this line of thinking.
Firstly, no, the "Bitcoin ecosystem" is not well funded. Blockstream might
be, but significant numbers of users are running programs developed by tiny
startups, or volunteers who don't have millions in venture capital to play
with.
Arm-twisting "the ecosystem" into developing complicated Rube Goldberg
machines in double quick time, just to keep the Bitcoin show on the road,
is in fact the opposite of decentralisation - it will effectively exclude
anyone who isn't able to raise large amounts of corporate funding from
writing code that uses the Bitcoin network. Decentralisation benefits from
simplicity, and bigger blocks are (in Gavin's words) "the simplest thing
that will work".
My second problem is the claim that everyone is playing pretend about
Bitcoin, except you guys. I would put it another way - I would say those
people are building products and getting users, by making reasonable
engineering tradeoffs and using systems that work. Yes, one day those
systems might have to change. That's the nature of scaling. It's the nature
of progress. But not today. Probably not tomorrow either.
What I would like to see from Blockstream is a counter-proposal. So far you
have made lots of vague comments that we all agree with - yes,
decentralisation is good, yes some block size limit must exist, if only
because computers are finite machines.
What I don't see from you yet is a *specific and credible plan* that fits
within the next 12 months and which allows Bitcoin to keep growing. Not
some vague handwave like "let's all use the Lightning network" (which does
not exist), or "let's do more research" (Gavin has done plenty of
research), or "but what about the risks" (Bitcoin is full of risks). A
plan, with dates attached, and a strong chance of actually being deployed
in time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/81942b17/attachment.html>

2023-06-07 17:31:55 CEST

- reply

📅 Original date posted:2015-03-13
📝 Original message:>
> Don't SPV clients announce their intentions by the act of uploading a
> filter?
>
Well they don't set NODE_NETWORK, so they don't claim to be providing
network services. But then I guess the Chainalysis nodes could easily just
clear that bit flag too.
> What I'd actually like to see is for network users to pay for the node
> resources that they consume
It's not quite pay-as-you-go, but I just posted a scheme for funding of
network resources using crowdfunding contracts here:
https://github.com/bitcoin/bitcoin/issues/5783#issuecomment-79460064
That comment doesn't have any kind of provision for access control, but
group signatures could be extended in both directions: the server proves it
was a part of the group that was funded by the contract, and the client
proves it was in group that funded the contract, but it's done in a
(relatively) anonymous way. Then any client can use any node it funded, or
at least, buy priority access.
But it's rather complicated. I'd hope that nodes can be like email
accounts: yes they have a cost but in practice people everyone gets one for
free because of random commercial cross-subsidisation, self hosting and
other things.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150313/41dda398/attachment.html>

2023-06-07 17:31:55 CEST

- reply

📅 Original date posted:2015-03-13
📝 Original message:>
> I'm not talking about keeping logs, I mean purporting to be a network
> peer in order to gain a connection slot and then not behaving as one
> (not relaying transactions)
That definition would include all SPV clients?
I get what you are trying to do. It just seems extremely tricky.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150313/2f839145/attachment.html>

2023-06-07 17:31:54 CEST

- reply

📅 Original date posted:2015-03-13
📝 Original message:That would be rather new and tricky legal territory.
But even putting the legal issues to one side, there are definitional
issues.
For instance if the Chainalysis nodes started following the protocol specs
better and became just regular nodes that happen to keep logs, would that
still be a violation? If so, what about blockchain.info? It'd be shooting
ourselves in the foot to try and forbid block explorers given how useful
they are.
If someone non-maliciously runs some nodes with debug logging turned on,
and makes full system backups every night, and keeps those backups for
years, are they in violation of whatever pseudo-law is involved?
I think it's a bit early to think about these things right now. Michael
Grønager and Jan Møller have been Bitcoin hackers for a long time. I'd be
interested to know their thoughts on all of this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150313/b0d0085a/attachment.html>

2023-06-07 17:31:28 CEST

- reply

📅 Original date posted:2015-03-11
📝 Original message:>
> I'd like to offer that the best practice for the shared wallet use case
> should be multi-device multi-sig.
Sure. But in practice people will want to have a pool of spending money
that they can spend when they are out and about, and also with one click
from their web browser on their primary computer, and maybe also on their
games console, etc etc.
I don't think we can realistically tell people to *always* use clever
multi-device wallets - there will always be a desire to have a convenient
hot wallet that's synchronised between different devices.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150311/2125934b/attachment.html>

2023-06-07 17:31:28 CEST

- reply

📅 Original date posted:2015-03-11
📝 Original message:Users will want to have wallets shared between devices, it's as simple as
that, especially for mobile/desktop wallets. Trying to stop them from doing
that by making things gratuitously incompatible isn't the right approach:
they'll just find workarounds or wallet apps will learn how to import
seeds from other apps. Better to just explain the risks and help people
mitigate them.
On Wed, Mar 11, 2015 at 3:57 PM, Aaron Voisine <voisine at gmail.com> wrote:
> I'm not convinced that wallet seed interoperability is such a great thing.
> There is a wide variability in the quality and security level of wallet
> implementations and platforms. Each new device and wallet software a user
> types their seed into increases their attack surface and exposure to flaws.
> Their security level is reduced to the lowest common denominator. I see the
> need for a "fire exit", certainly, but we must also remember that fire
> exits are potential entrances for intruders.
>
> Aaron Voisine
> co-founder and CEO
> breadwallet.com
>
> On Wed, Mar 11, 2015 at 12:46 PM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
>
>> On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
>> <ricardojdfilipe at gmail.com> wrote:
>> > i guess you look at the glass half full :)
>> > even though what you say is true, we should aim for wallets not to
>> > require those instructions, by standardizing these things in BIPs.
>> > let's hope bitcoin doesn't fail in standards as our industries have in
>> > the past...
>>
>> There are genuine principled disagreements on how some things should
>> be done. There are genuine differences in functionality.
>>
>> We cannot expect and should not expect complete compatibility. If you
>> must have complete compatibility: use the same software (or maybe not
>> even then, considering how poor the forward compatibility of some
>> things has been..).
>>
>> What we can hope to do, and I think the best we can hope to do, is to
>> minimize the amount of gratuitous incompatibility and reduce the
>> amount of outright flawed constructions (so if there are choices which
>> must be made, they're at least choices among relatively good options).
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> 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/20150311/2a1f4679/attachment.html>

2023-06-07 17:31:25 CEST

- reply

📅 Original date posted:2015-03-02
📝 Original message:Congrats Thomas! Glad to see Electrum 2 finally launch.
> * New seed derivation method (not compatible with BIP39).
Does this mean a "12 words" wallet created by Electrum won't work if
imported into some other wallet that supports BIP39? Vice versa? This seems
unfortunate. I guess if seeds are being represented with 12 words
consistently, people will expect them to work everywhere.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150302/3647f808/attachment.html>

2023-06-07 17:31:09 CEST

- reply

📅 Original date posted:2015-02-23
📝 Original message:>
> But via Bluetooth it checks for 'ack' directly:
We need a BIP70 conformance suite really. There are so many deviations from
the spec out there already and it's brand new :(
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150223/61dcfc81/attachment.html>

2023-06-07 17:31:08 CEST

- reply

📅 Original date posted:2015-02-23
📝 Original message:>
> At the moment I'm also modifying BitPay's memo field to contain 'ack', as
> Andreas' wallet otherwise reports a failure if I transmit the original via
> Bluetooth. :-)
>
Huh?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150223/c198eebd/attachment.html>

2023-06-07 17:31:06 CEST

- reply

📅 Original date posted:2015-02-23
📝 Original message:>
> I don't see how you propose to treat the bitcoin address as a secp256k1
> public key, or do you mean something else?
>
Sorry, I skipped a step. I shouldn't make assumptions about what's obvious.
The server would provide the public key and the client would convert it to
address form then match against the URI it has scanned. If it didn't match,
stop at that point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150224/2bf38af1/attachment.html>

2023-06-07 17:31:06 CEST

- reply

📅 Original date posted:2015-02-23
📝 Original message:>
> I read from your answer that even if we use ECDHE, we can't use it for
> every situation.
>
Which situations do you mean? I think it can be used in every situation.
It's the opposite way around - a fixed session key in the URI cannot be
used in every situation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150223/a9563929/attachment.html>

2023-06-07 17:31:05 CEST

- reply

📅 Original date posted:2015-02-23
📝 Original message:>
> DHKE will not improve the situation. Either we use a simple method to
> transfer a session key or a complex method.
>
You're right that just sending the session key is simpler. I originally
suggested doing ECDHE to set up an encrypted channel for the following
reasons:
1. URIs are put in QR codes more often than NFC tags. QR codes have
limited space. The more stuff you pack into them, the slower and flakier
the scanning process becomes.
For normal wallets, doing ECDH over secp256k1 to derive a session key
means we can reuse the address that was put in the URI already for
pre-BIP70 wallets, thus we don't have to expand the URI at all except
perhaps to flag that crypted Bluetooth connections are supported. Win!
2. If the wallet is a watching wallet, this won't work and in that case
you would need to put a separate key into the URI. However, this key is
ephemeral and does not need to be very strong. So we can generate a regular
secp256k1 key and then put say 5-8 prefix bytes into the URI as a new
parameter. The public key can then be provided in full in the clear over
the Bluetooth connection and the session key derived. If we put the session
key into the URI in full, then we could not use this trick. Win!
3. It's quite common in low tech scenarios like little coffee shops to
just print a QR code and put it in the menu, or sticky tape it to the back
wall of the shop.
In these cases, it's possible that the device is actually hanging around
in the shop somewhere but having the QR code somewhere larger and more
accessible than the shop devices screen is highly convenient. However it
means the data is entirely static.
Putting/reusing an identity key from the URI means the session keys are
always unique and known only to both devices, even though the bootstrap
data is public.
4. Doing ECDHE to derive the keys means we can derive a MAC key as well
as an AES key. Otherwise you have the issue of exchanging both, which again
uses up valuable bootstrap space.
So for a small increase in session setup complexity we potentially avoid
troubling problems down the line where people the same functionality from
NFC and QR code based bootstrap, but we can't provide it.
These discussions keep coming up. I think the next step is for someone to
upgrade Andreas' wallet to support encrypted connections and the TBIPs, to
see what happens.
Re: the h= parameter. I only objected to requiring this when the payment
request is also signed. It adds complexity, uses space, and the rationale
was "the PKI can't be trusted" even though it's been used to protect credit
card payments for 20 years without any issues. In the case of unsigned
payment requests, sure ... but with a proper implementation of an encrypted
Bluetooth channel it'd be unnecessary as the channel establishment process
would guarantee authenticity anyway.
But don't let me hold you guys back! I'd rather see something that works
than an endless debate about the perfect arrangement of hashes and URI
parameters :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150223/dac2bed5/attachment.html>

2023-06-07 17:30:43 CEST

- reply

📅 Original date posted:2015-02-20
📝 Original message:Hey Adam,
> Mike had posted a detailed response on the topic on why its complex
> and becomes bandwidth inefficient to improve it usefully.
>
To clarify, we *could* improve privacy and still preserve usefully high
performance, it's just a lot of complicated programming work. You need to
find out from the OS how much bandwidth you have to play with, for example,
and do all the very complex tracking to surf the wave and keep yourself in
roughly the right place.
The basic summary of which I think is that its not even intended to
> provide any practical privacy protection, its just about compacting
> the query for a set of addresses.
>
The original intent of Bloom filtering was to allow both. We want our cake
and we want to eat it.
The protocol can still do that, with sufficiently smart clients. The
problem is that being sufficiently smart in this regard has never come to
the top of the TODO list - users are always complaining about other things,
so those things are what gets priority.
It's not IMO a protocol issue per se. It's a code complexity and manpower
issue.
> Its seems surprising no one thought of it
> that way before (as it seems obvious when you hear it) but that seems
> to address the privacy issues as the user can fetch the block bloom
> filters and then scan it in complete privacy.
And then what? So you know the block matches. But with reasonable FP rates
every block will match at least a few transactions (this is already the
case - the FP rate is low but high enough that we get back FPs on nearly
every block). So you end up downloading every block? That won't work.
Eventually, wallets need to stop doing linear scans of the entire block
chain to find tx data. That worked fine when blocks were 10kb, it's still
working OK even though we scaled through two orders of magnitude, but we
can imagine that if we reach 10mb blocks then this whole approach will just
be too slow.
The main reason wallets are scanning the chain today (beyond lack of
protocol support for querying the UTXO set by script), is that they want to
show users time-ordered lists of transactions. Financial apps should show
you payment histories, everyone knows this, and without knowing roughly
when a tx happened and which inputs/outputs were mine, providing a useful
rendering is hard. Even with this data the UI is pretty useless, but at
least it's not actually missing.
By combining Subspace and BIP70 we can finally replace the payments list UI
with actual proper metadata that isn't extracted from the block chain, and
at that point non-scanning architectures become a lot more deployable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150220/3e911e29/attachment.html>

2023-06-07 17:30:43 CEST

- reply

📅 Original date posted:2015-02-20
📝 Original message:Ah, I see, I didn't catch that this scheme relies on UTXO commitments
(presumably with Mark's PATRICIA tree system?).
If you're doing a binary search over block contents then does that imply
multiple protocol round trips per synced block? I'm still having trouble
visualising how this works. Perhaps you could write down an example run for
me.
How does it interact with the need to download chains rather than
individual transactions, and do so without round-tripping to the remote
node for each block? Bloom filtering currently pulls down blocks in batches
without much client/server interaction and that is useful for performance.
Like I said, I'd rather just junk the whole notion of chain scanning and
get to a point where clients are only syncing headers. If nodes were
calculating a script->(outpoint, merkle branch) map in LevelDB and allowing
range queries over it, then you could quickly pull down relevant UTXOs
along with the paths that indicated they did at one point exist. Nodes can
still withhold evidence that those outputs were spent, but the same is true
today and in practice this doesn't seem to be an issue.
The primary advantage of that approach is it does not require a change to
the consensus rules. But there are lots of unanswered questions about how
it interacts with HD lookahead and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150220/f8a10aca/attachment.html>

2023-06-07 17:30:14 CEST

- reply

📅 Original date posted:2015-02-12
📝 Original message:>
> I see no fundamental difference in outcome from miner collusion in
> scorched-fee (which isn't guaranteed to pay the "right" pool!) and miner
> collusion in knowingly mining a doublespend transaction.
>
Well, they're the same thing. Replace-by-fee *is* miner collusion in
knowingly mining a double spend, just triggered in a certain way.
Remember that you aren't paying the bad pool, the bad pool is paying you.
Whichever pool benefits from the scorched earth protocol can simply pick an
address out of the transaction it perceived as starting the protocol, and
pay that.
> Zero-conf needs something else for security. A guarantee it can not be
> doublespent in the relevant time frame.
>
I think this is the core point which many of these debates revolve around.
No payment system provides *guarantees*, though some are stronger than
others. All they do is manage risk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/d546aa2e/attachment.html>

2023-06-07 17:30:13 CEST

- reply

📅 Original date posted:2015-02-12
📝 Original message:>
> So anyway, in my opinion, it is actually great that Bitcoin is still
> relatively small: we have an opportunity to analyze and improve things.
> But you seem to be hostile to people who do that (and who do not share
> your opinion), which is kinda uncool.
>
To clarify once more, I'm all for people researching and building ways to
make Bitcoin better and safer. And debating that here is cool too.
The "replace by fee" patches don't do this; as you said yourself the whole
scorched earth thing makes no sense. It's not a solution to anything and
it's important people realise that.
Perhaps it will help if I spell out why this whole approach won't work (but
can easily damage bitcoin a lot along the way).
Normal Bitcoin nodes pick which transaction to put into a block by simply
selecting whichever they saw arrive first, as determined by the arrival
order of network packets. This rule is simple and has multiple advantages
for people using Bitcoin to buy and sell things.
Replace-by-fee changes this so nodes select whichever chain of unconfirmed
transactions pays the highest miner fees. Up until the point that a
transaction appears in a block, anyone can broadcast a double spend (or a
spend of an unconfirmed transaction) which pays higher fees than before,
causing that tx chain to become the candidate for chain inclusion.
Peter argues that this is stable and makes unconfirmed transactions safe
because a fraudster can buy something, walk out of the shop, and broadcast
a double spend with a higher fee. But then the merchant can re-spend the
original payment back to themselves with an *even* higher fee than that.
Then the fraudster can re-spend their double spend with an *even* higher
fee than that, and so on back and forth, until *all* the money has been
spent to miner fees. Thus the merchant loses their goods but the fraudster
has still "paid" in some sense because they don't get the money either.
This argument makes no sense for two reasons.
The first is that this setup means miners can steal arbitrary payments if
they work together with the sender of the money. The model assumes this
collaboration won't happen, but it will. Because no existing wallet has a
"double spend this" button, to make the scheme work the dishonest miners
must create and distribute such a wallet that implements the whole
scorched-earth protocol. At that point it's easy for miners to reward the
payment fraudster with some of the stolen money the merchant lost, meaning
it now makes sense for the fraudster to always do this. The situation isn't
stable at all.
The second is that it incentivises competitors to engage in payment fraud
against each other. A big rich coffee shop chain that is facing competition
from a small, scrappy newcomer can simply walk into the new shop and buy
things, then trigger the "scorched earth". Even with no miner
collaboration, this means the big company is down the cost of the product
*but* so is the little company who lost everything. Whoever can outspend
the other wins.
We don't really need game theory to tell us that this plan is a bad idea.
Just imagine trying to explain it to an actual shop keeper. They would
think you were crazy. Bitcoin is already a hard enough concept to
understand without throwing into the mix "anyone can burn the money they
gave you after walking out of the shop".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/d71e96be/attachment.html>

2023-06-07 17:30:12 CEST

- reply

📅 Original date posted:2015-02-12
📝 Original message:>
> 1. They won't be attacking Bitcoin, they will attack merchants who accept
> payments with 0 confirmations.
>
Which is basically all of them other than exchanges. Any merchant that uses
BitPay or Coinbase, for instance, or any physical shop.
If you want to play word games and redefine "Bitcoin" to be something other
than what people are actually using, go right ahead. You will win the
argument under your own definitions which nobody else is using.
In your scenario I won't be able to get hamburgers for free because people
will stop selling them for ordinary bitcoin transactions. Most will say,
you know what, just pay me with Visa instead. And a few might knuckle down
and set up some network of PKI-like trusted third parties that interacts
with the block chain in some way.
Though eventually, if that were to happen, cunning merchants will notice
that having received a transaction counter-signed by a TTP they don't
actually have to broadcast it or pay miner fees at all. They can just keep
it around in their wallet and pass it along to the next guy when they
purchase something with those coins. Eventually whoever ends up not being
able to find a matching TTP gets to be the sucker who pays all the miner
fees at once, because he is the only one who actually needs their services.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/e2f3ae22/attachment.html>

2023-06-07 17:30:12 CEST

- reply

📅 Original date posted:2015-02-12
📝 Original message:>
> You can not consider the outcome resulting by replace-by-fee fraudulent,
> as it could be the world as observed by some.
>
Fraudulent in what sense?
If you mean the legal term, then you'd use the legal "beyond reasonable
doubt" test. You mined a double spend that ~everyone thinks came 5 minutes
later once? OK, that could be a fluke. Reasonable doubt. You do it 500
times in a row? Probably not a fluke.
If you mean under a technical definition then I think Tom Harding has been
researching this topic, though I've only kept half an eye on it. I guess
it's some statistical approximation of the above, i.e. sufficient to ensure
good incentives with only small false positive losses. Sort of like how the
block chain algorithm already works w.r.t orphans.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/4a915041/attachment.html>

2023-06-07 17:30:11 CEST

- reply

📅 Original date posted:2015-02-12
📝 Original message:>
> But, let's say, 5 years from now, some faction of miners who own
> soon-to-be-obsolete equipment will decide to boost their profits with a
> replace-by-fee pool and a corresponding wallet. They can market it as "1 of
> 10 hamburgers are free" if they have 10% of the total hashpower.
>
Yes, like any P2P network Bitcoin cannot work if a sufficiently large
number of miners decide to attack it. This is an ancient argument. It came
up the moment Bitcoin was first invented.
But this argument could have been made at any time in Bitcoin's entire
history. Lots of miners have dropped out due to hardware obsolescence, yet
massive double spending hasn't happened. Perhaps the system is not as
simple as you boil it down to be.
Anyway, what would happen in that event is within a few days some people
would stop selling Bitcoin for hamburgers, others would find workarounds,
and the fees collected from the double spends would be worth very little.
Nobody wins.
So would you take a responsibility for pushing the approach which isn't
> game-theoretically sound?
>
"The approach" is how Bitcoin has always worked.
People have been using game theory to predict the imminent demise of
Bitcoin since I first found it. Just one example: "Bitcoin will collapse
when the 50->25 BTC drop happens" was promoted as a dead cert thing by game
theorists. Every miner becomes unprofitable and stops at once!
So far game theory based predictions tend to be proven wrong by reality, so
this sort of argument doesn't impress me much.
Anyway, going around this loop again is pointless. I brought up the counter
argument so people who see this thread don't mistakenly think Peter's
position is some kind of de-facto consensus about how Bitcoin should work.
Not because I love rehashing the same arguments every six months ad nauseum.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/7484a16c/attachment.html>

2023-06-07 17:30:10 CEST

- reply

📅 Original date posted:2015-02-12
📝 Original message:>
> > So you're just arguing that a notary is different to a miner, without
> spelling out exactly why.
>
I'm afraid I still don't understand why you think notaries would build long
term businesses but miners wouldn't, in this model.
I think you are saying because notaries have identity, brand awareness and
because they have big up front bonds, that means they will be trustworthy.
Well, sure. It's the same model governments use and is why being a money
transmitter in the USA is so difficult: you need to put up large sums of
money as collateral and have your fingerprints taken 48 times. *Then* you
can start advertising to get customers!
The reason mining is such a nice model is it doesn't have these sorts of
requirements.
> As notaries can be small operations ..... [snip] ...... (almost every
> large organization in the world have some unallocated funds somewhere).
>
Which is it? Are notaries small operations or large operations?
I think exploring new consensus models with semi-trusted notaries is
interesting, but it's not Bitcoin.
> Depending on that which isn't guaranteed is baaaad, and breaking other
> people's assumptions is by itself NOT an attack if there never was a
> guarantee or even as little as an implicit understanding it is safe.
>
Please don't try and apply this logic in the real world :( Rephrased:
"*That's a nice house. I noticed it's made of wood. I'm going to start
fires until it burns down, because there is no guarantee your house won't
burn down in future and it's important you understand that wooden houses
aren't safe. Really I'm just doing you a favour*."
Don't get me wrong. I'm all for what *you're* doing - please do continue to
research and explore alternative trust configurations! This is helpful and
useful work. Perhaps we will find something that solves the burger problem
in a way that satisfies everyone.
I'm really not a fan of Peter's approach, which is "hey let's try and cause
as many problems as possible to try and prove a point, without having
created any solutions". Replace-by-fee-scorched-earth doesn't work and
isn't a solution. Miners can easily cut payment fraudsters in on the stolen
money, and as they'd need to distribute custom double-spending wallets to
make the scheme work it'd be very easy to do.
> Your also ssume people will expect the Bitcoin network to keep zero-conf
> safe forever and that Bitcoin valuation is tied to that. Given the options
> available and current state of things, I'm assuming that's wrong.
>
Why? You think ability to make payments in a few seconds is some irrelevant
curiousity?
Let's put it this way. If BitPay's business model evaporates tomorrow,
along with all the merchants they support, do you think that'd have any
effect on Bitcoin's value? If not, why not?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/7008132d/attachment.html>

2023-06-07 17:30:09 CEST

- reply

📅 Original date posted:2015-02-12
📝 Original message:>
> You can prove a doublespend instantly by showing two conflicting
> transactions both signed by thar party. This pair can be distributed as a
> proof of malice globally in seconds via a push messaging mechanism.
>
There have been lots of e-cash schemes proposed in the academic literature
that work like this, or variants of it. Schemes where participants are
anonymous until they double spend are popular.
Let's re-write your proposal but substituting the word notary for miner:
To profit, the *miner* would have to be sure the payout from agreeing on
collusion (or to perform the doublespend themselves) would pay out better
than acting honestly for a given amount of time info the future. This means
transactions for small sums are secure.
That's the exact argument we're having. The assertion is that a "rational"
notary would kill his own business to increase his profits in the next few
hours. So you're just arguing that a notary is different to a miner,
without spelling out exactly why.
Does the notary have to make a big up front investment? If so, why is that
different to mining investment?
Is the notary non-anonymous and afraid of being charged with payment fraud?
If so, note that big miners do lots of non-anonymous things too, like
renting warehouses and importing specialised equipment.
Is it because of the big up front collateral they're meant to have lying
around? If so, how do you ensure a fluid market for notaries?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/9ac6414a/attachment.html>

2023-06-07 17:30:08 CEST

- reply

📅 Original date posted:2015-02-12
📝 Original message:I know you will ignore this as usual, but the entire replace-by-fee folly
is based on your fundamental misunderstanding of miner incentives.
Miners are *not* incentivised to earn the most money in the next block
possible. They are incentivised to maximise their return on investment.
Making Bitcoin much less useful reduces demand for the bitcoins they are
mining, reducing coinbase and fee income in future blocks. Quite possibly,
to the point where those miners are then making a loss.
Your "scorched earth" plan is aptly named, as it's guaranteed to make
unconfirmed payments useless. If enough miners do it they will simply break
Bitcoin to the point where it's no longer an interesting payments system
for lots of people. Then miners who have equipment to pay off will be
*really* screwed, not to mention payment processors and all the investors
in them.
I'm sure you can confuse a few miners into thinking your ideas are a
super-duper way to maximise their income, and in the process might
facilitate a pile of payment fraud. But they aren't. This one is about as
sensible as your "let's never increase the block size" and "let's kill SPV
clients" crusades - badly thought out and bad for Bitcoin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/48b4714f/attachment.html>

2023-06-07 17:30:02 CEST

- reply

📅 Original date posted:2015-02-10
📝 Original message:We can certainly imagine many BIP70 extensions, but for things like
auto-filling shipping addresses, is the wallet the best place to do it? My
browser already knows how to fill out this data in credit card forms, it
would make sense to reuse that for Bitcoin.
It sounds like you want a kind of Star-Trek negotiation agent thing, where
your computer knows how to seek out the best deal because all the metadata
is standardised. Such a thing would be an interesting project, but it's
probably not best done in BIP70 given how it's deployed and used today.
Rather, I'd suggest looking at the various HTML5 data standards which would
allow merchants to advertise things like where they ship to in a machine
readable and crawlable form.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150210/f998119d/attachment.html>

2023-06-07 17:29:41 CEST

- reply

📅 Original date posted:2015-02-05
📝 Original message:>
> This sounds horrible. You could basically monitor anyone with a wallet in
> a highly populated area and track them super easily by doing facial
> recognition.
>
We're talking about BLE, still? The radio tech that runs in the so called
"junk bands" because propagation is so poor?
My watch loses its connection to my phone if I just put it down and walk
around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't
going to be enabling mass surveillance any time soon. It barely goes
through air, let alone walls.
Anyway, whatever. I'm just bouncing around ideas for faster user
interfaces. You could always switch it off or set it to be triggered by the
presence of particular wifi hotspots, if you don't mind an initial bit of
setup.
Back on topic - the debate is interesting, but I think to get this to the
stage of being a BIP we'd need at least another wallet to implement it?
Then I guess a BIP would be useful regardless of the design issues. The
prefix matching still feels flaky to me but it's hard to know if you could
really swipe payments out of the air in practice, without actually trying
it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150205/f97ddd7e/attachment.html>

2023-06-07 17:29:40 CEST

- reply

📅 Original date posted:2015-02-05
📝 Original message:>
> Even if a user could get the BIP70 URL in the URI, they would still need
> internet to access the URL.
>
The way Bitcoin Wallet does it, the bitcoin URI includes a MAC address
where you can download the request from. BIP70 does not depend on internet
access or HTTP, plus, you don't have to sign them.
The name field might work but requires the merchant to set it, e.g. by
asking the payer what their name is, then typing it in, then the payer has
to wait for it to show up. By this point it's probably faster to have
scanned a QR code.
Re: security. I'll repeat what I wrote up-thread in case you didn't see it:
it's not clear to me at all that this partial address scheme is actually
> secure. The assumption appears to be that the MITM must match the address
> prefix generated by the genuine merchant. But if they can do a wireless
> MITM they can just substitute their own address prefix/partial address, no?
>
> To avoid MITM attacks the sender must know who they are sending money to,
> and that means they must see a human understandable name that's
> cryptographically bound to the right public key. Displaying partial
> addresses to the user is not going to solve this unless users manually
> compare key prefixes across the screens.... which is even less convenient
> than a QR code.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150205/c3eb897f/attachment.html>

2023-06-07 17:29:39 CEST

- reply

📅 Original date posted:2015-02-05
📝 Original message:BIP70 requests can be sent over bluetooth as well, as can transactions.
Bitcoin Wallet can already send money even when offline by doing this. It's
transparent to the user. I mean original Bluetooth in this context - BLE
has incredibly tight data constraints and isn't really meant for data
transfer.
Yes Android Beam has a pretty stupid UI. You can actually tap the devices,
take them away and then press, but that's not obvious at all. There have
been new APIs added in recent releases that give more control over this, so
it's possible we can revisit things and make the UI better these days.
The donation to live performer example is good - there's no issue of
accidentally paying for someone else in this context as there's only one
recipient, but many senders.
The issue of confused payments remains in other situations though.
For the coffee shop use case, it'd be nicer (I think) if we aim for a
Square-style UI where the device broadcasts a (link to) a photo of the user
combined with a bluetooth MAC. Then the merchant tablet can show faces of
people in the shop, and can push a payment request to the users device.
That device can then buzz the user, show a confirmation screen, put
something on their smart watch etc or just auto-authorise the payment
because the BIP70 signature is from a trusted merchant. User never even
needs to touch their phone at all.
On Thu, Feb 5, 2015 at 9:06 PM, Paul Puey <paul at airbitz.co> wrote:
> The BIP70 protocol would preclude individuals from utilizing the P2P
> transfer spec. It would also require that a Sender have internet
> connectivity to get the payment protocol info. BLE could enable payment w/o
> internet by first transferring the URI to from Recipient to Sender. Then in
> the future, we could sign a Tx and send it over BLE back to the recipient
> (who would still need internet to verify the Tx). This is an important use
> case for areas with poor 3G/4G connectivity as I've experience myself.
>
> Also, due to Android issues, NFC is incredibly clunky. The URI Sender is
> required to tap the screen *while* the two phones are in contact. We
> support NFC the same way Bitcoin Wallet does, but unless the payment
> recipient has a custom Android device (which a merchant might) then the
> usage model is worse than scanning a QR code. BLE also allows people to pay
> at a distance such as for a donation to a live performer. We'll look at
> adding this to the Motivation section.
>
> [image: logo]
> *Paul Puey* CEO / Co-Founder, Airbitz Inc
> +1-619-850-8624 | http://airbitz.co | San Diego
> <http://facebook.com/airbitz> <http://twitter.com/airbitz>
> <https://plus.google.com/118173667510609425617>
> <https://go.airbitz.co/comments/feed/> <http://linkedin.com/in/paulpuey>
> <https://angel.co/paul-puey>
> *DOWNLOAD THE AIRBITZ WALLET:*
> <https://play.google.com/store/apps/details?id=com.airbitz>
> <https://itunes.apple.com/us/app/airbitz/id843536046>
>
>
> From: Andreas Schildbach <andreas at sc...> - 2015-02-05 13:47:04
>
> Thanks Paul, for writing up your protocol!
>
> First thoughts:
>
> For a BIP standard, I think we should skip "bitcoin:" URIs entirely and
> publish BIP70 payment requests instead. URIs mainly stick around because
> of QR codes limited capacity. BIP70 would partly address the "copycat"
> problem by signing payment requests.
>
> In your Motivation section, I miss some words about NFC. NFC already
> addresses all of the usability issues mentioned and is supported by
> mobile wallets since 2011. That doesn't mean your method doesn't make
> sense in some situations, but I think it should be explained why to
> prefer broadcasting payment requests over picking them up via near field
> radio.
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> 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/20150205/806f0139/attachment.html>

2023-06-07 17:29:38 CEST

- reply

📅 Original date posted:2015-02-05
📝 Original message:>
> For a BIP standard, I think we should skip "bitcoin:" URIs entirely and
> publish BIP70 payment requests instead.
>
Agreed - it's not clear to me at all that this partial address scheme is
actually secure. The assumption appears to be that the MITM must match the
address prefix generated by the genuine merchant. But if they can do a
wireless MITM they can just substitute their own address prefix/partial
address, no?
To avoid MITM attacks the sender must know who they are sending money to,
and that means they must see a human understandable name that's
cryptographically bound to the right public key. Displaying partial
addresses to the user is not going to solve this unless users manually
compare key prefixes across the screens.... which is even less convenient
than a QR code.
I think it should be explained why to
> prefer broadcasting payment requests over picking them up via near field
> radio.
>
This is probably an artifact of Apple's restrictions on iOS. Only the
iPhone 6 has NFC hardware and Apple don't expose it via any public API. It
can however support Bluetooth LE.
Apple isn't a big deal in Germany because iPhone only achieved about 17%
market share during the quarter when the iPhone 6 launched. Normally it's
closer to 10-13%. Most other markets are similar.
However in the USA, UK, Australia and Japan iOS is still a big deal and NFC
is going to be seen as a non-universal solution there. At least, until
Apple catches up and provides an NFC API.
It's certainly not a problem to have a working radio based broadcast
system, though the theoretician in me wonders what happens when lots of
people are trying to pay simultaneously for something that has equal cost
..... e.g. buying movie tickets at a counter. NFC and QR codes prevent any
kind of "oops I paid for someone elses stuff" confusion.
In practice of course Bitcoin payments are not normally popular enough for
this to be a problem outside of Bitcoin community events.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150205/58dccfae/attachment.html>

2023-06-07 17:28:44 CEST

- reply

📅 Original date posted:2015-01-28
📝 Original message:>
> My point is not that there is a limitation in BIP70. My point is that you
> put the burden of certificate verification on developer's shoulder when we
> can just leverage built in HTTPS support of the platform.
>
Platforms that support HTTPS but not certificate handling are rare - I know
HTML5 is such a platform but such apps are inherently dependent on the
server anyway and the server can just do the parsing and validation work
itself. If WinRT is such a platform, OK, too bad.
The embedding of the certificates is not arbitrary or pointless, by the
way. It's there for a very good reason - it makes the signed payment
request verifiable by third parties. Effectively you can store the signed
message and present it later to someone else, it's undeniable. Combined
with the transactions and merkle branches linking them to the block chain,
what you have is a form of digital receipt ... a proof of purchase that can
be automatically verified as legitimate. This has all kinds of use cases.
Because of how HTTPS works, you can't easily prove to a third party that a
server gave you a piece of data. Doing so requires staggeringly complex
hacks (see tls notary) and when we designed BIP70, those hacks didn't even
exist. So we'd lose the benefit of having a digitally signed request.
Additionally, doing things this way means BIP70 requests can be signed by
things which are not HTTPS servers. For example you can sign with an email
address cert, an EV certificate i.e. a company, a certificate issued by
some user forum, whatever else we end up wanting. Not every payment
recipient can be identified by a domain name + dynamic session.
> However, if you want to use your plateform's store, then you are toasted
>
That's a bit melodramatic. BitcoinJ is able to use the Android, JRE,
Windows and Mac certificate stores all using the same code or very minor
variants on it (e.g. on Mac you have to specify you want the system store
but it's a one-liner).
Yes, that's not *every* platform. Some will require custom binding glue and
it depends what abstractions and languages you are using.
> Have you tried to do that on windows RT and IOS ? I tried, and I quickly
> stopped doing that since it is not worth the effort. (Frankly I am not even
> sure you can on win rt, since the API is a stripped down version of windows)
>
There is code to do iOS using the Apple APIs here:
https://github.com/voisine/breadwallet/blob/master/BreadWallet/BRPaymentProtocol.m#L391
> Why have you not heard about the problem ? (until now, because I have this
> problem because I need to have the same codebase on
> winrt/win/android/ios/tablets)
>
WinRT is a minority platform in the extreme, and all the other platforms
you mentioned have the necessary APIs. Java abstracts you from them. So I
think you are encountering this problem because you desire to target WinRT
and other platforms with a single codebase. That's an unusual constraint.
AFAIK the only other people who encountered this are BitPay, because they
want to do everything in Javascript which doesn't really provide any major
APIs.
> Also, you bundle mozilla's store in bitcoinj, what happen when the store
> change and your customer have not intent to use bitcoinj new version ? by
> leveraging the plateform you benefit from automatic updates.
>
Yes, there are pros and cons to bundling a custom root store.
> Also, does java stores deals with certificate revocations ? sure you can
> theorically code that too... or just let the plateform deals with it.
>
It can do OCSP checks, yes, although I believe no wallets currently do so.
A better solution would be to implement an OCSP stapling extension to BIP70
though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150128/04112261/attachment.html>

2023-06-07 17:28:44 CEST

- reply

📅 Original date posted:2015-01-28
📝 Original message:I think we'll just have to agree to disagree on this one. I've implemented
BIP70 a couple of times now and didn't find it to be difficult. I know you
had odd problems with the C# protobuf implementation you were using but
library bugs can happen for any kind of programming.
I forgot to mention the other reason it's done this way. One of the driving
goals of BIP70 was to support the TREZOR and similar devices. For hardware
wallets, it's critical to keep the amount of code they need to run as small
as possible. Any bugs in the code there can cause security holes and lead
to the device being hacked.
Doing it the way you suggest would mean the secure code would have to
contain complex and bug-prone text parsing logic as well as a full blown
HTTP and SSL stack, that requires not only X.509 handling but also lots of
other stuff on top. It'd increase cost, complexity and decrease security
quite a bit.
Whilst I appreciate if your platform provides a scripting-like API and
nothing low level it might seem easier to use JSON+HTTPS, that isn't the
case for one of the primary design targets.
On Wed, Jan 28, 2015 at 6:04 PM, Nicolas Dorier <nicolas.dorier at gmail.com>
wrote:
> Mike, I am not denying it is impossible to do all of that.
> Just that it is not a trivial stuff to do to make it works everywhere, and
> I think that it is not a good thing for a client side technology.
> BIP70 has its use, and I understand why there is case where it is good to
> ship the certs in the message and not depends on the transport.
>
> But a standard that just use JSON and HTTPS, even if less flexible that
> BIP70, would make it easier and sufficient for today's use case.
>
> On Wed, Jan 28, 2015 at 5:55 PM, Mike Hearn <mike at plan99.net> wrote:
>
>> My point is not that there is a limitation in BIP70. My point is that you
>>> put the burden of certificate verification on developer's shoulder when we
>>> can just leverage built in HTTPS support of the platform.
>>>
>>
>> Platforms that support HTTPS but not certificate handling are rare - I
>> know HTML5 is such a platform but such apps are inherently dependent on the
>> server anyway and the server can just do the parsing and validation work
>> itself. If WinRT is such a platform, OK, too bad.
>>
>> The embedding of the certificates is not arbitrary or pointless, by the
>> way. It's there for a very good reason - it makes the signed payment
>> request verifiable by third parties. Effectively you can store the signed
>> message and present it later to someone else, it's undeniable. Combined
>> with the transactions and merkle branches linking them to the block chain,
>> what you have is a form of digital receipt ... a proof of purchase that can
>> be automatically verified as legitimate. This has all kinds of use cases.
>>
>> Because of how HTTPS works, you can't easily prove to a third party that
>> a server gave you a piece of data. Doing so requires staggeringly complex
>> hacks (see tls notary) and when we designed BIP70, those hacks didn't even
>> exist. So we'd lose the benefit of having a digitally signed request.
>>
>> Additionally, doing things this way means BIP70 requests can be signed by
>> things which are not HTTPS servers. For example you can sign with an email
>> address cert, an EV certificate i.e. a company, a certificate issued by
>> some user forum, whatever else we end up wanting. Not every payment
>> recipient can be identified by a domain name + dynamic session.
>>
>>
>>> However, if you want to use your plateform's store, then you are toasted
>>>
>>
>> That's a bit melodramatic. BitcoinJ is able to use the Android, JRE,
>> Windows and Mac certificate stores all using the same code or very minor
>> variants on it (e.g. on Mac you have to specify you want the system store
>> but it's a one-liner).
>>
>> Yes, that's not *every* platform. Some will require custom binding glue
>> and it depends what abstractions and languages you are using.
>>
>>
>>> Have you tried to do that on windows RT and IOS ? I tried, and I quickly
>>> stopped doing that since it is not worth the effort. (Frankly I am not even
>>> sure you can on win rt, since the API is a stripped down version of windows)
>>>
>>
>> There is code to do iOS using the Apple APIs here:
>>
>>
>> https://github.com/voisine/breadwallet/blob/master/BreadWallet/BRPaymentProtocol.m#L391
>>
>>
>>> Why have you not heard about the problem ? (until now, because I have
>>> this problem because I need to have the same codebase on
>>> winrt/win/android/ios/tablets)
>>>
>>
>> WinRT is a minority platform in the extreme, and all the other platforms
>> you mentioned have the necessary APIs. Java abstracts you from them. So I
>> think you are encountering this problem because you desire to target WinRT
>> and other platforms with a single codebase. That's an unusual constraint.
>>
>> AFAIK the only other people who encountered this are BitPay, because they
>> want to do everything in Javascript which doesn't really provide any major
>> APIs.
>>
>>
>>> Also, you bundle mozilla's store in bitcoinj, what happen when the store
>>> change and your customer have not intent to use bitcoinj new version ? by
>>> leveraging the plateform you benefit from automatic updates.
>>>
>>
>> Yes, there are pros and cons to bundling a custom root store.
>>
>>
>>> Also, does java stores deals with certificate revocations ? sure you can
>>> theorically code that too... or just let the plateform deals with it.
>>>
>>
>> It can do OCSP checks, yes, although I believe no wallets currently do
>> so. A better solution would be to implement an OCSP stapling extension to
>> BIP70 though.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150128/c4fd4b47/attachment.html>

2023-06-07 17:28:43 CEST

- reply

📅 Original date posted:2015-01-28
📝 Original message:>
> I'm frankly _horrified_ to learn that BitcoinJ ships its own root CA
> certificates bundle. This means that, if a root CA gets breached and a
> certificate gets revoked, all BitcoinJ-using software will be vulnerable
> until BitcoinJ ships an update *and* the software in question pulls in the
> new BitcoinJ update and releases its own update. That might never happen.
If your wallet is unmaintained, you have other problems beyond (extremely
rare) root CA revocations.
As far as I know the only time a CA in wide usage has been revoked entirely
is DigiNotar.
One advantage of doing it this way is if, for example, a widely used piece
of community infrastructure (e.g. bitcointalk, reddit, whatever) decides to
become a CA, the Bitcoin community can decide to have different inclusion
rules vs the OS/browser root CA programs. For example we'd probably relax
the constraint to use an HSM and just ensure that the rendering of the
asserted identity isn't confusible with other kinds of more strongly
protected identities. For example no forum usernames like "foo.com" but
rendering it in the UI as "Reddit forum user foo.com" would be OK.
Also you don't get problems due to old operating systems not including new
certs.
Finally, Linux doesn't have any kind of standardised cert/keystore API.
There are a few places where popular distros put certs but AFAIK they
aren't standardised and there's no standard code to load them. So that's
another reason why there's a built in store.
But yes, this is a debatable topic on which reasonable people can disagree.
The API makes it easy to use the platform OS store for wallet devs that
want to do that, and I think using the platform store on Android is the
default. It's only on the desktop where we fall back to a different store.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150128/bdcd16f5/attachment.html>

2023-06-07 17:28:42 CEST

- reply

📅 Original date posted:2015-01-28
📝 Original message:>
> It is not "fear", it is field experience.
>
> JSON has proven to be a bug generator for the reasons already stated.
>
To back Jeff up on this point, today we see this story:
http://www.theregister.co.uk/2015/01/27/trivial_hole_left_black_phones_open_to_plunder/
The maker of BlackPhone – a mobile marketed as offering unusually high
levels of security – has patched *a critical vulnerability that allows
hackers to run malicious code on the handsets*. Attackers need little more
than a phone number to send a message that can compromise the devices via
the Silent Text application.
"The SCIMP protocol encodes messages as JSON objects, which are then
transmitted to the remote party over XMPP," Dowd explained to *The Register*.
"*The flaw I discovered occurs during the deserialization of these JSON
objects*. It is *a type confusion vulnerability*, which when exploited
allows an attacker to overwrite a pointer in memory, either partially or in
full. This pointer is later manipulated by the program and also the system
allocator, allowing you to do things such as pass arbitrary pointers to
free()."
The C++/Java/Python protocol buffer implementations are used by Google for
all internal inter-server communication. Any similar exploit in them would
result in total bypass of their entire internal security and auditing
system by allowing you to run code as any user. The Google security team is
very good, the protobuf code is carefully reviewed and the format is
relatively constrained. The chances of there being any security problems in
the parsing code generated by the protobuf compilers is drastically
smaller. As BIP70 requests are parsed by security sensitive code, this
matters.
The vision for BIP70 has always been to be a foundation for many features.
We haven't really done much with it so far because there have always been
higher priorities. But I hope that if Bitcoin continues to be successful
and grows, one day payment requests will have many different features in
them and those will likely include many complex data structures.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150128/ec7ad39e/attachment.html>

2023-06-07 17:28:41 CEST

- reply

📅 Original date posted:2015-01-28
📝 Original message:>
> On the other hand, if you charge the developer (and not the plateform) to
> check certificate validity, it means that you have to develop a different
> codebase for all plateform you are targeting, because each plateform store
> trusted root certificate in a different manner with different APIs, and
> also have different types representing a X509 Certificate.
>
That's what cross-platform abstraction libraries are for. Both Java and Qt
provide a key store library that can load from either the OS root store or
a custom one. If your chosen app platform doesn't, OK, then you'll have to
make or find one yourself. Perhaps contribute it upstream or make it a
library. But that's not a limitation of BIP70.
Just as a reminder, there is no obligation to use the OS root store. You
can (and quite possibly should) take a snapshot of the Mozilla/Apple/MSFT
etc stores and load it in your app. We do this in bitcoinj by default to
avoid cases where BIP70 requests work on some platforms and not others,
although the developer can easily override this and use the OS root store
instead.
Of all possible solutions, using a third party service to convert things to
JSON is one of the least obvious and highest effort. I don't know anyone
else who arrived at such a conclusion and respectfully disagree that this
is a problem with the design choices in BIP70. It sounds like a bizarre
hack around lack of features in whatever runtime you're using.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150128/aabfe25a/attachment.html>

2023-06-07 17:28:39 CEST

- reply

📅 Original date posted:2015-01-19
📝 Original message:The engineers at Google were well aware that ASN.1 existed. I can assure
you of that, because I was one of them.
The protobuf FAQ has a very polite take on the matter:
https://developers.google.com/protocol-buffers/docs/faq
This email thread gives more enlightenment:
https://groups.google.com/forum/#!topic/protobuf/eNAZlnPKVW4
Anyone who has actually had to work with both ASN.1 and protocol buffers
will be able to explain why ASN.1 should not be chosen for any modern
formats. A lot of it boils down to simplicty and quality of
implementations, especially open source implementations.
With respect to the specific concerns Richard raises:
Performance doesn't feel that relevant when you think that:
>
Performance wasn't a concern.
> 2. One would be cramming this data into a binary format just so you can
> then attach it to a no-so-binary format such as HTTP.
>
HTTP transmits files as binary on the wire. So it's binary-clean and,
moreover, HTTP/2 aka SPDY is fully binary and doesn't use text anywhere
except the gzip dictionary.
> 2. There are tons of great open source libraries and API for parsing /
> manipulating / generating.
>
Luckily, this is also true of protocol buffers. Language support is pretty
good these days.
> 4. The standards are much easier to read and write. They don't need to
> contain code like BIP-0070 currently does and they can contain examples,
> which BIP70 does not.
>
BIP 70 doesn't contain any code, as far as I know. The protobuf schema
might look like code, but it's not - it's just a description of what fields
a message can contain and their types. This is very relevant for a
specification!
JSON in particular is pretty awful and I don't like it much. It suffers
complexities with things as basic as encoding numbers and strings. It's
very much unsuited to applications where correctness matters and where
you're dealing with binary structures.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150119/e6a76662/attachment.html>

2023-06-07 17:28:37 CEST

- reply

📅 Original date posted:2015-01-19
📝 Original message:>
> I'm a bit confused. It's been a long time since I looked at protobuf (and
> will have to dig into it soon), but I seem to recall it doesn't have any of
> the determinism properties you guys just said.
>
It's not guaranteed no, which is why we store signed sub-messages as byte
arrays instead of typed submessages. In practice though, most
implementations do seem to serialise things the same way. I recall Python
used to be an odd one out, unsure if it still is.
OK, I guess we can boil this down more simply. BIP 70 uses protocol buffers
because I designed it and implemented the original prototype (with lots of
input from Gavin and an earlier proposal by sipa). I used protocol buffers
because, beyond all their nice properties, I used to work at Google and so
was very familiar with them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150119/bbd8b7d4/attachment.html>

2023-06-07 17:28:24 CEST

- reply

📅 Original date posted:2015-01-09
📝 Original message:The original design is documented at the bottom of here:
https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party
In this design, time locked transactions can be broadcast across the
network and replaced by broadcasting a new transaction that uses higher
sequence numbers. That's what the sequence number field is for. It was
intended to allow arbitrary high frequency trading between a set of
parties, though the "channel" notion is a simple way to think about the two
party case.
The issue is that you can broadcast transactions with a lock time far in
the future to fill up memory, and keep broadcasting replacements to use up
CPU time and bandwidth.
Additionally, there is a school of thought that says Bitcoin must work even
if lots of miners are malicious and willing to break arbitrary things in
order to try and get more money. I don't think Bitcoin can really be a
mainstream success under such a threat model, for a whole bunch of reasons
(e.g. the economy relies pretty heavily on unconfirmed transactions), but
under such a threat model there's nothing that forces miners to actually
include the latest version in the block chain. They could pick any version.
In the 2-of-2 channel model it takes both parties to sign, so clients can
enforce that all versions have the same fee attached.
I disagree with Gregory that people refuse to use protocols that are
affected by malleability. There aren't any user-friendly apps that use
refunds currently, so we have no idea whether people would refuse to use
them or not. It's an open question. The answer would probably depend on the
real prevalence of attacks, which is currently unknowable and likely
application specific.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150109/0e36b48d/attachment.html>

2023-06-07 17:28:24 CEST

- reply

📅 Original date posted:2015-01-09
📝 Original message:>
> A limitation on most existing micropayment channel ideas is that payments
> can only flow in one direction.
>
It's worth noting that the original protocol as designed by Satoshi did not
have this limitation. It has evolved this way because of ad-hoc DoS fixes
over time (btw I'm not saying they were the wrong thing to do, as non "ad
hoc" solutions are significantly more work). But it seems like eventually a
different approach to handling DoS attacks based on resource prioritisation
and scheduling will become needed / implemented, and at that point the
original design could be safely brought back to life.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150109/dee4f22b/attachment.html>

2023-06-07 17:27:34 CEST

- reply

📅 Original date posted:2014-11-27
📝 Original message:>
> [As an aside I agree that there are lots of things to improve here,
> but the fact that users can in theory be forced off of tor via DOS
> attacks is not immediately concerning to me because its a conscious
> choice users would make to abandon their privacy
Bitcoin already has a large population of users who have little or no
technical skill, it wouldn't surprise me at all if it was found to be the
clear majority by now. Assuming success and growth in future, very few
users will make any decisions at all about their privacy, they will just
accept the defaults. In such a world no consumer wallet is going to
directly expose Tor to end users - if used at all it'll just be used behind
the scenes. So automated fallback or control over exits would be a concern
for such wallets.
My gut feeling about this stuff has changed over time. I don't think it'd
be a great idea to tie Bitcoin to Tor too deeply, convenient though its
infrastructure is. Most apps don't need a whole lot of onion routing - a
small amount built in to the p2p layer would be sufficient. Tor is huge,
complicated and could be a liability in future.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141127/506b3fb5/attachment.html>