<unnamed>

Public Key

npub1c8flqlwmkh5vehm7rfcacurk9x5ggv36vtra2p97thynzfq0vxus5zgzt8

Profile Code

nprofile1qqsvr5ls0hdmt6xvmalp5uwuwpmzn2yyxgax9374qjl9mjf3ys8krwgpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg5waehxw309aex2mrp0yhxgctdw4eju6t0qyxhwumn8ghj7mn0wvhxcmmvt7sst2

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 18:22:27 UTC

- reply

📅 Original date posted:2020-01-15
📝 Original message:> Instead of using sidechains, just use channel factories.
> You do not need to broadcast the entire internal ledgers of those
services, only their customers need to know those internal ledgers, and
sign off on the updates of those ledgers.
That's right, all you need to broadcast is a small proof, a non-interactive
blockchain suffix proof
https://eprint.iacr.org/2017/963.pdf
On Sun, Jan 12, 2020 at 7:33 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning Robin,
>
>
> > Good morning ZmnSCPxj,
> >
> > Thank you for your detailed feedback! Two topics:
> >
> > Lightning vs Sidechains
> >
> > ------------------------
> >
> > Why an either-or-solution, if we can connect sidechains via the LN to
> get the best of both worlds?
> >
> > The LN works exceptionally great under the following conditions:
> >
> > - you're always online
> > - you have BTC to manage your channels' inbound-capacity
> > - you can afford BTC transactions
> > - in your channel is much more than the minimum on-chain TX fees
> >
> > The next Billion users do not fit that category. They are on
> unreliable cell phone connections and do not have any BTC yet.
> > And the more popular Bitcoin becomes, the fewer people can
> afford LN channels. Even Eltoo requires your funds to be significantly
> higher than Bitcoin's TX fees, right?
> >
> > Already today, more and more services like tippin.me,
> BlueWallet, etc, provide custodial solutions.
> > For small amounts, custody is an acceptable workaround. And I
> love their usability. Install it and immediately I can send you $0.01. Yet,
> scaling their approach globally does not lead to desirable outcomes, since
> we'd be back to trusting banks with their Excel sheets.
> >
> > So let's make their internal ledgers public and trustless, via
> independent sidechains. Decentralized Blockchains do scale decently up to a
> couple Million UTXOs. So a couple thousand Sidechains is probably
> sufficient for a global medium of exchange. Cross-chain communication
> without requiring cross-chain validation is possible via atomic swaps and
> through Bitcoin's LN. That scales because it separates chain-validators
> from swap-validators.
> > Bitcoin's LN acts as the central settlement layer for efficient
> cross-chain transactions between all sidechains.
> >
> > So Endusers "living" in sidechains instead of directly in the LN
> has many advantages:
> >
> > - no bitcoin blockspace required for on-boarding new users
> > - no need to lock funds to provide inbound-capacity
> > - no need to stay online or pay watch towers
> > - no need to store channel histories
> > - account balances can be much smaller than BTC TX fees
> >
> > Those are the exact same reasons why BlueWallet built their LndHub.
> But sidechains can be trustless. Also a generic protocol provides
> flexibility for sidechain innovations with arbitrary digital assets and
> consensus rules.
>
>
> Which is why I brought up multiparticipant offchain updateable
> cryptocurrency systems.
> The "channel factories" concepts does what you are looking for, except
> with better trust-minimization than sidechains can achieve.
> Just replace "sidechain" with either Decker-Wattenhofer or
> Decker-Russell-Osuntokun constructions.
> You can even use the Somsen "statechain" mechanism, which rides a
> Decker-Wattenhofer/Decker-Russell-Osuntokun construction, though its
> trust-minimization is only very very slightly better than federated
> sidechains.
>
> It is helpful to remember that Poon-Dryja, Decker-Wattenhofer,
> Decker-Russell-Osuntokun, and all other future such constructions, can host
> any contract that its lower layer can support.
> So if you ride a Poon-Dryja on top of the Bitcoin blockchain, you can host
> HTLCs inside the Poon-Dryja, since the Bitcoin blockchain can host HTLCs.
> Similarly, if you ride a Decker-Wattenhofer on top of the Bitcoin
> blockchain, you can host a Poon-Dryja inside the Decker-Wattenhofer, since
> the Bitcoin blockchain can host Poon-Dryja channels.
> This central insight leads one to conclude that anything you can put
> onchain, you an generally also put offchain, so why use a chain at all
> except as an ultimate anchor to reality?
> Poon-Dryja is strictly two-participant, while Decker-Wattenhofer limits
> the practical number of updates due to its use of decrementing relative
> timelocks: so you put the payment layer in a bunch of Poon-Dryja channels
> which support tons of updates each but only two participants per channel,
> and create a layer that supports changes to the channel topology (where
> changes to the channel connectivity are expected to be much rarer than
> payments) and is multiparticipant so you can *actually* scale.
>
> Instead of using sidechains, just use channel factories.
> You do not need to broadcast the entire internal ledgers of those
> services, only their customers need to know those internal ledgers, and
> sign off on the updates of those ledgers.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> 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/20200115/48d7ea4b/attachment-0001.html>

2023-06-07 17:36:19 UTC

- reply

📅 Original date posted:2015-08-17
📝 Original message:I've been sharing a similar solution for the past 2 weeks. I think 2016
blocks is too much of a wait, I think we should look at the mean block size
during the last 60-120 minutes instead and avert any crisis caused by
transactional spikes that could well be caused by organic use of the
network (Madonna sells her next tour tickets on Bitcoin, OpenBazaar network
starts working as imagined, XYZ startup really kicks ass and succeeds in a
couple of major cities with major PR push)
Pseudo code in Python
https://gist.github.com/gubatron/143e431ee01158f27db4
My idea stems from a simple scalability metric that affects real users and
the desire to use Bitcoin:
Waiting times to get your transactions confirmed on the blockchain.
Anything past 45mins-1 hour should be unnacceptable.
Initially I wanted to measure the mean time for the transactions in blocks
to go from being sent by the user
(initial broadcast into mempools) until the transaction was effectively
confirmed on the blockchain, say for 2 blocks (acceptable 15~20mins)
When blocks get full, people start waiting unnaceptable times for their
transactions to come through
if they don't adjust their fees. The idea is to avoid that situation at all
costs and keep the network
churning to the extent of its capabilities, without pretending a certain
size will be right at some
point in time, nobody can predict the future, nobody can predict real
organic usage peaks
on an open financial network, not all sustained spikes will come from
spammers,
they will come from real world use as more and more people think of great
uses for Bitcoin.
I presented this idea to measure the mean wait time for transactions and I
was told
there's no way to reliably meassure such a number, there's no consensus
when transactions are still
in the mempool and wait times could be manipulated. Such an idea would have
to include new timestamp fields
on the transactions, or include the median wait time on the blockheader
(too complex, additional storage costs)
This is an iteration on the next thing I believe we can all agree is 100%
accurately measured, blocksize.
Full blocks are the cause why many transactions would have to be waiting in
the mempool, so we should be able
to also use the mean size of the blocks to determine if there's a
legitimate need to increase or reduce the
maximum blocksize.
The idea is simple, If blocks are starting to get full past a certain
threshold then we double the blocksize
limit starting the next block, if blocks remain within a healthy bound,
transaction wait times should be as
expected for everyone on the network, if blocks are not getting that full
and the mean goes below a certain
threshold then we half the maximum block size allowed until we reach the
level we need.
Similar to what we do with hashing difficulty, it's something you can't
predict, therefore no fixed limits,
or predicted limits should be established.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/795d714c/attachment.html>

