Troy Benjegerdes [ARCHIVE]

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

Public Key

npub1m6p5kgcd428x6pxyfege98zjmlwrdhp0gyz6pdnsvrvalscddnxqurdjn5

Profile Code

nprofile1qqsdaq6tyvx64rndqnzyu5vjn3fdlhpkmsh5zpdqkecxpkwlcvxkenqprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmddqajq8

Publishing to

relay.noswhere.com

Author Public Key

npub1m6p5kgcd428x6pxyfege98zjmlwrdhp0gyz6pdnsvrvalscddnxqurdjn5

Show more details

Last Notes

2023-06-07 17:59:42

- reply

📅 Original date posted:2017-04-08
📝 Original message:I would advise anyone worried about 'hard drive access' to order a
512GB NVME (pci-express interface) flash drive (or a laptop), and
I expect the performance will make you wonder why you ever bothered
with cloud.
My (very brief) analysis of the performance of a full chain download
on a new laptop was that there was more overhead in lock contention and
database writes and it barely loaded the machine. Now maybe this is
because the flash **write** speed is slow (but still several orders
of magnitude above spinning disk), but random reads are sure blazing
fast.
Flash storage sizes also appear to be growing at similiar rates as the
total blockchain size.
Which begs another question: In a distributed byzantine fault-tolerant
system, why do we even need to bother with persistant storage, except
for long-term archival and chain of custody issues, which we could
serialize the in-memory structures out as a stream to things like tape
drives or write-once optical media.
On Fri, Apr 07, 2017 at 11:39:18AM -0700, Bram Cohen via bitcoin-dev wrote:
> Expanding on this question a bit, it's optimized for parallel access, but
> hard drive access isn't parallel and memory accesses are very fast, so
> shouldn't the target of optimization be about cramming as much as possible
> in memory and minimizing disk accesses?
>
> On Fri, Apr 7, 2017 at 11:18 AM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > On Thu, Apr 6, 2017 at 10:12 PM, Tomas via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > >As this
> > > solution, reversing the costs of outputs and inputs, seems to have
> > > excellent performance characteristics (as shown in the test results),
> > > updates to the protocol addressing the UTXO growth, might not be worth
> > > considering *protocol improvements*
> >
> > I'm still lost on this-- AFAICT your proposals long term resource
> > requirements are directly proportional to the amount of unspent output
> > data, which grows over time at some fraction of the total transaction
> > volume (plus the rate of spending which is more or less a constant).
> >
> > Can you help out my understanding here?
> > _______________________________________________
> > 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

2023-06-07 15:37:11

- reply

📅 Original date posted:2015-06-10
📝 Original message:I think if the consensus is "pay with commits or pay with bitcoin"
we might have a consensus from the people that actually matter very
quickly, because they've already paid ;)
My opinion is the most sustainable solution would be to identify a
team of admins and use something like Digital Ocean's new team accounts
feature and have someone like SolidX contribute funds for the servers
and a few hours a week from one of their sysadmins to the team.
I am dubious of most commercial list-as-a-service providers for the same
reason I am dubious of sourceforge. Market conditions change and then all
of a sudden the fact you're in control of a popular list becomes more
valuable than what your customer is paying you to run the list.
If the list provider can actively help out in encouraging read-only mirrors
of the list archives, then I think we mitigate the above business risk.
On Wed, Jun 10, 2015 at 02:28:55PM -0400, Ivan Brightly wrote:
> I like elegant solutions and while eventually I can see a "pay to
> contribute" service, I don't imagine you'll get consensus in short order.
>
> List provider costs are pretty reasonable, so if that's the hurdle to
> overcome I'm happy to offer sponsorship.
>
> Ivan Brightly
> SolidX Partners
>
> On Wed, Jun 10, 2015 at 12:46 PM, Andy Schroder <info at andyschroder.com>
> wrote:
>
> > Regarding changing the e-mail list provider. Is anyone interested in
> > sponsoring it? There are non-free options, but it may be difficult to
> > always ensure the fee is being paid to the provider. I think finding an
> > agreeable free solution may have been the issue before? I've also
> > thought of trying to make a pay per message or byte solution (and this
> > cost could be dynamic based upon the number of current mailing list
> > subscribers). This could solve the who pays problem (the sender pays),
> > as well as motivate people to be more concise and clear with their
> > messages, and at the same time limit spam.
> >
> >
> >
> > Any thoughts?
> >
> > Andy Schroder
> >
> > On 06/10/2015 05:35 AM, Wladimir J. van der Laan wrote:
> > > On Wed, Jun 10, 2015 at 10:25:12AM +0200, xor wrote:
> > >>
> > http://www.howtogeek.com/218764/warning-don%E2%80%99t-download-software-from-sourceforge-if-you-can-help-it/
> > > All our downloads (even old ones) have recently been deleted from
> > sourceforge, for this reason. They haven't been mentioned in Bitcon Core
> > release announcements for a long time.
> > >
> > > No opinion on the mailing list. Though I think it's less urgent. The
> > issue of moving the mailinglist has come up before a few times and people
> > can't agree where to move to.
> > >
> > > Wladimir
> > >
> > >
> > >
> > ------------------------------------------------------------------------------
> >
> >
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
----------------------------------------------------------------------------
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

2023-06-07 15:37:11

- reply

