Thomas Zander [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-09-15 to 2015-08-14
💬 Posted a total of 66 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1du3xh5wgds32a5fweqkd9k45kh30wl7kv2kyu8ugz9c2ztdg00tqqvyg93

Profile Code

nprofile1qqsx7gnt68yxcg4w6yhvstxjm26ttchh0ltx9tzwr7ypzu9p9k58h4sz9l72d

Author Public Key

npub1du3xh5wgds32a5fweqkd9k45kh30wl7kv2kyu8ugz9c2ztdg00tqqvyg93

Show more details

Last Notes

2023-06-07 17:34:51

- reply

📅 Original date posted:2015-08-12
📝 Original message:On Wednesday 12. August 2015 12.28.39 Jorge Timón wrote:
> But let's just list the concerns first.
Concerns?
I have never heard of "develop-by-concerns"? Is that similar to
fire fighting management?
To that I have this reply;
http://www.aleanjourney.com/2009/07/stop-fighting-fires.html
Your question makes sure that the proper answers don't fit.
And that may be why you are getting frustrated because I've given a lot of
reasons why a blocksize increase is needed soon, and none of them show up
in your list...
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010120.html
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010129.html
And various others; I'm not going to bother pasting URLs, you probably have
them already.
Point is, Bitcoin is a growing network, with a growing amount of transactions
and we KNOW we will get into problems when the block consistently get full.
How do we know? Because of the old guys in this list having the experience
that this always happens, because anyone in the IT business can tell you the
same.
We have started LN to cope with this growth, but this won't be enough since it
just won't handle all usecases and thus the on-chain growth will continue. For
instance remittances and cross-border purchases.
We need both LN as well as bigger blocks.
--
Thomas Zander

2023-06-07 17:34:50

- reply

📅 Original date posted:2015-08-14
📝 Original message:On Friday 14. August 2015 09.26.33 Venzen Khaosan via bitcoin-dev wrote:
> In the scenario below, you argue that the current 1MB limit would lead
> to "constantly full" blocks. If the limit is increased to say 1.6GB
> then a government or banking group may choose to utilize 1.5GB of the
> capacity of each block (and pay fees or not) for their settlement
> network. Then how did upping the blocksize remedy anything? Or is this
> use-case not plausible?
Your usecase only makes sense if we assume that blocks are community property.
This is provably not the case, it has been proven with the recent spam attack,
people could just continue sending their payments without issues by just
increasing the fee a bit.
As such, the bigger blocks don't immediately get filled, it makes more space
for everyone. People abusing it will also have to spend a lot more money (that
goes to benefit the network as a whole) to disrupt it.
--
Thomas Zander

2023-06-07 17:34:34

- reply

📅 Original date posted:2015-08-10
📝 Original message:On Monday 10. August 2015 12.53.33 Leo Wandersleb via bitcoin-dev wrote:
> > The reason of it being faster makes no sense, as your example the channel
> > has been open for a month then he really doesn't care it takes 1, 10 or
> > 50 blocks before his transaction is included. What is 5 hours wait on a
> > month of profit?
>
> I guess the assumption here is a full-block scenario where users of LN would
> be willing to pay 100 times the fees users of crude transactions would be
> willing to pay for the same limited space in the blockchain, simply because
> LN would group 100 real world payments into 1 crude transaction.
Thats exactly what I argued makes no sense to me.
Why pay for something you don't need? Paying something Just because you have
money is really not a good business strategy. I doubt that will happen.
--
Thomas Zander

2023-06-07 17:34:34

- reply

📅 Original date posted:2015-08-10
📝 Original message:On Monday 10. August 2015 07.57.30 Rune K. Svendsen via bitcoin-dev wrote:
> What Lightning does is raise the value of a transaction on the block chain.
> Imagine you're a Lightning node, and in order to collect your fees, that
> you've earned over the past month, you have to settle on the blockchain. If
> you've earned, say, 0.5 BTC in fees, you can attach a huge 0.005 BTC fee to
> the Bitcoin settlement transaction. The miners earn a larger fee, and you
> make sure your transaction gets into the blockchain quickly, and you can
> afford to pay this fee because you've made much more on the Lightning
> transactions you've routed.
I don't buy that argument, you are saying a company will give away profits
because of... what? It can?
The reason of it being faster makes no sense, as your example the channel has
been open for a month then he really doesn't care it takes 1, 10 or 50 blocks
before his transaction is included. What is 5 hours wait on a month of profit?
--
Thomas Zander

2023-06-07 17:34:24

- reply

📅 Original date posted:2015-08-10
📝 Original message:On Monday 10. August 2015 22.17.52 Jorge Timón wrote:
> But I don't see how that is relevant, allowing trust to be involved in
> different ways is a feature, but it's optional.
Agreed.
> I think the point "you don't need to trust anyone to use Bitcoin" remains.
yes, and thats fine.
The argument that Adam was making was the other extreme; that Bitcoin was
useless the moment he has to trust any 3rd party.
And that is why I started this thread, because that idea that Bitcoin looses
its functionality when you deviate from the trust-no-one path, is destructive.
For instance I suggested a week ago that the Chinese firewall (blocksize
propagation) problem could maybe be solved by having a chinese miner partially
trust some full nodes on Internet hubs. For instance in Amsterdam, one in
Stockholm, etc.
And then propagation of a newly mined block would make the miner only sent the
header to this server where a full x-MB block is then created by some
specialized software that bases it on the mempool of its bitcoind.
Propagation of a Chinese miner then suddenly doesn't care about blocksize when
hopping over the chinese firewall. You'd only send a small amount of data,
likely around 20Kb for even 8Mb blocks.
A critic would argue its a useless strategy because you'd have to trust the
data center operators.
I'd argue that its a risk, for sure, but one that can be mitigated easily by
having various datacenters around the world where you'd run your software so
you'd be able to check the validity of each.
Risks can only be assessed fairly if people are less black/white in their
thinking.
I love that about Bitcoin, it combines technical specialized thinking with
Economics and planning. If you don't have both, you probably end up rejecting
the best ideas.
> Adam, I think he means a multisig escrow transaction where the escrow
> is trusted by both parties, and other examples like that.
Yes, thats one example. Thanks Jorge!
A similar but relevant example would be like the M-Pesa example.
People that have a phone but not a smart phone can choose to have their
private keys stored at a trusted company in their own country. Some payments
can be off-chain, but as soon as you deal with people outside of this small
community they would be on-chain.
When we are talking about remittances, this means one of the two parties does
not have an account at the trusted party and as such this will be an on-chain
transaction.
Same for a farmer in Nairobi buying equipment from a company in Cairo, or a
Internet startup in Kampala/Uganda selling services to users in Europe and
those users send their payments on-chain.
All of these examples are about the largest group of people in the world; the
unbanked. Bitcoin could mean a huge change to these people and I care a lot
about this usecase. We need bigger bocks for these usecases as LN will not do
anything for them.
--
Thomas Zander

2023-06-07 17:34:23

- reply

📅 Original date posted:2015-08-08
📝 Original message:On Saturday 8. August 2015 12.54.36 Adam Back wrote:
> On 8 August 2015 at 09:54, Thomas Zander <thomas at thomaszander.se> wrote:
> > I didn't say off-chain, and gave an example of on-chain usecase with
> > trusted middleman.
> That's basically the definition of off-chain. When we say MtGox or
> coinbase etc are off-chain transactions, that is because a middle man
> has the private keys to the coins and gave you an IOU of some kind.
I'm so sorry to have to correct you again, and please don't feel bad about
misreading my post twice.
Sending something to another Bitcoin on-chain user is really on-chain. Please
believe me when I say that I actually understand my own example.
--
Thomas Zander

2023-06-07 17:34:21

- reply

📅 Original date posted:2015-08-08
📝 Original message:I didn't say off-chain, and gave an example of on-chain usecase with trusted middleman.
So, no, that's not what I meant.
Sent on the go, excuse the brevity.
Original Message
From: Adam Back
Sent: Saturday, 8 August 2015 09:50
To: Thomas Zander
Cc: Bitcoin Dev
Subject: Re: [bitcoin-dev] trust
If you are saying that some people are happy trusting other people,
and so would be perfectly fine with off-chain use of Bitcoin, then we
agree and I already said that off-chain use case would be a
constructive thing for someone to improve scale and interoperability
of in the post you are replying to. However that use case is not a
strong argument for weakening Bitcoin's security to get to more scale
for that use case.
In a world where we could have scale and decentralisation, then of
course it would be nice to provide people with that outlook more
security than they seem to want. And sometimes people dont understand
why security is useful until it goes wrong, so it would be a useful
thing to do. (Like insurance, your money being seized by paypal out
of the blue etc). And indeed providing security at scale maybe
possible with lightning like protocols that people are working on.
Adam

2023-06-07 17:34:20

- reply

📅 Original date posted:2015-08-08
📝 Original message:On Friday 7. August 2015 23.53.43 Adam Back wrote:
> On 7 August 2015 at 22:35, Thomas Zander via bitcoin-dev
> > As we concluded in our previous email, the need to run a node is inversely
> > proportional to the ability (or willingness) to trust others.
[]
> > And lets face it, practically everyone trusts others with their money
> > today.
> Bitcoin's very reason for existence is to avoid that need. For people
> fully happy to trust others with their money, Bitcoin may not be as
> interesting to them.
I'm making this a thread of its own because this is very serious.
The idea that Bitcoins very reason for existence is to avoid trusting anyone
but yourself is something I've heard before, and I have to comment because it
is a destructive thought. It is very much untrue because we don't live in a
black/white world.
If you look at the history of money (500 years is enough) you may know about
business being done in the late 1600s in Europe that included essentially a
general ledger that every merchant used and had his own copy of (at least
their own bits).
Merchant in France used a system that when they bought stock from one company
they didn't give them money, they instead gave them a IOU-style piece of
paper. To break your promise meant to be evicted from their money system.
Which to a merchant in that time is equal to starvation.
The point was NOT to trust no-one, the point was to trust everyone, but keep
everyone honest by keeping the ledger open and publicly available.
Bitcoins current model to decentralize and distribute trust has historical
precedent and is known to work. It was abandoned when Newton started the mint
in London because that allowed international trade. And their system didn't
scale.
On a tangent;
What we saw with the Internet is growth because of a lack of centralized
controller. This does not mean lack of trust in your neighbours. Internet grew
because permissionless innovation was allowed. Not by going from one extreme
of central trust to the other extreme of no trust.
It flourished just by stepping out of the trust-one party extreme.
What Adam Black and probably some others must understand is that there is a
whole spectrum between having a monopoly on trust and every player having
their own node.
Bitcoin sole reason for existence is because it is the first every system that
has global reach and does not need a central trusted party.
It is, in other words, the first alternative that for the very first time in
centuries that allows innovation without permission.
> For people
> fully happy to trust others with their money, Bitcoin may not be as
> interesting to them.
So, this is to black/white. And also wrong.
This thinking will block growth towards the thing you want, and leave you
without any toys at all.
For instance it is perfectly all right to have a central player in a poor
country that helps millions of unbanked to use Bitcoin as their first
international payment system.
I can only try to convince you to change your worldview be explaining some
history and concepts you may have missed, if you don't thats fine with me.
I do, however, have to ask you to assume people will not like Bitcoin and will
not use it because they don't fit your worldview. That will ultimately hurt
billions of people.
--
Thomas Zander

2023-06-07 17:34:11

- reply

📅 Original date posted:2015-08-12
📝 Original message:On Wednesday 12. August 2015 11.45.53 Jorge Timón wrote:
> This question had been dodged repeatedly (one more time in this last
> response).
This "last response" had a very direct answer to your question, why do you
think it was dodged?
I wrote; "To buy more time, get bigger blocks now." (quoted from parent-of-
parent)
But also said here;
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010129.html
and here;
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010186.html
> Then we could go one by one and classify them as:
>
> 1) Potential indirect consequence of rising fees.
I have not made any arguments that fall within this section.
> 2) Software problem independent of a concrete block size that needs to
> be solved anyway
I'd like to suggest that number two is not described narrowly enough. This
includes everything that we need, ever will need and want in the future...
2) Testing and architectural improvements related to nodes that get more
transactions than can be handled for a considerable time.
This includes problems we don't know of yet, since we haven't run under
these conditions before.
> If you think there's more "problem groups", please let me know.
> Otherwise I don't see the point in repeating the question. I have not
> received a straight answer but you think you've given it.
I quoted one such answer above, would be interested in knowing how you
missed it.
Here is another one from 2 hours before that email;
"All the banks, nasdaq, countries, businesses etc etc
"now contemplating using Bitcoin itself will see this as a risk too big to
"ignore and the 1Mb Bitcoin will loose 99% of its perceived value."
source; http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010180.html
> Seems like a dead end.
After repeating some answers you said were missing, it would be nice to
know where the connection drops.
Maybe you don't understand what people answer, if so, please ask to explain
instead of saying people are dodging the question. ;)
--
Thomas Zander

