Tom Zander [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-10-05 to 2017-09-02
💬 Posted a total of 85 messages
📚 Participated in the following categories: bitcoin-dev, patch, BIP Proposal
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1mju50kqcm07heu967fkq6h4kq666xgekc4yrldf7q52xx9vr8jnsrdxnq7

Profile Code

nprofile1qqsdew28mqvdhltu7za0ymqdt6mqdddryvmv2jplk5lq29rrzkpnefcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dswmvtfx

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1mju50kqcm07heu967fkq6h4kq666xgekc4yrldf7q52xx9vr8jnsrdxnq7

Show more details

Last Notes

2023-06-07 20:05:13

- reply

📅 Original date posted:2017-09-01
📝 Original message:On Friday, 1 September 2017 14:47:08 CEST Cserveny Tamas via bitcoin-dev
wrote:
> The fundamental problem is that if the miners add capacity it will only
> increase (protect) their share of block reward, but does not increase the
> speed of transactions.
Adding more space in blocks has no effect on the block-reward. It does
actually increase the throughput speed of transactions.
> This will only raise the fee in the long run with
> the block reward decreasing.
Also this is exactly the opposite of what actually happened.
> The current chain is effectively single threaded.
This is not true, since xthin/compactblocks have been introduced we
completely removed this bottle-neck.
The transactions will be validated continuously, in parallel and not just
when a block is found.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 20:04:23

- reply

📅 Original date posted:2017-07-12
📝 Original message:On Tuesday, 11 July 2017 23:11:38 CEST Gregory Maxwell via bitcoin-dev
wrote:
> I think it's great that people want to experiment with things like
> drivechains/sidechains and what not, but their security model is very
> distinct from Bitcoin's and, given the current highly centralized
> mining ecosystem, arguably not very good. So positioning them as a
> major solution for the Bitcoin project is the wrong way to go. Instead
> we should support people trying cool stuff, at their own risk.
>
> So, given that although the vast majority of the things in the document
> are things I've been supporting for months (Please see Note 1 way down
> at the bottom) I cannot support your document.
I”m thinking along the same lines, a industry wide roadmap makes very little
sense.
Much like in Linux we have a lot of smaller groups doing their own thing,
all working for the good of Linux as they see it, and implicitly, as they
use it.
I think its safe to say that Linus would not want any say over the roadmap
of Intel or Google or any other particpant in the Linux space.
I am in agreement with Gregory that we should reject a Bitcoin-wide scaling
roadmap.
I do suggest that smalle groups publish their individual roadmaps, show what
they are planning to work on in a place that people will find it (a website,
not a mailinglist archive).
Those individual roadmaps then show what that group will work on, which
helps their communication. It helps people talking about Bitcoin to the
general public as well, and it helps people understand whom they would like
to support financially or otherwise.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 20:04:22

- reply

📅 Original date posted:2017-07-12
📝 Original message:On Wednesday, 12 July 2017 03:22:59 CEST Karl Johan Alm via bitcoin-dev
wrote:
> Bitcoin development differs from Linux kernel development in a number
> of obvious ways, such as the fact Bitcoin is being "patched in
> flight".
I've heard this before and it doesn't make any sense to me. Just like your
Linux box needs a reboot to get a kernel upgrade, your node needs a restart
to upgrade. Neither the (entire) internet will go down nor the (entire)
Bitcoin network will go down as a result.
> Having *something* like a roadmap that gives the average user some
> insights into what exactly is being planned for Bitcoin is very
> desirable, arguably even necessary,
This is fine, and groups that do development should do this more structured
than something like https://bitcoinhardforkresearch.github.io/
It just would not make any sense to have a roadmap for the *entire* industry
as this would require you to decide what technical solution is better than
another before either of them are fully researched.
Individual groups can have solutions that they believe is the best. And then
we can let the market decide which one is to be actually activated.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 20:04:05

- reply

📅 Original date posted:2017-07-12
📝 Original message:On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote:
> I think anything less than 1 year after release of tested code by some
> implementation would be irresponsible for any hardfork, even a very
> simple one.
Good news!
Code to support 2x (the hard fork part of the proposal) has been out and
tested for much longer than that.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 20:03:25

- reply

📅 Original date posted:2017-06-19
📝 Original message:On Monday, 19 June 2017 21:26:22 CEST Luke Dashjr via bitcoin-dev wrote:
> To ease the transition to BIP148 and to minimise risks in the event miners
> choose to perform a chain split attack, at least Bitcoin Knots will be
> using the temporary service bit (1 << 27) to indicate BIP148 support.
>
> Once the transition is complete, this will no longer be necessary, and the
> bit will be (manually) returned for reuse.
>
> I encourage other software implementing BIP148 (both full and light nodes)
> to set and use this service bit to avoid network partitioning risks.
I'm curious what you action on the finding (or not) of a peer with this bit
set (or not).
Can you link to the github commit where you implemented this?
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 20:02:13

- reply

📅 Original date posted:2017-06-20
📝 Original message:On Tuesday, 20 June 2017 00:41:49 CEST Gregory Maxwell via bitcoin-dev
wrote:
> Can someone make a case why saving no more than those figures would
> justify the near total loss of privacy that filtering gives?
First, your figures are wrong and also fall out of the sky with no
justification. Can’t debunk something that is pure garbage.
Second, stating that a bloom filter is a "total loss of privacy" is equally
baseless and doesn’t need debunking.
> "Because they already do it" isn't a good argument when talking about
> a new protocol feature; things which already do BIP37 will presumably
> continue to already do BIP37.
I think you just made the case for completely rejecting this proposal based
on the fact that nobody will use it, BIP37 already exists.
Not sure if I agree with that, improvements are always useful and we should
be able to come up with replacements.
But arguing against a feature you don’t like, especiallyh one used by
millions every day, is a sad way to stiffle innovation, Greg.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 20:02:10

- reply

📅 Original date posted:2017-06-19
📝 Original message:On Monday, 19 June 2017 14:26:46 CEST bfd--- via bitcoin-dev wrote:
> It's been debated if [filtering of] unconfirmed transactions are
> necessary,
Why would it not be needed? Any SPV client (when used as a payment-receiver)
requires this from a simple usability point of view.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 20:01:54

- reply

📅 Original date posted:2017-05-26
📝 Original message:On Friday, 26 May 2017 10:02:27 CEST Cameron Garnham via bitcoin-dev wrote:
> So, I started searching for the motivations of such a large amount of the
> mining hash-rate holding a position that isn’t at-all represented in the
> wider Bitcoin Community. My study of ASICBOOST lead to a ‘bingo’ moment:
> If one assumes that the 67% of the hash rate that refuse to signal for
> SegWit are using ASICBOOST. The entire picture of this political
> stalemate became much more understandable.
I’m uncomfortable with your “bingo” moment, and your huge assumption to get
to make it fit.
The reality is that we have seen repeatedly that the miners are stating they
are Ok with an ASICBOOST disabling change.
The larger mining industry has just this week come to consensus about a
better way to activate SegWit! Referring to the New York consensus meeting!!
https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77
I question your conclusions of miners not supporting SegWit because of
ASICBOOST, the evidence shows this accusation to be false.
You openly admitting here that you use ASICBOOST as a tool to push SegWit is
further making me uncomfortable. Your intention may be pure, but the methods
are not.
And on that I agree with Andreas, that taints this proposal.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 20:01:25

- reply

📅 Original date posted:2017-05-28
📝 Original message:On Saturday, 27 May 2017 01:09:10 CEST James Hilliard wrote:
> > why?
>
> the main
> issue is due to 0.13.1+ having many segwit related features active
> already, including all the P2P components, the new network service
> flag, the witness-tx and block messages, compact blocks v2 and
> preferential peering.
Hmm, the flags are identical in 0.13 and 0.14 clients.
Either way, this is rather trivial to solve. If bugs in older clients mean
they can’t operate properly when SW is activated (via bit 4) but they don’t
know its activated (since they only look at bit1), then just ban them when
they misbehave.
And tell people to upgrade to a version where SegWit is less buggy.
> You would have to then have multiple activation
> codepaths to test for such as BIP141(active)->HF BIP141(inactive)->HF
> etc. By doing BIP141 first you then only have the BIP141(active)->HF
> activation codepath to test for, and you also can't be sure you can
> rely on BIP141(inactive)->HF activation codepath being the only one
> until segwit activation expires.
Heh, well, this is rather simple to solve by not having all those activation
codepaths and just picking **one**.
You can safely replace the bit1 activation code with a bit4 activation
logic, which is based on 80% and has no end-date.
We both know that the bip9 (bit1) based activation will not trigger before
the expiration date anyway.
These worries are rather trivial to solve if you do a little bit of proper
architecture of the solution. This honestly can’t be a reason for saying NO
to the majority of the mining hash power giving you a break and offering a
better SegWit activation.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 20:01:24

