Angel Leon [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-03-19 to 2020-01-16
💬 Posted a total of 33 messages
📚 Participated in the following categories: Bitcoin-development, QT, Libbitcoin, bitcoin-dev, 104
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:22:27

- 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:54:58

- reply

📅 Original date posted:2016-12-15
📝 Original message:Perhaps if there were a message that would nag your stdout or log output
letting you know there's a new version available, or N more versions
available and that you might be missing out on X security patches, Y
protocol improvements, depending on how far back you are, you'd be tempted
to upgrade, works for me in Ubuntu every time I log to my servers and I see
how far behind I am in terms of available updates.
Other thing done in open source projects to encourage updates, is to
automatically distribute (download) the patches and let the node operator
know an update has been downloaded for them, and let them know they're just
one step away from applying such update.
We do this for our bittorrent client. We don't ever want to do automatic
upgrades of our network, however, we want to make it painless to update.
For Bitcoin this could be done for the official binary distribution, would
not be an option for those that build from source.
On Thu, Dec 15, 2016 at 11:49 AM Jorge Timón via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Older node versions may generate issues because some upgrades will make
> > several of the nodes running older protocol versions obsolete and or
> > incompatible. There may be other hard to predict behaviors on older
> versions
> > of the client.
>
> Hard to predict or not, you can't force people to run newer software.
>
> > In order to avoid such wide fragmentation of "Bitcoin Core” node versions
> > and to help there be a more predictable protocol improvement process, I
> > consider it worth it to analyze introducing some planned obsolescence in
> > each new version. In the last year we had 4 new versions so if each
> version
> > is valid for about 1 year (52560 blocks) this may be a reasonable time
> frame
> > for node operators to upgrade. If a node does not upgrade it will stop
> > working instead of participating in the network with an outdated protocol
> > version.
>
> When you introduce anti-features like this in free software they can
> be trivially removed and they likely will.
>
> > These changes may also simplify the developer's jobs in some cases by
> > avoiding them having to deal with ancient versions of the client.
>
> There's a simpler solution for this which is what is being done now:
> stop maintaining and giving support for older versions.
> There's limited resources and developers are rarely interested in
> fixing bugs for very old versions. Users shouldn't expect things to be
> backported to old versions (if developers do it and there's enough
> testing, there's no reason not to do more releases of old versions, it
> is just rarely the case).
> _______________________________________________
> 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/20161215/9eb2ae06/attachment.html>

2023-06-07 17:44:47

- reply

📅 Original date posted:2015-11-13
📝 Original message:I believe in the end it's the usability of bitcoin that matters.
For instance, a goal could be that no user on the network should wait more
than an hour to get 3 confirmations on the blockchain so that they can
actually have useful Bitcoins.
We can debate all we want about lots of technical aspects, but if you can't
send money what's the point?
My humble proposal tried to take that into consideration, but I like way
way more what you propose with NG.
http://twitter.com/gubatron
On Fri, Nov 13, 2015 at 11:37 AM, Emin Gün Sirer <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> By now, we have seen quite a few proposals for the block size increase.
> It's hard not to notice that there are potentially infinitely many
> functions for future block size increases. One could, for instance, double
> every N years for any rational number N, one could increase linearly, one
> could double initially then increase linearly, one could ask the miners to
> vote on the size, one could couple the block size increase to halvings,
> etc. Without judging any of these proposals on the table, one can see that
> there are countless alternative functions one could imagine creating.
>
> I'd like to ask a question that is one notch higher: Can we enunciate what
> grand goals a truly perfect function would achieve? That is, if we could
> look into the future and know all the improvements to come in network
> access technologies, see the expansion of the Bitcoin network across the
> globe, and precisely know the placement and provisioning of all future
> nodes, what metrics would we care about as we craft a function to fit what
> is to come?
>
> To be clear, I'd like to avoid discussing any specific block size increase
> function. That's very much the tangible (non-meta) block size debate, and
> everyone has their opinion and best good-faith attempt at what that
> function should look like. I've purposefully stayed out of that issue,
> because there are too many options and no metrics for evaluating proposals.
>
> Instead, I'm asking to see if there is some agreement on how to evaluate a
> good proposal. So, the meta-question: if we were looking at the best
> possible function, how would we know? If we have N BIPs to choose from,
> what criteria do we look for?
>
> To illustrate, a possible meta goal might be: "increase the block size,
> while ensuring that large miners never have an advantage over small miners
> that [they did not have in the preceding 6 months, in 2012, pick your time
> frame, or else specify the advantage in an absolute fashion]." Or "increase
> block size as much as possible, subject to the constraint that 90% of the
> nodes on the network are no more than 1 minute behind one of the tails of
> the blockchain 99% of the time." Or "do not increase the blocksize until at
> least date X." Or "the increase function should be monotonic." And it's
> quite OK (and probably likely) to have a combination of these kinds of
> metrics and constraints.
>
> For disclosure, I personally do not have a horse in the block size debate,
> besides wanting to see Bitcoin evolve and get more widely adopted. I ask
> because as an academic, I'd like to understand if we can use various
> simulation and analytic techniques to examine the proposals. A second
> reason is that it is very easy to have a proliferation of block size
> increase proposals, and good engineering would ask that we define the
> meta-criteria first and then pick. To do that, we need some criteria for
> judging proposals other than gut feeling.
>
> Of course, even with meta-criteria in hand, there will be room for lots of
> disagreement because we do not actually know the future and reasonable
> people can disagree on how things will evolve. I think this is good because
> it makes it easier to agree on meta-criteria than on an actual, specific
> function for increasing the block size.
>
> It looks like some specific meta-level criteria would help more at this
> point than new proposals all exploring a different variants of block size
> increase schedules.
>
> Best,
>
> - egs
>
>
> P.S. This message is an off-shoot of this blog post:
>
>
> http://hackingdistributed.com/2015/11/13/suggestion-for-the-blocksize-debate/
>
>
>
>
> _______________________________________________
> 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/20151113/4b303813/attachment-0001.html>

2023-06-07 17:40:24

- reply

📅 Original date posted:2015-09-15
📝 Original message:might want to specify there that the rate being sent is out of USD.
http://twitter.com/gubatron
On Tue, Sep 15, 2015 at 7:10 AM, John Bailon via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello,
>
> I'd like to propose a BIP for a standard URI scheme to allow wallet
> operators that implement instant exchange or pegging to other currencies,
> cryptocurrencies or asset classes to allow for interoperable communications
> of rates and other pertinent information.
>
> The idea is to include in the wallet address as parameters information
> that supplements the presentation of a proposed transaction.
>
> For example, a wallet operator that instantly exchanges bitcoin to gold
> would present a wallet address as follows:
>
> bitcoin:1JohnxNT6jRzhu3H1wgVFbSGKmHP4EUjUV?currency=xau&rate=0.2084&expires=1458432000
>
> Wherein:
> <currency> : the currency, cryptocurrency or asset that the transaction
> will end up as encoded in ISO 4217 if applicable.
> <rate> : the bitcoin to <currency> rate as dictated by receiving wallet
> <expires> : unix timestamp of when the rate loses validity
>
> This would allow the sending wallet the ability to present up-to-date
> exchange rates. When, for example, a wallet operator that pegs to the USD
> scans the address above, it would be able to present to the user the
> following information:
>
> 1. USD to XAU rate
> 2. How much XAU will be received by the address
> 3. How long before the rates expires
>
>
> Thoughts?
>
>
> Regards,
> John
>
> _______________________________________________
> 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/20150915/246bc9b0/attachment.html>

2023-06-07 17:36:19

- 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 15:48:06

- reply

📅 Original date posted:2015-08-17
📝 Original message:so you want us to, (i) at the moment of payment decide wether to pay a tx
fee, or to include some data about what the transaction is about...
(ii) and (iii) are out of the question as you'd be forcing people to not
have privacy, which is one of the main reasons people use bitcoin, just
paying like cash.
then the rest goes down hill.
1. You want to add more data to a transaction, which would fill blocks even
faster.
2. The data will be on the blockchain, why in hell would anybody pay the
miners for it when you can just mine it yourself, or pay XYZ online service
to give you the tools you mention, and why would XYZ company pay miners for
the revenues of such service?
because... you want to change the Bitcoin license from MIT to something
else?
I'm sorry. this is dead on arrival, very unrealistic. Perhaps this will
work for some other coin where people accept all these orwellianism from
the start.
If you think there's much debate about blocksize you've no idea how things
would get at the mention of moving away from MIT into some sort of
commercial license, that would indeed destroy Bitcoin from being adopted as
it would enter into many many conflicts that would render it unusable by
lots of organizations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/93b533aa/attachment.html>

2023-06-07 15:48:05

- reply

📅 Original date posted:2015-08-17
📝 Original message:>"By increasing the size of blocks, transaction fees may not be available
to supplement mining revenue and so those who do not have access to cheap
or free power to mine;"
why?
wouldn't a bigger block size actually allow for more transactions per
block, therefore more fees to be collected, and the cost spread out among
many more users (thus still keeping tx fees low). If anything, wouldn't
bigger blocksizes are needed to suplement the losses of coinbase rewards
being halfed.
http://twitter.com/gubatron
On Mon, Aug 17, 2015 at 12:39 PM, Ahmed Zsales via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello,
>
> Here we propose a long-term solution to replace mining rewards and
> transactions fees.
>
> BIP [104] is currently a discussion draft only.
>
>
> https://drive.google.com/file/d/0BwEbhrQ4ELzBSXpoUjRkc01QUGc/view?usp=sharing
>
> Views and feedback welcome.
>
> Regards,
>
> Ahmed
>
> _______________________________________________
> 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/026f94fa/attachment.html>

2023-06-07 15:45:53

- 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:33:20

- 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

- 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

- 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:31

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

- reply

📅 Original date posted:2014-08-19
📝 Original message:"I suggest that Bitcoin Core should generate a public/private key pair and
share the public one with peers."
I've not read the p2p protocol of Bitcoin core, but I suppose the initial
handshake between 2 peers would be the ideal place to exchange a public
keys.
would it make sense to generate a new random pair of keys per each peer you
connect to?
then each subsequent message to every peer gets encrypted differently,
keeping each conversation isolated from each other encryption-speaking.
These keys would have nothing to do with your wallet, they're just to
encrypt any further communication between peers post-handshake. Would that
be of any use to "This could provide privacy and integrity but not
autentication."?
http://twitter.com/gubatron
On Tue, Aug 19, 2014 at 12:38 PM, Gregory Maxwell <gmaxwell at gmail.com>
wrote:
> On Tue, Aug 19, 2014 at 9:07 AM, Justus Ranvier
> <justusranvier at riseup.net> wrote:
> > If that's not acceptable, even using TLS with self-signed certificates
> > would be an improvement.
>
> TLS is a huge complex attack surface, any use of it requires an
> additional dependency with a large amount of difficult to audit code.
> TLS is trivially DOS attacked and every major/widely used TLS
> implementation has had multiple memory disclosure or remote execution
> vulnerabilities even in just the last several years.
>
> We've dodged several emergency scale vulnerabilities by not having TLS.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/5903b960/attachment.html>