2023-06-07 17:34:10

- reply

📅 Original date posted:2015-08-12
📝 Original message:On Wednesday 12. August 2015 10.51.57 Jorge Timón wrote:
> > Personally I think its a bad idea to do write the way you do, which is
that
> > some people have to prove that bad things will happen if we don't make a
> > certain change. It polarizes the discussion and puts people into camps.
> > Peoplehave to choose sides.
>
> Whatever,
No, please don't just say "whatever". Show some respect, please.
If you have the courage to say people are spreading FUD you really should
have already exhausted all possible avenues of cooperation.
Now you look like you give up and blame others.
> I just give up trying that people worried about a non-increase in the short
> term answer to me that question. I will internally think that they just
> want to spread fud, but not vey vocal about it.
Again, I've been trying really hard to give you answers, straight answers.
It saddens me if you really are giving up trying to understand what people
equally enthusiastic about this technology may see that you don't see.
> It's just seems strange to me that you don't want to prove to me that's not
> the case when it is so easy to do so: just answer the d@#/&m question.
In the evolution of Bitcoin over the next couple of years we need bigger
blocks for a lot of different reasons. One of them is that LN isn't here.
The other is that we have known bugs that we have to fix, and that will take
time. Time we are running out of.
To buy more time, get bigger blocks now.
Anyway, I dislike your approach, as I said in the previous mail.
Its not about people spreading FUD or sidestepping the question, it is about
keeping the discussion civilised. You are essentially the one that asks;
"if you are not beating your wife, please prove it to me".
And the you get upset when I try to steer the conversation into less
black/white situations...
And, yes, that analogy is apt because you can't prove either.
--
Thomas Zander

2023-06-07 17:34:07

- reply

📅 Original date posted:2015-08-11
📝 Original message:On Tuesday 11. August 2015 00.08.42 Mark Friedenbach wrote:
> On Mon, Aug 10, 2015 at 11:31 PM, Thomas Zander via bitcoin-dev <
> So why do I work on Bitcoin, [] It can't
> be censored, it can't be shut down, and the rules cannot change from
> underneath you.
Fully agreed, and I like that a lot as well.
> It may hopefully never be necessary to operate under such constraints,
> except by freedom seeking individuals within existing totalitarian regimes.
I think remembering the Internet architecture here is viable.
There is a saying that censorship on the internet is seen as a defect and
route around. Bitcoin follows the same concept, and arguable is even better at
it since transactions don't have to be delivered to the network in real time.
It can be shipped by carrier pigeon in the extreme case ;)
Or though smileys over skype chat...
> However the credible threat of doing so may be what keeps Bitcoin from
> being repressed in the first place. Lose the capability to go underground,
> and it will be pressured into regulation, eventually.
I understand your point, its a good one.
Here is my counter argument; countries (or states) that fail to legally get
the bandwidth to do mining, are not an indicator for the success of Bitcoin.
Tor will work fine with a full node (or gnunet, if you want), just make sure
you take the transmission delays into account.
And naturally, there is the point that actual end users don't need a full
node. The system as a whole will work just fine for people in totalitarian
regimes as long as 100% of the world doesn't reach that point.
With various nodes in Sealand (near the UK) and miners in China, the system
would still work for users in New York.
> > Remember 8Gb/block still doesn't support VISA/Mastercard.
>
> No, it doesn't. And 8GB/block is ludicrously large -- it would absolutely,
> without any doubt destroy the very nature of Bitcoin, turning it into a
> fundamentally uninteresting reincarnation of the existing financial system.
> And still be unable to compete with VISA/Mastercard.
>
> So why then the pressure to go down a route that WILL lead to failure by
> your own metrics?
Naturally, I was referring to the existing proposal that 8Gb blocks would be
reached only in many years. Its a really long way away.
And if you read my previous replies on this thread you can see a more
substantial argument which I'll make brief here;
I'm not suggesting we scale the blocksize to accomodate for the next 10 years
of growth.
Instead I'm suggesting that we use solutions like Lightning and sidechains and
anything people can invent as soon as possible. But we need bigger blocks as
well. Because not any single solution is the answer, we need a combination of
multiple.
There really is no reason to suspect we can't actually increase the blocksize
in some months as the first thing we do.
--
Thomas Zander

2023-06-07 17:34:01

- reply

📅 Original date posted:2015-08-11
📝 Original message:An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/d95e325c/attachment.html>

2023-06-07 17:34:00

- reply