📅 Original date posted:2015-06-10
📝 Original message:I'll sponsor it, if we agree to implement a HashCash spam filter
in the next 6 months. I've run mail servers for $DAYJOB for 5 or
so years, and I've run my own personal server for the last 14.
Since Bitcoin is a perfectly good HashCash system, I'm thinking a
http://www.courier-mta.org/courierfilter.html filter plugin that
checks to ensure that the required bitcoin fee has been paid, or
better yet included in the message in some standard form.
I'd like to have several other people with linux admin experience
also agree to host live mirrors of the list, which could be switched
over by whomever controls the relevant MX records for the mail list.
What do you think a reasonable per-message fee should be, such that
a couple of independent admins can reasonably expect to be able to
pay $250/month each for their time and server hosting/bandwidth costs?
I also think that anyone who's contributed more than say 10 or 15
commits to https://github.com/bitcoin/bitcoin/graphs/contributors
should be excluded from the pay-with-bitcoin filter, as they have
paid with code. The rest of us should be paying to distribute and
archive their efforts.
On Wed, Jun 10, 2015 at 12:46:49PM -0400, Andy Schroder wrote:
> Regarding changing the e-mail list provider. Is anyone interested in
> sponsoring it? There are non-free options, but it may be difficult to
> always ensure the fee is being paid to the provider. I think finding an
> agreeable free solution may have been the issue before? I've also
> thought of trying to make a pay per message or byte solution (and this
> cost could be dynamic based upon the number of current mailing list
> subscribers). This could solve the who pays problem (the sender pays),
> as well as motivate people to be more concise and clear with their
> messages, and at the same time limit spam.
>
>
>
> Any thoughts?
>
> Andy Schroder
>
> On 06/10/2015 05:35 AM, Wladimir J. van der Laan wrote:
> > On Wed, Jun 10, 2015 at 10:25:12AM +0200, xor wrote:
> >> http://www.howtogeek.com/218764/warning-don%E2%80%99t-download-software-from-sourceforge-if-you-can-help-it/
> > All our downloads (even old ones) have recently been deleted from sourceforge, for this reason. They haven't been mentioned in Bitcon Core release announcements for a long time.
> >
> > No opinion on the mailing list. Though I think it's less urgent. The issue of moving the mailinglist has come up before a few times and people can't agree where to move to.
> >
> > Wladimir
> >
> >
> > ------------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
----------------------------------------------------------------------------
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

2023-06-07 15:31:40

- reply

📅 Original date posted:2015-03-01
📝 Original message:So let's play this out a little.. Let's call it "Solomon's spend[1]"
Exchange gets hacked, bitcoins move.
The exchange has a contract with an insurance company and miners for
'scorched earth' theft response that creates a double-spend of the
original transaction.
So now there's a 10,000 bitcoin incentive for miners to roll back the
chain and start (re)mining the block where the theft occurred.
The exchange gets an insurance payout, some miner wins the lottery, and
the thief gets nothing. Seems like a good deal, what am I missing?
[1] http://en.wikipedia.org/wiki/Judgment_of_Solomon
On Sun, Feb 22, 2015 at 04:06:13AM -0800, Eric Lombrozo wrote:
> I should note that my proposal does require a change to the consensus
> rules...but getting bitcoin to scale will require this no matter what.
>
> - Eric Lombrozo
> On Feb 22, 2015 3:41 AM, "Eric Lombrozo" <elombrozo at gmail.com> wrote:
>
> > It seems to me we're confusing two completely different motivations for
> > double-spending. One is the ability to replace a fee, the other is the
> > ability to replace outputs.
> >
> > If the double-spend were to merely add or remove inputs (but keep at least
> > one input in common, of course), it seems fairly safe to assume it's the
> > former, a genuine fee replacement. Even allowing for things like coinjoin,
> > none of the payees would really care either way.
> >
> > Conversely, if at least one of the inputs were kept but none of the
> > outputs were, we can be confident it's the the latter.
> >
> > It is possible to build a wallet that always does the former when doing
> > fee replacement by using another transaction to create an output with
> > exactly the additional desired fee.
> >
> > If we can clearly distinguish these two cases then the fee replacement
> > case can be handled by relaying both and letting miners pick one or the
> > other while the output replacement case could be handled by rewarding
> > everything to a miner (essentially all outputs are voided...made
> > unredeemable...and all inputs are added to coinbase) if the miner includes
> > the two conflicting transactions in the same block.
> >
> > Wouldn't this essentially solve the problem?
> >
> > - Eric Lombrozo
> > On Feb 21, 2015 8:09 PM, "Jeff Garzik" <jgarzik at bitpay.com> wrote:
> >
> >> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> >> > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik at bitpay.com>
> >> wrote:
> >> >> This isn't some theoretical exercise. Like it or not many use
> >> >> insecure 0-conf transactions for rapid payments. Deploying something
> >> >> that makes 0-conf transactions unusable would have a wide, negative
> >> >> impact on present day bitcoin payments, thus "scorched earth"
> >>
> >> > And maybe by maintaining first seen policies we're harming the system
> >> > in the long term by encouraging people to widely deploy systems based
> >> > on extremely weak assumptions.
> >>
> >> Lacking a coded, reviewed alternative, that's only a platitude.
> >> Widely used 0-conf payments are where we're at today. Simply ceasing
> >> the "maintaining [of] first seen policies" alone is simply not a
> >> realistic option. The negative impact to today's userbase would be
> >> huge.
> >>
> >> Instant payments need a security upgrade, yes.
> >>
> >> --
> >> Jeff Garzik
> >> Bitcoin core developer and open source evangelist
> >> BitPay, Inc. https://bitpay.com/
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> >> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> >> Get technology previously reserved for billion-dollar corporations, FREE
> >>
> >> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
----------------------------------------------------------------------------
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

2023-06-07 15:31:39

- reply

