<unnamed>

Public Key

npub1mju50kqcm07heu967fkq6h4kq666xgekc4yrldf7q52xx9vr8jnsrdxnq7

Profile Code

nprofile1qqsdew28mqvdhltu7za0ymqdt6mqdddryvmv2jplk5lq29rrzkpnefcpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqgdwaehxw309ahx7uewd3hkcqg5waehxw309aex2mrp0yhxgctdw4eju6t06taqw6

Publishing to

relay.primal.net

nos.lol

relay.damus.io

Last Notes

2023-06-07 20:00:24 CEST

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

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

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

- 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 19:59:59 CEST

- reply

📅 Original date posted:2017-04-14
📝 Original message:Thinking about this a bit, I support this proposal for a BIP.
This is not Bitcoin, but address types are bound to meet in meat-space and
it would be good to have a central place where this is defined.
I would very much appreciate someone that worked on BIP32/BIP43 itself to
comment on the details.
Quoting bip 43;
"We encourage different schemes to apply for assigning a separate BIP
number and use the same number for purpose field, so addresses won't be
generated from overlapping BIP32 spaces."
On Wednesday, 12 April 2017 12:02:37 CEST Nick Johnson via bitcoin-dev
wrote:
> <pre>
> BIP: bip-nickjohnson-ethereum-purpose
> Layer: Applications
> Title: Ethereum purpose allocation for Deterministic Wallets
> Author: Nick Johnson <nick at ethereum.org>
> Status: Proposed
> Type: Standards Track
> Created: 2017-04-12
> </pre>
>
> ==Abstract==
>
> This BIP defines a logical hierarchy for deterministic wallets on the
> Ethereum blockchain based on an algorithm described in BIP-0032 (BIP32
> from now on) and purpose scheme described in BIP-0043 (BIP43 from now
> on).
>
> This BIP is a particular application of BIP43.
>
> ==Motivation==
>
> Because Ethereum is based on account balances rather than UTXO, the
> hierarchy defined by BIP44 is poorly suited. As a result, several
> competing derivation path strategies have sprung up for deterministic
> wallets, resulting in inter-client incompatibility. This BIP seeks to
> provide a path to standardise this in a fashion better suited to
> Ethereum's unique requirements.
>
> ==Path levels==
>
> We define the following 2 levels in BIP32 path:
>
> <pre>
> m / purpose' / subpurpose' / *
> </pre>
>
> Apostrophe in the path indicates that BIP32 hardened derivation is used.
>
> Each level has a special meaning, described in the chapters below.
>
> ===Purpose===
>
> Purpose is a constant set to the hardened value of the BIP number assigned
> to this BIP (equivalently, the BIP number, bitwise ORed with 0x80000000)
> following the BIP43 recommendation.
> It indicates that the subtree of this node is used according to this
> specification.
>
> Hardened derivation is used at this level.
>
> ===Subpurpose===
> Subpurpose is set to the EIP number specifying the remainder of the BIP32
> derivation path. This permits new Ethereum-focused applications of
> deterministic wallets without needing to interface with the BIP process.
>
> Hardened derivation is used at this level.
>
> ==Reference== * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic
> Wallets]] * [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic
> Wallets]]
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:59:53 CEST

- 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:58:59 CEST

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

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

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

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

- 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:58:04 CEST

- 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:57:21 CEST

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

- reply

📅 Original date posted:2017-01-02
📝 Original message:On Monday, 2 January 2017 16:05:58 CET t. khan wrote:
> On Mon, Jan 2, 2017 at 3:35 PM, Tom Zander <tomz at freedommail.ch> wrote:
> > 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?
>
> The beauty of math is that everyone on the planet agrees how it works.
> Everything in Bitcoin is math, with the exception of the blocksize limit
> (1MB) which was a stop-gap solution at the time.
In actual fact the block size *is* set by miners, not math. And always has
been.
In your proposal the max blocksize continues to be set by miners as a
secondary effect of them choosing the block size.
Saying the max is actually math is painting an illusion that is rather thin
and easy to see through because every single usecase for your suggestion
starts with the choice of blocksize that a human makes. There is not really
any other input except some rather simple algorithm.
> > 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?
>
> No. That would be an epic disaster. There's no such thing as a "simple
> policy" when humans are involved.
This is ignoring history where miners have successfully set policy on block
size for years now.
> Obviously no one would agree on what X
> bytes would be and you'd have some nodes rejecting blocks that others
> already accepted.
Not sure about your "obviously". I don't agree. In fact, there is plenty of
reason to think it does work.
Miners have always been the ones to decide on the block size, and they have
always done this in a coordinated fashion. This is a natural consequence of
the rather elegant (economic) design of Bitcoin.
* Miners earn more fee-based income when they produce bigger blocks.
* Miners take more risk of their blocks being orphaned with bigger blocks.
* Miners want to avoid emptying the memory pool every block as that removes
a total need for users to pay fees.
* Miners want to make sure the mempool does not become backlogged because
users that do not see their transactions confirmed will get disappointed and
find other means to do payments. Which hurts the price and in effect hurts
the miners income.
This behaviour in block size means blocks will not get huge and they will
not stay small either, because there are reasons for both. And so the size
will be something in the middle.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:55:14 CEST

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

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

- reply

📅 Original date posted:2016-10-16
📝 Original message:On Sunday, 16 October 2016 12:35:58 CEST Gavin Andresen wrote:
> On Sun, Oct 16, 2016 at 10:58 AM, Tom Zander via bitcoin-dev <
>
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> > The fallow period sounds waaaay to short. I suggest 2 months at minimum
> > since anyone that wants to be safe needs to upgrade.
>
> I asked a lot of businesses and individuals how long it would take them to
> upgrade to a new release over the last year or two.
>
> Nobody said it would take them more than two weeks.
The question you asked them was likely about the block size. The main
difference is that SPV users do not need to update after BIP109, but they do
need to have a new wallet when SegWit transactions are being sent to them.
This upgrade affects also end users, not just businesses etc.
Personally, I'd say that 2 months is even too fast.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

2023-06-07 19:50:17 CEST

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

- 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:53 CEST

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

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

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

- 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:44 CEST

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

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

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