2023-06-07 17:35:46 UTC

- reply

📅 Original date posted:2015-08-18
📝 Original message:"How then to end this XT madness?"
Instead of bashing on someone that has actually put a solution forward,
make your own fork and see if your ideas on how to solve the issue are any
better.
As of now, 1Mb blocks are pure madness, and people are voting over an 8mb
block increase every day that passes, even with a "useless project" like
you call it.
Go out there and see how bitcoin is actually used.
http://twitter.com/gubatron
On Tue, Aug 18, 2015 at 10:54 PM, odinn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The "XT Fork" (better said, a POS alt*) and those behind it make not
> even a pretense to work through process involved with bitcoin developmen
> t.
>
> (*This is not intended as a slight toward any other alts, as here in
> this post I am focusing solely on XT.)
>
> Instead of abandoning their useless project, or at least conceding
> that their alt is operating essentially outside of the development
> funnel (by this I mean BIP process), the developers of XT, via their
> latest presentation of XT give nothing more than an attack on bitcoin
> (albeit one that, more than anything, is designed to sidetrack real
> discussion necessary to resolve the issues so as to achieve some level
> of consensus in block size debates). Curiously, XT is not even truly
> the implementation of BIP 101; the actual proposed implementation of
> BIP 101 as proposed at
> https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki#implement
> ation
> is found here: https://github.com/bitcoin/bitcoin/pull/6341
> (It is currently a closed issue.)
>
> It's probably valid to call into question why Mike Hearn in particular
> persists with this project at all, as he has been its biggest
> cheerleader. Some reasons may be:
> 1) His interest in attacking bitcoin in the past (seems to be a
> recurring pattern)
> https://bitcointalk.org/index.php?topic=333824.0
>
> 2) His employment (has come up before) - QinetiQ, Google, etc
> https://plus.google.com/+MikeHearn/about - it's simply not
> unreasonable to ask why he's pushing it so hard when nobody wants it.
>
> 3) Various reasons mentioned here:
> https://www.reddit.com/r/Bitcoin/comments/39yaug/the_history_of_mike_hea
> rn_and_why_you_should_not/
>
>
> 4) His disinterest in following what is actually happening with votes
> on legitimate proposals (e.g. Garzik's BIP 100) in the blocks. (Caveat
> ~ one doesn't see the BIP 100 yet in bitcoin/bips because it won't
> appear for another couple weeks, supposedly. The miners' voting is
> already happening however.) Even according to http://xtnodes.com/ we
> see that XT runs minimal nodes in comparison to the rest of nodes
> being run across the network.
>
> BIP 100 itself is anticipated to be submitted w/ implementation in the
> next 2 weeks and many miners are already voting on BIP 100 (as per
> Jeff Garzik, from a post 08/12/2015 12:46 PM -0400 to this mailing list)
> .
>
> It is an insult to see Hearn fling the XT turd into the community
> repeatedly.
>
> How then to end this XT madness?
>
> "The ring was made in the fires of Mount Doom. Only there can it be
> unmade. The ring must be taken deep into Mordor and cast back into the
> fiery chasm from whence it came. One of you must do this."
> - - Lord Elrond
>
> Do not download this loathsome XT thing. Cast it back into the fires
> from whence it came.
>
> - -Odinn
>
>
> On 08/15/2015 10:43 AM, Satoshi Nakamoto via bitcoin-dev wrote:
> > 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
> >
> > _______________________________________________ bitcoin-dev mailing
> > list bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
> - --
> http://abis.io ~
> "a protocol concept to enable decentralization
> and expansion of a giving economy, and a new social good"
> https://keybase.io/odinn
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJV0+/fAAoJEGxwq/inSG8C4ZAIAKm1pEne0FlOW1O4zLe6mZOz
> YTcnpSHFiVw4AfUPgbzR813ODphnJqcwnoT1q/sojjqgIDtwZY+AqdjA3VAbe15D
> bAPlvQGmXMlaXq8OteDYPKxPzQMUlRtxEd9+sxO5IGFx0kvmKQLzdk6cmgawcRhN
> PrDyXIqLlx6Yp0REQ03v3poLTGojUkPLeqdMrJAjwpuAyv9F8iVUn7SeHemEi8cm
> fW4wOJogA8j9P//3a7+Cr8bjnOz6+QwpHsdlZlKM4VUTxt3Vgx4vu+SQjQxWgZEK
> I+HGvgQW1buoDxleBbFq6SJc55lhF41IB17tewuDuPzT2nL4zOkbis1tUk3ASxY=
> =Rm7w
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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/20150818/dd142daf/attachment.html>

2023-06-07 17:35:16 UTC

- reply