📅 Original date posted:2015-03-01
📝 Original message:Bitcoin was/is a disruptive technology for credit card payment processors,
and replace-by-fee/stag-hunt is a disruptive technology for Bitcoin payment
processors.
I think whether you call it scorched earth is a bit more of a reflection of
whether you stand to make money, or lose money from the distruption.
Personally, I think 'first-seen' is a dangerous scorched-earth policy that
only benefits the people who own the internet routers that determine what
is seen first.
But from the standpoint of consensus, can we at least agree that it's a
*node policy* decision, and the market particpants should be free to choose
whichever policy works best for them?
Otherwise, I think the only way to make 'first-seen' work is by adding
a timestamp to CTransaction.
On Sat, Feb 21, 2015 at 05:47:28PM -0500, Jeff Garzik wrote:
> "scorched earth" refers to the _real world_ impact such policies would
> have on present-day 0-conf usage within the bitcoin community.
>
> All payment processors AFAIK process transactions through some scoring
> system, then accept 0-conf transactions for payments.
>
> This isn't some theoretical exercise. Like it or not many use
> insecure 0-conf transactions for rapid payments. Deploying something
> that makes 0-conf transactions unusable would have a wide, negative
> impact on present day bitcoin payments, thus "scorched earth"
>
> Without adequate decentralized solutions for instant payments,
> deploying replace-by-fee widely would simply push instant transactions
> even more into the realm of centralized, walled-garden services.
>
>
>
>
>
>
> On Sat, Feb 21, 2015 at 3:30 PM, Mark Friedenbach <mark at friedenbach.org> wrote:
> > Thank you Jorge for the contribution of the Stag Hunt terminology. It is
> > much better than a politically charged "scorched earth".
> >
> > On Feb 21, 2015 11:10 AM, "Jorge Timón" <jtimon at jtimon.cc> wrote:
> >>
> >> I agree "scorched hearth" is a really bad name for the 0 conf protocol
> >> based on game theory. I would have preferred "stag hunt" since that's
> >> basically what it's using (see http://en.wikipedia.org/wiki/Stag_hunt)
> >> but I like the protocol and I think it would be interesting to
> >> integrate it in the payment protocol.
> >> Even if that protocol didn't existed or didn't worked, replace-by-fee
> >> is purely part of a node's policy, not part of consensus.
> >> >From the whitepaper, 0 conf transactions being secure by the good will
> >> of miners was never an assumption, and it is clear to me that the
> >> system cannot provide those guaranties based on such a weak scheme. I
> >> believe thinking otherwise is naive.
> >> As to consider non-standard policies "an attack to bitcoin" because
> >> "that's not how bitcoin used to work", then I guess minimum relay fee
> >> policies can also be considered "an attack to bitcoin" on the same
> >> grounds.
> >> Lastly, "first-seen-wins" was just a simple policy to bootstrap the
> >> system, but I expect that most nodes will eventually move to policies
> >> that are economically rational for miners such as replace-by-fee.
> >> Not only I disagree this will be "the end of bitcoin" or "will push
> >> the price of the btc miners are mining down", I believe it will be
> >> something good for bitcoin.
> >> Since this is apparently controversial I don't want to push for
> >> replace-by-fee to become the new standard policy (something that would
> >> make sense to me). But once the policy code is sufficiently modular as
> >> to support several policies I would like bitcoin core to have a
> >> CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no
> >> policy checks at all).
> >> One step at a time I guess...
> >>
> >>
> >> On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes <hozer at hozed.org> wrote:
> >> > On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote:
> >> >>
> >> >>
> >> >> On 02/15/2015 11:25 PM, Troy Benjegerdes wrote:
> >> >> >
> >> >> > Most money/payment systems include some method to reverse or undo
> >> >> > payments made in error. In these systems, the longer settlement
> >> >> > times you mention below are a feature, not a bug, and give more
> >> >> > time for a human to react to errors and system failures.
> >> >> >
> >> >>
> >> >> Settlement has to be final somewhere. That is the whole point of it.
> >> >> Transfer costs in current electronic payment systems are a direct
> >> >> consequence of their non-finality. That's the point Satoshi was making
> >> >> in the introduction to the whitepaper: "With the possibility of
> >> >> reversal, the need for trust spreads".
> >> >
> >> > The problem with that statement is I trust a merchant that I went into
> >> > a store and made a payment with personally more than I trust the
> >> > firmware
> >> > on my hard drive [1].
> >> >
> >> > The attack surface of devices in your computer is huge. A motivated
> >> > attacker
> >> > just needs to get an intern into a company that makes some kind of
> >> > component
> >> > or system that's in your computer, cloud server, hardware wallet, or
> >> > what
> >> > have you that has firmware capable of reading your private keys.
> >> >
> >> > With the possibility of mass trojaned hardware, if we are going to trust
> >> > the system, it must somehow allow reversal through a human-in-the-loop.
> >> >
> >> >> There is nothing wrong with having reversible mechanisms built on top
> >> >> of Bitcoin, and indeed it makes sense for most activity to happen at
> >> >> those higher layers. It's easy to build things that way, but
> >> >> impossible to build them the other way: you can't build a
> >> >> non-reversible layer on top of a reversible layer.
> >> >
> >> > We built 'reliable' TCP on top of unreliable ethernet networks. My
> >> > experience
> >> > with networking was if you tried to guarantee message delivery at the
> >> > lowest
> >> > level, the system got exceedingly complicated, expensive, and brittle.
> >> >
> >> > Most applications, in particular paying someone you already trust, are
> >> > quite
> >> > happy running on reversible systems, and in some cases more reliable and
> >> > lower risk. (carrying non-reversible cash is generally considered risky)
> >> >
> >> > The problem is that if the base currency is assumed to be
> >> > non-reversible,
> >> > then it's brittle and becomes 'too big to fail'.
> >> >
> >> > Where the blockchain improves on everything else is in transparency. If
> >> > you
> >> > reverse transactions a lot, it will be obvious from an analysis. I would
> >> > much
> >> > rather deal with a known, predictable, and relatively continous
> >> > transaction
> >> > reversal rate (percentage) than have to deal with sudden failures where
> >> > some anonymous bad actor makes off with a fortune.
> >> >
> >> > We already have zero-conf double-spend transaction reversal, why not
> >> > explicitly
> >> > extend that a little in a way that senders and receivers have a choice
> >> > to
> >> > use it, or not?
> >> >
> >> >
> >> > [1]
> >> > http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216
> >> >
> >> >
> >> > ------------------------------------------------------------------------------
> >> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> >> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> >> > with Interactivity, Sharing, Native Excel Exports, App Integration &
> >> > more
> >> > Get technology previously reserved for billion-dollar corporations, FREE
> >> >
> >> > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> >> > _______________________________________________
> >> > Bitcoin-development mailing list
> >> > Bitcoin-development at lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> >> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> >> Get technology previously reserved for billion-dollar corporations, FREE
> >>
> >> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> > ------------------------------------------------------------------------------
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> > with Interactivity, Sharing, Native Excel Exports, App Integration & more
> > Get technology previously reserved for billion-dollar corporations, FREE
> > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
----------------------------------------------------------------------------
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