📅 Original date posted:2015-08-11
📝 Original message:On Monday 10. August 2015 23.03.39 Mark Friedenbach wrote:
> > So, while LN is written, rolled out and tested, we need to respond with
> > bigger
> > blocks. 8Mb - 8Gb sounds good to me.
>
> This is where things diverge. It's fine to pick a new limit or growth
> trajectory. But defend it with data and reasoned analysis.
We currently serve about 0,007% of the world population sending maybe one
transaction a month.
This can only go up.
There are about 20 currencies in the world that are unstable and showing early
signs of hyperinflation. If even small percentage of these people cash-out and
get Bitcoins for their savings you'd have the amount of people using Bitcoin
as savings go from maybe half a million to 10 million in the space of a couple
of months. Why so fast? Because all the world currencies are linked.
Practically all currencies follow the USD, and while that one may stay robust
and standing, the linkage has been shown in the past to cause chain-effects.
It is impossible to predict how much uptake Bitcoin will take, but we have
seen big rises in price as Cyprus had a bailin and then when Greece first
showed bad signs again.
Lets do our due diligence and agree that in the current world economy there
are sure signs that people are considering Bitcoin on a big scale.
Bigger amount of people holding Bitcoin savings won't make the transaction
rate go up very much, but if you have feet on the ground you already see that
people go back to barter in countries like Poland, Ireland, Greece etc.
And Bitcoin will be an alternative to good to ignore. Then transaction rates
will go up. Dramatically.
If you are asking for numbers, that is a bit tricky. Again; we are at
0,007%... Thats like a f-ing rounding error in the world economy. You can't
reason from that. Its like using a float to do calculations that you should
have done in a double and getting weird output.
Bottom line is that a maximum size of 8Mb blocks is not that odd. Because a 20
times increase is very common in a "company" that is about 6 years old.
For instance Android was about that age when it started to get shipped by non-
Google companies. There the increase was substantially bigger and the company
backing it was definitely able to change direction faster than the Bitcoin
oiltanker can change direction.
On the other side, 3Tb harddrives are sold, which take 8Mb blocks without
problems.
You can buy broadband in every relevant country that easily supports the
bandwidth we need. (remember we won't jump to 8Mb in a day, it will likely
take at least 6 months).
We should get the inverted bloom filters stuff (or competing products) working
at least on a one-to-one basis so we can solve the propagation time problem.
There frankly is a huge amount of optimization that can be done in that area,
we don't even use locality (pingtime) to optimize distribution..
>From my experience you can expect a 2-magnitude speedup in that same 6 month
period by focusing some research there.
Another metric to remember; if you follow hackernews (well, the incubator more
than the linked articles) you'd be exposed to the thinking of these startups.
Their only criteria is growth. and this is rather substantial growth. Like
150% per month. Naturally, most of these build on top of html or other
existing technologies. But the point is that exponential growth is expected
in any startup. They typically have a much much more agressive timeline,
though. Every month instead of every year.
Having exponential growth in the blockchain is really not odd and even if we
have LN or sidechains or the next changetip, this space will be used. And we
will still have scarcity.
Remember 8Gb/block still doesn't support VISA/Mastercard.
--
Thomas Zander

2023-06-07 17:33:59

- reply

📅 Original date posted:2015-08-11
📝 Original message:On Tuesday 11. August 2015 00.52.23 Pieter Wuille wrote:
> The whole point is that whether confirmation at a particular price point is
> reliable depends on how much demand there is at that price point. And
> increasing the block size out of fear of what might happen is failing to
> recognize that it can always happen that there is a sudden change in demand
> that outcompetes the rest.
>
> The point is not that evolution towards a specific higher feerate needs to
> happen, but an evolution to an ecosystem that accepts that there is never a
> guarantee for reliability, unless you're willing to pay more than everyone
> else - whatever that number is.
I'm going to go with this one, since we are seeking common ground and all of
this makes sense to me. And I bet to Gavin would agree to this too.
The question I want to ask is this;
How do you expect to get from the current to the situation outlined above?
There are several market forces at work;
* people currently expect near-free payments.
* people currently expect zero-confirmations.
* Bitcoin is seeing a huge amount of uptake, popularity, etc.
* With Greece still in flux, there is a potential enormous spike of usage set
to come when (not if) the Euro falls.
I conclude that we need;
* to create and make working solutions like LN, sidechains etc etc etc.
This should allow people to get their fast confirmation time. Who cares its of
a different nature, the point is that the coffeeshop owner lets you leave with
your coffee. We can sell that.
* To buy ourselves time, LN is not done, Bitpay and friends work on-chain.
That won't change for a year at least.
We need to move the max-block size to a substantial bigger size to allow
Bitcoin to grow.
Unfortunately for us all, Bitcoin is over-sold. We don't have a sales
department but the worth-of-mouth leaves us in a bad situation. And we need to
react to make sure the product isn't killed by bad publicity. What Gox didn't
manage can certainly happen when people find out that Bitcoin can't currently
do any of the things everyone is talking about.
So, while LN is written, rolled out and tested, we need to respond with bigger
blocks. 8Mb - 8Gb sounds good to me.
Can everyone win?
--
Thomas Zander

2023-06-07 17:33:58

- reply

📅 Original date posted:2015-08-10
📝 Original message:On Monday 10. August 2015 16.55.40 Jorge Timón via bitcoin-dev wrote:
> I'm not trying to be obstinate but I seriously can't see how they are
> different.
> When you say unreliable I think you mean "unreliable for cheap fee
> transactions". Transactions with the highest fees will always confirm
> reliably. For example, a 1 btc fee tx will probably always confirm very
> reliably even if capacity never increases and demands increases a lot.
The actual fee is irrelevant, the amount of transactions is relevant.
Have you ever been to a concert that was far away from public transport? They
typically set up bus shuttles, or taxis to get people back into town
afterwards.
The result there is always you end up waiting forever and it actually may be
easier to just walk instead of wait.
The amount you pay is irrelevant if everyone is paying it. There still is more
demand than there is capacity.
At the concert the amount of people will stop after some time, and you'd get
your bus. But in the scenarios created here the queues will never stop.
So, no, its not unreliable for cheap free transactions.
Its unreliable for all types of transactions.
--
Thomas Zander

2023-06-07 17:33:57

- reply

📅 Original date posted:2015-08-10
📝 Original message:On Monday 10. August 2015 16.34.55 Pieter Wuille via bitcoin-dev wrote:
> On Mon, Aug 10, 2015 at 4:12 PM, Gavin Andresen <gavinandresen at gmail.com>
>
> wrote:
> > Executive summary: when networks get over-saturated, they become
> > unreliable. Unreliable is bad.
> >
> > Unreliable and expensive is extra bad, and that's where we're headed
> > without an increase to the max block size.
>
> I think I see your point of view. You see demand for on-chain transactions
> as a single number that grows with adoption. Once the transaction creation
> rate grows close to the capacity, transactions will become unreliable, and
> you consider this a bad thing.
Everyone in any industry will consider that a bad thing.
There is no doubt that on-chain transactions will grow, absolutely no doubt.
You can direct many people to off-chain systems, but that will not stop growth
of on-chain transactions. Bitcoin economy is absolutely tiny and there is a
huge amount of growth possible. It can only grow.
> And if you see Bitcoin as a payment system where guaranteed time to
> confirmation is a feature, I fully agree.
Naturally, that is a usecase. But not really one that enters my mind. It
certainly is not a requirement to have guaranteed time.
The situation is much simpler than that.
We have maybe 0,007% of the world population using Bitcoin once a month. (half
a million people). And I'm being very optimistic with that number...
This should give you an idea of how much growth is possible.
There is no doubt at all that the 1Mb blocks will get full, continuously, if
we get to a higher rate of usage. Even with the vast majority of users using
Bitcoin off-chain.
As such its not about a guaranteed time-to confirmation. Its about a
confirmation before I die.
> If you want transactions to be cheap, it will also be cheap to make them
> unreliable.
Its not about transactions being cheap. The fee market is completely
irrelevant to the block size. If you think otherwise you are delusional.
The reason it is irrelevant is because when the system starts consistently
dropping transactions when user count goes up, and when that happens the
Bitcoin network looses value because people don't put value in something that
is unreliable.
This is simple economy 101.
Look at history; so many great companies made great products that had more
features, but didn't make it because their competition might have been slower
to market, but it was actually reliable.
--
Thomas Zander

2023-06-07 17:33:56

- reply

📅 Original date posted:2015-08-10
📝 Original message:On Monday 10. August 2015 10.24.18 Alex Morcos via bitcoin-dev wrote:
> think they are more just an example of how
> immature all of this technology is, and we should be concentrating on
> improving it before we're trying to scale it to world acceptance levels.
Would it be an idea to create a generator of transactions on the test network
that a large number of people can run? Using some randomization as well as the
actual estimation code would generate some reasonably useful data.
I'd volunteer my node to run that.
--
Thomas Zander

2023-06-07 17:33:55

- reply

📅 Original date posted:2015-08-12
📝 Original message:On Tuesday 11. August 2015 19.47.56 Jorge Timón wrote:
> On Aug 11, 2015 12:14 AM, "Thomas Zander via bitcoin-dev"
> > See my various emails in the last hour.
>
> I've read them. I have read gavin's blog posts as well, several times.
> I still don't see what else can we fear from not increasing the size apart
> from fees maybe rising and making some problems that need to be solved
> rewardless of the size more visible
[]
> This discussion is frustrating for everyone. I could also say "This have
> been explained many times" and similar things, but that's not productive.
> I'm not trying to be obstinate, please, answer what else is to fear or
> admit that all your feas are just potential consequences of rising fees.
Since you replied to me;
I have to admit I find that a little depressing.
I put forward about 10 reasons in the last 24 hours and all you remember is
something with fees. Which, thats the funny part, I never wrote as being a
problem directly.
> With the risk of sounding condescending or aggressive...Really, is not that
> hard to answer questions directly and succinctly.
I would really like to avoid putting blame. I'd like to avoid the FUD
accusation and calling people paranoid, even yourself, sounds rather bad
too...
Personally I think its a bad idea to do write the way you do, which is that
some people have to prove that bad things will happen if we don't make a
certain change. It polarizes the discussion and puts people into camps. People
have to choose sides.
I've been reading the blocksize debate for months now and have been
wondering
why people here are either for or against, it makes no sense to me.
Neither camp is right, and everyone knows this!
Everyone knows that bigger blocks doesn't solve the scalability problem.
Everyone knows that you can't get substantial growth using lightning or higher
fees in, say, the next 12 months.
please reply to this email;
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010129.html
--
Thomas Zander

