Oliver Egginger [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-04-07 to 2015-08-21
💬 Posted a total of 21 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

npub182pe36hcvp2va069x068fcqt7w38fhdhrfkmhxdnlqausddvmucq3nlkws

Profile Code

nprofile1qqsr4qucatuxq4xwhazn8ar5uq9l8gn5mkm35mdmnxelsw7gxkkd7vqn720u6

Author Public Key

npub182pe36hcvp2va069x068fcqt7w38fhdhrfkmhxdnlqausddvmucq3nlkws

Show more details

Last Notes

2023-06-07 17:37:24

- reply

📅 Original date posted:2015-08-20
📝 Original message:Hello,
BitPay seems to support BIP 101:
https://medium.com/@spair/increasing-the-block-size-limit-85ff236fc516
We do not know where this is going. But I suspect that ultimately also
the core client will increase the block size.
Bitcoin is also the subject of research. I think that research is much
to slow (and uncertain) for many companies and users. This is the
reason for XT. Nevertheless, I think further research on the base of the
current protocol version is very important. Thus, I hope that the
current block chain survives. Albeit at a lower level with fewer
users. And expressly not to sabotage necessary changes in the main project.
Let's suppose XT prevails or core is changed within the terms of BIP 101:
Do you think that there are enough people to continue with the old
protocol version? Would developers fork a Bitcoin client for supporting
the old nodes with security updates? Or will there be a compatibility
mode in XT, so that XT behave like an old Bitcoin node? What about
smaller but important projects like picocoin?
- oliver

2023-06-07 17:36:53

- reply

📅 Original date posted:2015-08-21
📝 Original message:Am 21.08.2015 um 15:34 schrieb Will Madden:
> Keeping the block size at 1mb restricts the number of active users of bitcoin to around 100,000 people transacting twice a day on blockchain.
> BItcoin is a protocol. Protocols are successful because of their network effect. Capping the block size freezes bitcoin’s network effect, limits users and prevents new users from joining (which will cut demand to exchange bitcoin) and also freeze the economic incentive to mine, because it will hurt the price.
As a protocol Bitcoin could support millions of full nodes. What you
talking about is the number of shareholders. But these are poorly
determined by the block size. The number of shareholders is determined
by many parameter but manly by the decreasing-supply algorithm. Which
"was chosen because it approximates the rate at which commodities like
gold are mined". See: https://en.bitcoin.it/wiki/Controlled_supply
While the decreasing-supply algorithm of Bitcoin has many advantage it's
very hard to believe that the block chain will ever reach mass adoption.
Even after 6 years, hardly anyone owns Bitcoins. Like Gold Bitcoin is
distributed in large blocks to a few. Exceptions prove the rule. In the
last 6 years the 1MB limit has been sufficient. I don't think that we
will hit the 8MB limit in the next 6 years, except for stress tests and
spam.
> Freezing bitcoin’s growth for any meaningful length of time will
> threaten its position as the leading cryptocurrency.
I don't think that a relative tight block size could harm Bitcoin
middle-term. Only experienced users penetrate the block chain directly.
They know what they are doing and deal with problems. When space for
transactions starts to become scarce and the fees rise too much, the
developers have enough time to make a change. It would then also not so
controversial. A matter of a few days or weeks. Especially if all
necessary preparations have already been taken.
But I know that my opinion is very different from other claims. However,
reliable people share some more fatalism as I'm currently find in some
parts of the the Bitcoin community. Fear is a very bad adviser and can
make a genius stupid.
- oliver

2023-06-07 17:36:52

- reply

📅 Original date posted:2015-08-21
📝 Original message:Yifu Guo via bitcoin-dev:
> One thing is for sure though, not increasing the blocksize is not an option.
Why not? The blocksize increase eliminates the pressure to seek durable
solutions. But it will turn out differently. Other than we all think.
I really can not imagine that a 20-year plan will be successful. At one
point we like to clear away the auto-increase. I think that is the only
thing for sure at the moment.
I hope that the current protocol and blockchain will be continued.
Perhaps with fewer people. That would settles the matter for the time
being. ;)
- oliver

2023-06-07 17:35:42