- reply

📅 Original date posted:2017-05-26
📝 Original message:On Friday, 26 May 2017 23:30:37 CEST James Hilliard via bitcoin-dev wrote:
> It would not be feasible to schedule any HF until one can be
> completely sure BIP141 is active
why?
> Since it is likely a HF will take months of development and testing I
> see this or something similar as the fastest safe path forward
This should not be an issue, it started 2 years ago. Its tested.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 20:01:23

- reply

📅 Original date posted:2017-05-26
📝 Original message:On Friday, 26 May 2017 19:47:11 CEST Jacob Eliosoff via bitcoin-dev wrote:
> Forgive me if this is a dumb question.
Sorry for picking your email.
I understand people want something different for the agreement, I know I do
too.
We have a specific agreement on the table, signed by a huge subsection of the
industry.
Maybe the time for changing things is not to be *after* the signatures are
set. I know I’d change some detials. But do we really want to go through
another conference where all the important people are present to agree on a
compromise? Or can we use the one we have?
The compromise is pretty simple;
https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77
* Activate Segregated Witness at an 80% threshold, signaling at bit 4
* Activate a 2 MB hard fork within six months
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 20:00:46

- reply

📅 Original date posted:2017-05-04
📝 Original message:I agree with you here, Erik. Greg's standard answer doesn’t apply to your
suggestion.
I think he was a bit too trigger happy because we have seen a lot of similar
suggestions that have the Sybill issue he mentioned.
On Thursday, 4 May 2017 15:15:02 CEST Erik Aronesty via bitcoin-dev wrote:
> > Greg
> > The primary result would be paying people to sybil attack the network.
>
> I cannot imagine the benefit to replicating an ip address in this case,
> except maybe you think that you would be more likely to be selected as a
> peer? But there would be no actual advantage since download peers are
> selected based on throughput and actual blocks served.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 20:00:24

- reply

📅 Original date posted:2017-04-18
📝 Original message:On Monday, 17 April 2017 08:54:49 CEST David Vorick via bitcoin-dev wrote:
> The best alternative today to storing the full blockchain is to run a
> pruned node
The idea looks a little overly complex to me.
I suggested something similar which is a much simpler version;
https://zander.github.io/scaling/Pruning/
> # Random pruning mode
>
> There is a large gap between the two current modes of everything
> (currently 75GB) and only what we need (2GB or so).
>
> This mode would have two areas, it would keep a days worth of blocks to
> make sure that any reorgs etc would not cause a re-download, but it would
> have additionally have an area that can be used to store historical data
> to be shared on the network. Maybe 20 or 50GB.
>
> One main feature of Bitcoin is that we have massive replication. Each node
> currently holds all the same data that every other node holds. But this
> doesn't have to be the case with pruned nodes. A node itself has no need
> for historic data at all.
>
> The suggestion is that a node stores a random set of blocks. Dropping
> random blocks as the node runs out of disk-space. Additionally, we would
> introduce a new way to download blocks from other nodes which allows the
> node to say it doesn't actually have the block requested.
>
> The effect of this setup is that many different nodes together end up
> having the total amount of blocks, even though each node only has a
> fraction of the total amount.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 20:00:23

- reply

📅 Original date posted:2017-04-21
📝 Original message:On Thursday, 20 April 2017 22:32:12 CEST Andrew Poelstra wrote:
> > > If you are downloading 450,000 blocks, you will need to
> > > connect to an expected 46 peers to download the whole blockchain.
> >
> > I don’t really see the problem here, even if your math is a off.
> > (Statistics is difficult, I know). Connecting to many nodes to download
> > faster is really not an issue and already happens.
>
> I think the expected number of peers is actually ~47.75
Nice to join bitcoin-dev, Andrew. Haven’t seen you post here before.
I’m not sure how you reached that strange number, but I have to point out
your number is quite useless.
The actual amount of nodes you need to be 100% sure you find all the blocks
when you know each node will have a completely random 25% of the blocks is
not a maths problem that leads to a single answer because of the randomness
involved.
The actual answer is a series of probabilities.
Same as the answer is to the age old question; how many coin flips does it
take to be 100% certain I have at least one “Heads”.
In our blocks retrieval scenario; with num-nodes < 4, probability is zero.
There is a really really small chance you will get 100% of the blocks with 4
nodes (actual number depends on the amount of total blocks you are looking
for).
And this goes up as you add more nodes, but never reaches 100%
At the other end of this question you can ask what the chance is of at least
one block being lost when there are N nodes, a block nobody has. That chance
is small with current > 6000 nodes, but not zero (a second reason why the
previous parag never reaches 100%).
Bottom line, it is silly to assume 100% of the nodes would be partial-
pruning, and if you continue on that path you will only have probabilities
to predict how many nodes it takes to have 100% coverage, exact numbers are
worse than useless, they are misleading.
As I said in my initial email, statistics is hard. Crypto is much easier in
that it is absolute. Either correct or false. Never in between.
To repeat, the goal of this pruning method is not to replace a full
“archival” node, the goal of this pruning node is to provide an improvement
over the current pruning node which stops any and all serving of historical
blocks.
Anyone that feels the need to talk about pruning modes like 100% of the full
nodes will run it are in actual fact not talking about the real world.
Distributed systems will never (and should never) end up being a mono-
culture. Diversity is the essential thing you aim for.
I would suggest we focus on the real world and not on irreleavant math
experiments that only lead to confusion.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 20:00:22

- reply

📅 Original date posted:2017-04-20
📝 Original message:On Wednesday, 19 April 2017 19:30:30 CEST David Vorick via bitcoin-dev
wrote:
> > I suggested something similar which is a much simpler version;
> > https://zander.github.io/scaling/Pruning/
> Your proposal has a significant disadvantage: If every peer is dropping
> 75% of all blocks randomly, then you need to connect to a large number of
> peers to download the whole blockchain.
...
> If you are downloading 450,000 blocks, you will need to
> connect to an expected 46 peers to download the whole blockchain.
I don’t really see the problem here, even if your math is a off. (Statistics
is difficult, I know). Connecting to many nodes to download faster is really
not an issue and already happens.
> Your proposal is also a lot less able to handle active adversaries: if
> nodes are randomly dropping blocks, the probability that one block in
> particular is dropped by everyone goes up significantly.
You make the assumption that this new mode of pruning will be used by 100%
of the network, this is not how distributed systems work.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 20:00:05

- reply

📅 Original date posted:2017-04-14
📝 Original message:On Friday, 14 April 2017 22:51:04 CEST James Hilliard wrote:
> This doesn't remove the need for consensus rule enforcement of course.
Thanks for confirming my point.
This means that Gregory was incorrect saying that there is no risk to a non-
upgraded node on a SegWit network mining a new invalid block. That risk is
most definitely there for any miners "left behind" operating on a different
set of consensus rules than the majority.
Kind of obvious, when you think about it.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 20:00:04

- reply

📅 Original date posted:2017-04-14
📝 Original message:On Friday, 14 April 2017 09:56:31 CEST Gregory Maxwell via bitcoin-dev
wrote:
> Segwit was carefully engineered so that older unmodified miners could
> continue operating _completely_ without interruption after segwit
> activates.
> They [Older nodes] can
> upgrade to it [segwit] on their own schedule. The only risk
> non-participating
> miners take after segwit activation is that if someone else mines an
> invalid block they would extend it,
This is false,
a segwit transaction to the miner you describe is an "everyone can spend"
transaction, and as such a miner that does not validate the segregated area
in a post-segwit world will be able to create blocks that will not validate
for segwit miners by including a transaction that spends a SW tx.
This would then lead to a chain-fork as the SW miners reject it and the non-
SW miners continue to mine on it.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 20:00:04