2023-06-07 17:33:55

- reply

📅 Original date posted:2015-08-12
📝 Original message:On Tuesday 11. August 2015 21.27.46 Jorge Timón wrote:
> Can we agree that the first step in any potentially bad situation is
> hitting the limit and then fees rising as a consequence?
Fees rising due to scarcity has nothing to do with the problem. Its a
consequence that is irrelevant to me.
Bad situations are roughly divided into two parts;
* technical
* marketing.
The technical part is that we already know of several technical
solutions we
will need when we have a forever growing backlog. Without them, nodes
will
crash.
On top of that, we can expect a lot of new problems we don't know yet.
IT experts are serious when they say that they avoid maxing out a
system like
the plague.
Marketing wise full blocks means we can only serve 3 transactions a
second.
Which is beyond trivial. All the banks, nasdaq, countries, businesses
etc etc
now contemplating using Bitcoin itself will see this as a risk too big to
ignore and the 1Mb Bitcoin will loose 99% of its perceived value.
If you want fees to rise, then it should be viable to be used, withing 6
months, for something bigger than the economic size of Iceland.
(=random
smallest country I know).
--
Thomas Zander

2023-06-07 17:33:54

- reply

📅 Original date posted:2015-08-12
📝 Original message:On Tuesday 11. August 2015 21.51.59 Pieter Wuille via bitcoin-dev wrote:
> If people are doing transactions despite being unreliable, there
> must be a use for them.
Thats one usage of the form unreliable.
Yes, if people start getting their transactions thrown out because of full
blocks or full memory pools, then its unreliable to send stuff.
Much more importantly is the software is unreliable at such loads. Bitcoin
core will continue to grow in memory consumption, and eventually crash. Or,
worse, crash the system its running on.
We know of some issues in the software with regards to running at > 100%
capacity, I'm sure we'll find more when it actually happens.
IT experts are serious when they say that they avoid maxing out a system like
the plague.
This, btw, is a good scenario where more centralization ends up happening when
blocks are always full and people need to upgrade their client every week to
keep up with the bugfixes.

2023-06-07 17:33:54

- reply

📅 Original date posted:2015-08-12
📝 Original message:On Wednesday 12. August 2015 11.00.29 Jorge Timón wrote:
> Don't fear this happening at 1 MB, fear this happening at any size. This
> needs to be solved regardless of the block size.
I know, everyone knows.
There is a lot of work that needs to be done to be able to use bitcoind at an
forever growing backlog. And since I've been doing software for some decades,
I can tell you this won't be done or fixed in 6-12 months.
We probably haven't found the majority of the issues yet.
We need more time and a bigger blocksize gives us more time.
--
Thomas Zander

2023-06-07 17:33:42

- reply

📅 Original date posted:2015-08-10
📝 Original message:On Monday 10. August 2015 13.55.03 Jorge Timón via bitcoin-dev wrote:
> Gavin, I interpret the absence of response to these questions as a
> sign that everybody agrees that there's no other reason to increase
> the consensus block size other than to avoid minimum market fees from
> rising (above zero).
> Feel free to correct that notion at any time by answering the
> questions yourself.
> In fact if any other "big block size advocate" thinks there's more
> reason I would like to hear their reasons too.
See my various emails in the last hour.
--
Thomas Zander

2023-06-07 17:33:40

- reply

📅 Original date posted:2015-08-09
📝 Original message:On Saturday 8. August 2015 19.05.29 Alex Morcos via bitcoin-dev wrote:
> I agree
> There are a lot of difficult technical problems introduced by insufficient
> block space that are best addressed now.
I agree problems for space restrictions should be solved, and the sooner the
better.
What your statement has as a side-effect is that we will run into problems when
the moment of insufficient block space comes *this* year instead of in 5 years.
I can practically guarantee that no proper solutions will be deployed in time
for natural growth of usage to reach always 1Mb full blocks.
Having several more years to make such solutions will be very healthy.
> As well as problems that scale
> will exacerbate like bootstrapping that we should develop solutions for
> first.
Notice that many people here have tried but have been unable to find a relation
between max-blocksize and full node-count.
Also, there are pretty good solutions already, like a bootstrap torrent and
the headers first. In the upcoming release the actual CPU load should also get
better making the actual download much much faster than the 0.9 release.
Or, in other words, these problems have been solved in a large part already,
and more is underway.
I don't expect them to be showstoppers when a the network finally allows bigger
than 1Mb blocks. Natural growth has shown that blocks won't jump in size
significantly in one month anyway. So this scenario still has 6 months or so.
--
Thomas Zander

2023-06-07 17:33:40

- reply

📅 Original date posted:2015-08-09
📝 Original message:On Saturday 8. August 2015 15.45.28 Dave Scotese via bitcoin-dev wrote:
> Someone mentioned that when the backlog grows faster than it shrinks, that
> is a real problem. I don't think it is. It is a problem for those who
> don't wait for even one confirmation
The mention you refer to was about the fact that the software doesn't cope
well with a continuously growing mempool.
If Bitcoind starts eating more and more memory, I expect lots of people that
run it now to turn it off.
> but backlogs in the past have already
> started training users to wait for at least one confirmation, or go
> off-chain.
I am wondering how you concluded that? The only time we saw full blocks for a
considerable amount of time was when we had a spammer, and the only thing
we taught people was to use higher fees.
Actually, we didn't teach people anything, we told wallet developers to do it.
Most actual users were completely ignorant of the problem.
Full blocks will then stop being a supported usecase when real humans are
trying to buy a beer or a coffee. Waiting for a confirmation won't work either
for the vast majority of the current usages of Bitcoin in the real world.
> I am comfortable leaving those zero-conf people in a little bit
> of trouble. Everyone else can double-spend (perhaps that's not as easy as
> it should be in bitcoin core) and use a higher fee, thus competing for
> block space.
This is false, if you want to double spent you have to do a lot of work and
have non-standard software. For instance sending your newer transaction to a
random node will almost always get it rejected because its a double spent.
Replace by fee (even safe) is not supported in the vast majority of Bitcoin
land.
--
Thomas Zander

2023-06-07 17:33:37

- reply

