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

nprofile1qqsdew28mqvdhltu7za0ymqdt6mqdddryvmv2jplk5lq29rrzkpnefcprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskueqpzaz3e

Publishing to

relay.noswhere.com

relay.nostr.band

Author Public Key

npub1mju50kqcm07heu967fkq6h4kq666xgekc4yrldf7q52xx9vr8jnsrdxnq7

Show more details

Last Notes

2023-06-07 18: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 18: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 18: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 18: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 18: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 18: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 17: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 17: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 17: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 17: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 17: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 17: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 17: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 17: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 17:54:34

- reply

📅 Original date posted:2016-11-25
📝 Original message:On Thursday, 24 November 2016 22:39:05 CET Sergio Demian Lerner via bitcoin-
dev wrote:
> Without a detailed analysis, unlimited block size seems a risky change to
> Bitcoin, to me.
What exactly do you think is a ‘change’ in bitcoin here?
The concept of proof-of-work is that the longer a chain, the higher
probability that that one will be extended for the simple reason that
another chain will have to show a higher amount of proof of work to ‘win’.
As far as I understand the document from Peter, there is no change there at
all. Only chains with more POW will win.
Or, to answer your example, miners will prefer to extend the chain with the
most POW.
The other fact stays the same as well, if you protect from reorgs by
expecting more confirmations. Nothing changes here either. The common-sense 6
confirmations for things like exchange-deposits keep having the same
security.
The basic idea that we have a 3 or 4 deep fork is a huge problem in Bitcoin.
It hasn’t happened for ages, and we like it that way. The miners like it
that way too. Its disruptive.
The is a problem that is not created by the ‘excessive block’ concept. It
does, however, provide a possible solution to this very far-fetched problem.
You should also realize that the policy of a miner is stored in the
coinbase.
That said, I’m sure there are improvements to be made to the policy that BU
uses. But since this is a node-local policy, the consensus rules are not
affected by it.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 17: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 17: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 17: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 17: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 17: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 17: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?