- reply

📅 Original date posted:2017-04-14
📝 Original message:On Friday, 14 April 2017 18:50:47 CEST praxeology_guy via bitcoin-dev wrote:
> Criticizing 148 without suggesting a specific alternative leaves the
> community in disarray.
Here is a list of clear alternatives;
https://github.com/bitcoin/bips/
See the BIPs with number 010[1-8].
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 20:00:04

- reply

📅 Original date posted:2017-04-14
📝 Original message:On Friday, 14 April 2017 21:33:49 CEST James Hilliard wrote:
> This is false,
>
> Those "everyone can spend" transactions are prohibited from being
> mined due to policy rules.
I expected you to know this, but ok, I'll explain.
A policy rule is not a protocol rule, a mining node is certainly not
guarenteet to have it, and those that do typically make it configurable.
If you depend on one implementation and user configuration for the avoidance
of chain forks, you are going to have a hard time.
Thanks for your thoughtful reply, though.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:59:53

- reply

📅 Original date posted:2017-04-11
📝 Original message:The version field is still needed to actually allow future block version
upgrades. We would cut off our road forward if that were to be blocked.
On Friday, 7 April 2017 22:06:39 CEST Jimmy Song via bitcoin-dev wrote:
> Currently, the version bits (currently 4 bytes, or 32 bits) in the header
> are used for BIP9 signaling. We change the version bits to a nonce-space
> so the miners can use it for overt ASICBoost. The 32-bits are now moved
> over to the Coinbase transaction as part of the witness commitment. The
> witness commitment goes from 38 bytes to 42 bytes, with the last 4 bytes
> being used as the version bits in the block header previously. The
> witness commitment becomes required as per Gregory Maxwell’s proposal.
> Reasoning
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:59:02

- reply

📅 Original date posted:2017-04-05
📝 Original message:On Tuesday, 4 April 2017 20:01:51 CEST Luke Dashjr via bitcoin-dev wrote:
> BIP 9 provides a mechanism for having
> miners coordinate softforks because they can make the upgrade process
> smoother this way. But the same is not true of hardforks: miners are
> essentially irrelevant to them, and cannot make the process any smoother.
Can you explain how miners are irrelevant if the upgrade is not a soft fork?
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:59:01

- reply

📅 Original date posted:2017-04-04
📝 Original message:On Monday, 3 April 2017 11:06:02 CEST Sancho Panza wrote:
> ==Specification==
>
> To be elaborated.
Please do elaborate :)
The meat of the proposal is missing.
> It is thought that only cosmetic changes are needed to generalize from
> only soft forks to 'soft or hard forks', and to add the additional
> per-bit parameters 'threshold' and 'windowsize'
I agree that the type of forks are rather irrelevant to the voting
mechanism. As we remember that BIP109 used a voting bit too.
The per-bit (lets call that per-proposal) parameter threshold and windowsize
are a different matter though, based on the next paragraph you wrote;
> The design of the state machine is envisioned to remain unchanged.
The entire point of BIP9 is to allow nodes that do not know about an upgrade
to still have a functional state machine. But I don’t see how you can have a
state machine if the two basic variables that drive it are not specified.
Now, to be clear, I am a big fan of making the window size and the threshold
more flexible.
But in my opinion we would not be able to have a state machine without those
variables in the actual BIP because old nodes would miss the data to
transition to certain states.
Maybe an idea; we have 30 bits. 2 currently in use (although we could reuse
the CSV one). Maybe we can come up with 3 default sets of properties and
when a proposal starts to use bit 11 it behaves differently than if it uses
22.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:58:59

- reply

📅 Original date posted:2017-04-04
📝 Original message:Can you tell me where it is enforced?
The only place I found was here;
https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1793
which doesn’t enforce it, all that code does is check that the txid is
unknown or fully spent.
And since the below idea from Russel would change the txid, it would seem no
full client would reject this.
Maybe its in a BIP, but I can’t find it in the code.
On Tuesday, 4 April 2017 16:59:12 CEST James Hilliard wrote:
> It is a consensus rule
> https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
>
> On Tue, Apr 4, 2017 at 6:47 AM, Tom Zander via bitcoin-dev
>
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > On Sunday, 2 April 2017 22:39:13 CEST Russell O'Connor via bitcoin-dev
> >
> > wrote:
> >> Someone told me a while back that it would be more natural if we move
> >> the
> >>
> >> nHeight from the coinbase script to the coinbase locktime. Have you
> >> considered doing this?
> >
> > That change would not be a consensus change and thus free to make any
> > day.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:58:58

- reply

📅 Original date posted:2017-04-04
📝 Original message:On Sunday, 2 April 2017 22:39:13 CEST Russell O'Connor via bitcoin-dev
wrote:
> Someone told me a while back that it would be more natural if we move the
> nHeight from the coinbase script to the coinbase locktime. Have you
> considered doing this?
That change would not be a consensus change and thus free to make any day.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:58:26

- reply

📅 Original date posted:2017-03-30
📝 Original message:On Wednesday, 29 March 2017 21:50:48 CEST Raystonn . via bitcoin-dev wrote:
> Low node costs are a good goal for nodes that handle transactions the node
> operator can afford. Nobody is going to run a node for a network they do
> not use for their own transactions. If transactions have fees that
> prohibit use for most economic activity, that means node count will drop
> until nodes are generally run by those who settle large amounts. That is
> very centralizing.
>
> Raystonn
The idea that people won’t run a node for a network they don’t use for their
own transactions is a very good observation and a good reason to get on-
chain scaling happening well before lightning hits.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:58:17

- reply

📅 Original date posted:2017-03-30
📝 Original message:On Thursday, 30 March 2017 22:51:45 CEST Jared Lee Richardson wrote:
> Unfortunately miners could arbitrarily decide to limit blocksizes, and
> there's little except relay restrictions that everyone else could do about
> it.
No, there is a lot you and I can do about it. They call it a fee market for
a reason because you can take your money elsewhere. You can choose to not
make the transfer at all, use another crypto or just use fiat.
Bitcoin has value because we use it as money, supporess that usecase and the
value of it goes down.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:58:16

- reply

📅 Original date posted:2017-03-30
📝 Original message:On Thursday, 30 March 2017 07:23:31 CEST Ryan J Martin via bitcoin-dev
wrote:
> The original post and the assorted limit proposals---lead me to
> something I think is worth reiterating: assuming Bitcoin adoption
> continues to grow at similar or accelerating rates, then eventually the
> mempool is going to be filled with thousands of txs at all times whether
> block limits are 1MB or 16MB
This is hopefully true. :)
There is an unbounded amount of demand for block space, and as such it
doesn’t benefit anyone if the amount of free transactions get out of hand.
Because freeloaders would definitely be able to completely suffocate Bitcoin.
In the mail posted by OP he makes clear that this is a proposal for a hard
fork to change the block size *limit*. The actual block size would not be
changed at the same time, it will continue being set based on market values
or whatever we decide between now and then.
The block size itself should be set based on the amount of fees being paid
to miners to make a block.
What we want is a true fee-market where the miner can decide to make a block
smaller to get people to pay more fees, because if we were to go to 16MB
blocks in one go, the cost of the miner would go up, but his reward based on
fees will go down!
A block so big that 100% of the transactions will always be mined in the
next block will just cause a large section of people to no longer feel the
need to pay fees.
As such I don’t fear the situation where the block size limit goes up a lot
in one go, because it is not in anyone’s interest to make the actual block
size follow.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:58:13

- reply

📅 Original date posted:2017-03-28
📝 Original message:On Tuesday, 28 March 2017 21:56:49 CEST Paul Iverson via bitcoin-dev wrote:
> It is clear that, spam aside, blocks are getting full and we need increase
> them soon. What I don't like about your proposal is it forces all node
> operators to implicitly accept larger blocks in 2020, even maybe against
> their will. 32 MB blocks might result in a loss of decentralization, and
> it might be too difficult to coordinate for small blocks before it's too
> late.
The suggestion was not to produce 32MB blocks, so your fear here is
unfounded.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:58:04

- reply