📅 Original date posted:2015-08-07
📝 Original message:On Friday 7. August 2015 19.33.34 Jorge Timón via bitcoin-dev wrote:
> When "the network runs out of capacity" (when we hit the limit) do we
> expect anything to happen apart from minimum market fees rising (above
> zero)?
How many clients actually evict transactions from their mempool currently? If
the backlog grows infinitely (as a result of more in than out), that would be
a problem.
How many wallets re-transmit their transaction when your local full nodes
mempool no longer has it? Problem.
What will the backlash be when people here that are pushing for "off-chain-
transactions" fail to produce a properly working alternative, which
essentially means we have to say NO to more users. We can't service you,
sorry. Please go away.
At this time and this size of bitcoin community, my personal experience (and
I've been part of many communities) saying NO to new customers will kill the
product totally. Or, if we are lucky, just make an altcoin that quickly
becomes the de-facto standard.
--
Thomas Zander

2023-06-07 17:33:28

- reply

📅 Original date posted:2015-08-07
📝 Original message:On Friday 7. August 2015 20.10.48 Pieter Wuille wrote:
> But if the reason for increasing is because you fear a change of economics,
> then it means you prefer not dealing with that change.
Let me quote yourself;
On Thursday 6. August 2015 17.26.11 Pieter Wuille via bitcoin-dev wrote:
> I believe that it is essential to not take unnecessary risks,
> and find a non-controversial solution.
You want to change the basic economics of Bitcoin itself.
If anything is "unnecessary risks", that would be a clear contender.
--
Thomas Zander

2023-06-07 17:33:27

- reply

📅 Original date posted:2015-08-07
📝 Original message:On Friday 7. August 2015 20.10.48 Pieter Wuille wrote:
> On Aug 7, 2015 7:50 PM, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
> > I believe people in the Bitcoin ecosystem will choose different
> > tradeoffs, and I believe that is OK-- people should be free to make those
> > tradeoffs.
>
> I agree. Though I believe that the blockchain itself cannot offer many
> tradeoffs, and by trying to make it scale we hurt the whole system. The
> place to introduce tradeoffs is in layers on top - there you can build
> systems with various levels of trust without hurting others.
Pieter, you either misunderstood or misquoted Gavin here.
The tradeoffs Gavin talks about are about trusting your own node or using a
centralized system (as the two extremes in a spectrum).
Your answer talks about something completely different. Not sure how your
answer fits in this conversation, although, you do seem to use these
misunderstandings often to push your own position in a way that to the naive
reader it sounds like others agree with you. Please try to be more concise
and on-topic.
--
Thomas Zander

2023-06-07 17:33:25

- reply

📅 Original date posted:2015-08-07
📝 Original message:On Friday 7. August 2015 18.30.28 Pieter Wuille wrote:
> On Fri, Aug 7, 2015 at 6:06 PM, Thomas Zander via bitcoin-dev <
> > But your conclusion that low node count is an indication that its hard
> > to run one discards your own point. You forget the point that running
> > a node is only needed if you don't know anyone you can trust to run it
> > for you. I'm pretty darn sure that this will have a bigger effect on
> > nodecount than how hard it is.
>
> I never said it is the only factor that influences node count.
You wrote;
> They are an indication of how hard [node count] is (for various
> reasons) to run/use a full node, and thus provide feedback.
You clearly indicated that node count is an indicator of how hard it is to run
a node.
Thats like saying something is too expensive because we don't sell enough. It
forgets to ask the question of need. Do people want it.
Like in our case the need to run a node in the first place.
> If the incentives for running a node don't weight up against the
> cost/difficulty using a full node yourself for a majority of people in the
> ecosystem, I would argue that there is a problem. As Bitcoin's fundamental
> improvement over other systems is the lack of need for trust, I believe
> that with increased adoption should also come an increased (in absolute
> terms) incentive for people to use a full node. I'm seeing the opposite
> trend, and that is worrying IMHO.
And you do the same thing again; you dismiss the need factor.
Most merchants have no need for a node, most miners don't even want to run one
anymore. Users don't make a significant amount of payments to care.
Any conclusions with regards to difficulty of running a node based on max-
blocksize is speculation without numbers; the only numbers you have is
historical node count, and they don't mean shit because the need has not
grown.
For instance, merchants are told to trust someone like bitpay.
Historical node-count says nothing. Anyone using it for the blocksize debate
is speculating without basis.
--
Thomas Zander

2023-06-07 17:33:25

- reply

📅 Original date posted:2015-08-07
📝 Original message:On Friday 7. August 2015 19.09.30 Pieter Wuille wrote:
> > And you do the same thing again; you dismiss the need factor.
>
> Of course there is a need. It's the primary mechanism that keeps Bitcoin
> secure and immune from malicious influence.
I see a pretty big problem if this really is your insight, the need an
individual has for running a node is a completely different concept than the
need for nodes to exist. And, really, you are describing miners, not nodes.
good thing is that you seem to agree with me as your continue with;
> Of course not everyone needs to run a node.
Thats the 'need' I was talking about.
As we concluded in our previous email, the need to run a node is inversely
proportional to the ability (or willingness) to trust others.
And lets face it, practically everyone trusts others with their money today.
> But that leaves the
> responsibility on us - the community - to help the situation by not making
> it too hard to run a node. And I see the block size as the primary way
> through which we do that.
That won't really have any influence, economics 101 says that it doesn't work
that way. Lowering the cost on a product won't make it sell more without the
people wanting or needing the product.
> If the impact of the system goes u[p], so should the - joint - incentives to
> keep it secure. And I think we're (slowly) failing at that.
That is your opinion. At least, I don't see that conclusion supported by
evidence.
I'll defer to Gavins emails that countered this point better.
--
Thomas Zander

2023-06-07 17:33:24

- reply

📅 Original date posted:2015-08-07
📝 Original message:On Thursday 6. August 2015 20.52.28 Pieter Wuille via bitcoin-dev wrote:
> It's about reduction of trust. Running a full node and using it verify your
> transactions is how you get personal assurance that everyone on the network
> is following the rules. And if you don't do so yourself, the knowledge that
> others are using full nodes and relying on them is valuable. Someone just
> running 1000 nodes in a data center and not using them for anything does
> not do anything for this, it's adding network capacity without use.
>
> That doesn't mean that the full node count (or the reachable full node
> count even) are meaningless numbers. They are an indication of how hard it
> is (for various reasons) to run/use a full node, and thus provide feedback.
> But they are not the goal, just an indicator.
You make a logical fallacy;
I would agree that nodes are there for people to stop trusting someone that
they have no trust-relationship with.
But your conclusion that low node count is an indication that its hard to run
one discards your own point. You forget the point that running a node is only
needed if you don't know anyone you can trust to run it for you. I'm pretty
darn sure that this will have a bigger effect on nodecount than how hard it
is.
Or, in other words, without a need to run a node you can't judge the
difficulty of why there aren't more running.
>From another mail;
On Thursday 6. August 2015 17.26.11 Pieter Wuille via bitcoin-dev wrote:
> Maybe. But I believe that it is essential to not take unnecessary risks,
> and find a non-controversial solution.
This is a very political answer; it doesn't actually say anything since
'unnecessary' is a personal judgment. Everyone will agree with you, but that
doesn't mean anything.
--
Tom Zander

2023-06-07 17:33:10

- reply

📅 Original date posted:2015-08-10
📝 Original message:On Sunday 9. August 2015 23.51.50 Btc Drak via bitcoin-dev wrote:
> I thought it's worth mentioning there is a specific Lightning Network
> development mailing list at
> http://lists.linuxfoundation.org/mailman/listinfo/lightning-dev and already
> some pretty interesting explanations in the archives.
While that is interesting, and I'll surely check it out, I think this list
should get a good idea of what the limitations are.
Where does it NOT make sense to use LN, where would it be better to put the
transaction directly on the blockchain?
This is what I'd like to know.
Gavins usecase is useful, I'm also wondering about remittances and allowing
international payments and global economy (company in Nairobi buys stock from
company in Spain).
--
Thomas Zander

2023-06-07 17:32:43

- reply

📅 Original date posted:2015-08-07
📝 Original message:On Monday 3. August 2015 11.22.14 Gavin Andresen via bitcoin-dev wrote:
> (my only big disagreement with those predictions is the 'Number of nodes'
> -- I don't think replace-by-fee would affect that number, and I think even
> with no change we will see the number of full nodes on the network drop to
> a couple thousand, because the general-purpose-home-PC is headed the way of
> the dodo []
On the other hand, things like the Raspberry PI and similar hardware are
gaining ground fast. And they can run a node just fine.
I have many friends that run such small hardware for things like Owncloud.org
because it is decentralized. When Bitcoin gets traction with these people, I
have no doubt a nice portion of them will run a node for the same reason they
are running their private cloud. Trust No One.
Or, in other words, when Bitcoin grows in popularity and more people find it
interesting (and we fix longstanding issues in Core), the desktop node that
eventually get shut down will be replaced with the next generation hardware of
a different kind of Bitcoin user.
--
Thomas Zander

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-07-30
📝 Original message:On Thursday 30. July 2015 16.25.02 Pieter Wuille via bitcoin-dev wrote:
> Hello all,
>
> here is a proposal for long-term scalability I've been working on:
> https://gist.github.com/sipa/c65665fc360ca7a176a6
>
> Some things are not included yet, such as a testnet whose size runs ahead
> of the main chain, and the inclusion of Gavin's more accurate sigop
> checking after the hard fork.
>
> Comments?
Maybe this part could use a bit more rationale, it looks like its a sudden and
unexplained.
> No hard forking change that relaxes the block size limit can be guaranteed
> to provide enough space for every possible demand - or even any particular
> demand - unless strong centralization of the mining ecosystem is expected.
--
Thomas Zander

2023-06-07 15:44:10

- reply

📅 Original date posted:2015-07-31
📝 Original message:On Friday 31. July 2015 03.21.07 Jorge Timón via bitcoin-dev wrote:
> If I was a miner and you want me to include your transaction for free,
> you're asking me to give you money
What?
Ask yourself; why do miners include transactions at all? What it the incentive
if there really is only less than 0.8% of income to be derived from fees?
Miners don't get payed by fees. They won't need to get payed by fees for
decades to come. Maybe you want to re-do your math, it seems off.
--
Thomas Zander

2023-06-07 15:44:03

- reply

📅 Original date posted:2015-07-31
📝 Original message:On Thursday 30. July 2015 11.02.43 Mark Friedenbach wrote:
> It is possible for a decentralized system like bitcoin to scale via
> distribution in a way that introduces minimal trust, for example by
> probabilistic validation and distribution of fraud proofs. However changes
> to bitcoin consensus rules (mostly soft-forks) are required in order to
> make this possible.
Sounds overly complicated...
What about a much simpler solution where the miner has a CPU in a well
connected data center. Say, Amsterdam.
He runs bitcoind on there and he, in China or such, connects to it over RPC
(and ssl) to get a "block 000f00" accepted signal. Which would be 100 bytes or
so.
The miner continues to use his current setup, but with actual validation of
the blocks to completely eliminate the risk of mining on orphaned blocks and
at the same time remove most of the cost of larger-than-average bandwidth in
his country.
A slightly more complicated solution is needed to allow the miner to only send
the headers to the bitcoind instance. So he only sends a couple of kb and his
datacenter machine does the actual propagation.
If the risk of duplication becomes an issue, setup multiple propagating nodes
on different sides of the world.
Bottom line for me is that most of the innovation for making stuff better for
miners should be done in miners-specific software. Not in end-user software
like bitcoin-core.
--
Thomas Zander

2023-06-07 15:44:02

- reply

📅 Original date posted:2015-07-30
📝 Original message:On Thursday 30. July 2015 10.24.07 Bryan Bishop wrote:
> On Thu, Jul 30, 2015 at 9:52 AM, Thomas Zander via bitcoin-dev <
>
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> > What makes you think that when there is such a low availability of
> > transaction
> > space that paying to be included costs you $10, that Bitcoin is not going
> > to
> > be outcompeted and replaced or otherwise regarded as worthless?
>
> Ah, well that's simple. Because any decentralized system is going to have
> high transaction costs and scarcity anyway.
I've been doing system design for about 10 years and I can understand your
initial response.
I have to disagree with you, though. Surely decentralized adds an overhead,
but in its place it adds replication, redundancy and very cheap expansion of
capacity.
Remember when we went from single-core CPUs to multi-core (and
hyperthreading)? Developers were saying it was useless because all apps were
still single-threaded. And now, 15 years later, there are fantastic
frameworks to make this easy.
Same will happen with distributed. Any assumption you wrote above is not
inherent in the technology.
--
Thomas Zander

2023-06-07 15:44:02

- reply

📅 Original date posted:2015-07-30
📝 Original message:On Thursday 30. July 2015 11.55.50 Gavin Andresen wrote:
> What other successful or unsuccessful decentralized systems should we be
> looking at?
Parallel compiling systems (distcc, icecream, teambuilder).
Git vs subversion (or perforce).
Not a joke; googles search. Not from a user perspective, naturally. But their
filesystem and internal databases.
Wait, let me get a link; https://en.wikipedia.org/wiki/Google_File_System
and since I'm on wikipedia.
https://en.wikipedia.org/wiki/Parallel_rendering
Thinking about it; one inherent trait of successful distributed systems is
that they are fractal-like. Not one huge mesh, but islands that connect.
Bitcoin core does something similar, but it doesn't really. The 'ping' score
for connections is unreliable and its not really used to propagate smartly...
--
Thomas Zander

2023-06-07 15:44:02

- reply

📅 Original date posted:2015-07-30
📝 Original message:On Thursday 30. July 2015 18.07.40 Thomas Zander via bitcoin-dev wrote:
> Remember when we went from single-core CPUs to multi-core (and
> hyperthreading)? Developers were saying it was useless because all apps
> were still single-threaded. And now, 15 years later, there are fantastic
> frameworks to make this easy.
>
> Same will happen with distributed. Any assumption you wrote above is not
> inherent in the technology.
My brain went a bit to fast (dinner was being served, she made me close the
laptop...) and wrote distributed above while the topic is decentralized.
Its not entirely wrong, even; Libraries or approaches that do distributed will
be useful for decentralized systems. ;)
--
Thomas Zander