📅 Original date posted:2015-08-15
📝 Original message:"I don’t think the concern here is so much that some people want to
increase block size. It’s the *way* in which this change is being pushed
that is deeply problematic."
As a developer on the side lines, bitcoin holder, bitcoin entrepreneur, and
someone who thinks block size limits should be dynamic, I applaud Mike and
Co. for this initiative, some of us that have different ideas on how to
deal with the blocksize issue will certainly not be afraid of wasting time
sending patches to the Bitcoin XT project where it seems they're a bit more
open minded about this issue. I bet sending the same patch to Bitcoin-Core
would be rejected on the spot. Bitcoin XT, I hope, will give room to allow
for scalability, it seems the other camp is bent on using Bitcoin their own
way and their own way only and that's far more problematic because that
will allienate the entire user base eventually.
http://twitter.com/gubatron
On Sat, Aug 15, 2015 at 6:16 PM, Eric Lombrozo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> What are you so afraid of, Eric? If Mike's fork is successful, consensus
> is reached around larger blocks. If it is rejected, the status quo will
> remain for now. Network consensus, NOT CORE DEVELOPER CONSENSUS, is the
> only thing that matters, and those that go against network consensus will
> be severely punished with complete loss of income.
>
>
> I fully agree that core developers are not the only people who should have
> a say in this. But again, we’re not talking about merely forking some open
> source project - we’re talking about forking a ledger representing real
> assets that real people are holding…and I think it’s fair to say that the
> risk of permanent ledger forks far outweighs whatever benefits any change
> in the protocol might bring. And this would be true even if there were
> unanimous agreement that the change is good (which there clearly IS NOT in
> this case) but the deployment mechanism could still break things.
>
> If anything we should attempt a hard fork with a less contentious change
> first, just to test deployability.
>
> I'm not sure who appointed the core devs some sort of Bitcoin Gods that
> can hold up any change that they happen to disagree with. It seems like the
> core devs are scared to death that the bitcoin network may change without
> their blessing, so they go on and on about how terrible hard forks are.
> Hard forks are the only way to keep core devs in check.
>
>
> Again, let’s figure out a hard fork mechanism and test it with a far less
> contentious change first
>
> Despite significant past technical bitcoin achievements, two of the most
> vocal opponents to a reasonable blocksize increase work for a company
> (Blockstream) that stands to profit directly from artificially limiting the
> blocksize. The whole situation reeks. Because of such a blatant conflict of
> interest, the ethical thing to do would be for them to either resign from
> Blockstream or immediately withdraw themselves from the blocksize debate.
> This is the type of stuff that I hoped would end with Bitcoin, but alas, I
> guess human nature never changes.
>
>
> For the record, I do not work for Blockstream. Neither do a bunch of other
> people who have published a number of concerns. Very few of the concerns
> I’ve seen from the technical community seem to be motivated primarily by
> profit motives.
>
> It should also be pointed out that *not* making drastic changes is the
> default consensus policy…and the burden of justifying a change falls on
> those who want to make the change. Again, the risk of permanent ledger
> forks far outweighs whatever benefits protocol changes might bring.
>
> Personally, I think miners should give Bitcoin XT a serious look. Miners
> need to realize that they are in direct competition with the lightning
> network and sidechains for fees. Miners, ask yourselves if you think you'll
> earn more fees with 1 MB blocks and more off-chain transactions or with 8
> MB blocks and more on-chain transactions…
>
>
> Miners are NOT in direct competition with the lightning network and
> sidechains - these claims are patently false. I recommend you take a look
> at these ideas and understand them a little better before trying to make
> any such claims. Again, I do not work for Blockstream…and my agenda in this
> post is not to promote either of these ideas…but with all due respect, I do
> not think you properly understand them at all.
>
> The longer this debate drags on, the more I agree with BIP 100 and Jeff
> Garzik because the core devs are already being influenced by outside forces
> and should not have complete control of the blocksize. It's also
> interesting to note that most of the mining hashpower is already voting for
> 8MB blocks BIP100 style.
>
>
> I don’t think the concern here is so much that some people want to
> increase block size. It’s the *way* in which this change is being pushed
> that is deeply problematic.
>
> On Sat, Aug 15, 2015 at 5:32 PM, Eric Lombrozo via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> You deeply disappoint me, Mike.
>>
>> Not only do you misrepresent many cogent, well thought out positions from
>> a great number of people who have published and posted a number of articles
>> detailing an explaining in-depth technical concerns…you also seem to fancy
>> yourself more capable of reading into the intentions of someone who
>> disappeared from the scene years ago, before we even were fully aware of
>> many things we now know that bring the original “plan” into question.
>>
>> I ask of you, as a civilized human being, to stop doing this divisive
>> crap. Despite your protestations to the contrary, YOU are the one who is
>> proposing a radical departure from the direction of the project. Also, as
>> several of us have clearly stated before, equating the fork of an open
>> source project with a fork of a cryptoledger is completely bogus - there’s
>> a lot of other people’s money at stake. This isn’t a democracy - consensus
>> is all or nothing. The fact that a good number of the people most
>> intimately familiar with the inner workings of Satoshi’s invention do not
>> believe doing this is a good idea should give you pause.
>>
>> Please stop using Bitcoin as your own political football…for the sake of
>> Bitcoin…and for your own sake. Despite your obvious technical abilities
>> (and I sincerely do believe you have them) you are discrediting yourself
>> and hurting your own reputation.
>>
>>
>> - Eric
>>
>> On Aug 15, 2015, at 10:02 AM, Mike Hearn via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Hello,
>>
>> As promised, we have released Bitcoin XT 0.11A which includes the bigger
>> blocks patch set. You can get it from
>>
>> https://bitcoinxt.software/
>>
>> I feel sad that it's come to this, but there is no other way. The Bitcoin
>> Core project has drifted so far from the principles myself and many others
>> feel are important, that a fork is the only way to fix things.
>>
>> Forking is a natural thing in the open source community, Bitcoin is not
>> the first and won't be the last project to go through this. Often in forks,
>> people say there was insufficient communication. So to ensure everything is
>> crystal clear I've written a blog post and a kind of "manifesto" to
>> describe why this is happening and how XT plans to be different from Core
>> (assuming adoption, of course).
>>
>> The article is here:
>>
>> https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1
>>
>> It makes no attempt to be neutral: this explains things from our point of
>> view.
>>
>> The manifesto is on the website.
>>
>> I say to all developers on this list: if you also feel that Core is no
>> longer serving the interests of Bitcoin users, come join us. We don't bite.
>>
>> _______________________________________________
>> 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
>>
>>
> _______________________________________________
> 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/20150815/d77855cf/attachment-0001.html>

2023-06-07 17:34:01 UTC

- reply