📅 Original date posted:2017-03-28
📝 Original message:On Tuesday, 28 March 2017 19:34:23 CEST Johnson Lau via bitcoin-dev wrote:
> So if we really want to get prepared for a potential HF with unknown
> parameters,
That was not suggested.
Maybe you can comment on the very specific suggestion instead?
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:58:04

- reply

📅 Original date posted:2017-03-28
📝 Original message:On Tuesday, 28 March 2017 18:59:32 CEST Wang Chun via bitcoin-dev wrote:
> Despite spam tx on the network, the block capacity is approaching its
> limit, and we must think ahead. Shall we code a patch right now, to
> remove the block size limit of 1MB, but not activate it until far in
> the future. I would propose to remove the 1MB limit at the next block
> halving in spring 2020, only limit the block size to 32MiB which is
> the maximum size the current p2p protocol allows. This patch must be
> in the immediate next release of Bitcoin Core.
...
> We don't yet have an agreement on how to increase the block size
> limit. There have been many proposals over the past years, like
> BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so
> on. These hard fork proposals, with this patch already in Core's
> release, they all become soft fork.
I think that is a very smart idea, thank you for making it.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:57:57

- reply

📅 Original date posted:2017-03-27
📝 Original message:For some time now the relation between block size and propagation speed has
been decoupled. Using xthin/compact blocks miners only send a tiny version
of a block which then causes the receiving node to re-create it using the
memory pool. Immediately getting double benefits by including pre-verified
transactions from the memory pool you avoid the old problem of having to
validate them again when a block was mined.
As such there is no downside to a miner creating a bigger block, as long as
all the transactions they include are actually in the mempool.
As such I'm personally convinced that the problem you are trying to solve
has already been solved.
Cheers!
On Monday, 27 March 2017 18:12:19 CEST Btc Ideas via bitcoin-dev wrote:
> Add a preference for mined blocks to be the one with more transactions.
> This comes into play when 2 blocks of the same height are found. The
> first good block mined would be orphaned if it had less transactions than
> another. Optionally, have this rule apply to the current block and the
> previous one.
>
> This increases incentive for full blocks because a miner thinking the
> faster propagation of a smaller block will win him the reward, but that
> would no longer be a good assumption.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:57:29

- reply

📅 Original date posted:2017-03-29
📝 Original message:On Wednesday, 29 March 2017 14:48:42 CEST Martin Stolze wrote:
> Your
> conception holds under the presupposition that all action of
> hash-power is motivated by 'rational' economic interest.
This shows you didn't think this through,
instead, the concept holds true when there is even a small section of hash
power motivated by rational economic interest.
Your claim that it has to be 100% of the miners that need to be honest is
something I already addressed in the previous email when I wrote its a
distributed system.
Since this is an open market, the requirement of a secton of miners being
honest is pretty trivial to fulful, especially since Bitcoins are worth
quite a lot which makes greed be the main cause of honest miners.
This is the best part, greedy miners are the ones that end up working inside
the system.
This is very quickly going off-topic. I suggest you to take it to a
different forum where more people can explain Bitcoin without spamming the
dev list.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:57:28

- reply

📅 Original date posted:2017-03-29
📝 Original message:On Monday, 20 March 2017 21:12:36 CEST Martin Stolze via bitcoin-dev wrote:
> Background: The current protocol enables two parties to transact
> freely, however, transaction processors (block generators) have the
> authority to discriminate participants arbitrarily.
Nag; they don’t have any authority.
> This is well known
> and it is widely accepted that transaction processors may take
> advantage of this with little recourse. It is the current consensus
> that the economic incentives in form of transaction fees are
> sufficient because the transaction processing authorities are assumed
> to be guided by the growth of Bitcoin and the pursuit of profit.
This is not the case, it misunderstands Bitcoin and specifically is
misunderstands that Bitcoin is distributed and decentralized.
What you call “block generators” or “transaction processors” are in reality
called miners and they don’t have any authority to mine or not mine certain
transactions. All they have is a business incentive to mine or not mine a
certain transaction.
This is a crucial distinction as that makes it a economical decision, not a
political.
The massive distribution of miners creating blocks means that one miner is
free to add his political agenda. They can choose to not mine any satoshi-
dice transactions, should they want. But they can’t stop other miners from
mining those transactions anyway, and as such this is not a political move
that has any effect whatsoever, at the end of the day it is just an
economcal decision.
The rest of your email is based on this misconception as well, and therefore
the above answers your question.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:57:21

- reply

📅 Original date posted:2017-03-29
📝 Original message:On Saturday, 18 March 2017 16:23:16 CEST Chris Stewart via bitcoin-dev
wrote:
> As everyone in the Bitcoin space knows, there is a massive scaling debate
> going on. One side wants to increase the block size via segwit, while the
> other side wants to increase via hard fork. I have strong opinions on the
> topic but I won’t discuss them here. The point of the matter is we are
> seeing the politicization of protocol level changes.
I agree with your assessment, the sides are political and picking sides
makes people a target.
For that reason I know that many companies are not picking sides, we’ve seen
some bad stuff happen to companies that did.
I’m not convnced it makes sense to use anonymous, but provable, identities
is the way to solve this. Though.
I also don’t believe people are rejecting proposals purely based on the
name. What I see is that pratically all proposals are ignored for the time
being becaues we can’t make any changes anyway until we have made a protocol
upgrade and came out stronger.
I do agree that bips are seen politically, but not based on the person that
suggests them, but more based on the content being useful for their
political side.
I am not entirely against pseudonymous submissions, but in that case I think
it should be carried by a well known member of the Bitcoin community.
This raises the bar somewhat to a point where you have to convince someone
that is already publicly known to propose it with you.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:57:05

- reply

📅 Original date posted:2017-03-07
📝 Original message:On Tuesday, 7 March 2017 00:23:47 CET Gareth Williams via bitcoin-dev wrote:
> What you're describing is a hashpower activated soft fork to censor
> transactions, in response to a user activated soft fork that the majority
> of hashpower disagrees with.
It is incorrect to say that censoring of transactions is what Edmund
suggested. It's purely about the form they take, you can re-send the
transaction in a different form with the same content and they go through.
Hence, not transaction censoring.
I do believe the point that Edmund brought up is a very good one, the idea
that a set of users can force the miners to do something is rather silly and
the setup that a minority miner fraction can force the majority to do
something is equally silly. This is because the majority mining hashpower
can fight back against this attack upon them.
Don’t be mistaken; a hash-minority attacking the hash-majority is in actual
fact an attack upon Bitcoin as a whole.
If this were possible then next year we’d see governments try to push
through changes in the same UASF way. I’m very happy that UASFs can’t work
because that would be the end of Bitcoin's freedom and decentralized nature.
> It is always possible for a majority of hashpower to censor transactions
> they disagree with. Users may view that as an attack, and can always
> respond with a POW hard fork.
I definitely welcome that approach.
The result would be that you have two chains, but also you ensure that the
chain that the miners didn’t like will no longer be something they can mine.
Not even the minority set of miners that like the softfork can mine on it.
This is a win-win and then the market will decide which one will "win".
> Bitcoin only works if the majority of hashpower is not hostile to the
> users.
This goes both ways, miners both generate value (in the form of security)
and they take value (in the form of inflation).
If the majority of the users are hostile and reject blocks that the miners
create, or change the POW, then what the miners bring to the table is also
removed.
Bitcoin would lose the security and in the short term even the ability to
mine blocks every 10 minutes.
So, lets correct your statement a little;
«Bitcoin only works when the majority of the hashpower and the (economic)
majority of the users are balanced in power and have their goals aligned.»
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:57:01

- reply

📅 Original date posted:2017-03-08
📝 Original message:On Wednesday, 8 March 2017 20:47:54 CET Jonas Schnelli via bitcoin-dev
wrote:
> Please Eric. Stop spreading FUD.
> BIP150 has a fingerprint-free **OPTIONAL** authentication. It’s designed
> to not reveal any node identifier/identity without first get a
> crypto.-proof from other peer that he already knows your identity.
> **Peers can’t be identified without having the identity-keys pre shared
> by the node operators.**
Do you know the trick of having an open wifi basestation in a public street
and how that can lead to tracking? Especially if you have a network of them.
The trick is this; you set up an open wifi base station with a hidden ssid
and phones try to connect to it by saying “Are you ssid=xyz?”
This leads the basestation to know that the phone has known credentials with
another wifi that has a specific ssid. (the trick is slightly more elaborate,
but the basics are relevant here).
Your BIP is vulnarable to the same issue, as a node wants to connect using
the AUTHCHALLENGE which has as an argument the hash of the person I’m trying
to connect with.
Your BIP says "Fingerprinting the requesting peer is not possible”.
Unfortunately, this is wrong. Yes the peer is trivial to fingerprint. Your
hash never changes and as you connect to a node anyone listening can see you
sending the same hash on every connect to that peer, whereever you are or
connect from.
Just like the wifi hack.
I think you want to use industry standards instead, and a good start may be
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:55:23

