<unnamed>

Public Key

npub1du3xh5wgds32a5fweqkd9k45kh30wl7kv2kyu8ugz9c2ztdg00tqqvyg93

Profile Code

nprofile1qqsx7gnt68yxcg4w6yhvstxjm26ttchh0ltx9tzwr7ypzu9p9k58h4spz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsv6xdrt

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-07 19:34:34 CEST

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 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:46:20 CEST

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

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

- reply

2023-06-07 17:46:02 CEST

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

- reply

2023-06-07 17:46:00 CEST

- reply

2023-06-07 17:46:00 CEST

- reply

2023-06-07 17:45:59 CEST

- reply

2023-06-07 17:45:59 CEST

- 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:45:49 CEST

- reply

2023-06-07 17:45:47 CEST

- reply

2023-06-07 17:45:47 CEST

- reply

2023-06-07 17:45:45 CEST

- reply

2023-06-07 17:45:34 CEST

- reply

2023-06-07 17:45:33 CEST

- reply

2023-06-07 17:45:32 CEST

- reply

2023-06-07 17:45:20 CEST

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 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