📅 Original date posted:2015-08-11
📝 Original message:- policy neutrality.
- It can't be censored.
- it can't be shut down
- and the rules cannot change from underneath you.
except it can be shutdown the minute it actually gets used by its inability
to scale.
what's the point of having all this if nobody can use it?
what's the point of going through all that energy and CO2 for a mere 24,000
transactions an hour?
It's clear that it's just a matter of time before it collapses.
Here's a simple proposal (concept) that doesn't pretend to set a fixed
block size limit as you can't ever know the demands the future will bring
https://gist.github.com/gubatron/143e431ee01158f27db4
We don't need to go as far as countries with hyper inflation trying to use
the technology to make it collapse, anybody here who has distributed
commercial/free end user software knows that any small company out there
installs more copies in a couple weeks than all the bitcoin users we have
at the moment, all we need is a single company/project with a decent amount
of users who are now enabled to transact directly on the blockchain to
screw it all up (perhaps OpenBazaar this winter could make this whole thing
come down, hopefully they'll take this debate and the current limitations
before their release, and boy are they coding nonstop on it now that they
got funded), the last of your fears should be a malicious government trying
to shut you down, for that to happen you must make an impact first, for now
this is a silly game in the grand scheme of things.
And you did sound pretty bad, all of his points were very valid and they
share the concern of many people, many investors, entrepreneurs putting
shitload of money, time and their lives on a much larger vision than that
of a network that does a mere 3,500 tx/hour, but some people seem to be
able to live in impossible or useless ideals.
It's simply irresponsible to not want to give the network a chance to grow
a bit more. Miners centralizing is inevitable given the POW based
consensus, hobbists-mining is only there for countries with very cheap
energy.
If things remain this way, this whole thing will be a massive failure and
it will probably take another decade before we can open our mouths about
cryptocurrencies, decentralization and what not, and this stubornness will
be the one policy that censored everyone, that shutdown everyone, that made
the immutable rules not matter.
Perhaps it will be Stellar what ends up delivering at this stubborn pace.
http://twitter.com/gubatron
On Tue, Aug 11, 2015 at 4:38 AM, Thomas Zander via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> >It follows then, that if we make a decision now which destroys that
> property, which makes it possible to censor bitcoin, to deny service, or to
> pressure miners into changing rules contrary to user interests, then
> Bitcoin is no longer interesting.
>
> You asked to be convinced of the need for bigger blocks. I gave that.
> What makes you think bitcoin will break when more people use it?
>
> Sent on the go, excuse the brevity.
> *From: *Mark Friedenbach
> *Sent: *Tuesday, 11 August 2015 08:10
> *To: *Thomas Zander
> *Cc: *Bitcoin Dev
> *Subject: *Re: [bitcoin-dev] Fees and the block-finding process
>
> On Mon, Aug 10, 2015 at 11:31 PM, Thomas Zander via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Monday 10. August 2015 23.03.39 Mark Friedenbach wrote:
>> > 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.
>>
>> ...
>>
>> 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.
>
>
> I'm sorry, I really don't want to sound like a jerk, but not a single word
> of that mattered. Yes we all want Bitcoin to scale such that every person
> in the world can use it without difficulty. However if that were all that
> we cared about then I would be remiss if I did not point out that there are
> plenty of better, faster, and cheaper solutions to finding global consensus
> over a payment ledger than Bitcoin. Architectures which are algorithmically
> superior in their scaling properties. Indeed they are already implemented
> and you can use them today:
>
> https://www.stellar.org/
> http://opentransactions.org/
>
> So why do I work on Bitcoin, and why do I care about the outcome of this
> debate? Because Bitcoin offers one thing, and one thing only which
> alternative architectures fundamentally lack: policy neutrality. It can't
> be censored, it can't be shut down, and the rules cannot change from
> underneath you. *That* is what Bitcoin offers that can't be replicated at
> higher scale with a SQL database and an audit log.
>
> It follows then, that if we make a decision now which destroys that
> property, which makes it possible to censor bitcoin, to deny service, or to
> pressure miners into changing rules contrary to user interests, then
> Bitcoin is no longer interesting. We might as well get rid of mining at
> that point and make Bitcoin look like Stellar or Open-Transactions because
> at least then we'd scale even better and not be pumping millions of tons of
> CO2 into the atmosphere from running all those ASICs.
>
> On the other side, 3Tb harddrives are sold, which take 8Mb blocks without
>> problems.
>>
>
> Straw man, storage is not an issue.
>
>
>> 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).
>>
>
> Neither one of those assertions is clear. Keep in mind the goal is to have
> Bitcoin survive active censorship. Presumably that means being able to run
> a node even in the face of a hostile ISP or government. Furthermore, it
> means being location independent and being able to move around. In many
> places the higher the bandwidth requirements the fewer the number of ISPs
> that are available to service you, and the more visible you are.
>
> It may also be necessary to be able to run over Tor. And not just today's
> Tor which is developed, serviced, and supported by the US government, but a
> Tor or I2P that future governments have turned hostile towards and actively
> censor or repress. Or existing authoritative governments, for that matter.
> How much bandwidth would be available through those connections?
>
> It may hopefully never be necessary to operate under such constraints,
> except by freedom seeking individuals within existing totalitarian regimes.
> 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.
>
> To the second point, it has been previously pointed out that large miners
> stand to gain from larger blocks, for the same basic underlying reasons as
> selfish mining. The incentive is to increase blocks, and miners are able to
> do so at will and without cost. I would not be so certain that we wouldn't
> see large blocks sooner than that.
>
>
>> 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.
>>
>
> This is basically already deployed thanks to Matt's relay network. Further
> improvements are not going to have dramatic effects.
>
>
>> 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?
>
> I humbly suggest that maybe we should play the strengths of Bitcoin
> instead -- it's trustlessness via policy neutrality.
>
> Either that, or go work on Stellar. Because that's where it's headed
> otherwise.
>
>
> _______________________________________________
> 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/20150811/206db4a3/attachment-0001.html>

2023-06-07 17:33:50 UTC

- reply

📅 Original date posted:2015-08-11
📝 Original message:> So if they dont care about decentralisation, they'll be happy using cheaper
off-chain systems, right?
You betcha! Just talk to a regular people and try to sell them on the
different scenarios.
They will start using something cheaper/faster the minute it comes along
from the banking industry, just to give you a real world example, this week
I've been dreading the idea of having to go to the bank to make a couple of
cash deposits. If I could open my bank's web page right now and do a very
simple interbank transaction (without having to convince the to let me link
their accounts to mine, with the process that takes like 2 days when they
deposit 2 different cent amounts...) just here within the retarded US
banking system... which has clearly realized the threat from
cryptocurrencies as evidenced on many banker conferences this year.
They will come up with ways to allow us to do person to person transfers,
but this will surely be limited to transactions within the country,
international remittances still have a great chance of being disrupted by
Bitcoin, if and only if, it will be cheap, otherwise the western unions and
xooms of the world will still rule.
Please get out of our your academic cocoon for a bit, talk to real people,
try to convince them to use Bitcoin, and think how hard it will be to make
the sell if on top you tell them... "it costs more... but it's
decentralized!" LOL
http://twitter.com/gubatron
On Tue, Aug 11, 2015 at 5:34 PM, Adam Back <adam at cypherspace.org> wrote:
> So if they dont care about decentralisation, they'll be happy using
> cheaper off-chain systems, right?
>
> Adam
>
> On 11 August 2015 at 22:30, Angel Leon <gubatron at gmail.com> wrote:
> > tell that to people in poor countries, or even in first world countries.
> The
> > competitive thing here is a deal breaker for a lot of people who have no
> > clue/don't care for decentralization, they just want to send money from
> A to
> > B, like email.
> >
> > http://twitter.com/gubatron
> >
> > On Tue, Aug 11, 2015 at 5:23 PM, Adam Back via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> I dont think Bitcoin being cheaper is the main characteristic of
> >> Bitcoin. I think the interesting thing is trustlessness - being able
> >> to transact without relying on third parties.
> >>
> >> Adam
> >>
> >>
> >> On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> > The only reason why Bitcoin has grown the way it has, and in fact the
> >> > only
> >> > reason why we're all even here on this mailing list talking about
> this,
> >> > is
> >> > because Bitcoin is growing, since it's "better money than other
> money".
> >> > One
> >> > of the key characteristics toward that is Bitcoin being inexpensive to
> >> > transact. If that characteristic is no longer true, then Bitcoin isn't
> >> > going
> >> > to grow, and in fact Bitcoin itself will be replaced by better money
> >> > that is
> >> > less expensive to transfer.
> >> >
> >> > So the importance of this issue cannot be overstated -- it's compete
> or
> >> > die
> >> > for Bitcoin -- because people want to transact with global consensus
> at
> >> > high
> >> > volume, and because technology exists to service that want, then it's
> >> > going
> >> > to be met. This is basic rules of demand and supply. I don't
> necessarily
> >> > disagree with your position on only wanting to support uncontroversial
> >> > commits, but I think it's important to get consensus on the
> criticality
> >> > of
> >> > the block size issue: do you agree, disagree, or not take a side, and
> >> > why?
> >> >
> >> >
> >> > On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille <
> pieter.wuille at gmail.com>
> >> > wrote:
> >> >>
> >> >> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev
> >> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> >>>
> >> >>> Hitting the limit in and of itself is not necessarily a bad thing.
> The
> >> >>> question at hand is whether we should constrain that limit below
> what
> >> >>> technology is capable of delivering. I'm arguing that not only we
> >> >>> should
> >> >>> not, but that we could not even if we wanted to, since competition
> >> >>> will
> >> >>> deliver capacity for global consensus whether it's in Bitcoin or in
> >> >>> some
> >> >>> other product / fork.
> >> >>
> >> >>
> >> >> The question is not what the technology can deliver. The question is
> >> >> what
> >> >> price we're willing to pay for that. It is not a boolean "at this
> size,
> >> >> things break, and below it, they work". A small constant factor
> >> >> increase
> >> >> will unlikely break anything in the short term, but it will come with
> >> >> higher
> >> >> centralization pressure of various forms. There is discussion about
> >> >> whether
> >> >> these centralization pressures are significant, but citing that it's
> >> >> artificially constrained under the limit is IMHO a misrepresentation.
> >> >> It is
> >> >> constrained to aim for a certain balance between utility and risk,
> and
> >> >> neither extreme is interesting, while possibly still "working".
> >> >>
> >> >> Consensus rules are what keeps the system together. You can't simply
> >> >> switch to new rules on your own, because the rest of the system will
> >> >> end up
> >> >> ignoring you. These rules are there for a reason. You and I may agree
> >> >> about
> >> >> whether the 21M limit is necessary, and disagree about whether we
> need
> >> >> a
> >> >> block size limit, but we should be extremely careful with change. My
> >> >> position as Bitcoin Core developer is that we should merge consensus
> >> >> changes
> >> >> only when they are uncontroversial. Even when you believe a more
> >> >> invasive
> >> >> change is worth it, others may disagree, and the risk from
> disagreement
> >> >> is
> >> >> likely larger than the effect of a small block size increase by
> itself:
> >> >> the
> >> >> risk that suddenly every transaction can be spent twice (once on each
> >> >> side
> >> >> of the fork), the very thing that the block chain was designed to
> >> >> prevent.
> >> >>
> >> >> My personal opinion is that we should aim to do a block size increase
> >> >> for
> >> >> the right reasons. I don't think fear of rising fees or unreliability
> >> >> should
> >> >> be an issue: if fees are being paid, it means someone is willing to
> pay
> >> >> them. If people are doing transactions despite being unreliable,
> there
> >> >> must
> >> >> be a use for them. That may mean that some use cases don't fit
> anymore,
> >> >> but
> >> >> that is already the case.
> >> >>
> >> >> --
> >> >> Pieter
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > 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/20150811/c51a5d14/attachment.html>

