Levin Keller [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 17:36:18

- reply

📅 Original date posted:2015-08-17
📝 Original message:Interesting. I am writing down something similar. Will share soon.
Upal Chakraborty via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
schrieb am Mo., 17. Aug. 2015 um 11:45 Uhr:
> I have tried to solve the maximum block size debate, depending on the
> previous block size calculation.
>
> Requesting for comment - http://upalc.com/maxblocksize.php
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/8718b74f/attachment.html>

2023-06-07 17:36:09

- reply

📅 Original date posted:2015-08-17
📝 Original message:Dear Eric,
thank you for sharing your thoughts.
It obviously boils down to political beliefs, not so much technical
arguments. I understand that you are in favor of a "guided
decentralization" and you are most happily invited to follow this path. I
don't want to be on it. I want total decentralisation of bitcoin and many
other parts of the current system.
So in the end the hard fork might be perfect, because people like you will
not waste so much more energy and time fighting people like me (and others)
who are following different dogmata because we are using different coins
and talking about different code. Interestingly enough in the end we will
probably have a winner - determined by the price - so I am looking forward
to the outcome. It is just the time so make some bets, which I embrace.
Another interesting thing is, that you actually fear problems arising from
this. What do you have to loose? Just stick with the old bitcoin version
and weather this storm. Bitcoin is not going to vanish or break from this.
It is just forking. One fork will come stronger out of this. You just have
to choose a side and live with it, if you loose it all. But that is the
story of bitcoin since the beginning. If you ask me, you fear the choice,
not the change.
Cheers
Levin
Adam Back via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> schrieb
am Mo., 17. Aug. 2015 um 16:37 Uhr:
> Thank you Eric for saying what needs to be said.
>
> Starting a fork war is just not constructive and there are multiple
> proposals being evaluated here.
>
> I think that one thing that is not being so much focussed on is
> Bitcoin-XT is both a hard-fork and a soft-fork. It's a hard-fork on
> Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin core
> SPV nodes that did not opt-in. It exposes those SPV nodes to loss in
> the likely event that Bitcoin-XT results in a network-split.
>
> The recent proposal here to run noXT (patch to falsely claim to mine
> on XT while actually rejecting it's blocks) could add enough
> uncertainty about the activation that Bitcoin-XT would probably have
> to be aborted.
>
> Adam
>
> On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > NxtChg,
> >
> > In the entire history of Bitcoin we’ve never attempted anything even
> closely resembling a hard fork like what’s being proposed here.
> >
> > Many of us have wanted to push our own hard-forking changes to the
> protocol…and have been frustrated because of the inability to do so.
> >
> > This inability is not due to any malice on anyone’s part…it is a feature
> of Satoshi’s protocol. For better or worse, it is *very hard* to change the
> rules…and this is exactly what imbues Bitcoin with one of its most powerful
> attributes: very well-defined settlement guarantees that cannot be suddenly
> altered nor reversed by anyone.
> >
> > We’ve managed to have a few soft forks in the past…and for the most part
> these changes have been pretty uncontroversial…or at least, they have not
> had nearly the level of political divisiveness that this block size issue
> is having. And even then, we’ve encountered a number of problems with these
> deployments that have at times required goodwill cooperation between
> developers and mining pool operators to fix.
> >
> > Again, we have NEVER attempted anything even remotely like what’s being
> proposed - we’ve never done any sort of hard fork before like this. If even
> fairly uncontroversial soft forks have caused problems, can you imagine the
> kinds of potential problems that a hard fork over some highly polarizing
> issue might raise? Do you really think people are going to want to
> cooperate?!?
> >
> > I can understand that some people would like bigger blocks. Other people
> might want feature X, others feature Y…and we can argue the merits of this
> or that to death…but the fact remains that we have NEVER attempted any hard
> forking change…not even with a simple, totally uncontroversial no-brainer
> improvement that would not risk any sort of ill-will that could hamper
> remedies were it not to go as smoothly as we like. *THIS* is the
> fundamental problem - the whole bigger block thing is a minor issue by
> comparison…it could be any controversial change, really.
> >
> > Would you want to send your test pilots on their first flight…the first
> time an aircraft is ever flown…directly into combat without having tested
> the plane? This is what attempting a hard fork mechanism that’s NEVER been
> done before in such a politically divisive environment basically amounts
> to…but it’s even worse. We’re basically risking the entire air force (not
> just one plane) over an argument regarding how many seats a plane should
> have that we’ve never flown before.
> >
> > We’re talking billlions of dollars’ worth of other people’s money that
> is on the line here. Don’t we owe it to them to at least test out the
> system on a far less controversial, far less divisive change first to make
> sure we can even deploy it without things breaking? I don’t even care about
> the merits regarding bigger blocks vs. smaller blocks at this point, to be
> quite honest - that’s such a petty thing compared to what I’m talking about
> here. If we attempt a novel hard-forking mechanism that’s NEVER been
> attempted before (and which as many have pointed out is potentially fraught
> with serious problems) on such a politically divisive, polarizing issue,
> the result is each side will refuse to cooperate with the other out of
> spite…and can easily lead to a war, tanking the value of everyone’s assets
> on both chains. All so we can process 8 times the number of transactions we
> currently do? Even if it were 100 times, we wouldn’t even come close to
> touching big payment processors like Visa. It’s hard to imagine a protocol
> improvement that’s worth the risk.
> >
> > I urge you to at least try to see the bigger picture here…and to
> understand that nobody is trying to stop anyone from doing anything out of
> some desire for maintaining control - NONE of us are able to deploy hard
> forks right now without facing these problems. And different people
> obviously have different priorities and preferences as to which of these
> changes would be best to do first. This whole XT thing is essentially
> giving *one* proposal special treatment above those that others have
> proposed. Many of us have only held back from doing this out of our belief
> that goodwill amongst network participants is more important than trying to
> push some pet feature some of us want.
> >
> > Please stop this negativity - we ALL want the best for Bitcoin and are
> doing our best, given what we understand and know, to do what’s right.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/5816f286/attachment-0001.html>

2023-06-07 17:36:06

- reply

📅 Original date posted:2015-08-17
📝 Original message:Eric Lombrozo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
schrieb am Mo., 17. Aug. 2015 um 16:03 Uhr:
> NxtChg,
>
> In the entire history of Bitcoin we’ve never attempted anything even
> closely resembling a hard fork like what’s being proposed here.
>
> Many of us have wanted to push our own hard-forking changes to the
> protocol…and have been frustrated because of the inability to do so.
>
> This inability is not due to any malice on anyone’s part…it is a feature
> of Satoshi’s protocol. For better or worse, it is *very hard* to change the
> rules…and this is exactly what imbues Bitcoin with one of its most powerful
> attributes: very well-defined settlement guarantees that cannot be suddenly
> altered nor reversed by anyone.
>
> We’ve managed to have a few soft forks in the past…and for the most part
> these changes have been pretty uncontroversial…or at least, they have not
> had nearly the level of political divisiveness that this block size issue
> is having. And even then, we’ve encountered a number of problems with these
> deployments that have at times required goodwill cooperation between
> developers and mining pool operators to fix.
>
> Again, we have NEVER attempted anything even remotely like what’s being
> proposed - we’ve never done any sort of hard fork before like this. If even
> fairly uncontroversial soft forks have caused problems, can you imagine the
> kinds of potential problems that a hard fork over some highly polarizing
> issue might raise? Do you really think people are going to want to
> cooperate?!?
>
> I can understand that some people would like bigger blocks. Other people
> might want feature X, others feature Y…and we can argue the merits of this
> or that to death…but the fact remains that we have NEVER attempted any hard
> forking change…not even with a simple, totally uncontroversial no-brainer
> improvement that would not risk any sort of ill-will that could hamper
> remedies were it not to go as smoothly as we like. *THIS* is the
> fundamental problem - the whole bigger block thing is a minor issue by
> comparison…it could be any controversial change, really.
>
> Would you want to send your test pilots on their first flight…the first
> time an aircraft is ever flown…directly into combat without having tested
> the plane? This is what attempting a hard fork mechanism that’s NEVER been
> done before in such a politically divisive environment basically amounts
> to…but it’s even worse. We’re basically risking the entire air force (not
> just one plane) over an argument regarding how many seats a plane should
> have that we’ve never flown before.
>
> We’re talking billlions of dollars’ worth of other people’s money that is
> on the line here. Don’t we owe it to them to at least test out the system
> on a far less controversial, far less divisive change first to make sure we
> can even deploy it without things breaking? I don’t even care about the
> merits regarding bigger blocks vs. smaller blocks at this point, to be
> quite honest - that’s such a petty thing compared to what I’m talking about
> here. If we attempt a novel hard-forking mechanism that’s NEVER been
> attempted before (and which as many have pointed out is potentially fraught
> with serious problems) on such a politically divisive, polarizing issue,
> the result is each side will refuse to cooperate with the other out of
> spite…and can easily lead to a war, tanking the value of everyone’s assets
> on both chains. All so we can process 8 times the number of transactions we
> currently do? Even if it were 100 times, we wouldn’t even come close to
> touching big payment processors like Visa. It’s hard to imagine a protocol
> improvement that’s worth the risk.
>
> I urge you to at least try to see the bigger picture here…and to
> understand that nobody is trying to stop anyone from doing anything out of
> some desire for maintaining control - NONE of us are able to deploy hard
> forks right now without facing these problems. And different people
> obviously have different priorities and preferences as to which of these
> changes would be best to do first. This whole XT thing is essentially
> giving *one* proposal special treatment above those that others have
> proposed. Many of us have only held back from doing this out of our belief
> that goodwill amongst network participants is more important than trying to
> push some pet feature some of us want.
>
Yadayadayada.
If someone could threaten the network by releasing a hard-forking bitcoind
version, then already all is lost. Bitcoins stability does not (and cannot)
depend on the "good will" of anyone. If it would, we should all abandon
this silly project. Relying on the good will of people is the worst idea
one could have.
So please (please please) go ahead and release your hardforking bitcoinds
you have been holding back. Competition is everything.
Cheers
Levin
>
> Please stop this negativity - we ALL want the best for Bitcoin and are
> doing our best, given what we understand and know, to do what’s right.
>
>
>
> > On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> >
> >> We should have the highest respect for what these people are doing, and
> we should try to do something constructive, not waste time with anger and
> disrespect.
> >
> > Why, exactly, should I have any respect for what these people are doing
> (and supposedly not have any respect for what the other side is doing)?
> >
> > From my point of view, the XT side _does_ something constructive. It's
> the Core side that resorts to dirty tactics and tries to sabotage
> community's free choice instead.
> >
> >
> >> Nobody should be forced to do anything.
> >
> > Great, so how about you go tell theymos to stop censoring XT posts and
> banning the other side on /r/Bitcoin?
> >
> > Let users decide what Bitcoin is or isn't.
> >
> >
> >> The developers are not telling you what to do, they are trying to do
> what they consider is best for the ecosystem given their technical
> abilities.
> >
> > The developers & Co are doing their best to stay in power, so they could
> continue imposing their will on Bitcoin ecosystem. This is the real power
> grab, not Gavin and Hearn, who merely provided an alternative.
> >
> > And the fear they show is most telling.
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/b35a3070/attachment.html>

2023-06-07 17:36:02

- reply

📅 Original date posted:2015-08-16
📝 Original message:Hey everyone,
as with the current "max block size" debate I was wondering: Is anyone here
in favor of a minimum block size (say 2 MB or so)? If so I would be
interested in an exchange (maybe off-list) of ideas. I am in favor of a
lower limit and am giving it quite a bit of thought at the moment.
Cheers
Levin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150816/f97a3eca/attachment-0001.html>

2023-06-07 17:35:25

- reply

📅 Original date posted:2015-08-16
📝 Original message:Hear hear Tamas,
I agree. I personally prefer to use the "only-bigblocks" branch and not XT
with all its features - but as I am not mining that doesn't mean much
anyhow. Nevertheless I am happy to be able to publicly proclaim my opinion
that the block size should be raised asap.
Thank you for going ahead Mike
Levin
Tamas Blummer via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
schrieb am So., 16. Aug. 2015 um 18:07 Uhr:
> Being a bitcoin software developer an entrepreneur for years I learned
> that success is not a direct consequence of technology and is not
> inevitable.
> BitcoinXT manifesto (
> https://github.com/bitcoinxt/bitcoinxt#the-xt-manifesto) should resonate
> with many fellow entrepreneurs.
> I applaud Mike and Gavin for creating that choice for us.
>
> Tamas Blummer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150816/76127ff3/attachment.html>

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-02-03
📝 Original message:Why even bother with the specific HD scheme such as BIP32 or BIP44. What
are the interesting parameters?
Required:
- gap limit
Optional:
- which node of the derivation chain is actually exported (m0' for
BIP32, m44'0'account' for BIP44)
- which subnodes are used for external and internal purposes
- creation date
To import the data in a read only application it is not important which
node one actually gets and in all implementations the subnode of the
exported node "0" is used for external addresses and "1" for internal
addresses.
There is no usecase to export any higher node than m0' in BIP32 or
m44'0'account' as one can only derive any child nodes of the higher nodes *with
the private master key*. As for lower nodes (like further down the path)
there is also no need to export because in all implementations today they
will only give around half of the used addresses.
So I think a more general but very useful export scheme would be:
bitcoin-pub-export:xpub[gibberish]?gaplimit=[number]&path=[path in
derivation tree]&subchains=[numbers]&creationdate=[unixtimestamp]
Why not have more descriptive parameters? Saving on data?
I am a big fan of unix timestamps. Would vote for Andreas' format on the
creation date.
Cheers
Levin
2015-02-03 1:22 GMT+01:00 Pavol Rusnak <stick at gk2.sk>:
> On 03/02/15 01:05, Andreas Schildbach wrote:
> > I don't think that parameterizing will work, we can't predict future
> > BIPs. It's the same as for BIP43, in the end we agreed on just putting
> > the BIP number.
>
> Hm, let me put the questions the other way around:
>
> What gap limit should a wallet use if it encounters h=bip32?
>
> What h value should I use for myTREZOR wallets? Which is essentially a
> BIP44 wallet that produces h=bip32 xpubs with gap limit 20 ...
>
> --
> Best Regards / S pozdravom,
>
> Pavol Rusnak <stick at gk2.sk>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150203/80057add/attachment.html>

2023-06-07 15:29:24

- reply

📅 Original date posted:2015-02-02
📝 Original message:Hello everyone,
I think this is my first email to this mailinglist so I will shortly
introduce myself:
I am Levin and the CEO of Coyno (www.coyno.com). Based in Berlin,
mathematician. Bitcoiner since 2011.
And now the reason for this email: Andreas (Schildbach) just released a new
update of his wallet. It now provides an export functionality for the m/0'
key in order to run read only copies on other devices. We already support
the format on our website. Of course we would love for this to become
standard. I also updated the Wiki article for Andreas' Wallet:
https://en.bitcoin.it/wiki/Bitcoin_Wallet
How do you like it? How does this format get standard? Shall I try to get a
pull request to BIP32 passed?
Cheers
Levin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150202/37a91920/attachment.html>