- reply

📅 Original date posted:2017-01-07
📝 Original message:On Saturday, 7 January 2017 00:55:19 CET Eric Lombrozo wrote:
> Your release announcement does not make it clear that Bitcoin Classic is
> incompatible with the current Bitcoin network and its consensus rules.
To explain why I didn't write that;
Bitcoin Classic is not incompatible with the current Bitcoin network and its
consensus rules.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:55:22

- reply

📅 Original date posted:2017-01-06
📝 Original message:Bitcoin Classic version 1.2.0 is now available from;
<https://bitcoinclassic.com/gettingstarted.html>
This is a new major version release, including new features, various
bugfixes and performance improvements.
This release marks a change in strategy for Bitcoin Classic, moving from the
very conservative block size proposal based on compromise to one where
Classic truly innovates and provides a long term solution for the market to
choose and leave behind the restrictions of the old.
The most visible change in this version is the decentralised block size
solution where node operators decide on the maximum size.
Bitcoin Classic is focused on providing users a way to get onto the Bitcoin
network using a high quality validating node for a large set of use cases.
Classic presents top notch quality processes in this release, to help anyone
running Bitcoin.
We include in this release various projects with the beta label. People who
want to use the Classic node as an on-ramp to Bitcoin will find them
interesting. These projects will need to be enabled in the config by those
that want to test them.
More background information on this release and Classic can be seen in this
video: https://vimeo.com/192789752
The full release notes are on github at
https://github.com/bitcoinclassic/bitcoinclassic/releases/tag/v1.2.0
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:55:15

- reply

📅 Original date posted:2017-01-02
📝 Original message:On Monday, 2 January 2017 14:32:24 CET t. khan wrote:
> Math should decide the max block size, not humans (miners in this
> case). The goal of Block75 is to manage the max block size without any
> human intervention.
If the input of your math is completely free and human created, how does it
follow that it was math that created it ?
Why do you want it math created anyway?
> A maximum block size is necessary to prevent a single nefarious miner from
> creating a ridiculously large block which would break the network.
A maximum is needed, yes. But does it have to be part of the protocol?
A simple policy which is set by node operators (reject block if greater than
X bytes) will solve this just fine, no?
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:55:14

- reply

📅 Original date posted:2017-01-02
📝 Original message:On Monday, 2 January 2017 13:04:37 CET t. khan via bitcoin-dev wrote:
> Thoughts?
This proposal doesn't change the block size, it only changes the maximum
block size. Which is expected, nothing bad there.
The direct consequence of this, though is that the miners set the maximum
block size. Because they decide on the actual created block size.
This leads me to the simple question why we can't just give the miners full
control of the maximum block size directly?
The fact of the matter is that miners have for the full history of Bitcoin
been able to set the block size, until they hit the 1MB limit.
And your proposal keeps that property, but why have a maximum in the
protocol?
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:54:42

- reply

📅 Original date posted:2016-12-05
📝 Original message:On Sunday, 4 December 2016 21:37:39 CET Hampus Sjöberg via bitcoin-dev
wrote:
> > Also how about making timestamp 8 bytes? 2106 is coming up soon
>
> AFAICT this was fixed in this commit:
> https://github.com/jl2012/bitcoin/commit/
fa80b48bb4237b110ceffe11edc14c813
> 0672cd2#diff-499d7ee7998a27095063ed7b4dd7c119R200
That commit hacks around it, a new block header fixes it. Subtle difference.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:54:32

- reply

📅 Original date posted:2016-11-21
📝 Original message:On Monday, 21 November 2016 10:54:19 CET Russell O'Connor wrote:
> Hi Tom,
>
> On Tue, Sep 20, 2016 at 1:15 PM, Tom via bitcoin-dev <bitcoin-dev at lists.
>
> linuxfoundation.org> wrote:
> > The OP_CHECKSIG is the most well known and, as its name implies, it
> > validates a signature.
> > In the new version of 'script' (version 2) the data that is signed is
> > changed to be equivalent to the transaction-id. This is a massive
> > simplification and also the only change between version 1 and version 2
> > of script.
>
> I'm a fan of simplicity too; Unfortunately, your proposal above to change
> the semantics of OP_CHECKSIG is too naive.
Thanks for your email, Russell.
Unfortunately you waited 6 weeks with writing this and the problem you are
seeing has been fixed quite some time ago.
Thanks again for reviewing, though!
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:54:05

- reply

📅 Original date posted:2016-10-17
📝 Original message:On Sunday, 16 October 2016 17:19:37 CEST Andrew C wrote:
> On 10/16/2016 4:58 PM, Tom Zander via bitcoin-dev wrote:
> > Lets get back to the topic. Having a longer fallow period is a simple
> > way to be safe. Your comments make me even more scared that safety is
> > not taken into account the way it would.
>
> Can you please explain how having a longer grace period makes it any
> safer? Once the fork reaches the LOCKED_IN status, the fork will become
> active after the period is over. How does having a longer grace period
> make this any safer besides just adding more waiting before it goes
> active?
As Marek wrote just minutes before your email came in; companies will not
roll out their updates until it locks in. Peter Todd says the same thing.
So your assumption that the lock-in time is the END of the upgrading is
false. Thats only the case for miners.
The entire point here is that SegWit is much bigger than just full nodes
(including miner).
An entire ecosystem of Bitconin will have a need to upgrade.
I understand people saying that non-miners don't *need* to upgrade in order
to avoid being kicked of the network, but truely, thats a bogus argument.
People want to actually participate in Bitcoin and that means they need to
understand all of it. Not just see anyone-can-spend transactions.
I think its rather odd to think that developers on this list can decide
the risk profile that Bitcoin using companies or individuals should have.
> You said something about rolling back the changes. There is no
> mechanism for roll backs, and the whole point of the soft fork
> signalling is such that there is no need to roll back anything because
> miners have signaled that they are supporting the fork.
There are a bunch of really large assumptions in there that I disagree with.
First of all, miners running the latest software doesn't mean the software
is free from flaws. Everyone makes mistakes. People that see a way to abuse
the system may have found things and are not reporting it because they want
to abuse the flaw for their own gains. Which is exactly what happened with
Etherium.
The amount of code and the amount of changes in SegWit makes this a very
dangerous change in (of?) Bitcoin. I counted 10 core concepts in Bitcoin
being changed with it. We don't yet know how they will interact. We can’t.
You are asking people to create everyone-can-spend transactions that would
mean a loss of funds to everyone that used it if we do find a major flaw and
need to rollback.
The gamble is rather uncomforable to many...
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:54:04

- reply

