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