2023-06-07 15:44:01

- reply

📅 Original date posted:2015-07-30
📝 Original message:On Thursday 30. July 2015 11.38.00 Jorge Timón via bitcoin-dev wrote:
> It is important ro note that even if lightning was never developed, the
> block size remains at 1 MB forever and fees rise to 10 usd per transaction,
> such "high fees" are still extremely competitive with non-decentralized
> payment systems that have proportional fees.
What makes you think that when there is such a low availability of transaction
space that paying to be included costs you $10, that Bitcoin is not going to
be outcompeted and replaced or otherwise regarded as worthless?
--
Thomas Zander

2023-06-07 15:43:53

- reply

📅 Original date posted:2015-07-30
📝 Original message:I have just been around for 2 years or so, and its interesting to see you two
argue and give links to the past conversations.
But do realize that if you argue in public about content that is easy to read
by anyone that you have to double check your memory fits the facts.
And I feel you skipped that this time...
On Wednesday 29. July 2015 19.53.02 Gregory Maxwell via bitcoin-dev wrote:
> (The same message also mentions that smart contracts can be used to
> create trustless trade with off-chain systems;
> As well, later in that
> thread: "it will be much easier if you can freely use all the space
> you need without worrying about paying fees for expensive space in
> Bitcoin's chain.")
Hmm... A DNS record is much much bigger than a single bitcoin transaction has
space for.
I don't think you can take his quote out of context. The thread shows that
having a full domain-registry DB on chain is what he was explaining doesn't fit
with Bitcoin.
So Satoshi just explains that a rich database shouldn't live on the
blockchain. Similarly with the quote you made before;
"Piling every proof-of-work quorum system in the world into one
dataset doesn't scale."
It just fights the stupid idea of sharing the blockchain space with tons of
global databases.
Please re-read the whole thread as it really doesn't support your view that
Satoshi argued that somehow decentralization would be protected by limiting
the size of the chain.
--
Thomas Zander

2023-06-07 15:43:52

- reply

📅 Original date posted:2015-07-30
📝 Original message:On Wednesday 29. July 2015 20.00.10 Jorge Timón via bitcoin-dev wrote:
> And, of course, short term convenience for users is much more
> important than figuring out the long term viability of the system once
> the seigniorage (spent on the miner's subsidy) goes away.
There are various decades spanned in that sentence. Your idea of "short term"
is vastly different from mine.
--
Thomas Zander

2023-06-07 15:43:51

- reply

📅 Original date posted:2015-07-29
📝 Original message:On Wednesday 29. July 2015 03.43.50 Eric Lombrozo via bitcoin-dev wrote:
> > > Enter a “temporary” anti-spam measure - a one megabyte block size limit.
> > The one megabyte limit was nothing to do with anti spam. It was a quick
> > kludge to try and avoid the user experience degrading significantly in
> > the event of a "DoS block", back when everyone used Bitcoin-Qt. The fear
> > was that some malicious miner would generate massive blocks and make the
> > wallet too painful to use, before there were any alternatives.
> I thought I clarified this in an earlier post - I meant DoS. Please don’t
> digress on such stupid technicalities.
This particular technicality is rather important since it removes the basis of
your argument.
More specifically, your 4 points of what you claim Satoshi expected to happen,
but didn't were in actual fact not planned, wanted or predicted by Satoshi.
So, you can do name calling if you want, but maybe thats not very productive.
> > The plan was to remove it once SPV wallets were widespread. But Satoshi
> > left before that happened.
> >
>
> Guess what? SPV wallets are still not particularly widespread…
This is an odd statement, we keep on hearing about low bitcoin-core node count
and since that is the only alternative, your statement can only be interpreted
as saying there really are not a whole lot of users out there..
Is that really what you mean?
> and those that
> are out there are notoriously terrible at detecting network forks and
> making sure they are on the right one.
What is the point you are trying to make with that? It seems completely
irrelevant to the point of this thread...
--
Thomas Zander

2023-06-07 15:43:50

- reply

📅 Original date posted:2015-07-31
📝 Original message:On Thursday 30. July 2015 16.33.16 Eric Lombrozo via bitcoin-dev wrote:
> I don’t think it’s really a matter of whether we agree on whether it’s good
> to raise the block size limit, Gavin. I think it’s a matter of a difference
> in priorities.
Having different priorities is fine, using your time to block peoples attempts
to increase block size is not showing different priorities, it shows conflicting
priorities.
Different priorities means you can trust someone else to do things they care
about while you do things you care about.
--
Thomas Zander

2023-06-07 15:43:48

- reply

📅 Original date posted:2015-07-30
📝 Original message:On Thursday 30. July 2015 14.50.46 Pieter Wuille via bitcoin-dev wrote:
> > I believe the costs and risks of 8MB blocks are minimal, and that the
> > benefits of supporting more transaction FAR outweigh those costs and
> > risks,
> > but it is hard to have a rational conversation about that when even simple
> > questions like 'what is s reasonable cost to run a full node' are met with
> > silence.
>
> I think the benefit of an 8 MB over a 1 MB in terms of utility is marginal
Like 640kb should be enough for everyone... Unfortunately the world doesn't
like things that can be bigger not getting bigger. ;)
> Bitcoin's advantage over other systems does not lie in scalability.
> Well-designed centralized systems can trivially compete with Bitcoin's
> on-chain transactions in terms of cost, speed, reliability, convenience,
> and scale. Its power lies in transparency, lack of need for trust in
> network peers, miners, and those who influence or control the system.
The real advantage of Bitcoin is simpler; its the first system that is not
owned and possible to subvert that actually works.
All existing attempts before Bitcoin are companies that try to benefit from
being in the middle, to the exclusion of everyone else and to the exclusion of
innovation.
> Wanting to increase the scale of the system is in conflict with all of
> those.
Thats circular arguing. This didn't actually add anything to the
conversation.
The insight you skip over is that that Bitcoin's advantage, and the concept of
distributed computing in general, has is one of ownership and control.
If you want to keep Bitcoin small at 1Mb, do you still reach your goal of
being free from ownership and control? With our excellent growth trends;
transactions have to go somewhere, they will not use Bitcoin if we don't have
space. And that means we loose decentralization, we lose avoidance of
ownership of the network and we introduce control.
All your rhetoric is missing this basic point; is holding Bitcoin at 1Mb
advancing it, or hurting that basic goal of avoiding ownership?
--
Thomas Zander

2023-06-07 15:43:45

- reply

📅 Original date posted:2015-07-29
📝 Original message:On Wednesday 29. July 2015 05.03.45 Eric Lombrozo via bitcoin-dev wrote:
> Point is…processing blocks requires computational resources that someone
> needs to put up. Unless the people who are putting up these resources are
> properly incentivized to continue doing it, the network will fail.
This assumption is proven wrong by history.
Take a look at the RC5 challance, and its related cousins like the folding-at-
home or seti-at-home.
Next to that, there is incentive for running a node. It is that you don't have
to trust someone else. This incentive has in business always been a very
strong motivator. See how many companies run Outlook on their own intranet
instead of using Outlook.com or similarly in the cloud.
In my own opinion, its waaay to early to call failure on running nodes. Maybe
you want to actually help merchants/chains/individuals run them by making
bitcoin-core more useful for them.
What is the reason people don't run it? Well, reddit says its because of the
upstream bandwidth not being able to be throttled. What about you try working
on that instead of giving up on it?
--
Thomas Zander

2023-06-07 15:43:43

- reply

📅 Original date posted:2015-07-29
📝 Original message:On Tuesday 28. July 2015 19.40.21 Eric Lombrozo via bitcoin-dev wrote:
> 1) A fee market never really got created, we don’t really know how
> transaction fees would work in practice.
>
> The only way to see how fees would work in practice is to have scarcity.
This skips over the question why you need a fees market. There really is no
reason that for the next 10 to 20 years there is a need for a fees market to
incentive miners to mine. Planning that far ahead is doomed to failure.
--
Thomas Zander