- reply

📅 Original date posted:2015-08-18
📝 Original message:Am 18.08.2015 um 11:15 schrieb Warren Togami Jr.:
> I honestly don't understand your position, but I get the sense that you
> are suggesting Satoshi wouldn't be welcome to return if he wanted to be
> active in development again?
Who am I? Personally I have zero objection if the creator steps in. I
think he would be highly welcome by the most people. At first I had the
impression that the email was a fake, but maybe I was wrong. At the
moment I think: Maybe it's even the best if we do not know exactly
whether it was Satoshi or not.
Unanimity is mission critical for Bitcoin and must be an absolute
priority. If not the vast majority is in favor for a fork, then the fork
should be avoided until a consensus is found. Even if it takes until the
cows come home.
But it is very likely now that it will come to a fork. No matter which
site will win, this will produce a lot of humiliated people at the end.
That's not good and leads to bitterness on both sites.
- oliver

2023-06-07 17:35:41

- reply

📅 Original date posted:2015-08-17
📝 Original message:Am 17.08.2015 um 21:03 schrieb Warren Togami Jr.:
> This bitcoin-dev list restarted with an empty subscriber list on June
> 21st, 2015. So whoever posted from satoshi at vistomail.com
> <mailto:satoshi at vistomail.com> subscribed and verified the address
> recently. Do you propose that we manually approve new subscribers to
> prevent these kind of "abuses" as you put it?
I would simply block the creators old email addresses. Easy with
Mailman. I thought that would be a good and easy approach, but maybe I'm
wrong.
Some believes it is possible that the email could be genuine. Some say
that only the content is important. I have closely followed. An
interesting discussion. Thank you all so far.
But let's say the poster would be the real Satoshi. Would we discuss his
posting if he would not claim to be Satoshi? There are a lot of smart
people on this list, which publish occasionally quite useful ideas. But
much of this is hardly the subject of greater discussion. Especially not
when it comes to the blocksize. On this subject almost everything has
been already said. But not yet by everyone. Especially not by Satoshi.
Satoshi would have a decisive influence on the community. I'm sure. To
say it does not matter who's talking is maybe genteelly but a little bit
remote from everyday life. Or not? Satoshi is the creator. What he says
is in the newspaper and is perceived by all. If he says it's okay to do
nothing as long as we stand together, then people have the courage to do
maybe something dangerous or something wrong. Then people only follow
their hearts. Otherwise they follow their fear. It is a paradox of the
human nature that some type of Dictatorship can make you free. I say
some type, not any type. Enough said.
- oliver

2023-06-07 17:35:39

- reply

📅 Original date posted:2015-08-17
📝 Original message:Am 17.08.2015 um 18:32 schrieb Jorge Timón:
> On Mon, Aug 17, 2015 at 1:51 PM, Oliver Egginger <bitcoin at olivere.de> wrote:
>> Am 17.08.2015 um 13:44 schrieb Jorge Timón:
>>>
>>> On Aug 17, 2015 1:40 PM, "Oliver Egginger via bitcoin-dev"
>>> <bitcoin-dev at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>>> That made it to the news and is now discussed in various places. Could
>>>> you please delete Satoshis old email addresses from the list and block
>>>> them? Sorry to post this to all members but I can't find an owner for
>>>> this list.
>>>
>>> Why should we block any email address?
>>
>> To avoid such discussions.
>
> You mean to avoid discussions about his authenticity?
> Should that matter at all?
> Does the content of the post matter less than its author?
It just creates confusion. Particularly in the media. I also find it
unfair if people abuses Satoshi's name to submit their personal views on
an issue.
- oliver

2023-06-07 17:35:38

- reply

📅 Original date posted:2015-08-17
📝 Original message:Am 17.08.2015 um 13:44 schrieb Jorge Timón:
>
> On Aug 17, 2015 1:40 PM, "Oliver Egginger via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>> That made it to the news and is now discussed in various places. Could
>> you please delete Satoshis old email addresses from the list and block
>> them? Sorry to post this to all members but I can't find an owner for
>> this list.
>
> Why should we block any email address?
To avoid such discussions.
- oliver

2023-06-07 17:35:38