2023-06-07 15:30:22

- reply

📅 Original date posted:2015-02-19
📝 Original message:On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote:
>
>
> On 02/15/2015 11:25 PM, Troy Benjegerdes wrote:
> >
> > Most money/payment systems include some method to reverse or undo
> > payments made in error. In these systems, the longer settlement
> > times you mention below are a feature, not a bug, and give more
> > time for a human to react to errors and system failures.
> >
>
> Settlement has to be final somewhere. That is the whole point of it.
> Transfer costs in current electronic payment systems are a direct
> consequence of their non-finality. That's the point Satoshi was making
> in the introduction to the whitepaper: "With the possibility of
> reversal, the need for trust spreads".
The problem with that statement is I trust a merchant that I went into
a store and made a payment with personally more than I trust the firmware
on my hard drive [1].
The attack surface of devices in your computer is huge. A motivated attacker
just needs to get an intern into a company that makes some kind of component
or system that's in your computer, cloud server, hardware wallet, or what
have you that has firmware capable of reading your private keys.
With the possibility of mass trojaned hardware, if we are going to trust
the system, it must somehow allow reversal through a human-in-the-loop.
> There is nothing wrong with having reversible mechanisms built on top
> of Bitcoin, and indeed it makes sense for most activity to happen at
> those higher layers. It's easy to build things that way, but
> impossible to build them the other way: you can't build a
> non-reversible layer on top of a reversible layer.
We built 'reliable' TCP on top of unreliable ethernet networks. My experience
with networking was if you tried to guarantee message delivery at the lowest
level, the system got exceedingly complicated, expensive, and brittle.
Most applications, in particular paying someone you already trust, are quite
happy running on reversible systems, and in some cases more reliable and
lower risk. (carrying non-reversible cash is generally considered risky)
The problem is that if the base currency is assumed to be non-reversible,
then it's brittle and becomes 'too big to fail'.
Where the blockchain improves on everything else is in transparency. If you
reverse transactions a lot, it will be obvious from an analysis. I would much
rather deal with a known, predictable, and relatively continous transaction
reversal rate (percentage) than have to deal with sudden failures where
some anonymous bad actor makes off with a fortune.
We already have zero-conf double-spend transaction reversal, why not explicitly
extend that a little in a way that senders and receivers have a choice to
use it, or not?
[1] http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216

2023-06-07 15:30:08

- reply

📅 Original date posted:2015-02-15
📝 Original message:On Thu, Feb 12, 2015 at 09:27:22AM +0100, Tamas Blummer wrote:
>
>
> On Feb 12, 2015, at 9:16 AM, Alex Mizrahi <alex.mizrahi at gmail.com> wrote:
> > Why don't you use getrawmempool RPC call to synchronize mempool contents?
>
>
>
> Since RPC interface does not scale to serve a multi user service.
> In absence of better alternative, the interfaces used by a proprietary extension are usually the same as in P2P consensus.
>
> POW is used to figure the longest chain and until now broadcasted transactions were assumed the one and only.
> These simple rules ensure a consensus between the proprietary stack and the border router, and that is the consensus I referred to.
>
If a proprietary stack has problems with replace-by-fee then it's probably
succeptible to malicious attack because an attacker could just broadcast
one transaction to the network and then replace it when they are able to
mine a block themselves.
>
> On Feb 12, 2015, at 8:45 AM, Peter Todd <pete at petertodd.org> wrote:
> > IOW, assume every transaction your "border router" gives you is now the
> > one and only true transaction, and everything conflicting with it must
> > go.
>
>
> You are right that the assumption about the one and only transaction have to be relaxed. Broadcasting
> double spend only if it is actually replacing an earlier - for whatever reason, would simplify internal consensus logic .
>

2023-06-07 15:25:31

- reply

📅 Original date posted:2014-08-23
📝 Original message: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

2023-06-07 15:25:29

- reply

📅 Original date posted:2014-08-23
📝 Original message:Gerrit is free if you can afford the admin(s) to maintain it.
http://code.google.com/p/gerrit/wiki/ShowCases
And yes, I'm volunteering to get paid to be the admin, especially if you
want a 'painless' log in with a github account feature, because it will
be very painful for me to unroll the damage if github is compromised.
My preference would be that we use the same ECDSA keys we secure our
bitcoins with to secure our access to the code review and source
control systems.
On Wed, Aug 20, 2014 at 04:16:11PM +0200, Mike Hearn wrote:
> If github were to be abandoned for anything, it'd make sense to move code
> review and bug tracking elsewhere. GitHub does a reasonably good job of
> hosting git repositories. It kind of sucks at code review and the issue
> tracker is rudimentary at best. These days you can do "log in with my
> github account" so if done well, it'd not have to be very painful.
>
> JetBrains make great stuff and they have a code review and repository
> exploration tool called Upsource in development, which should come out
> soon. I think it's proprietary but that would be no different to github,
> and it's designed for self hosting.
--
----------------------------------------------------------------------------
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

2023-06-07 15:25:29

- reply

📅 Original date posted:2014-08-23
📝 Original message:On Wed, Aug 20, 2014 at 08:24:33AM +0200, Wladimir wrote:
> On Wed, Aug 20, 2014 at 3:26 AM, Troy Benjegerdes <hozer at hozed.org> wrote:
>
> > If bitcoin wants to become irrelevant, then by all means, continue to
> > depend on github and all the unknown attack surface it exposes.
> >
> > Those of us that do run our own servers will migrate to higher quality
> > alternatives.
>
> So that means you're volunteering to run a web-accessible mirror of
> the bitcoin repositories?
>
> Wladimir
http://bitspjoule.org/hg/upstream/bitcoin
I guess I should update it more than every 6 months and then the updates
won't take so long. It would also go a lot faster if I had a couple of
dedicated servers, but that won't happen until I sell someone a support
contract for crypto-commodities trading. I figure a bitcoin a month should
support the hardware, 24x7 monitoring, and maybe a couple of full nodes
running on the servers as well.
And to pick up from another comment on this thread if you don't understand
some of the differences between git and mercurial, or how to set up servers
that pull from git and mirror to mercurial, you will have a lot harder time
tracking down and removing malicous code that could get injected if someone
gets root on a Github server.
It is also a very usefull excercise in distributed systems design to
understand how distributed revision control systems in theory converge to a
coherent global state, and what is similiar or different to Bitcoin's
global consensus model of what the balance of every bitcoin address is.