2023-06-07 17:33:47 UTC

- reply

📅 Original date posted:2015-08-11
📝 Original message:tell that to people in poor countries, or even in first world countries.
The competitive thing here is a deal breaker for a lot of people who have
no clue/don't care for decentralization, they just want to send money from
A to B, like email.
http://twitter.com/gubatron
On Tue, Aug 11, 2015 at 5:23 PM, Adam Back via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I dont think Bitcoin being cheaper is the main characteristic of
> Bitcoin. I think the interesting thing is trustlessness - being able
> to transact without relying on third parties.
>
> Adam
>
>
> On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > The only reason why Bitcoin has grown the way it has, and in fact the
> only
> > reason why we're all even here on this mailing list talking about this,
> is
> > because Bitcoin is growing, since it's "better money than other money".
> One
> > of the key characteristics toward that is Bitcoin being inexpensive to
> > transact. If that characteristic is no longer true, then Bitcoin isn't
> going
> > to grow, and in fact Bitcoin itself will be replaced by better money
> that is
> > less expensive to transfer.
> >
> > So the importance of this issue cannot be overstated -- it's compete or
> die
> > for Bitcoin -- because people want to transact with global consensus at
> high
> > volume, and because technology exists to service that want, then it's
> going
> > to be met. This is basic rules of demand and supply. I don't necessarily
> > disagree with your position on only wanting to support uncontroversial
> > commits, but I think it's important to get consensus on the criticality
> of
> > the block size issue: do you agree, disagree, or not take a side, and
> why?
> >
> >
> > On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille <pieter.wuille at gmail.com>
> > wrote:
> >>
> >> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>
> >>> Hitting the limit in and of itself is not necessarily a bad thing. The
> >>> question at hand is whether we should constrain that limit below what
> >>> technology is capable of delivering. I'm arguing that not only we
> should
> >>> not, but that we could not even if we wanted to, since competition will
> >>> deliver capacity for global consensus whether it's in Bitcoin or in
> some
> >>> other product / fork.
> >>
> >>
> >> The question is not what the technology can deliver. The question is
> what
> >> price we're willing to pay for that. It is not a boolean "at this size,
> >> things break, and below it, they work". A small constant factor increase
> >> will unlikely break anything in the short term, but it will come with
> higher
> >> centralization pressure of various forms. There is discussion about
> whether
> >> these centralization pressures are significant, but citing that it's
> >> artificially constrained under the limit is IMHO a misrepresentation.
> It is
> >> constrained to aim for a certain balance between utility and risk, and
> >> neither extreme is interesting, while possibly still "working".
> >>
> >> Consensus rules are what keeps the system together. You can't simply
> >> switch to new rules on your own, because the rest of the system will
> end up
> >> ignoring you. These rules are there for a reason. You and I may agree
> about
> >> whether the 21M limit is necessary, and disagree about whether we need a
> >> block size limit, but we should be extremely careful with change. My
> >> position as Bitcoin Core developer is that we should merge consensus
> changes
> >> only when they are uncontroversial. Even when you believe a more
> invasive
> >> change is worth it, others may disagree, and the risk from disagreement
> is
> >> likely larger than the effect of a small block size increase by itself:
> the
> >> risk that suddenly every transaction can be spent twice (once on each
> side
> >> of the fork), the very thing that the block chain was designed to
> prevent.
> >>
> >> My personal opinion is that we should aim to do a block size increase
> for
> >> the right reasons. I don't think fear of rising fees or unreliability
> should
> >> be an issue: if fees are being paid, it means someone is willing to pay
> >> them. If people are doing transactions despite being unreliable, there
> must
> >> be a use for them. That may mean that some use cases don't fit anymore,
> but
> >> that is already the case.
> >>
> >> --
> >> Pieter
> >>
> >
> >
> > _______________________________________________
> > 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/20150811/cc54f99b/attachment.html>

2023-06-07 15:47:55 UTC

- reply

2023-06-07 15:47:28 UTC

- reply

2023-06-07 15:47:06 UTC

- reply

2023-06-07 15:46:56 UTC

- reply