- reply

📅 Original date posted:2015-08-17
📝 Original message:Am 15.08.2015 um 19:43 schrieb Satoshi Nakamoto via bitcoin-dev:
> I have been following the recent block size debates through the mailing list. I had hoped the debate would resolve and that a fork proposal would achieve widespread consensus. However with the formal release of Bitcoin XT 0.11A, this looks unlikely to happen, and so I am forced to share my concerns about this very dangerous fork.
>
> The developers of this pretender-Bitcoin claim to be following my original vision, but nothing could be further from the truth. When I designed Bitcoin, I designed it in such a way as to make future modifications to the consensus rules difficult without near unanimous agreement. Bitcoin was designed to be protected from the influence of charismatic leaders, even if their name is Gavin Andresen, Barack Obama, or Satoshi Nakamoto. Nearly everyone has to agree on a change, and they have to do it without being forced or pressured into it. By doing a fork in this way, these developers are violating the "original vision" they claim to honour.
>
> They use my old writings to make claims about what Bitcoin was supposed to be. However I acknowledge that a lot has changed since that time, and new knowledge has been gained that contradicts some of my early opinions. For example I didn't anticipate pooled mining and its effects on the security of the network. Making Bitcoin a competitive monetary system while also preserving its security properties is not a trivial problem, and we should take more time to come up with a robust solution. I suspect we need a better incentive for users to run nodes instead of relying solely on altruism.
>
> If two developers can fork Bitcoin and succeed in redefining what "Bitcoin" is, in the face of widespread technical criticism and through the use of populist tactics, then I will have no choice but to declare Bitcoin a failed project. Bitcoin was meant to be both technically and socially robust. This present situation has been very disappointing to watch unfold.
>
> Satoshi Nakamoto
That made it to the news and is now discussed in various places. Could
you please delete Satoshis old email addresses from the list and block
them? Sorry to post this to all members but I can't find an owner for
this list.
- oliver

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-06-01
📝 Original message:On Mon, Jun 1, 2015 at 3:59 PM, Gavin Andresen wrote:
> What do other people think? Would starting at a max of 8 or 4 get
> consensus? Scaling up a little less than Nielsen's Law of Internet
> Bandwidth predicts for the next 20 years? (I think predictability is
> REALLY important).
>
> I chose 20 because all of my testing shows it to be safe, and all of my
> back-of-the-envelope calculations indicate the costs are reasonable.
>
> If consensus is "8 because more than order-of-magnitude increases are
> scary" -- ok.
It would feel better for me if you would keep the power of two:
2^0 = 1MB
2^1 = 2MB
2^2 = 4MB
2^3 = 8MB
.
.
.
But that's only personal. Maybe other people feeling the same.
- oliver

2023-06-07 15:33:20

- reply

📅 Original date posted:2015-05-13
📝 Original message:08.05.2015 at 5:49 Jeff Garzik wrote:
> To repeat, the very first point in my email reply was: "Agree that 7 tps
> is too low"
For interbank trading that would maybe enough but I don't know.
I'm not a developer but as a (former) user and computer scientist I'm
also asking myself what is the core of the problem? Personally, for
privacy reasons I do not want to leave a footprint in the blockchain for
each pizza. And why should this expense be good for trivial things of
everyday life?
If one encounters the block boundary, he or she will do more effort or
give up. I'm thinking most people will give up because their
transactions are not really economical. It is much better for them to
use third-partys (or another payment system).
And that's where we are at the heart of the problem. The Bitcoin
third-party economy. With few exceptions this is pure horror. More worse
than any used car dealer. And the community just waits that things get
better. But that will never happen of its own accord. We are living in a
Wild West Town. So we need a Sheriff and many other things.
We need a small but good functioning economy around the blockchain. To
create one, we have to accept a few unpleasant truths. I do not know if
the community is ready for it.
Nevertheless, I know that some companies do a good job. But they have to
prevail against their dishonest competitors.
People take advantage of the blockchain, because they no longer trust
anyone. But this will not scale in the long run.
- oliver

2023-06-07 15:27:36

- reply