📅 Original date posted:2016-10-16
📝 Original message:On Sunday, 16 October 2016 12:49:47 CEST Douglas Roark via bitcoin-dev
wrote:
> It's not the website's fault if wallet devs aren't updating their
> statuses. Besides, "WIP" can mean an awful lot of things.
As I said, it would be nice to get an updated version so we can see more
than 20% readyness of wallets.
The wallet devs not caring enough to update the status should be a worrying
sign, though.
> A lot of devs have already worked on SegWit support. This has been
> covered. Even if they don't support SegWit, the wallets will probably
> work just fine. (For awhile, Armory did crash when trying to read SegWit
SegWit is probably the most disruptive and most invasive change ever made to
Bitcoin. We have miners actively saying they don't like it and this makes it
a contriversial upgrade which means the network may split and other issues.
Your "wallets will probably work just fine" comment is honestly not the
answer to make people put faith in the way that this is being vetted and
checked...
> Also, once again, FlexTrans is off-topic.
Its an alternative and brought up in that vain. Nothing more. Feel free to
respond to the BIP discussion (134) right on this list if you have any
opinions on it. They will be on-topic there. No problems have been found so
far.
Lets get back to the topic. Having a longer fallow period is a simple way to
be safe. Your comments make me even more scared that safety is not taken
into account the way it would.
People are not even acknowledging the damage a contriversial soft fork of
the scope and magnitude of SegWit can have, and a simple request to extend
the fallow time for safety is really not a big deal.
SegWit has been in development for 18 months or so, what is a couple of
extra week??
I would just like to ask people to take the safety of Bitcoin serious. This
discussion and refusal to extend the safety period is not a good sign.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:54:03

- reply

📅 Original date posted:2016-10-16
📝 Original message:On Monday, 17 October 2016 03:11:23 CEST Johnson Lau wrote:
> > Honestly, if the reason for the too-short-for-safety timespan is that
> > you
> > want to use BIP9, then please take a step back and realize that SegWit
> > is a contriversial soft-fork that needs to be deployed in a way that is
> > extra safe because you can't roll the feature back a week after
> > deployment. All transactions that were made in the mean time turn into
> > everyone-can- spent transactions.
>
> No one should use, nor anyone is advised to use, segwit transactions
> before it is fully activated.
Naturally, I fully agree.
It seems I choose the wrong words, let me rephrase;
You can't roll the SegWit back a week after people are allowed to send
segwit transactions (lock-in + fallow period). All transactions that were
made in the mean time turn into everyone-can- spent transactions.
Because the network as a whole and any implementation is unable to roll back
in an environment where SegWit is a contriversial soft-fork, it is super
important to make sure that it is properly supported by all miners. This
takes time and the risk you take by pushing this is that actual real people
loose actual real money because of the issue I outlined inthe previous
paragraph.
> Having 2 months or 2 weeks of grace period
> makes totally no difference in this regard. If anyone tried to use segwit
> tx during your proposed 2 months grace period, all those txs were still
> everyone-can-spent.
>
> All you are advocating is just stalling the process with no improvement in
> security.
I hope the above explains the actual security issue better.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:54:02

- reply

📅 Original date posted:2016-10-16
📝 Original message:On Sunday, 16 October 2016 20:41:34 CEST Jorge Timón wrote:
> You keep insisting on "2 months after activation", but that's not how
> BIP9 works. We could at most change BIP9's initial date, but if those
> who haven't started to work on supporting segwit will keep waiting for
> activation, then changing the initial date won't be of any help to
> them can only delay those who are ready and waiting.
Then don't use BIP9...
Honestly, if the reason for the too-short-for-safety timespan is that you
want to use BIP9, then please take a step back and realize that SegWit is a
contriversial soft-fork that needs to be deployed in a way that is extra
safe because you can't roll the feature back a week after deployment.
All transactions that were made in the mean time turn into everyone-can-
spent transactions.
I stand by the minimum of 2 months. There is no reason to use BIP9 as it was
coded in an older client. That is an excuse that I don't buy.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:54:02

- reply

📅 Original date posted:2016-10-16
📝 Original message:On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev
wrote:
> Would I want anyone to lose money due to faulty wallets? Of course not.
> By the same token, devs have had almost a year to tinker with SegWit and
> make sure the wallet isn't so poorly written that it'll flame out when
> SegWit comes along. It's not like this is some untested, mostly unknown
> feature that's being slipped out at the last minute
There have been objections to the way that SegWit has been implemented for a
long time, some wallets are taking a "wait and see" approach. If you look
at the page you linked[1], that is a very very sad state of affairs. The
vast majority is not ready. Would be interesting to get a more up-to-date
view.
Wallets probably won't want to invest resources adding support for a feature
that will never be activated. The fact that we have a much safer alternative
in the form of Flexible Transactions may mean it will not get activated. We
won't know until its actually locked in.
Wallets may not act until its actually locked in either. And I think we
should respect that.
Even if all wallets support it (and thats a big if), they need to be rolled
out and people need to actually download those updates.
This takes time, 2 months after the lock-in of SegWit would be the minimum
safe time for people to actually upgrade.
1) https://bitcoincore.org/en/segwit_adoption/
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:53:58

- reply

📅 Original date posted:2016-10-15
📝 Original message:On Saturday, 15 October 2016 14:12:09 CEST Marco Falke wrote:
> On Sat, Oct 15, 2016 at 1:00 PM, Tom Zander via bitcoin-dev
>
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > My suggestion (sorry for not explaining it better) was that for BIPS to
> > be a public domain (aka CC0) and a CC-BY option and nothing else.
>
> Indeed, we agree that BIPs should be licensed as permissive as
> possible. Still, I wonder why you chose otherwise with BIP 134.
> (Currently OPL and CC-BY-SA)
OPL was the only allowed option apart from CC0.
I dual licensed it so future acceptance of the CC-BY-SA one may mean someone
can just remove the OPL from the BIP and no futher action or permission is
needed from all the authors.
> BIP 2 does not forbid you to release your work under PD in
> legislations where this is possible
It does, actually.
> One
> of the goals of BIP 2 is to no longer allow PD as the only copyright
> option.
That's odd as PD was never the only copyright option.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:53:57

- reply

📅 Original date posted:2016-10-15
📝 Original message:On Saturday, 15 October 2016 12:11:02 CEST Marco Falke wrote:
> On Sat, Sep 24, 2016 at 11:41 AM, Tom via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I'd suggest saying that "Share alike" is required and "Attribution" is
> > optional.
>
> Please note there is no CC license that requires SA and at the same
> time has BY as an option.
>
> Generally, I think CC0 is best suited as license for BIPs. If authors
> are scared that they won't get proper attribution, they can choose
> MIT/BSD or CC-BY.
My suggestion (sorry for not explaining it better) was that for BIPS to be a
public domain (aka CC0) and a CC-BY option and nothing else.
I like you agree with that part, but I see you added two licenses.
Do you have a good reason to add MIT/BSD to that list? Otherwise I think we
agree.
Using code-specific licenses (including the GPL) for documentation and
specifically a specification is a really poor fit and doens't make much sense.
> Other than that I don't think that more restrictive
> licenses are suitable for BIPs. The BIP repo seems like the wrong
> place to promote Open Access (e.g. by choosing a CC-BY-SA license).
> BIP 2 allows such licenses, but does not recommend them, which is
> fine.
>
> I think that BIP 2 in its current form (
> https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki
> @6e47447b )
Well, it has this sentence;
> This BIP is dual-licensed under the Open Publication License and
> BSD 2-clause license.
Which is a bit odd in light of the initial email from Luke that suggested we
drop the Open Publication License and we use the CC ones instead in addition
to the public domain one.
Marco:
> looks good and addressed the feedback which was
> accumulated last year. If there are no objections I'd suggest to move
> forward with BIP 2 in the next couple of days/weeks.
Thats odd, you just stated you like the public domain (aka CC0) license, yet
you encourage the BIP2 that states we can no longer use public domain for
BIPs... Did you read it?
It says;
«Public domain is not universally recognised as a legitimate action, thus
it is inadvisable.» [1]
Also;
This list has not seen a lot of traffic, if you want to make sure people keep
using the BIP process, I think you need to reach out to the rest of the
community and make sure this has been heard and discussed.
Moving forward the way it is now will likely deminish the importance of the
BIP process.
I strongly suggest people make very clear any and all changes that are
proposed and defend each of them with reasons why you want to change things.
1) if you write as a rationale "In some jurisdictions, public domain is not
recognised as a legitimate legal action" then you can at least name those
jurisdictions and explain how they *do* support things like GPL. Burden of
proof is on the man who wants to change things.
It looks fishy when lawyers disagree. See the CC wikipedia page;
"public domain: cc0 Freeing content globally without restrictions"
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:53:55

- reply

📅 Original date posted:2016-10-15
📝 Original message:On Friday, 14 October 2016 04:51:01 CEST Daniel Robinson via bitcoin-dev
wrote:
> > Because if not, the DPL is still better than the status quo.
>
> Agreed. Also worth noting that it has a potential advantage over
> unilateral patent disarmament, analogous to the advantage of copyleft
> licenses over MIT/BSD: it provides an incentive (at least a theoretical
> one) for other companies to adopt it too.
This is a very important point and a huge step forward in my opinion.
The downside of MIT/BSD licenses is that companies can take and not give
back. It doesn't build a community and commonly-shared property. Copyleft
allows people to take and embrace, but if they extend they have to give
back. Which is fair, you build it on their stuff...
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:50:17