📅 Original date posted:2015-08-14
📝 Original message:Like this?
https://gist.github.com/gubatron/143e431ee01158f27db4
http://twitter.com/gubatron
On Fri, Aug 14, 2015 at 5:59 AM, Jakob Rönnbäck <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Greetings,
>
> a thought occurred to me that I would love to hear what some bitcoin
> experts think about.
>
> What if one were to adjust the difficulty (for individual blocks)
> depending on the relative size to the average block size of the previous
> difficulty period? (I apologize if i’m not using the correct terms, I’m not
> a real programmer, and I’ve only recently started to subscribe to the
> mailing list)
>
>
> In practice:
>
> 1. calculate average block size for the previous difficulty period (is it
> 2016-blocks?)
> 2. when trying to find a new block adjust the difficulty by adding the
> relative size difference. For instance, if i’m trying to create a block
> half (or double) the size of the average block size for the previous
> difficulty period then my difficulty will be 2x the normal one… if I’m
> trying to make one that is 30% bigger (or smaller) then the difficulty is
> 1.3 times the normal one
>
>
> Right now this would force miners to make blocks as close to 1mb as
> possible (since the block reward >> fees). But unless I’m mistaken sometime
> in the future the block size should be adjusted to maximize the fees…
>
>
> Could the concept be useful somehow?
>
> I apologize if it’s been discussed before or if it’s a stupid idea, I
> would have run it by some other people, but I’m afraid I don’t know anyone
> that have any interest in bitcoin.
>
> Regards
> /jakob
> _______________________________________________
> 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/20150814/d72f5daf/attachment.html>

2023-06-07 15:45:56 UTC

- reply

2023-06-07 15:45:53 UTC

- reply

2023-06-07 15:42:34 UTC

- reply

📅 Original date posted:2015-07-17
📝 Original message:When blocks are found under or over the 10 minute threshold, hashing
difficulty is raised or reduced dinamically to keep a balance. This
intelligent measure has avoided us having discussions and kept a balance.
The same way you can't assume how much hashpower there will be to find the
next blocks, why can't we have a
function that adapts to the transactional volume on the blockchain, one
which allows us to grow/shrink an acceptable maximum block size. We're not
putting caps on processing, why should we put a date based cap on
transactional volume per block? You can't predict the future, but you can
look at what's happened recently to correct these limits.
Such function/filter should be able to recognize real sustained growth in
transactional volume and let us adjust the maximum accepted blocksize to
allow for the organic growth that will come due to real activity from
things like distributed market-places, decentralized bitcoin based services
(and all the things the community dreams about and might be building
already), truly decentralized technological breakthroughs that geniunely
need to use the blockchain. <Going the off-chain way only leads to
centralization and personal/corporate agendas, which to me goes against the
Bitcoin ethos>
It should be able to adapt fast enough so that we don't have episodes where
people need to wait 4 hours to days for transactions to get on the
blockchain and be confirmed. I believe proposals that include "every
100,000 blocks" are out of touch with reality, the blocksize needs to adapt
the same way blockdifficulty already adapts to growth or lack of hashing
power.
I'm not a statistician/mathematician, but I'm sure if we propose the
parameters that need to be considered for a realistic blocksize that
reflects the needs of the Bitcoin network users, there's plenty of
crypto/statistician/mathematician brain power to propose such filtering
function here.
Things that could be considered:
- median number of transactions per block (between 6 to 12 hours, you
should be able to adjust to a real shopping sprint for instance, or huge
pop band/artist decides to sell concert tickets on Bitcoin)
- median fees offered per transaction (can we detect spammers)
- median blocksizes
- median size per transaction
- number of new addresses signing off transactions, number of addresses
we've already seen in the blockchain before (are these spammers creating
lots of new addresses to move around the same outputs, is there an
efficient way to detect the likelyhood of a transaction being spam? Bayes?
No clue, no mathematician)
- median velocity between which an address receives an input and sends it
to another one?
- more things I've no knowledge of since I'm not familiar with the details,
but could immediatly come to mind to the experts.
Mining Centralization is already happening due to its competitive nature,
we don't complain or try to force hashing limits, we shouldn't do the same
for storage. There will be no shortage of blockchain mirrors, and those
interested in running full nodes, will surely find a way to do so.
Angel
http://twitter.com/gubatron
On Fri, Jul 17, 2015 at 4:29 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Friday, July 17, 2015 3:55:19 PM Jeff Garzik via bitcoin-dev wrote:
> > BIP PR: https://github.com/bitcoin/bips/pull/173
>
> I'm concerned that miners are prematurely bumping their soft limit to 1 MB
> lately. The only reason block size limit lifting is remotely reasonable is
> if
> we can trust miners to at the very least keep their soft limits set at a
> manageable size, but this assumption appears to already be failing in
> practice.
>
> 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.
>
> If we can get some kind of commitment from miners not to move their soft
> limits beyond 1 MB until some future-agreed-on point, maybe the BIP is
> acceptable as-is.
>
> On Friday, July 17, 2015 4:12:05 PM Tier Nolan via bitcoin-dev wrote:
> > It establishes a precedent for hard forks not to require a vote though.
>
> Hardforks are not something where voting makes sense. They need consensus
> among /nodes/, not majority among /miners/. No hardfork has ever had such a
> vote.
>
> Luke
> _______________________________________________
> 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/20150717/7415d690/attachment.html>

2023-06-07 15:33:20 UTC

- reply

📅 Original date posted:2015-05-13
📝 Original message:> 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?
Then what's the point?
Isn't this supposed to be an Open transactional network, it doesn't matter
if you don't want that, what matters is what people want to do with it, and
there's nothing you can do to stop someone from opening a wallet and buying
a pizza with it, except the core of the problem you ask yourself about,
which is, the minute this goes mainstream and people get their wallets out
the whole thing will collapse, regardless of what you want the blockchain
for.
Why talk about the billions of unbanked and all the romantic vision if you
can't let them use their money however they want in a decentralized
fashion. Otherwise let's just go back to centralized banking because the
minute you want to put things off chain, you need an organization that will
need to respond to government regulation and that's the end for the
billions of unbanked to be part of the network.
http://twitter.com/gubatron
On Wed, May 13, 2015 at 6:37 AM, Oliver Egginger <bitcoin at olivere.de> wrote:
> 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
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> 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/20150513/4b199524/attachment.html>

2023-06-07 15:29:07 UTC

- reply

📅 Original date posted:2015-01-30
📝 Original message:On the Chinese "Single's Day" (sort of like the american Black Friday)
according to MIT's Tech Review
<http://www.technologyreview.com/news/534001/alipay-leads-a-digital-finance-revolution-in-china/>
magazine
"Alipay handled up to 2.85 million transactions per minute, and 54 percent
of its transactions are made via mobile device."
For a few weeks I've been reading the conversations about block sizes and
the experiments being done on the subject with larger blocks.
On the day with the most transactions, the Bitcoin block chain averages
about 73 transactions per minute. I kept wondering what blocksize we'd need
for handling 100,000 transactions per minute, and estimated that roughly
we'd need a blocksize of about 1300x times larger than what we have now, so
bigger than 1Gb block... but seeing the numbers Alipay gets to handle just
in China make me wonder how scalable is Bitcoin if it were to truly compete
with worldwide financial services.
If you were to include double the number Alipay can handle, you'd be
shooting about 6 million transactions per minute, or roughly 60 million
transactions per block.
If you average every transaction around 250 bytes, then you'd need ~15
Gigabytes per block to be broadcast and hashed by all the full nodes every
10 minutes, eating good 2Tb of storage daily... do miners have enough
bandwidth and CPU power to handle this?
are my scalability concerns absurd?
http://twitter.com/gubatron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150131/3b354179/attachment.html>