2023-06-07 15:43:34

- reply

📅 Original date posted:2015-07-24
📝 Original message:On Friday 24. July 2015 05.37.30 Slurms MacKenzie via bitcoin-dev wrote:
> It's worth noting that even massive companies with $30M USD of funding don't
> run a single Bitcoin Core node,
I assume you mean that they don't have a Bitcoin Core node that is open to
incoming connections. Since that is the only thing you can actually test, no?
Most companies are still terrified of accepting incoming connections from the
scary Internet. So I'm not entirely surprised by this conclusion. I would be
very surprised if companies don't actually have a node at all.
--
Thomas Zander

2023-06-07 15:42:35

- reply

📅 Original date posted:2015-07-24
📝 Original message:On Friday 17. July 2015 20.29.16 Luke Dashjr via bitcoin-dev wrote:
> We are unlikely to approach 1 MB of actual volume by November, so I would
> prefer to see the activation date on this moved later - maybe November
> 2016, if not 2017. It would also be an improvement to try to follow
> reasonably- expected bandwidth increases, so 15% (1.15 MB) rather than
> doubling. Doubling in only a few months seems to be far from a
> "conservative" increase.
The reference to bandwidth increases makes no sense, the bandwidth in most of
the world is already far exceeding the 8Mb limit. Not everyone lives where you
live :)
In Germany you buy a 150Mbit connection for a flatrate and a cheap monthly
rate, for instance. Not saying that Germany is where all the miners are, but
since 150Mbit allows one to comfortably have 16 megabyte blocks, it is a good
example of how far off Luke's calculations are from real-world.
I don't belief your argument to push forward holds.
--
Thomas Zander

2023-06-07 15:42:18

- reply

📅 Original date posted:2015-07-15
📝 Original message:On Tuesday 14. July 2015 17.24.23 Tom Harding via bitcoin-dev wrote:
> Rule 2: A transaction and its dependents are evicted on its 2-hour
> anniversary, whether space is required or not
Instead of 2 hours, why not a number of blocks?
--
Thomas Zander

2023-06-07 15:42:18

- reply

📅 Original date posted:2015-07-16
📝 Original message:On Wednesday 15. July 2015 16.15.24 Tom Harding via bitcoin-dev wrote:
> On 7/15/2015 12:18 PM, Thomas Zander via bitcoin-dev wrote:
> > On Tuesday 14. July 2015 17.24.23 Tom Harding via bitcoin-dev wrote:
> >> Rule 2: A transaction and its dependents are evicted on its 2-hour
> >> anniversary, whether space is required or not
> >
> > Instead of 2 hours, why not a number of blocks?
>
> So users/wallets can know when they should rebroadcast and consider
> increasing the fee.
>
>
> Using 12 blocks, there is a 5% chance he has to wait 3 hours.*
>
> Using 120 minutes, there is only a .23% chance that fewer than 4 blocks
> have occurred.**
Using the good old saying; results in the past are no indication of the
future.
I see a logic error in your thinking.
Your assumption that time is a better indicator is false. Naturally time
itself is universal, but blocks are known by wallets too. Its just as good.
This assumption of yours leans heavily on block mining times, and that is
not guaranteed in the future. Imagine one day half the miners dropping and
blocks take much longer for a week or so. Your assumptions just broke the
mempool.
--
Thomas Zander

2023-06-07 15:33:05

- reply

📅 Original date posted:2015-05-08
📝 Original message:On Wednesday 6. May 2015 21.49.52 Peter Todd wrote:
> I'm not sure if you've seen this, but a good paper on this topic was
> published recently: "The Economics of Bitcoin Transaction Fees"
The obvious flaw in this paper is that it talks about a block size in todays
(trivial) data-flow economy and compares it with the zero-reward situation
decades from now.
Its comparing two things that will never exist at the same time (unless
Bitcoin fails).
--
Thomas Zander

2023-06-07 15:28:15

- reply

📅 Original date posted:2014-12-29
📝 Original message:On Monday 29. December 2014 11.30.42 Mike Hearn wrote:
> With the current DNS protocol you get an all or nothing choice
Its a seed. Not the protocol itself.
> Firstly, Peter, get help. I'm serious.
I think most would agree with me that, Mike, this answer is not just a little
over the line, its unacceptable behavior in any collaborative group.
Please be respectful and avoid ad-hominem attacks.
--
Thomas Zander

2023-06-07 15:28:15

- reply

📅 Original date posted:2014-12-29
📝 Original message:On Sunday 28. December 2014 18.25.29 Mike Hearn wrote:
> Lately we have been bumping up against the limitations of DNS as a protocol
> for learning about the p2p network.
Can you explain further where limitations and problems were hit?
--
Thomas Zander

2023-06-07 15:27:10

- reply

📅 Original date posted:2014-11-06
📝 Original message:On Thursday 6. November 2014 10.51.38 Francis GASCHET wrote:
> Dear all,
>
> I'm currently discovering the Bitcoin's universe.
> I installed bitcoind on my PC and I'm currently testing different things
> on testnet. I just read an article saying that the risk for Bitcoin in the
> future is the decreasing number of full nodes, with appropriate resources.
> There are only few of them in France !
>
> My company operates a dual homed Internet access and has some capacity to
> host an HA server in a secured environment. So I'm thinking about setting
> up a full node. But I'd like to know what storage, RAM and bandwidth
> resources are needed. I guess that the problem is not the CPU.
There is a stats script running on this node;
http://213.165.91.169/
more peoples opinions;
https://bitcointalk.org/index.php?topic=760094.0
--
Thomas Zander

2023-06-07 15:27:01

- reply

📅 Original date posted:2014-10-28
📝 Original message:On Tuesday 28. October 2014 22.44.50 Ferdinando M. Ametrano wrote:
> It amazes me that basic economic considerations seems completely lost here,
> especially when it comes to mining.
Please don't confuse people dismissing your thoughts with dismissing the basic
economic considerations. The fact of the matter is that you didn't read the
archives where these ideas have been brought forward and discussed, a
consensus was reached. (it wasn't so basic afterall)
The fact that people don't want to repeat the discussion just for your sake is
not the same as people not listening to those arguments.

2023-06-07 15:26:59

- reply

📅 Original date posted:2014-10-28
📝 Original message:On Monday 27. October 2014 19.26.48 Tom Harding wrote:
> Miner has to be very careful including a double-spend in his block -- he
> hopes:
How does it help the zero-confirmation to not include a payment? Doesn't that
just mean that if I send a double spend that neither of the payments will be
made? So the thief just got an even bigger incentive to double-spent!
> - that based on his measured time offset from the first spend he
> received, at most a tiny fraction of the network will delay his block
>
> - that not too many nodes saw an earlier spend that he didn't see,
> which could increase that fraction
>
> - that most other nodes saw his tx. Any who didn't will only learn
> about it by receiving his block, and they will assign it the time when
> they receive the block. That's likely to be more than T (30 seconds)
> after an earlier spend, so they would delay the block.
This doesn't addresses the point that Matt brought up.
Your proposal essentially has some side effects that would be disastrous to
miners. As detailed by the other two replies on this thread.

2023-06-07 15:26:48

- reply

📅 Original date posted:2014-10-25
📝 Original message:On Saturday 25. October 2014 21.06.32 Alex Mizrahi wrote:
> If miner's income margin are less than 50% (which is a healthy situation
> when mining hardware is readily available), we might experience
> catastrophic loss of hashpower (and, more importantly, catastrophic loss of
> security) after reward halving.
For the sake of argument, lets assume that somehow (quite unlikely) half the
mining equipment gets shut off.
The amount of hashes/second is such that it is currently, lets just say, quite
secure against any takeover.
Your document makes a long series of assumptions about how this can turn out
bad with each individually is implausible, together are just fiction.
Your research didn't convince me about this being bad somehow. It also
completely disregards the equilibriums reached by doing so.