📅 Original date posted:2014-11-28
📝 Original message:On Thu, Nov 27, 2014 at 6:54 PM, Wladimir <laanwj at gmail.com> wrote:
> On Thu, Nov 27, 2014 at 5:27 PM, Mem Wallet <memwallet.info at gmail.com> wrote:
>
>> Is there an intention that the various internal libraries could/should
>> be strengthened and heirachicalized such that they would be suitable for
>> 3rd party development of bitcoin related services and tools, or is that not
>> a goal, and some other project would have to fill such a role ?
>
> The plan is to provide the consensus functionality as a library, the
> essential parts that make bitcoin bitcoin.
> 0.10 will have a basic transaction/script verifier available.
> In the version after that, I expect this will be extended to further
> utxo set management, but no API has been worked out for that yet.
> There are also plans to add a library for transaction signing.
>
> However there is no goal to expose *everything* as a library.
> Certainly not wallet- or user interface related functionality.
> Specialized utility libraries would fill this purpose better.
> See for example https://github.com/bitcoin/libbase58 for base58 processing.
Sorry for the off-topic but while reading this I like to ask you for
picocoin, see:
https://github.com/jgarzik/picocoin
For a research project I'm looking for a C library to operate some block
chain analysis (parsing raw blocks and transactions). Has anyone of you
experience with picocoin for that? Are there any relevant limitations?
- oliver

2023-06-07 15:26:31

- reply

📅 Original date posted:2014-10-16
📝 Original message:15.10.2014 at 20:13 Mike Hearn wrote:
> For a project that is based on digital signatures, it's really
> bad that the mailing list is incompatible with Yahoo's "mail signatures
> must be valid" policy.
# Mailman: Do not break existing DKIM signatures
DEFAULT_SUBJECT_PREFIX = ""
DEFAULT_MSG_HEADER = ""
DEFAULT_MSG_FOOTER = ""
Maybe you should remove these settings. They make little sense and cause
apparently problems for some recipients.
Also the mail body must not be altered through advertising or something
else.
- oliver

2023-06-07 15:25:37

- reply

📅 Original date posted:2014-08-29
📝 Original message:Am 28.08.2014 um 22:21 schrieb Matt Corallo:
> I'm sure many of you have already seen this, but Hal Finney passed away
> on Tuesday.
No, I have not noticed yet. I did not know him personally, but it still
makes me sad now. Last year he wrote on Bitcoin Talk in a
thought-provoking way about his disease:
https://bitcointalk.org/index.php?topic=155054.0
I think a very inspiring Character for all of us. Not only because of
his work.
- oliver

2023-06-07 15:19:02

- reply

📅 Original date posted:2014-04-20
📝 Original message:Hello,
just my two 'cents':
Terms arises by itself. Just as most people speak of coins when they
mean bitcoins. I do not see that bitcoin is currently in common use
except for speculation. Therefore no term for smaller units has
established yet. No problem in my eyes. Time will tell.
- oliver

2023-06-07 15:18:52

- reply

📅 Original date posted:2014-04-19
📝 Original message:Hello,
bitcoin-qt produces on many systems an unnecessary alert:
"URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed"
Especially the stable channel is affected:
https://launchpad.net/~bitcoin/+archive/bitcoin
This is a bit frightening for normal users. I think the best would be to
turn off this message (if possible). It produces too many false
positives and motivates people to maybe harmful workarounds.
- oliver

2023-06-07 15:18:35

- reply

📅 Original date posted:2014-04-12
📝 Original message:Am 12.04.2014 17:34, schrieb Matt Corallo:
> Hmm? It's up to date... 0.9.1 doesn't change anything for
> dynamically-linked-to-openssl builds.
>
Okay, my mistake. Sorry to trouble you, but good to know that you are here.
regards
Oliver

2023-06-07 15:18:34

- reply

📅 Original date posted:2014-04-12
📝 Original message:Hello,
so far, nothing yet?
See: https://launchpad.net/~bitcoin/
I'm developing currently a LiveCD for hot/cold wallet management on
Ubuntu LTS basis. For critical vulnerabilities I have to provide timely
updates. I have now decided to maintain my own repository for this
project. If there are better alternatives, let me know.
regards
Oliver