2023-06-07 15:28:45 UTC

- reply

📅 Original date posted:2015-01-28
📝 Original message:why not allow both serializations and keep serialization format a
parameter, keep everyone happy.
http://twitter.com/gubatron
On Wed, Jan 28, 2015 at 12:14 PM, Mike Hearn <mike at plan99.net> wrote:
> I think we'll just have to agree to disagree on this one. I've implemented
> BIP70 a couple of times now and didn't find it to be difficult. I know you
> had odd problems with the C# protobuf implementation you were using but
> library bugs can happen for any kind of programming.
>
> I forgot to mention the other reason it's done this way. One of the
> driving goals of BIP70 was to support the TREZOR and similar devices. For
> hardware wallets, it's critical to keep the amount of code they need to run
> as small as possible. Any bugs in the code there can cause security holes
> and lead to the device being hacked.
>
> Doing it the way you suggest would mean the secure code would have to
> contain complex and bug-prone text parsing logic as well as a full blown
> HTTP and SSL stack, that requires not only X.509 handling but also lots of
> other stuff on top. It'd increase cost, complexity and decrease security
> quite a bit.
>
> Whilst I appreciate if your platform provides a scripting-like API and
> nothing low level it might seem easier to use JSON+HTTPS, that isn't the
> case for one of the primary design targets.
>
>
>
> On Wed, Jan 28, 2015 at 6:04 PM, Nicolas Dorier <nicolas.dorier at gmail.com>
> wrote:
>
>> Mike, I am not denying it is impossible to do all of that.
>> Just that it is not a trivial stuff to do to make it works everywhere,
>> and I think that it is not a good thing for a client side technology.
>> BIP70 has its use, and I understand why there is case where it is good to
>> ship the certs in the message and not depends on the transport.
>>
>> But a standard that just use JSON and HTTPS, even if less flexible that
>> BIP70, would make it easier and sufficient for today's use case.
>>
>> On Wed, Jan 28, 2015 at 5:55 PM, Mike Hearn <mike at plan99.net> wrote:
>>
>>> My point is not that there is a limitation in BIP70. My point is that
>>>> you put the burden of certificate verification on developer's shoulder when
>>>> we can just leverage built in HTTPS support of the platform.
>>>>
>>>
>>> Platforms that support HTTPS but not certificate handling are rare - I
>>> know HTML5 is such a platform but such apps are inherently dependent on the
>>> server anyway and the server can just do the parsing and validation work
>>> itself. If WinRT is such a platform, OK, too bad.
>>>
>>> The embedding of the certificates is not arbitrary or pointless, by the
>>> way. It's there for a very good reason - it makes the signed payment
>>> request verifiable by third parties. Effectively you can store the signed
>>> message and present it later to someone else, it's undeniable. Combined
>>> with the transactions and merkle branches linking them to the block chain,
>>> what you have is a form of digital receipt ... a proof of purchase that can
>>> be automatically verified as legitimate. This has all kinds of use cases.
>>>
>>> Because of how HTTPS works, you can't easily prove to a third party that
>>> a server gave you a piece of data. Doing so requires staggeringly complex
>>> hacks (see tls notary) and when we designed BIP70, those hacks didn't even
>>> exist. So we'd lose the benefit of having a digitally signed request.
>>>
>>> Additionally, doing things this way means BIP70 requests can be signed
>>> by things which are not HTTPS servers. For example you can sign with an
>>> email address cert, an EV certificate i.e. a company, a certificate issued
>>> by some user forum, whatever else we end up wanting. Not every payment
>>> recipient can be identified by a domain name + dynamic session.
>>>
>>>
>>>> However, if you want to use your plateform's store, then you are toasted
>>>>
>>>
>>> That's a bit melodramatic. BitcoinJ is able to use the Android, JRE,
>>> Windows and Mac certificate stores all using the same code or very minor
>>> variants on it (e.g. on Mac you have to specify you want the system store
>>> but it's a one-liner).
>>>
>>> Yes, that's not *every* platform. Some will require custom binding glue
>>> and it depends what abstractions and languages you are using.
>>>
>>>
>>>> Have you tried to do that on windows RT and IOS ? I tried, and I
>>>> quickly stopped doing that since it is not worth the effort. (Frankly I am
>>>> not even sure you can on win rt, since the API is a stripped down version
>>>> of windows)
>>>>
>>>
>>> There is code to do iOS using the Apple APIs here:
>>>
>>>
>>> https://github.com/voisine/breadwallet/blob/master/BreadWallet/BRPaymentProtocol.m#L391
>>>
>>>
>>>> Why have you not heard about the problem ? (until now, because I have
>>>> this problem because I need to have the same codebase on
>>>> winrt/win/android/ios/tablets)
>>>>
>>>
>>> WinRT is a minority platform in the extreme, and all the other platforms
>>> you mentioned have the necessary APIs. Java abstracts you from them. So I
>>> think you are encountering this problem because you desire to target WinRT
>>> and other platforms with a single codebase. That's an unusual constraint.
>>>
>>> AFAIK the only other people who encountered this are BitPay, because
>>> they want to do everything in Javascript which doesn't really provide any
>>> major APIs.
>>>
>>>
>>>> Also, you bundle mozilla's store in bitcoinj, what happen when the
>>>> store change and your customer have not intent to use bitcoinj new version
>>>> ? by leveraging the plateform you benefit from automatic updates.
>>>>
>>>
>>> Yes, there are pros and cons to bundling a custom root store.
>>>
>>>
>>>> Also, does java stores deals with certificate revocations ? sure you
>>>> can theorically code that too... or just let the plateform deals with it.
>>>>
>>>
>>> It can do OCSP checks, yes, although I believe no wallets currently do
>>> so. A better solution would be to implement an OCSP stapling extension to
>>> BIP70 though.
>>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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/20150128/42f6b20a/attachment.html>

2023-06-07 15:25:32 UTC

- reply

📅 Original date posted:2014-08-23
📝 Original message:I think this is the only project where people are concerened wether commit
messages are signed or not.
Commit messages should be merged only upon their correctness, not their
signature.
I could care less if I receive a buggy patch that's signed.
http://twitter.com/gubatron
On Sat, Aug 23, 2014 at 2:17 AM, Troy Benjegerdes <hozer at hozed.org> wrote:
> On Fri, Aug 22, 2014 at 09:20:11PM +0200, xor wrote:
> > On Tuesday, August 19, 2014 08:02:37 AM Jeff Garzik wrote:
> > > It would be nice if the issues and git repo for Bitcoin Core were not
> > > on such a centralized service as github, nice and convenient as it is.
> >
> > Assuming there is a problem with that usually is caused by using Git the
> wrong
> > way or not knowing its capabilities. Nobody can modify / insert a commit
> > before a GnuPG signed commit / tag without breaking the signature.
> > More detail at the bottom at [1], I am sparing you this here because I
> suspect
> > you already know it and there is something more important I want to
> stress:
> >
> > Bitcoin has currently 4132 forks on Github. This means that you can get
> > contributions by pull requests from 4132 developers. That is a HUGE
> amount,
> > and you shouldn't ditch that due to not using all features of git :)
> > To get a grasp of how much that is: When you search projects with more
> than
> > 4100 forks, there are only 32 of them!
> > You are one of the top open source projects, and you should be grateful
> for
> > that and keep Github up so the other people can send you pull requests
> with
> > their improvements :) Volunteer contributions need to be honored and
> made as
> > easy as possible, for people are investing their personal time.
> >
> > Greetings and thanks for your work,
> > xor, one developer of https://freenetproject.org
> >
> >
> > [1] If you GPG-sign a commit / tag, you sign its hash, including the
> hash of
> > the previous commit. So is a chain of hashes and thus of trust from all
> > commits up to what is signed. It's pretty similar to the blockchain
> actually
> > :)
> > So Github cannot modify anything. If they did, the head of the
> hash-chain
> > would change, and thus the signature would break. Git would notify people
> > about that when they pull.
> > Of course people can still ignore that warning and let Github rewrite
> their
> > Git history. But people who aren't educated about this shouldn't be
> release
> > managers. They should not even have push access to your main repository,
> they
> > should only be sending pull requests. Thats is where the
> decentralization of
> > Git is: In the pull-requests. The people who deal with them should
> verify tag
> > and possibly even commit signatures carefully, and not accept anything
> which
> > is not signed. Also, before deploying a binary, the very same commit
> which is
> > going to become a binary has to be given a signed tag by the release
> manager,
> > and by everyone who reviews the code. The person who deploys the actual
> binary
> > needs to verify that signature.
> > There is an article which elaborates on some of the ways you have to
> ensure
> > Github doesn't insert malicious code - but please read it with care,
> some of
> > its recommendations are bad, especially the part where its about rebasing
> > because that DOES rewrite history which is what you want to prevent:
> > http://mikegerwitz.com/papers/git-horror-story
> >
> >
>
>
> This is why I clone git to mercurial, which is generally designed around
> the
> assumption that history is immutable. You can't rewrite blockchain history,
> and we should not be re-writing (rebasing) commit history either.
>
> The problem with github is it's too tempting to look at the *web page*,
> which
> is NOT pgp-signed, and hit the 'approve' button when you might have someone
> in the middle approving an unsigned changeset because you're in a hurry to
> get the latest new critical OpenSSL 0day security patch build released.
>
> We need multiple redundant 'master' repositories run by different people in
> different jurisdictions that get updated on different schedules, and have
> all
> of these people pay attention to operational security, and not just
> outsource
> it all to github because it's convenient.
>
>
> There's no reason to *stop* using github, cause it *is* easy... but you
> want
> to have multiple review of *the actual code*, not just signatures and see
> if the changes really do make sense.
>
> --
>
> ----------------------------------------------------------------------------
> Troy Benjegerdes 'da hozer'
> hozer at hozed.org
> 7 elements earth::water::air::fire::mind::spirit::soul
> grid.coop
>
> Never pick a fight with someone who buys ink by the barrel,
> nor try buy a hacker who makes money by the megahash
>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> 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/20140823/03d92c0a/attachment.html>