2023-06-07 15:26:48

- reply

📅 Original date posted:2014-10-25
📝 Original message:On Saturday 25. October 2014 13.27.30 Adam Back wrote:
> - alternatively you might say why not 1/100th reward reduction per 2
> week period rather than 1/2 every 4 years, a difficulty retarget could
> be a convenient point to do that.
mining equipment has a much shorter lifetime than 4 years, so the halving
makes it easy to base purchases on.
Also, divide by two is the cleanest way to get to zero after a specific amount
of divisions.

2023-06-07 15:26:33

- reply

📅 Original date posted:2014-10-19
📝 Original message:On Sunday 19. October 2014 09.17.51 xor wrote:
> I joined the list when Bitcoin was already in the 10-billions of market
> capitalization, and it actually really surprised me how low the traffic is
> here given the importance of Bitcoin.
I gather that actual code changes to bitcoin-core and naturally all the other
clients are already done in another place. Which is likely the reason for your
impression.
> So as a random stranger to the project, I would vote against that if I was
> allowed to. There really should be *more* discussion here, and splitting
> the list up won't help with that.
I agree with your stance that more discussion in public is always good.
Lets allow people that work on bitcoin java, or completely other bitcoin based
stuff to have a simple way to filter out the topics they are interested in.
Mailinglist handling is pretty trivial in practically all email software,
people can equally trivially subscribe to multiple lists as their interests
go.
As a long time open source developer, my experience is that more lists has
never really caused fragmentation in the way that you fear.

2023-06-07 15:26:31

- reply

📅 Original date posted:2014-10-16
📝 Original message:On Wednesday 15. October 2014 20.13.11 Mike Hearn wrote:
> Plus its moderation features suck, its mail archiving features suck, etc.
> It essentially has no redeeming features at all.
Other than it being open source, an open platform with no lock-in 'features'
and it works with everyone that uses the standards properly.
Naturally, if an old version fails to function with Yahoo, I'm all for finding
a different provider. Thats what open platforms, like Mailman, are about.
--
Thomas Zander

2023-06-07 15:26:30

- reply

📅 Original date posted:2014-10-16
📝 Original message:On Wednesday 15. October 2014 11.36.58 Wladimir wrote:
> > We're also having problems with people failing to comment on things,
> > not even "I looked at this and have no opinion", which is really
> > obstructing things.
>
> Well - the only way to avoid that is to set a reasonable deadline,
> after which there is a default decision. You'd hope this would
> motivate people to get involved in time.
I have been part of both the OSI (NEN) and the OASIS standards committees for
a while, working on standards as a technical adviser.
There I learned a lot about how to manage this process, maybe some ideas from
such committees can be useful.
The idea that one person owns a BIP makes total sense, (s)he is the only one
that should be putting forward the BIP when its mature enough for making it
final. Note that this can be already after its been implemented once or twice.
So you have a phase where you have random people propose changes, which should
all go in the public mailinglist, and they can be accepted by the owner
without discussion.
If anyone that sees that change has an objection to the change, (s)he speaks
up and you follow group consensus. This means (and this is actually in an ISO
standard ;) that consensus is reached when nobody is left objecting to the
change.
At some point the BIP is mature enough to vote on, at the discretion of the
owner, and the owner puts it forward and requests a vote. If the above process
was handled cleanly there is a very small chance of it being down-voted so an
actual vote may not be needed (its hard to decide who gets a vote..).
You obviously need a deadline for this and afterwards you mark the proposal
final. Or you close it as "needs more work".
--
Thomas Zander

2023-06-07 15:26:27

- reply

📅 Original date posted:2014-10-14
📝 Original message:On Tuesday 14. October 2014 04.34.16 Pieter Wuille wrote:
> This means that scripts that use booleans as inputs will be inherently
> malleable.
I've ran into this issue in C++ often enough,
a funny example is assigning "2" to a native c++ bool and then you can do a
if (myBool == true)
else if (myBool == false)
and neither of them will hit.
> I
> would like to change BIP62 to also state that interpreted booleans
> must be of minimal encoded size (in addition to numbers).
What about rejecting a script where a bool is not explicitly zero or one?
--
Thomas Zander

2023-06-07 15:26:21

- reply

📅 Original date posted:2014-10-10
📝 Original message:On Friday 10. October 2014 19.26.49 Mike Hearn wrote:
> I'm sure this suggestion will go down like a lead balloon, but Bitcoin Core
> is not the first project that's had issues with Linux distros silently
> modifying their software as they package it.
And so far its been near impossible for those others to make distros not
modify it.
Firefox is actually a good idea, it made debian stop distributing it.
Best solution is to build good relations with the packagers of distros.
ps. Linux distros distributing GPL licensed apps are required by law to offer
the sources of the thing they build and distribute as binary. Which allows you
to check the difference with upstream. Most distros therefore have a process in
place for this. Even for not FLOSS software like bitcoin core.

2023-06-07 15:25:48

- reply

📅 Original date posted:2014-09-15
📝 Original message:The reason it is in fact geek wanking is because pgp tried to solve a problem
that can't be solved.
It tried to provide distributed trust to a system of identity, while still
depending on the local governments (i.e. centralization) for the upstream ID.
Its a marriage that has no benefits.
What we really want is a (decentralized) identity management that allows me to
create a new anonymous ID and use that as something more secure when needed
that I have to proof its me.
So for instance I start including a bitcoin public key in my email signature.
I don't sign the emails or anything like that, just to establish that everyone
has my public key many times in their email archives.
Then when I need to proof its me, I can provide a signature on the content
that the requester wants me to sign.
All the overhead of PGP and the WoT is really completely unneeded and just
means that less people use it.
Consider this; people create accounts on GitHub or Reddit and those have in
fact more value than your pgp key! Because they got the anonymous part right.
On Monday 15. September 2014 09.32.03 Brian Hoffman wrote:
> I would agree that the in person aspect of the WoT is frustrating, but to
> dismiss this as "geek wanking" is the pot calling the kettle.
>
> The value of in person vetting of identity is undeniable. Just because your
> risk acceptance is difference doesn't make it wanking. Please go see if you
> can get any kind of governmental clearance of credential without in-person
> vetting. Ask them if they accept your behavioral signature.
>
> I know there is a lot of PGP hating these days but this comment doesn't
> necessarily apply to every situation.
> > On Sep 15, 2014, at 9:08 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> >> On Mon, Sep 15, 2014 at 3:23 AM, Thomas Zander <thomas at thomaszander.se>
> >> wrote: Any and all PGP related howtos will tell you that you should not
> >> trust or sign a formerly-untrusted PGP (or GPG for that matter) key
> >> without seeing that person in real life, verifying their identity etc.
> >
> > Such guidelines are a perfect example of why PGP WoT is useless and
> > stupid geek wanking.
> >
> > A person's behavioural signature is what is relevant. We know how
> > Satoshi coded and wrote. It was the online Satoshi with which we
> > interacted. The online Satoshi's PGP signature would be fine...
> > assuming he established a pattern of use.
> >
> > As another example, I know the code contributions and PGP key signed
> > by the online entity known as "sipa." At a bitcoin conf I met a
> > person with photo id labelled "Pieter Wuille" who claimed to be sipa,
> > but that could have been an actor. Absent a laborious and boring
> > signed challenge process, for all we know, "sipa" is a supercomputing
> > cluster of 500 gnomes.
> >
> > The point is, the "online entity known as Satoshi" is the relevant
> > fingerprint. That is easily established without any in-person
> > meetings.

2023-06-07 15:25:48

- reply

📅 Original date posted:2014-09-15
📝 Original message:On Monday 15. September 2014 11.51.35 Matt Whitlock wrote:
> If you were merely attaching your public key to them, then the email server
> could have been systematically replacing your public key with some other
> public key,
The beauty of publicly archived mailinglists make it impossible to get away
with this without detection.
I recall reading the awesome book "The inmates are running the asylum" which
states that solutions created by software engineers typically suffer from the
flaw of absolutes. (find the part where he describes homo-digitalus for more)
I think this applies to PGP and your objection; in order to make it absolutely
correct, you need to introduce loads of things. Signatures, WoT, etc.
PGP&GPG do this. But each change of the normal workflow means you loose about
50% of your audience...
So, my silly example is not perfect. But I bet its good enough for most. In
the end the value of the imperfect solution is higher than the perfect one.

2023-06-07 15:25:45

- reply

📅 Original date posted:2014-09-15
📝 Original message:On Sunday 14. September 2014 08.28.27 Peter Todd wrote:
> Do we have any evidence Satoshi ever even had access to that key? Did he
> ever use PGP at all for anything?
Any and all PGP related howtos will tell you that you should not trust or sign
a formerly-untrusted PGP (or GPG for that matter) key without seeing that
person in real life, verifying their identity etc.
I think that kind of disqualifies pgp for identity purposes wrt Satoshi :-)
--
Thomas Zander