- reply

📅 Original date posted:2016-05-09
📝 Original message:On Sunday, May 08, 2016 03:24:22 AM Matt Corallo wrote:
> >> ===Intended Protocol Flow===
> >
> > I'm not a fan of the solution that a CNode should keep state and talk to
> > its remote nodes differently while announcing new blocks.
> > Its too complicated and ultimately counter-productive.
> >
> > The problem is that an individual node needs to predict network behaviour
> > in advance. With the downside that if it guesses wrong that both nodes
> > end up paying for the wrong guess.
> > This is not a good way to design a p2p layer.
>
> Nodes don't need to predict much in advance, and the cost for predicting
> wrong is 0 if your peers receive blocks with a few hundred ms between
> them (as we should expect) and you haven't set the announce bit on more
> than a few peers (as the spec requires for this reason).
You misunderstand the networking effects.
The fact that your node is required to choose which one to set the announce
bit on implies that it needs to predict which node will have the best data in
the future.
It needs to predict which nodes will not start being incommunicado and it
requires them to predict all the things that are not possible to predict in a
network.
In networking it is even more true than in stocks; results of the past are no
guarantee for the future.
This means you are creating a fragile system. Your system will only work in
laboratory situations. It will fail spectacularly when the network or the
internet is under stress or some parts fall away.
Another problem with your solution is that nodes send a much larger amount of
unsolicited data to peers in the form of the thin-block compared to the normal
inv or header-first data.
Saying this is mitigated by only subscribing on this data from a small
subsection of nodes means you position yourself in a situation that I
displayed above. A tradeoff of fragile and fast. With no possible way to make
a node automatically decide on a good equilibrium.
> It seems I forgot to add a suggested peer-preforwarding-selection
> algorithm in the text, but the intended use-case is to set the bit on
> peers which recently provided you blocks faster than other peers, up to
> only one or three peers. This is both simple and should be incredibly
> effective.
Network autorepair systems have been researched for decades, no real solution
has as of yet appeared.
PHDs are written on the subject and you want to make this a design for Bitcoin
based on "[it] should be incredibly effective", I think you are underestimating
the subject matter you are dealing with.
> > I would suggest that a new block is announced to all nodes equally and
> > then
> > individual nodes can respond with a request of either a 'compact' or a
> > normal block.
> > This is much more in line with the current design as well.
> >
> > Detection if remote nodes support compact blocks, for the purpose of
> > requesting a compact-block, can be done either via a network-bit or just a
> > protocol version. Or something else entirely, if you have better
> > suggestions.
>
> In line with recent trends, neither service bits nor protocol versions
> are particularly well-suited for this purpose.
Am I to understand that you choose the solution based on the fact that service
bits are too expensive to extend? (if not, please respond to my previous
question actually answering the suggestion)
That sounds like a rather bad way of doing design. Maybe you can add a second
service bits field of message instead and then do the compact blocks correctly.
> >> Variable-length integers: bytes are a MSB base-128 encoding of the
> >> number.
> >> The high bit in each byte signifies whether another digit follows.
> >> [snip bitwise spec]
> >
> > I suggest just referring to UTF-8 which describes this just fine.
> > it is good practice to refer to existing specs when possible and not copy
> > the details.
>
> Hmm? There is no UTF anywhere in this protocol. Indeed this section
> needs to be rewritten, as indicated. I'd recommend you read the code
> until I update the section with better text if you're confused.
Wait, you didn't steal the variable length encoding from an existing standard
and you programmed a new one?
I strongly suggest you don't reinvent this kind of protocol level encodings
but instead steal from something like UTF8. Which has been around for decades.
Please base your standard on other standards where possible.
Look at UTF-8 on wikipedia, you may have "invented" the same encoding that IBM
published in 1992.
> >> ====Short transaction IDs====
> >> Short transaction IDs are used to represent a transaction without
> >> sending a full 256-bit hash. They are calculated by:
> >> # single-SHA256 hashing the block header with the nonce appended (in
> >> little-endian)
> >> # XORing each 8-byte chunk of the double-SHA256 transaction hash with
> >> each corresponding 8-byte chunk of the hash from the previous step
> >> # Adding each of the XORed 8-byte chunks together (in little-endian)
> >> iteratively to find the short transaction ID
> >
> > I don't think this is needed. Just use the first 8 bytes.
> > The reason to do xor-ing doesn't hold up and extra complexity is unneeded.
> > Especially since you mention some lines down;
> >
> >> The short transaction ID calculation is designed to take absolutely
> >> minimal processing time during block compaction to avoid introducing
> >> serious DoS vulnerabilities
>
> I'm confused as to what, specifically, you're proposing this be changed
> to.
Just the first (highest) 8 bytes of a sha256 hash.
The amount of collisions will not be less if you start xoring the rest.
The whole reason for doing this extra work is also irrelevant as a spam
protection.
--
Tom Zander

2023-06-07 19:48:42

- reply

📅 Original date posted:2016-02-06
📝 Original message:On Saturday, February 06, 2016 06:09:21 PM Jorge Timón via bitcoin-dev wrote:
> None of the reasons you list say anything about the fact that "being lost"
> (kicked out of the network) is a problem for those node's users.
That's because its not.
If you have a node that is "old" your node will stop getting new blocks.
The node will essentially just say "x-hours behind" with "x" getting larger
every hour. Funds don't get confirmed. etc.
After upgrading the software they will see the new reality of the network.
Nobody said its a problem, because its not.
--
Tom Zander

2023-06-07 19:43:54

- reply

📅 Original date posted:2015-10-28
📝 Original message:On Monday 26 Oct 2015 11:06:56 Douglas Roark via bitcoin-dev wrote:
> While not exactly the most rigorous link,
> https://en.wikipedia.org/wiki/LevelDB#Bugs_and_Reliability seems like an
> okay place to start.
Thanks for that link!
Another Google open source product I'll avoid like the plague ;)

2023-06-07 19:43:53

- reply

📅 Original date posted:2015-10-23
📝 Original message:On Thursday 22 Oct 2015 17:26:42 Jeff Garzik via bitcoin-dev wrote:
> It was noted that leveldb is unmaintained, and this is part of researching
> alternatives that are maintained and reliable.
Apart from it being unmaintained, any links to what are problems with levelDB?

2023-06-07 19:43:18

- reply

📅 Original date posted:2015-10-14
📝 Original message:On Tuesday 13 Oct 2015 14:56:08 Jonathan Toomim via bitcoin-dev wrote:
> Does anybody have any guesses where we might be leaking memory, or what is
> using the additional 2.4 GB? I've been using minrelaytxfee=0.00003 or
> similar on my nodes. Maybe there's a leak in the minrelaytxfee code path?
> Has anyone else seen something similar?
I suggest running it in valgrind with --leak-check=full for 10 minutes.
valgrind --leak-check=full src/bitcoind 2>&1 | tee out
This at least will show you any memory leaks at exit.
Naturally, the leaks you observe may just be design issues where cache can
grow to much and when the cache is cleaned on shutdown you won't see it in the
valgrind output.

2023-06-07 19:42:48

- reply

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

2023-06-07 19:42:48

- reply