2023-06-07 15:25:31 UTC

- reply

📅 Original date posted:2014-08-22
📝 Original message:+1000. Don't fix it if it ain't broken. Don't kill community support. I for
instance wouldn't have contributed or forked if the project hadn't been on
github.
"Bitcoin has currently 4132 forks on Github. This means that you can get
contributions by pull requests from 4132 developers. That is a HUGE amount,
and you shouldn't ditch that due to not using all features of git :)
To get a grasp of how much that is: When you search projects with more than
4100 forks, there are only 32 of them!
You are one of the top open source projects, and you should be grateful for
that and keep Github up so the other people can send you pull requests with
their improvements :) Volunteer contributions need to be honored and made as
easy as possible, for people are investing their personal time.
Greetings and thanks for your work,
xor, one developer of https://freenetproject.org"
http://twitter.com/gubatron
On Fri, Aug 22, 2014 at 3:20 PM, xor <xor at freenetproject.org> wrote:
> On Tuesday, August 19, 2014 08:02:37 AM Jeff Garzik wrote:
> > It would be nice if the issues and git repo for Bitcoin Core were not
> > on such a centralized service as github, nice and convenient as it is.
>
> Assuming there is a problem with that usually is caused by using Git the
> wrong
> way or not knowing its capabilities. Nobody can modify / insert a commit
> before a GnuPG signed commit / tag without breaking the signature.
> More detail at the bottom at [1], I am sparing you this here because I
> suspect
> you already know it and there is something more important I want to stress:
>
> Bitcoin has currently 4132 forks on Github. This means that you can get
> contributions by pull requests from 4132 developers. That is a HUGE amount,
> and you shouldn't ditch that due to not using all features of git :)
> To get a grasp of how much that is: When you search projects with more than
> 4100 forks, there are only 32 of them!
> You are one of the top open source projects, and you should be grateful for
> that and keep Github up so the other people can send you pull requests with
> their improvements :) Volunteer contributions need to be honored and made
> as
> easy as possible, for people are investing their personal time.
>
> Greetings and thanks for your work,
> xor, one developer of https://freenetproject.org
>
>
> [1] If you GPG-sign a commit / tag, you sign its hash, including the hash
> of
> the previous commit. So is a chain of hashes and thus of trust from all
> commits up to what is signed. It's pretty similar to the blockchain
> actually
> :)
> So Github cannot modify anything. If they did, the head of the hash-chain
> would change, and thus the signature would break. Git would notify people
> about that when they pull.
> Of course people can still ignore that warning and let Github rewrite their
> Git history. But people who aren't educated about this shouldn't be release
> managers. They should not even have push access to your main repository,
> they
> should only be sending pull requests. Thats is where the decentralization
> of
> Git is: In the pull-requests. The people who deal with them should verify
> tag
> and possibly even commit signatures carefully, and not accept anything
> which
> is not signed. Also, before deploying a binary, the very same commit which
> is
> going to become a binary has to be given a signed tag by the release
> manager,
> and by everyone who reviews the code. The person who deploys the actual
> binary
> needs to verify that signature.
> There is an article which elaborates on some of the ways you have to ensure
> Github doesn't insert malicious code - but please read it with care, some
> of
> its recommendations are bad, especially the part where its about rebasing
> because that DOES rewrite history which is what you want to prevent:
> http://mikegerwitz.com/papers/git-horror-story
>
>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> 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/20140822/b5746cb2/attachment.html>

2023-06-07 15:25:30 UTC

- reply

📅 Original date posted:2014-08-19
📝 Original message:-1
http://twitter.com/gubatron
On Tue, Aug 19, 2014 at 11:44 AM, Bryan Bishop <kanzure at gmail.com> wrote:
> On Tue, Aug 19, 2014 at 7:02 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> > As a first step, one possibility is putting the primary repo on
> > bitcoin.org somewhere, and simply mirroring that to github for each
> > push.
>
> Smaller first step would be to mirror the git repository on
> bitcoin.org, which is necessary anyway before switching primaries.
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/20140819/118a53b7/attachment.html>