2023-06-07 15:25:24

- reply

📅 Original date posted:2014-08-23
📝 Original message:On Sat, Aug 23, 2014 at 04:50:30PM +0000, Justus Ranvier wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 08/23/2014 04:17 PM, xor wrote:
> > On Tuesday, August 19, 2014 07:40:39 PM Jeff Garzik wrote:
> >> Encryption is of little value if you may deduce the same
> >> information by observing packet sizes and timings.
> >
> > Instead of spawning a discussion whether this aspect is a reason to
> > NOT encrypt, you should do the obvious:
> >
> > Fix that as well. X being broken is not a reason for not fixing Y.
> > Pad the then encrypted packets with random bytes. The fact that
> > they are encrypted makes them look like random data already, so the
> > padding will not be distinguishable from the rest. Also, add some
> > random bias to their timing.
>
> The packet size and timing issue will become less of an issue as the
> network grows anyway.
>
> One transaction inserted into a 3 transaction-per-second encrypted
> stream is more obvious than the same transaction inserted into a 100
> or 1000 TPS stream.
The requirement for anonymity and privacy is lawyers and a Bitlicense.
If you want privacy and anonymity, then do high-frequency trading on
a centralized exchange, and if you want to go over-the-top, run some
arbitrage bots as well, and hide in the millions of transactions per
second that go on.
But make sure you get a Bitlicense and have a good securities lawyer.
Trying to solve a legal/legislative/social problem with more crypto is
only going to serve the people who created the legal/legislative/social
problem in the first place, because they can hire a hacker who will
find a misplaced (} in your crypto code, and all the work you did to
encrypt wire protocols becomes silently worthless.

2023-06-07 15:17:19

- reply