📅 Original date posted:2015-10-06
📝 Original message:On Monday 5. October 2015 21.26.01 Gregory Maxwell wrote:
> On Mon, Oct 5, 2015 at 9:08 PM, Tom Zander via bitcoin-dev
>
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > On Monday 5. October 2015 20.56.34 Gregory Maxwell wrote:
> >> (In this case, I don't even believe we have any regulator
> >>
> >> contributors that disagree).
> >
> > Regular contributor?
> >
> > Please explain how for a fork in the protocol should you only listen to
> > regular Bitcoin Core contributors?
>
> I'm providing some perspective and scope-- referencing again your
> comment about following actions-- what element of the many dozens of
> responses suggests to you that _anyone_ is not being listened to?
Have you ever been at a meeting where you didn't feel like you were being
listened to?
You get comments like;
«I respond to the technical arguments not because I believe they are
earnestly motivated, but because they provide an avenue for learning for
myself and others.»
«"there is no gridlock here» After several respected members stated there is
disagreement.
«That Mike himself continues to misexplain things is not surprising since he
has all but outright said that »[snip] Which is putting words in the mouth
of someone you disagree with.
But what really gives a lot of people here the suggestion that members of the
community that are against the softfork are not being listened to is the
simple undeniable fact that an alternative or a remedy is not even considered.
There is no code. There is no question posted by the authors which flags to
use.
Actions speak much louder than words. Read the topic of this thread!
The actions show a disregard for the many objections. Consensus is not build
by repeating again and again the arguments that you belief will convince your
debate-opponent. It is about reaching a middle ground. If either side of the
debate refuses to budge from their position, you have gridlock.
What came of the request made to PeterT to document the risks and required
changes in wallets should this soft fork continue?
Why is it soo bad to use a hardfork (with proper voting) instead of a softfork
that we are in a place that the Bitcoin Core team is willing to throw out a
lot of goodwill and show their true colours in hundreds of mails that leave
the opposing side of this debate feeling ignored and left out?
I don't feel specifically unique or special. Nobody needs to reply to this
email. I don't claim peoples time.
All I'm doing is spelling out what has been living in the back of my head, and
with me a great deal of others, about how this is playing out.
If you choose to ignore this and you force a softfork, I belief you may be
surprised at how many active players in the Bitcoin marketplace may see that
the "Bitcoin Core" team is not an ally any longer.
It is good to remember that the graveyards are filled with people that
believed to be unreplaceable.
Bitcoin will go on.
Have a nice day!

2023-06-07 19:42:47

- reply

📅 Original date posted:2015-10-05
📝 Original message:On Monday 5. October 2015 19.41.30 Gregory Maxwell wrote:
> On Mon, Oct 5, 2015 at 7:13 PM, Tom Zander via bitcoin-dev
>
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > It is an eloquent change, but not really the topic we were discussing. It
> > also makes you attack Mike (calling him out as having a strawman) without
> > basis. For the second time in this thread.
> > I would suggest arguing on the topic, not on the man.
>
> Such a shame you appear to reserve that wisdom for those you disagree
> with, biting your tongue when others emit all forms of ad hominem--
You are special only in your eloquent use of the language. Consider yourself
lucky :)
> In this case, I think, however your correction is also misplaced at
> least on this message; though I would otherwise welcome it.
I would not expect anything less.
> I'm not complaining about the man;
> but pointing out the behavior of stating an
> opinion no one has held as theirs and attacking it is not a productive
> way to hold a discussion. It's an argument or a behavior, not a
> person, and beyond calling it bad I attempted to explaining (perhaps
> poorly) why its bad.
Thanks for explaining your thinking.
Fortunately I can say that while we certainly value your opinion, when peoples
opinions are hard to read, as you indicated they can be, we should look at
their actions. The group has followed the consensus rule quite rigorously,
which I applaud.
But next to that people like Black and Laan have given strong verbal
indications confirming the practice you personally keep explaining is not
real.
When I was a little boy of maybe 12 years, I remember reading a short story,
that stuck with me. It was about a man that had vowed to never lie. He was
invited to a dinner party and asked to assist with another man's accusation of
a crime he claimed to not have committed.
The end result was that the accused man was indeed guilty, but he minced his
words so well that every sentence uttered was true. To the layman he seemed
truthful and pleasant. Certainly innocent.
But to the man that never lied, his stories quickly fell apart as he himself
had had years of practice with the same. And the guilty man was jailed.
I really enjoy reading your emails and github posts too, they have an
eloquence and a brashness.
> If there is continued
> misunderstanding, I do not doubt its my fault; but it's probably not a
> good use of hundreds/thousands of people's time for you to help me
> interactively improve my explanation on list.
Quite.

2023-06-07 19:42:44

- reply

📅 Original date posted:2015-10-05
📝 Original message:Gregory,
you are good at language and its easy to write eloquent words.
Looking at this little dialog, for instance;
On Mon, Oct 5, 2015 at 3:56 PM, Sergio Demian Lerner wrote:
> > 1) ignores him, which is against the established criteria that all
> > technical objections coming from anyone must be addressed until that
> > person agrees, so that a change can be uncontroversial.
[snip]
On Monday 5. October 2015 18.35.13 Gregory Maxwell via bitcoin-dev wrote:
> I am aware of no instance where an active contributor to core has made
> the claim that no change to consensus can happen without 100% support
This *seems* to read like the same thing. But it is not. Your version is more
polarizing and changes the intent quite dramatically.
It is an eloquent change, but not really the topic we were discussing. It also
makes you attack Mike (calling him out as having a strawman) without basis.
For the second time in this thread.
I would suggest arguing on the topic, not on the man.

2023-06-07 19:42:43

- reply

📅 Original date posted:2015-10-05
📝 Original message:On Monday 5. October 2015 20.33.04 s7r via bitcoin-dev wrote:
> For example, I don't see this controversial nor a violation of the BIP
> requirements. Mike had some fair objections, they were explained by
> gmaxwell and Jorge, everybody understood. The explanation is clear,
> with plausible practical examples, so from my point of view the
> objections have no arguments to sustain the claim.
I enjoyed reading them, but I have to admit I'm not convinced and for me the
objections stand.
Softforks are unnecessarily dangerous and I feel entirely avoidable. It is a
risk that not worth taking.

2023-06-07 19:42:42

- reply

📅 Original date posted:2015-10-05
📝 Original message:On Monday 5. October 2015 18.04.48 Gregory Maxwell wrote:
> > Unsuccessfully.
>
> I think rather successfully.
Arguing that BIP66 rollout was a full success is in the same park of
"successful" ?
Where for weeks people were told not to trust the longest chain until it was
30 blocks.
Lets put that in perspective. The main functionality of Bitcoin
Frankly, if that fiasco happened in a company, people would get fired for
gross misconduct.
Bottom line is that there is a horrible track record of doing soft forks in
the past, there are some really good technical reasons why this should not
happen again.
And the defence against this argument is to do character assassination because
you think he has ulterior motives? Like you say in this part;
> That Mike himself continues to misexplain
> things is not surprising since he has all but outright said that his
> motivation here is to disrupt Bitcoin in order to try to force his
> blocksize hardfork on people.
"all but outright said" is still not said. Is still just a suspicion you have.
And you are accusing a man of something he didn't do.
That’s just not right.
> > The point is that Bitcoin Core claims to have a consensus mechanism and
> > sticks to "no change" on not reaching a consensus. And that rule is the
> > reason why bigger blocks were blocked for years.
>
> You're repeating Mike's claims there-- not anyone elses. Take your
> complaint up with him-- not the list.
There is no complaint. Why do you think there is?
Are you claiming that not reaching consensus is NOT the reason that bigger
blocks are not in Bitcoin Core?
Reaching consensus is an admirable goal. But its exactly that, a goal.
And anyone that is a perfectionist will know that in the real world goals are
often not reached. That doesn't make them less useful. That makes them goals.
This specific goal is in conflict of building a good product and a well
functioning community.
A good product and a well functioning community needs rules and needs timely
decisions and conflict resolution.
It does not need muting of valuable voices, it does not need character
assassinations and it really doesn't need egos.
I suggest reading this book;
http://www.artofcommunityonline.org/

2023-06-07 19:42:41

- reply

📅 Original date posted:2015-10-05
📝 Original message:On Monday 5. October 2015 18.03.05 Btc Drak via bitcoin-dev wrote:
> However, I would like to challenge your assumption of point 1 that that by
> Mike making a rabble, it somehow makes CLTV deployment controversial. His
> arguments have been refuted.
Unsuccessfully.
> Simply making a noise does not make something controversial. When it is
> controversial, it is obvious and plain to see.
I think its plain to see the soft fork is controversial.
But that’s not the point.
The point is that Bitcoin Core claims to have a consensus mechanism and sticks
to "no change" on not reaching a consensus. And that rule is the reason why
bigger blocks were blocked for years.
History has shown that for many decision making processes this doesn't work,
and this argument has been made to Core.
Until today this was essentially a rule that hurt the things that Mike was
really passionate about.
Today this hurts the things that some other devs are passionate about.
I think today is the day that everyone should agree that the past is the past
and we all learned our lesson and Bitcoin Core will make decisions a different
way.