2023-06-07 15:16:02

- reply

📅 Original date posted:2014-03-22
📝 Original message:Am 22.03.2014 18:03, schrieb Mike Hearn:
> In case you didn't see this yet,
>
> http://gavintech.blogspot.ch/2014/03/it-aint-me-ive-got-pgp-imposter.html
>
> If you're using PGP to verify Bitcoin downloads, it's very important
> that you check you are using the right key. Someone seems to be creating
> fake PGP keys that are used to sign popular pieces of crypto software,
> probably to make a MITM attack (e.g. from an intelligence agency) seem
> more legitimate.
>From the user's perspective: In the beginning I found it difficult to
find the keys. At last I have made this side for documentation:
https://www.olivere.de/blog/archives/2013/06/02/install_bitcoin_client/
Okay, is outdated meanwhile ...
Normally people fetch the keys by key-id from a well known key server.
Not because they are paranoid, but because it is the most convenient
method under Linux.
A Google search for Gavin+Andresen+gpg brings me herein:
http://sourceforge.net/p/bitcoin/mailman/message/30551147/
Key-Id?
Nevertheless, I'm glad that you guys signed anything. That makes me
sleep better. I really check this.
- oliver
GPG: https://olivere.de/gpg

2023-06-07 15:13:40

- reply

📅 Original date posted:2014-02-10
📝 Original message:Am 10.02.2014 13:28, schrieb Pieter Wuille:
> Hi all,
>
> I was a bit surprised to see MtGox's announcement. The malleability of
> transactions was known for years already (see for example the wiki
> article on it, https://en.bitcoin.it/wiki/Transaction_Malleability it,
> or mails on this list from 2012 and 2013). I don't consider it a very
> big problem, but it does make it harder for infrastructure to interact
> with Bitcoin. If we'd design Bitcoin today, I'm sure we would try to
> avoid it altogether to make life easier for everyone.
Sorry, I'm not a developer, but I have got a question. It's a little bit
off-topic and can't maybe answered easy.
As I understand this attack someone renames the transaction ID before
being confirmed in the blockchain. Not easy but if he is fast enough it
should be possible. With a bit of luck for the attacker the new
transaction is added to the block chain and the original transaction is
discarded as double-spend. Right?
Up to this point the attacker has nothing gained. But next the attacker
stressed the Gox support and refers to the original transaction ID. Gox
was then probably fooled in such cases and has refunded already paid
Bitcoins to the attackers (virtual) Gox-wallet.
So far everything is clear. But what I do not understand: Why apparently
had so many customers of Gox payment defaults or severely delayed
payments? I would imagine that the attacker may have doubled not only
his own transaction (maybe for obfuscating the fraud). But then all
transfers would still have go through anyway. And a normal customers
would have been satisfied. Most people observe only their wallets, I
think. What am I missing here?
Sorry, is perhaps a silly question. But maybe you can put me on the
right track.
regards
Oliver

2023-06-07 11:44:18

- reply

📅 Original date posted:2013-04-07
📝 Original message:Am 07.04.2013 17:22, schrieb Scott Howard:
> Many new users have started using the reference client which downloads
> the whole blockchain from peers.
Yes I have made a clean start because of the the new database structure.
> There currently isn't a throttling
> mechanism [1] so it's possible to quickly eat up your bandwidth. You
> can try QoS on your router or use the -nolisten command line flag. You
> will still relay transactions, just not serve the whole blockchain.
I see. I successfully have downloaded the Blockchain again. Thus, it
should not occur again now. If it does, I'll be back again. :-)
Thank you for your quick help.
regards
Oliver

2023-06-07 11:44:12

- reply

📅 Original date posted:2013-04-07
📝 Original message:Hello,
I'm using your bitcoin-qt client (version 0.8.1). Normally everything is
working pretty fine, but sometimes it seems that other nodes produce an
enormous amount of traffic. I have not had the time to investigate
thoroughly yet. I only have briefly viewed with tshark.
So far I have just restarted the client in the hope that it no longer
connects with the 'evil' node. This usually works quite well.
Is anything about DOS-Attacks known to you?
regards
Oliver