📅 Original date posted:2014-04-07
📝 Original message:I have to play dissenter here again..
Using a bitcoin address as a persistent identity key is the first real-world
use of Bitcoin that I can imagine will make it a 'killer app' that everyone
and their grandma will want to use.
If you think 'certificates' are a good solution, then there is some way in
which we have dramatically divergent goals.
I like distributed, decentralized systems in which anyone can download the
code and be free to participate in the things they want to securely and
reliably.
As soon as I hear 'certificate', I see a system in which one must pay at toll
to speak, and which puts the listeners at risk because a certificate issuer
is such a high-value target for malicious attack.
Self-signed certificates are great for techno-wizards, but grandma has no
idea if the self-signed cert was signed by her grandson, or by the hacker
trying to redirect her social security check.
"This is your bitcoin address, it's your money AND your key to log into
your bank website securely, so don't lose it. If you want our address
protection insurance service that will be $20 per month, and if you do lose
it, we'll fix it. If you keep losing it, then your rates will go up, just
like car insurance if you keep crashing"
On Fri, Apr 04, 2014 at 09:32:40AM -0400, Gavin Andresen wrote:
> Using a bitcoin address repeatedly is something we're trying to move away
> from.
>
> And using a bitcoin address as a persistent identity key feels like the
> wrong direction to me.
>
> Better to use something like client certificates, the FIDO alliance's
> (new!) specs:
> http://fidoalliance.org/specifications/download
>
> ... or Steve Gibson's proposed SQRL system:
> https://www.grc.com/sqrl/sqrl.htm
>
> If one of those systems gets critical mass and actually starts being
> successful, then I think it would make sense to specify a standard way of
> using a HD wallet's deterministic seed to derive a key used for the FIDO or
> SQRL systems.
>
>
>
>
> On Fri, Apr 4, 2014 at 9:22 AM, Eric Larchevêque <elarch at gmail.com> wrote:
>
> > What I'm trying to achieve, is to have a very simple way of authenticating
> > yourself with one Bitcoin address from your wallet.
> > For most of the people using Bitcoin, their wallet is on their phone.
> >
> > The UX is clear and simple :
> > 1. click on "connect with Bitcoin" (the audience is normal people)
> > 2. flash the QRcode with your wallet (blockchain.info, mycelium, ...)
> > 3. accept the authentication request (same style than OpenID or Facebook
> > connect)
> > 4. user is autologged and identified by the chosen Bitcoin public address
> >
> > It makes sense only if major wallets are supporting the protocol. If you
> > need to install a plugin or download a third party software, no one will do
> > it.
> > I see only benefits for the entire ecosystem, and if I'm working on such a
> > proposition it is because I really need this feature.
> >
> > Of course, it can be done without a BIP, I just need to convince wallet
> > developpers one by one to implement the feature.
> > But I thought it was much better to start the "official" way, so all
> > wallet could easily find and implement the same authentication mechanism.
> >
> > > Bitcoin and website authentication are unrelated problems
> >
> > I respectfully disagree. Many services require your Bitcoin address, and
> > to do that they artificially request an email/password to store it.
> > This is not about authentication as an identity (as "I'm Eric
> > Larcheveque"), but as in "I'm proving to you that I control this address".
> >
> > Without such a standard protocol, you could never envision a pure Bitcoin
> > physical locker rental, or booking an hotel room via Bitcoin and opening
> > the door through the paying address.
> >
> > Eric
> >
> >
> >
> > On Fri, Apr 4, 2014 at 3:08 PM, Mike Hearn <mike at plan99.net> wrote:
> >
> >> This comes up every few months. I think the problem you are trying to
> >> solve is already solved by SSL client certificates, and if you want to help
> >> make them more widespread the programs you need to upgrade are web browsers
> >> and not Bitcoin wallets. There are certainly bits of infrastructure you
> >> could reuse here and there, like perhaps a TREZOR with a custom firmware
> >> extension for really advanced/keen users, but overall Bitcoin and website
> >> authentication are unrelated problems.
> >>
> >>
> >> On Fri, Apr 4, 2014 at 2:15 PM, Eric Larchevêque <elarch at gmail.com>wrote:
> >>
> >>> Hello,
> >>>
> >>> I've written a draft BIP description of an authentication protocol based
> >>> on Bitcoin public address.
> >>>
> >>> By authentication we mean to prove to a service/application that we
> >>> control a specific Bitcoin address by signing a challenge, and that all
> >>> related data and settings may securely be linked to our session.
> >>>
> >>> The aim is to greatly facilitate sign ups and logins to services and
> >>> applications, improving the Bitcoin ecosystem as a whole.
> >>>
> >>> https://github.com/bitid/bitid/blob/master/BIP_draft.md
> >>>
> >>> Demo website :
> >>> http://bitid-demo.herokuapp.com/
> >>>
> >>> Classical password authentication is an insecure process that could be
> >>> solved with public key cryptography. The problem is that it theoretically
> >>> offloads a lot of complexity and responsibility on the user. Managing
> >>> private keys securely is complex. However this complexity is already being
> >>> addressed in the Bitcoin ecosystem. So doing public key authentication is
> >>> practically a free lunch to bitcoiners.
> >>>
> >>> I've formatted the protocol description as a BIP because this is the
> >>> only way to have all major wallets implementing it, and because it
> >>> completely fits in my opinion the BIP "process" category.
> >>>
> >>> Please read it and let me know your thoughts and comments so we can
> >>> improve on this draft.
> >>>
> >>> Eric Larcheveque
> >>> elarch at gmail.com
> >>>
> >>>
> >>>
> >>> ------------------------------------------------------------------------------
> >>>
> >>> _______________________________________________
> >>> Bitcoin-development mailing list
> >>> Bitcoin-development at lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>
> >>>
> >>
> >
> >
> > ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
>
>
> --
> --
> Gavin Andresen
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
----------------------------------------------------------------------------
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

2023-06-07 15:16:23

- reply

📅 Original date posted:2014-03-27
📝 Original message:On Thu, Mar 27, 2014 at 02:49:32PM +0100, Thomas Voegtlin wrote:
>
>
> Le 27/03/2014 13:49, Mike Hearn a écrit :
> > Ah, BIP32 allows for a range of entropy sizes and it so happens that
> > they picked 256 bits instead of 128 bits.
> >
> > I'd have thought that there is a right answer for this. 2^128 should not
> > be brute forceable, and longer sizes have a cost in terms of making the
> > seeds harder to write down on paper. So should this be a degree of freedom?
> >
>
>
> Here is what I understand:
>
> 2^128 iterations is not brute forcable today, and will not be for the
> foreseeable future.
I foresee 2^128 being brute forceable in 20-25 years. See below.
> An EC pubkey of length n can be forced in approximately 2^(n/2)
> iterations (see http://ecc-challenge.info/) Thus, Bitcoin pubkeys, which
> are 256 bits, would require 2^128 iterations. This is why unused
> addresses (160 bits hash) are better protected than already used ones.
>
> However, people tend to believe that a public key of size n requires 2^n
> iterations. This belief might have been spread by this popular image:
> https://bitcointalk.org/index.php?topic=508880.msg5616146#msg5616146
So I assume this image is using the Landauer principle for minimum
energy ( http://en.wikipedia.org/wiki/Landauer%27s_principle ), however
it is unknown (to me at least) if a reversible computing ecdsa forcing
algorithm could be implemented. (this may or may not be a quantum
computing device)
Let's suppose for a moment you could, and get a million times better
than the Landauer pinciple limit of 2.85 zJ per bit, so we have total
energy to cycle through 128 bits of address space of:
units "2**128 * 2.85zJ / 1e6" "megawatt*hours"
* 269.39021
An attacker with a sub-Landauer limit/1e6 cracker would need a lot of
silicon area, and a couple of hours energy from a large wind farm, and
could siphon that energy out in a rural area without anyone noticing
anything other than a few shipping containers and that the wind turbines
are running more on windy days.
If we go back to just Landauer limit, and assume a 10MW system that
runs 24x7 (much like the NCSA Blue Waters Cray machine), we need:
(please check my math, or point out any stupid assumptions I've made)
units "2**128 * 2.85zJ / 10 megawatts" " years"
* 3073.1914
Or 3000 years. Well that still sounds pretty safe. How about 250MW?
units "2**128 * 2.85zJ / 250 megawatts" " years"
* 122.92766
Now I'm starting to get worried, because when I started computing, it
was on an 8-bit CPU that was measured in thousand operations-per-second.
In 1996 the largest supercomputer in the world was ASCII Red, with an
amazing 1 trillion floating-point operations per second. This morning
I have a 1-2 Teraflop water-cooled graphics processor sitting next to
me warming the room.
I expect in 5-10 years we'll have silicon with 256 bit registers that
may be able to do thousands or millions of ECDSA calculations per
second per computation unit.
So if you stop hearing from me here, it's because I found a better
mailing list, or a got a contract to develop and ECDSA cracker, in
which case you probably won't hear from me again until I have a talk
at DEFCON showing it off.
-- Troy Benjegerdes

2023-06-07 15:16:16

- reply

📅 Original date posted:2014-03-27
📝 Original message:On Wed, Mar 26, 2014 at 09:49:39PM +0100, Mike Hearn wrote:
> Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
> our BIP32 wallet structures would be compatible - and I discovered that
> only I was planning to use the default structure.
>
> Because I'm hopeful that we can get a lot of interoperability between
> wallets with regards to importing 12-words paper wallets, we brainstormed
> to find a structure acceptable to everyone and ended up with:
>
> /m/cointype/reserved'/account'/change/n
>
> The extra levels require some explanation:
>
> - cointype: This is zero for Bitcoin. This is here to support two
> things, one is supporting alt coins based off the same root seed. Right now
> nobody seemed very bothered about alt coins but sometimes feature requests
> do come in for this. Arguably there is no need and alt coins could just use
> the same keys as Bitcoin, but it may help avoid confusion if they don't.
Using the same keys across different altcoins seems like an exceedingly bad opsec
practice. Cointype is critical, as well as having a predictable and deterministic
mapping of alt coins to Cointype.
What should I be using for Catcoin, for instance? the CAT symbol all the
exchanges use, or do we set up a 'registry', or some other mechanism?
I'd venture to guess the altcoin market is, or soon will be larger in US
dollar value trade volume than Bitcoin, so *some* of us are quite bothered
by the wailing and gnashing of teeth that occurs on this list at mere thought
of such heresy.
--
----------------------------------------------------------------------------
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

2023-06-07 15:16:07

- reply

📅 Original date posted:2014-03-25
📝 Original message:On Tue, Mar 25, 2014 at 08:40:40PM +0000, Ricardo Filipe wrote:
> 2014-03-25 13:49 GMT+00:00 Peter Todd <pete at petertodd.org>:
> > On Tue, Mar 25, 2014 at 08:45:00AM -0400, Gavin Andresen wrote:
> >> On Tue, Mar 25, 2014 at 8:28 AM, Peter Todd <pete at petertodd.org> wrote:
> >>
> >> > Bitcoin doesn't scale. There's a lot of issues at hand here, but the
> >> > most fundemental of them is that to create a block you need to update
> >> > the state of the UTXO set, and the way Bitcoin is designed means that
> >> > updating that state requires bandwidth equal to all the transaction
> >> > volume to keep up with the changes to what set. Long story short, we get
> >> > O(n^2) scaling, which is just plain infeasible.
> >> >
> >>
> >> We have a fundamental disagreement here.
> >>
> >> If you go back and read Satoshi's original thoughts on scaling, it is clear
> >> that he imagined tens of thousands of mining nodes and hundreds of millions
> >> of lightweight SPV users.
> >
> > Yeah, about that...
> >
> > https://blockchain.info/pools
> >
>
> On-topic:
> This argument is quite the fallacy. The only reason we have that few
> pools is because each of their miners doesn't find it feasible to mine
> "on their own". if you count the individual miners on those pools you
> will get to the scale Gavin was trying to point out.
>
> Nevertheless i think that is just a minor disagreement, since tree
> chains help decentralization.
I think is actually a major fundamental disagreement, and opinions
tend to correlate strongly with salary considerations.
"It is difficult to get a man to understand something, when his salary
depends upon his not understanding it!" -- Upton Sinclair
Let us either agree to disagree, or get on with moderating this list
so that only sensible salaried discussions can take place.

2023-06-07 15:15:33

- reply

📅 Original date posted:2014-03-13
📝 Original message:On Thu, Mar 13, 2014 at 04:50:14PM +0100, Mike Hearn wrote:
> On Thu, Mar 13, 2014 at 3:32 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
> > Such hand-wavy, data-free logic is precisely why community
> > coordination is preferred to random apps making random decisions in
> > this manner.
> >
>
> That ship sailed months ago. If you wanted a big push for uBTC, then would
> have been the time. Though given that it'd have made lots of normal
> balances incredibly huge, perhaps it's a good thing that didn't happen.
> Also "milli" is a unit people encounter in daily life whereas micro isn't.
> Is it milli / micro / nano or milli / nano / micro? I bet a lot of people
> would get that wrong.
I think the ship of hand-wavy, data-free logic sailed with
'money supply == 21 million', so why not enjoy the ride? If we care about
real people and real use cases, then let's talk about indexing the money
supply to some blockchain-observable value and add demurrage instead of
of bikeshedding the color of the latest coat of paint.
>
> If you have to export to financial packages that can't handle fractional
> pennies, then by all means represent prices in whatever units you like for
> that purpose, but in software designed for ordinary people in everyday life
> mBTC is a pretty good fit.
>
> Besides, fractional pennies crop up in existing currencies too (the famous
> Verizon Math episode showed this), so if a financial package insists on
> rounding to 2dp then I guess it may sometimes do the wrong thing in some
> business cases already.
>
> Fundamentally, more than two decimal places tends to violate the
> > Principle Of Least Astonishment with many humans, and as a result,
> > popular software systems have been written with that assumption.
>
>
> Lots of people use currencies that don't have any fractional components at
> all ! So perhaps all prices should be denominated in satoshis to ensure
> that they're not surprised :)
I'm surprised every time I pull up to a gas pump and the price is 3.249999
per gallon. But I don't really care what the price is, as long as there's
an e85 pump. If I could pay at the pump with bitcoin, I wouldn't even look
at the price, I'd only care if my tank got filled up or if I have to drive
slower to get better mileage.
Hell, I'd have an app that would tell me what gas station to go to that got
me the best miles per bitcoin based on where I actually wanted to go.

2023-06-07 15:14:56

- reply

📅 Original date posted:2014-03-07
📝 Original message:On Thu, Mar 06, 2014 at 10:45:31AM +0100, Mike Hearn wrote:
> I just did my first contactless nfc payment with a MasterCard. It worked
> very well and was quite delightful - definitely want to be doing more of
> these in future. I think people will come to expect this kind of
> no-friction payment experience and Bitcoin will need to match it, so here
> are some notes on what's involved.
>
> There are two aspects that can be implemented independently of each other:
>
> 1) The physical/NFC layer.
> 2) The risk analysis layer.
>
> A contactless payment needs two things to work: one is a VERY fast, low
> latency communication between payment device (phone in our case) and
> terminal. I couldn't find actual latency specs yet but it felt like using
> an Oyster card, which aims for <400msec.
What matters more than the latency is the *variability*. I would spec this
system for no less than 200ms, and no more than 250ms to be 'standard'.
> ..... so I bet we'd need to optimise the bootup process of the Android
> wallet app. Right now it does slow things like deserialising giant protocol
> buffers and is just generally not optimised for startup time. Loading the
> wallet, reading the payment request over NFC, checking the cert signatures,
> making the trust decision, calculating a transaction, signing it, sending
> it back to the recipient all in under 400 msec would be a tough (but fun)
> programming challenge. Some of the steps can be parallelised and modern
> phones are mostly multicore.
If you have to invoke a java/ios/etc app you are never going to be consistent,
however if you have a GPL linux kernel module (like I proposed for my still
hypothetical 7coin), you should have no trouble meeting those specs.
I'd like to be able to load my java app, tell it to put $50 on my 'instant'/nfc
wallet, and then let the kernel module spend out the $50 whenever the phone
gets swiped by somehting.
If you do this right, every device has a well-known payment address for it's
'instant' wallet, and it should be trivial for merchants to just look at the
blockchain and confirm the instant wallet has a sufficient balance to cover
the transaction.
One more comment... having a bitcoin payment application 'check certs' seems
like a great way to ensure that Visa maintains their market share.
If it's my phone, and I press the hardware payment button, and I only put
$50 on it, I frankly don't care if there's a cert or not. The last thing I
want is a 'certificate validation error' when I'm trying to buy a soda.
----------------------------------------------------------------------------
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

2023-06-07 15:13:58

- reply

📅 Original date posted:2014-02-28
📝 Original message:To each his own, but if I say "Please don't charge me for YOUR privacy
by putting junk like stealth addresses in the blockchain", I think I'd
get laughed out of most rooms.
Either the transaction fees are sufficient to pay the cost for whatever
random junk anyone wants to put there, or they are not, and if they are
not, then I suggest you re-think the fee structure rather than trying
to pre-regulate me putting 80 character pithy quotes in the blockhain.
On Mon, Feb 24, 2014 at 09:23:12AM -0800, Mark Friedenbach wrote:
> Given our standardization on 128-bit security / 256-bit primitives, I
> can't think of any crypto related data payload which requires more than
> 40 bytes. Even DER encoded compressed public keys will fit in there. A
> signature won't fit, but why would you need one in there?
>
> There's no need to design for 64-byte hashes, and the 80-char line
> length comparison is a good point. As an Engineer I'd want to have a
> little more room as a 32-byte hash or EC point + 8 bytes identifying
> prefix data is the bare minimum, but it is also very important that we
> send a message: This is for payment related applications like stealth
> addresses only. Don't burden everybody by putting your junk on the block
> chain.
>
> On 02/24/2014 08:39 AM, Wladimir wrote:
> >
> > On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik <jgarzik at bitpay.com
> > <mailto:jgarzik at bitpay.com>> wrote:
> >
> > A common IRC proposal seems to lean towards reducing that from 80.
> > I'll leave it to the crowd to argue about size from there. I do think
> > regular transactions should have the ability to include some metadata.
> >
> >
> > I'd be in favor of bringing it down to 40 for 0.9.
> >
> > That'd be enough for <8 byte header/identifier><32 byte hash>.
> >
> > 80, as the standard line length, is almost asking for "insert your
> > graffiti message here". I also see no need for 64 bytes hashes such as
> > SHA512 in the context of bitcoin, as that only offers 256-bit security
> > (at most) in the first place.
> >
> > And if this is not abused, these kind of transactions become popular,
> > and more space is really needed, the limit can always be increased in a
> > future version.
> >
> > Wladimir
> >
> >
> > ------------------------------------------------------------------------------
> > Flow-based real-time traffic analytics software. Cisco certified tool.
> > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> > Customize your own dashboards, set traffic alerts and generate reports.
> > Network behavioral analysis & security monitoring. All-in-one tool.
> > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
----------------------------------------------------------------------------
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

2023-06-07 15:13:15

- reply

📅 Original date posted:2014-02-09
📝 Original message:On Sun, Feb 09, 2014 at 05:25:41PM +0000, Luke-Jr wrote:
> On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote:
> > We have an embedded consensus system and we want to be able to upgrade
> > it with new rules.
>
> This asserts a central authority and gives developers too much power.
I don't quite see how, There is nothing that 'forces' me to upgrade,
unless I have chosen to run an operating system (MacOS, Windows, Android)
that have automatic don't-ask-the-user update mechanisms.
The bigger problem with 'asset transfer' of assets which do not exist
soley in the blockchain is including the consensus of relevant local and
distributed legal jurisdictions.
For example, just because the 'colored coin' and blockchain consensus is
that I 'electronically' signed a mortgage document giving some random
internet company the rights to foreclose on my home does not mean that
my local county Judge or Sheriff are going to do anything if the internet
company cannot produce the original paper document with ink signature.
The only 'assertion' of central authority here is people who download and
run the code and submit to whatever the code asserts they are supposed to do.
At least with the 'central authority' of the big-business bitcoin developer
cabal I can read the code before I submit to it's central authority, and
this is a significant improvement over amgibuous legislation or proprietary
high-frequency trading algorithms.

2023-06-07 15:11:58

- reply

📅 Original date posted:2014-01-18
📝 Original message:On Wed, Jan 15, 2014 at 05:32:31PM -0800, Gregory Maxwell wrote:
> On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman <jeremy at taplink.co> wrote:
> > Choosing how many bits to put in the prefix may be difficult, particularly
> > if transaction load changes dramatically over time. 0 or 1 bits may be
> > just fine for a single user running their own node, whereas a central
> > service might want 4 or 5 bits to keep their computation costs scalable.
>
> Ignoring prefixes the cost for each reusable address is only a small
> percentage of the full node cost (rational: each transaction has one
> or more ECDSA signatures, and the derivation is no more expensive), so
> I would only expect computation to be an issue for large centralized
> services. (non-full nodes suffer more from just the bandwidth impact).
I have not seen anyone address my high-level question to (somewhat) complicated
mechanisms to keep coin flows private.
Who pays for it? From what I see it's going to double the amount of data
needed per address, further centralizing 'full' nodes. I'm fine if the NSA
is paying for privacy (I actually trust them more than banks and advertisers),
but let's just be honest, okay?
If socializing the cost of privacy is Bitcoin's goal, and giving the benefits
to a few that understand it and/or have the resources to determine privacy
providers that won't scam them, then say so, so I can get on with launching
a 'transparencycoin' with a modified code that explicitly ALWAYS re-uses
addresses, and has miners and pools that charge more for addresses they have
never seen before. I bet it will be more distributed and have about half the
average transaction cost of Bitcoin, because most people *just don't care*
about privacy if they get cheap and/or free services.
-- Troy, transparency advocate who is quite transparent that if you buy me
farmland, I'll shut up about transparency, because I'll be too busy growing
food and giving part of it away.