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

nprofile1qqsdaq6tyvx64rndqnzyu5vjn3fdlhpkmsh5zpdqkecxpkwlcvxkenqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsrqhmp0

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1m6p5kgcd428x6pxyfege98zjmlwrdhp0gyz6pdnsvrvalscddnxqurdjn5

Show more details

Last Notes

2023-06-07 20:04:29

- reply

📅 Original date posted:2017-07-14
📝 Original message:On Thu, Jul 13, 2017 at 01:04:19AM +0000, Gregory Maxwell via bitcoin-dev wrote:
> On Wed, Jul 12, 2017 at 6:17 AM, Dan Libby via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Hi!
> >
> > Up to now, I have purposefully been running bitcoin releases prior to
> > 0.13.1 as a way to avoid the (possible) segwit activation, at least
> > until such time as I personally am comfortable with it.
>
> It is not simple to do so correctly, I couldn't tell you off the top
> of my head; a number of things must be changed it isn't as simple as
> disabling the activiation because of the segwit P2P changes. Nor is
> it a supported configuration. Even if it were now, it wouldn't be one
> we'd continue to support in the future after segwit is active, as
> we're likely to drop deployment/compat code.
And this attitude is why bitcoin-core is going to get dropped and,
hopefully, instead of just one code to rule them all, we will have
good specifications and multiple competing implementations.
> Can you explain why you wish to do this? It should have absolutely no
> adverse impact on you-- if you don't use segwit, you don't use it-- it
> may be the case that there is some confusion about the implications
> that I could clear up for you... or suggest alternatives that might
> achieve your goals.
One of the significant adverse impacts of Segwit is the following:
https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2861
When viewed on Github, less than one third of the consensus-critical
code is visible on-screen.
This is a maintenance and readability nightmare, in my opinion. There
are many good reasons why giving *users* the ability to firewall off
that code, maybe even with #ifdefs, as ugly as they are, would provide
some much better confidence that one is indeed, not running segwit.
I suspect it would help the community a great deal in comfort level
if this code were easier to read and used some type of coding standard
in which the default github view on the average browser shows all the
code without having a "hidden feature" that requires scrolling that
has no obvious UI indication you even need to scroll.

2023-06-07 20:03:55

- reply

📅 Original date posted:2017-07-04
📝 Original message:On Tue, Jul 04, 2017 at 09:30:26PM -0400, shaolinfry via bitcoin-dev wrote:
> Some people have criticized BIP9's blocktime based thresholds arguing they are confusing (the first retarget after threshold). It is also vulnerable to miners fiddling with timestamps in a way that could prevent or delay activation - for example by only advancing the block timestamp by 1 second you would never meet the threshold (although this would come a the penalty of hiking the difficulty dramatically).
If there are miners that start doing 1 second timestamp advances, it would be
simpler (and probably safer) to require a minimum block time spacing of say
30 seconds or 1 minute, and orphan blocks that are too close in time and more
than say an hour behind real-time.
I cannot picture any realistic scenario in which an attempt to block activation
in this way is in anything other than a very expensive temper tantrum for any
miners foolish enough to attempt it.
It *might* be a delay tactic as a 'nuclear option' attack vector for a mining
cabal to run up the difficulty so high as to make it impractical to mine any
new blocks after the adjustment, but there are plenty of altcoins that have
hardforked and gotten along just fine after the same kind of thing due to
profit-switching pools.
> On the other hand, the exact date of a height based thresholds is hard to predict a long time in advance due to difficulty fluctuations. However, there is certainty at a given block height and it's easy to monitor.
> If there is sufficient interest, I would be happy to amend BIP8 to be height based. I originally omitted height based thresholds in the interests of simplicity of review - but now that the proposal has been widely reviewed it would be a trivial amendment.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19: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 19:52:11

- reply

📅 Original date posted:2016-08-03
📝 Original message:On Thu, Aug 04, 2016 at 04:16:20AM +1000, Matthew Roberts via bitcoin-dev wrote:
> In light of the recent hack: what does everyone think of the idea of
> creating a new address type that has a reversal key and settlement layer
> that can be used to revoke transactions?
I think many of us who think about human - computer interactions see the
need for a well defined process to roll back unexpected behavior in a computer
system. My 2014 era proposal is https://bitbucket.org/tmagik/catoshi/issues/24
The fundamental assumption around cryptocoins is you have a secret (private
key) known only by you. Currently in bitcoin if that assumption changes, the
response is blame the user. 'Incompetence, etc, etc'
This is bad business. For any cryptocurrency to really get mass market, we
need to provide our users with key revocation, to be used when the assumption
about being the only holder of a secret is broken.
I think there's a hardfork-worthy choice here:
1) implement reversal/revocation as an add-on feature
2) implement reversal/revocation as a fundamental that every address gets.
Ethereum made a quick hardfork choice to reverse a *single* instance of
unexpected behavior, and looks a lot like a bank bailout. We have the chance
to learn from this mistake, and, apparently, make a lot of money trading
on both sides of the hardfork.
> You could specify so that transactions "sent" from these addresses must
> receive N confirmations before they can't be revoked, after which the
> transaction is "settled" and the coins become redeemable from their
> destination output. A settlement phase would also mean that a transaction's
> progress was publicly visible so transparent fraud prevention and auditing
> would become possible by anyone.
>
> The reason why I bring this up is existing OP codes and TX types don't seem
> suitable for a secure clearing mechanism; Nlocktimed TXs won't work for
> this since you can't know ahead of time when and where a withdrawal needs
> to be made, plus there's still the potential for key mismanagement; Similar
> problems with OP_CHECKLOCKTIMEVERIFY apply too ??? unless you keep a private
> key around on the server which would defeat the purpose. The main use case
> here, would be specifically to improve centralized exchange security by
> making it impossible for a hot wallet to be raided all at once.
>
> Thoughts?
>
> Some existing background:
>
> http://hackingdistributed.com/2016/08/03/how-bitfinex-heist-could-have-been-avoided/
> -- Proposed the basic idea for a time-based clearing house but using
> blockchains directly, this is a much better idea than my own.
>
> roberts.pm/timechain -- My original paper written in 2015 which proposed a
> similar idea for secure wallet design but implemented using time-locked
> ECDSA keys. Obviously a blockchain would work better for this.
>
> Other -- if the idea has already been brought up by other people, I
> apologize.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:38:22

- reply

📅 Original date posted:2015-06-17
📝 Original message:> - How do you propose to deal with the extra risks that come from
> non-consensus hard-forks? Hard-forks themselves are quite risky, but
> non-consensus ones are extremely dangerous for consensus.
This is a non-issue.
If the hard-fork is not a consensus, then those of us that don't consent
ignore the fool that tried to hard-fork.
If a fool attempting a non-consensus hard-fork actually breaks something,
then you have a fragile system that needs some serious re-thinking.
I think a non-consensus hard-fork would be the best thing that could
happen to the bitcoin ecosystem long-term, because it would force some
re-examination of some very bad assumptions.
--
----------------------------------------------------------------------------
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 17: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 17: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 17: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 17: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 17:30:36

- reply

📅 Original date posted:2015-02-19
📝 Original message:On Sun, Feb 15, 2015 at 06:13:06PM +0100, Tamas Blummer wrote:
>
> On Feb 15, 2015, at 6:02 PM, Peter Todd <pete at petertodd.org> wrote:
> > Yes you are dicking around.
>
> I thought I was clear, that I am using Bitcoin Core as border router talking to its P2P interface.
>
> The reimplementation of consensus code helped me to deeply understand the protocol, aids debugging
> and now comes handy to create a side chain.
The work that Tamas did re-implementing is probably one of the most valuable
things he ever did.
It would significantly improve the quality of the consensus code if this
community would start treating it as a buggy & poorly defined proof-of-concept
that just happens to actually run, rather than some holy scripture upon which
we must never question (or change)
I'm impressed by the secp256k1 work, and other modularity efforts, but at
some point main.cpp needs to get untangled, and have some critical review
if bitcoin wants to remain relevant.
--
----------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' hozer at hozed.org

2023-06-07 17:30:21

- reply

📅 Original date posted:2015-02-15
📝 Original message:On Thu, Feb 12, 2015 at 10:27:53AM -0500, Jeff Garzik wrote:
> Repeating past statements, it is acknowledged that Peter's scorched
> earth replace-by-fee proposal is aptly named, and would be widely
> anti-social on the current network.
>
> At a high level, we can see that this thread is contentious because
> this covers _what we want bitcoin to be_, and that is an opinion
> (versus engineering fact), and it varies from person to person.
I find Peter's proposal relatively mild. I'd prefer that instead of
exchanges going bankrupt, that there be direct blockchain support
for key revocation and 'burning' stolen coins, and an economic
ecosystem that supports insurance underwriters that pay out when
someone inevitably gets hacked. This would definitely be 'scorched
earth' at one level, but I think would make for a far more
transparent and friendly system.
> However, hope is the denial of reality...instead we should walk
> forward with our eyes open[1]. My interest in bitcoin originates from
> the science fiction concept of "credits"[2], a universal money that
> transcends national borders and even planets. That is what I hoped
> bitcoin would be. "universal payments" is both a laudable goal and a
> shopworn bitcoin marketing slogan.
>
> The fundamental engineering truths diverge from that misty goal:
> Bitcoin is a settlement system, by design.
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.
> The process of consensus "settles" upon a timeline of transactions,
> and this process -- by design -- is necessarily far from instant.
> Alt-coins that madly attempt 10-second block times etc. are simply a
> vain attempt to paper over this fundamental design attribute:
> consensus takes time.
>
> As such, the blockchain can never support All The Transactions, even
> if block size increases beyond 20MB. Further layers are -- by design
> -- necessary if we want to achieve the goal of a decentralized payment
> network capable of supporting full global traffic.
>
> Bitcoin payments are like IP packets -- one way, irreversible. For
> larger value transfers this attaches attendent risk of loss -- as
> we've seen in the field time & again. The world's citizens en masse
> will not speak to each other with bitcoin (IP packets), but rather
> with multiple layers (HTTP/TCP/IP) that enable safe and secure value
> transfer or added features such as instant transactions.
I see a world in which we have many blockchains, along with not-quite
blockchain things like ripple that approximate that vision you have
of 'credits'. But we cannot have one chain to rule them all, for there
are inherent engineering trade-offs that one chain can never resolve.
There appear to be some things we will never come to a consensus on,
such as transaction reversibility, or what the optimal money supply
algorithm is. However we might learn a great deal from sharing code
and ideas. So in that line, see my thoughts on reversibility [3][4]
> This opinion is not a conspiracy to "put the bankers back in charge"
> -- it is a simple acknowledgement of bitcoin's design. The consensus
> system settles on a timeline.
>
> Bitcoin transactions are, by definition, not instant.
> Zero confirmation transactions are, by definition, not secure.
>
> Proposals such as Oleg's are _necessary_ to fully build out the
> bitcoin system. Avoid short-sighted, short-term thinking that views
> the lowest layer (one-way value xfer) at the most optimal layer at
> which free persons will transact freely & instantly across planet
> Earth.
>
> It is foolish to think the entire world will connect directly to the
> P2P block network and broadcast all the morning coffees to all the
> miners. That's not how the system works. It is a settlement layer.
> We _must_ build decentralized layered solutions on top of bitcoin,
> rather than stuffing everything into bitcoin itself.
I'll say the same about not stuffing everthing on top of the same
blockchain. We might very well have coffee shops that take coffecoin.
But Bitcoin will never be able to scale out horizontally like altcoins
can.
>
> [1] http://www.goodreads.com/quotes/35199-hope-is-the-denial-of-reality-it-is-the-carrot
> [2] http://garzikrants.blogspot.com/2013/06/shadowrun-and-bitcoins-roots.html
[3] https://bitbucket.org/tmagik/catoshi/issue/24
[4] https://bitbucket.org/tmagik/catoshi/issue/27
>
> On Thu, Feb 12, 2015 at 6:58 AM, Mike Hearn <mike at plan99.net> wrote:
> > I know you will ignore this as usual, but the entire replace-by-fee folly is
> > based on your fundamental misunderstanding of miner incentives.
> >
> > Miners are not incentivised to earn the most money in the next block
> > possible. They are incentivised to maximise their return on investment.
> > Making Bitcoin much less useful reduces demand for the bitcoins they are
> > mining, reducing coinbase and fee income in future blocks. Quite possibly,
> > to the point where those miners are then making a loss.
> >
> > Your "scorched earth" plan is aptly named, as it's guaranteed to make
> > unconfirmed payments useless. If enough miners do it they will simply break
> > Bitcoin to the point where it's no longer an interesting payments system for
> > lots of people. Then miners who have equipment to pay off will be really
> > screwed, not to mention payment processors and all the investors in them.
> >
> > I'm sure you can confuse a few miners into thinking your ideas are a
> > super-duper way to maximise their income, and in the process might
> > facilitate a pile of payment fraud. But they aren't. This one is about as
> > sensible as your "let's never increase the block size" and "let's kill SPV
> > clients" crusades - badly thought out and bad for Bitcoin.
> >
> > ------------------------------------------------------------------------------
> > 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
> >
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
> ------------------------------------------------------------------------------
> 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
--
----------------------------------------------------------------------------
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 17: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 17:28:08

- reply

📅 Original date posted:2014-12-16
📝 Original message:Thank you Jeff.
Having looked at a lot of linux code, and now a lot of bitcoin code, the
biggest long-term systemic risk I see is that Bitcoin has is the lack of
code janitors.
The problem is that janitoring was *disruptive* for non-x86 linux architectures
when it first got going, and it's going to be very disruptive for bitcoin as
well, but it **needs** to happen.
The code is too complex and hard to follow as it is now. (now, I could just
be speaking because I haven't paid the social debt of looking at the latest
bitcoin code, including libconsensus), but there really needs to be a focus
on readability, maintainability, and (as much as I hate to say it) a rather
hard-line policy on coding standards.
I don't care which tabbing style or column width you pick, but **pick one**,
and enforce it across the entire codebase.
Maybe this should be bitcoin-stable, and bitcoin-devel, with a 6-9 month
social expectation of minimal cosmetic changes in -stable, with a 1 month
'merge window' where -devel turns into -stable.
On Tue, Dec 16, 2014 at 12:59:06PM -0500, Jeff Garzik wrote:
> It can be useful to review open source development processes from time to
> time. This reddit thread[1] serves use both as a case study, and also a
> moment of OSS process introduction for newbies.
> [1]
> http://www.reddit.com/r/Bitcoin/comments/2pd0zy/peter_todd_is_saying_shoddy_development_on_v010/
>
>
>
>
> *Dirty Laundry*
> When building businesses or commercial software projects, outsiders
> typically hear little about the internals of project development. The
> public only hears what the companies release, which is prepped and
> polished. Internal disagreements, schedule slips, engineer fistfights are
> all unseen.
>
> Open source development is the opposite. The goal is radical
> transparency. Inevitably there is private chatter (0day bugs etc.), but
> the default is openness. This means that is it normal practice to "air
> dirty laundry in public." Engineers will disagree, sometimes quietly,
> sometimes loudly, sometimes rudely and with ad hominem attacks. On the
> Internet, there is a pile-on effect, where informed and uninformed
> supporters add their 0.02 BTC.
>
> Competing interests cloud the issues further. Engineers are typically
> employed by an organization, as a technology matures. Those organizations
> have different strategies and motivations. These organizations will
> sponsor work they find beneficial. Sometimes those orgs are non-profit
> foundations, sometimes for-profit corporations. Sometimes that work is
> maintenance ("keep it running"), sometimes that work is developing new,
> competitive features that company feels will give it a better market
> position. In a transparent development environment, all parties are
> hyperaware of these competing interests. Internet natterers painstakingly
> document and repeat every conspiracy theory about Bitcoin Foundation,
> Blockstream, BitPay, various altcoin developers, and more as a result of
> these competing interests.
>
> Bitcoin and altcoin development adds an interesting new dimension.
> Sometimes engineers have a more direct conflict of interest, in that the
> technology they are developing is also potentially their road to instant
> $millions. Investors, amateur and professional, have direct stakes in a
> certain coin or coin technology. Engineers also have an emotional stake in
> technology they design and nurture. This results in incentives where
> supporters of a non-bitcoin technology work very hard to thump bitcoin.
> And vice versa. Even inside bitcoin, you see "tree chains vs. side chains"
> threads of a similar stripe. This can lead to a very skewed debate.
>
> That should not distract from the engineering discussion. Starting from
> first principles, Assume Good Faith[2]. Most engineers in open source tend
> to mean what they say. Typically they speak for themselves first, and
> their employers value that engineer's freedom of opinion. Pay attention to
> the engineers actually working on the technology, and less attention to the
> noise bubbling around the Internet like the kindergarten game of grapevine.
> [2] http://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith
>
> Being open and transparent means engineering disagreements happen in
> public. This is normal. Open source engineers live an aquarium life[3].
> [3] https://www.youtube.com/watch?v=QKe-aO44R7k
>
>
>
>
> *What the fork?*
> In this case, a tweet suggests consensus bug risks, which reddit account
> "treeorsidechains" hyperbolizes into a dramatic headline[1]. However, the
> headline would seem to be the opposite of the truth. Several changes were
> merged during 0.10 development which move snippets of source code into new
> files and new sub-directories. The general direction of this work is
> creating a "libconsensus" library that carefully encapsulates consensus
> code in a manner usable by external projects. This is a good thing.
>
> The development was performed quite responsible: Multiple developers would
> verify each cosmetic change, ensuring no behavior changes had been
> accidentally (or maliciously!) introduced. Each pull request receives a
> full multi-platform build + automated testing, over and above individual
> dev testing. Comparisons at the assembly language level were sometimes
> made in critical areas, to ensure zero before-and-after change. Each
> transformation gets the Bitcoin Core codebase to a more sustainable, more
> reusable state.
>
> Certainly zero-change is the most conservative approach. Strictly speaking,
> that has the lowest consensus risk. But that is a short term mentality.
> Both Bitcoin Core and the larger ecosystem will benefit when the "hairball"
> pile of source code is cleaned up. Progress has been made on that front in
> the past 2 years, and continues. *Long term*, combined with the
> "libconsensus" work, that leads to less community-wide risk.
>
> The key is balance. Continue software engineering practices -- like those
> just mentioned above -- that enable change with least consensus risk. Part
> of those practices is review at each step of the development process:
> social media thought bubble, mailing list post, pull request, git merge,
> pre-release & release. It probably seems chaotic at times. In effect,
> git[hub] and the Internet enable a dynamic system of review and feedback,
> where each stage provides a check-and-balance for bad ideas and bad
> software changes. It's a human process, designed to acknowledge and handle
> that human engineers are fallible and might make mistakes (or be
> coerced/under duress!). History and field experience will be the ultimate
> judge, but I think Bitcoin Core is doing good on this score, all things
> considered.
>
> At the end of the day, while no change is without risk, version 0.10 work
> was done with attention to consensus risk at multiple levels (not just
> short term).
>
>
>
>
> *Technical and social debt*
> Working on the Linux kernel was an interesting experience that combined
> git-driven parallel development and a similar source code hairball. One of
> the things that quickly became apparent is that cosmetic patches,
> especially code movement, was hugely disruptive. Some even termed it
> anti-social. To understand why, it is important to consider how modern
> software changes are developed:
>
> Developers work in parallel on their personal computers to develop XYZ
> change, then submit their change "upstream" as a github pull request. Then
> time passes. If code movement and refactoring changes are accepted
> upstream before XYZ, then the developer is forced update XYZ -- typically
> trivial fixes, re-review XYZ, and re-test XYZ to ensure it remains in a
> known-working state.
>
> Seemingly cosmetic changes such as code movement have a ripple effect on
> participating developers, and wider developer community. Every developer
> who is *not* immediately merged upstream must bear the costs of updating
> their unmerged work.
>
> Normally, this is expected. Encouraging developers to build on top of
> "upstream" produces virtuous cycles.
>
> However, a constant stream of code movement and cosmetic changes may
> produce a constant stream of disruption to developers working on
> non-trivial features that take a bit longer to develop before going
> upstream. Trivial changes are encouraged, and non-trivial changes face a
> binary choice of (a) be merged immediately or (b) bear added re-base,
> re-view, re-test costs.
>
> Taken over a timescale of months, I argue that a steady stream of cosmetic
> code movement changes serves as a disincentive to developers working with
> upstream. Each upstream breakage has a ripple effect to all developers
> downstream, and imposes some added chance of newly introduced bugs on
> downstream developers. I'll call this "social debt", a sort of technical
> debt[4] for developers.
> [4] http://en.wikipedia.org/wiki/Technical_debt
>
> As mentioned above, the libconsensus and code movement work is a net gain.
> The codebase needs cleaning up. Each change however incurs a little bit of
> social debt. Life is a little bit harder on people trying to get work into
> the tree. Developers are a little bit more discouraged at the busy-work
> they must perform. Non-trivial pull requests take a little bit longer to
> approve, because they take a little bit more work to rebase (again).
>
> A steady flow of code movement and cosmetic breakage into the tree may be a
> net gain, but it also incurs a *lot* of social debt. In such situations,
> developers find that tested, working out-of-tree code repeatedly stops
> working *during the process of trying to get that work in-tree*. Taken
> over time, it discourages working on the tree. It is rational to sit back,
> *not* work on the tree, let the breakage stop, and then pick up the pieces.
>
>
>
>
> *Paradox Unwound*
> Bitcoin Core, then, is pulled in opposite directions by a familiar
> problem. It is generally agreed that the codebase needs further
> refactoring. That's not just isolated engineer nit-picking. However, for
> non-trivial projects, refactoring is always anti-social in the short term.
> It impacts projects other than your own, projects you don't even know
> about. One change causes work for N developers. Given these twin opposing
> goals, the key, as ever, is finding the right balance.
>
> Much like "feature freeze" in other software projects, developing a policy
> that opens and closes windows for code movement and major disruptive
> changes seems prudent. One week of code movement & cosmetics followed by 3
> weeks without, for example. Part of open source parallel development
> is *social
> signalling*: Signal to developers when certain changes are favored or not,
> then trust they can handle the rest from there.
>
> While recent code movement commits themselves are individually ACK-worthy,
> professionally executed and moving towards a positive goal, I think the
> project could strike a better balance when it comes to disruptive cosmetic
> changes, a balance that better encourages developers to work on more
> involved Bitcoin Core projects.

2023-06-07 17:25:33

- reply

📅 Original date posted:2014-08-23
📝 Original message:On Sat, Aug 23, 2014 at 10:32:15AM -0400, Peter Todd wrote:
> On Sat, Aug 23, 2014 at 01:17:01AM -0500, Troy Benjegerdes wrote:
> > 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.
>
> Git commits serve two purposes: recording public history and
> communication. While for the purpose of recording history immutable
> commits make sense, for the purpose of communicating to other developers
> what changes should be added to that history you *do* want the mutable
> commits that git's rebase functionality supports. Much like how
> university math classes essentially never teach calculus in the order it
> was developed, it is rare indeed for the way you happened to develop
> some functionality to be the best sequence of changes for other
> developers to understand why and what is being changed.
>
> Anyway, just because mercurial is designed around the assumption that
> commit history is immutable doesn't mean it actually is; an attacker can
> fake a series of mercurial commits just as easily as they can git
> commits. The only thing that protects against history rewriting is
> signed commits and timestamps.
What I would really like is a frontend and/or integration to Git/Mercurial that
uses Bitcoin transactions *as* the signature, which has the nice side effect of
providing timestamps backed by the full faith and credit of a billion dollar
blockchain. So what is the best way for me to stick both a git *and* a
mercurial identity hash into a bitcoin transaction? (which leads to point 2
below)
>
> > 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.
>
> The easiest and most useful way to achieve that would be to have a
> formal program of code review, perhaps on a per-release basis, that
> reviewed the diffs between the previous release and the new one. Master
> repos in this scenario are simply copies of the "master master" repo
> that someone has manually verified and signed-off on, with of course a
> PGP signature.
>
> If you feel like volunteering to maintain one of these repos, you may
> find my Litecoin v0.8.3.7 audit report to be a useful template:
>
> https://bitcointalk.org/index.php?topic=265582.0
I'm not interested in volunteer, I'm interested in getting paid, and the
best way I believe I can accomplish that is use *my* bitcoin address in a
signature-transaction of the code I've reviewed.
What is the advantage of PGP? Far more people have ECDSA public-private
keys than PGP keys.
--
----------------------------------------------------------------------------
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 17: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 17: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 17: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 17:25:28

- reply

📅 Original date posted:2014-08-19
📝 Original message:On Tue, Aug 19, 2014 at 04:58:48PM +0200, Wladimir wrote:
> On Tue, Aug 19, 2014 at 2:02 PM, Jeff Garzik <jgarzik at bitpay.com> 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.
>
> Despite my complaining about github, I don't like the idea of moving
> somewhere else. The current way of working - to use github for storing
> the tree, and use a custom script for signing+merging - is fine with
> me.
>
> Github has a low barrier to contribution. Almost every open source
> developer already has a github account. Switching to something
> self-hosted makes it more difficult for people to contribute.
>
> Plus if we have to take the hosting upon ourselves, we have to handle
> sysadmin work ourselves as well. That's not a good use of the limited
> manpower available.
>
> Also it will be a lot of work to migrate over all the current issues
> and pulls. I don't look forward to that. I don't see the point of
> this, sorry.
>
> Wladimir
If a project cannot be organized enough to run its own hosting/web presense/
counterintelligence/security that starts with installing an OS and patching
kernels, then it is really not wise for me to trust my financial future to
software written by such a group.
There is a great deal of 'work' that is really quite pointless, particularly
in regards to claims I see about security that are irrelevant unless you
have the understanding that comes from operating and running your own
servers.
This includes running DDOS protection, so no cloudflare.
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.
--
----------------------------------------------------------------------------
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 17: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 17:20:00

- reply

📅 Original date posted:2014-04-25
📝 Original message:Do it. Someone will scream harm. The loudest voices screaming how it would
be harmful are doing the most harm.
The only way to know is build it, and test it. If the network breaks, then
it is better we find out sooner rather than later.
My only suggestion is call it 'bitstake' or something to clearly differentiate
it from Bitcoin. This also might be an interesting application of the side
chains concept Peter Todd has discussed.
On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote:
> Hello all.
>
> I understand that Proof-of-Stake as a replacement for Proof-of-Work is a prohibited yet disputed change to Bitcoin Core. I would like to create a Bitcoin branch that provides a sandboxed testbed for researching the best PoS implementations. In the years to come, perhaps circumstances might arise, such as shifting of user opinion as to whether PoS should be moved from the prohibited list to the hard-fork list.
> -----
>
> A poll I conducted today on bitcointalk, https://bitcointalk.org/index.php?topic=581635.0 with an attention-grabbing title suggests some minority support for Bitcoin Proof-of-Stake. I invite any of you to critically comment on that thread.
>
> "Annual 10% bitcoin dividends can be ours if Proof-of-Stake full nodes outnumber existing Proof-of-Work full nodes by three-to-one. What is your choice?"
>
> "I do not care or do not know enough." - 5 (16.1%)
> "I would download and run the existing Proof-of-Work program to fight the change." - 14 (45.2%)
> "I would download and run the new Proof-of-Stake program to favor the change. " - 12 (38.7%)
> Total Voters: 31
> -----
>
> Before I branch the source code and learn the proper way of doing things in this community, I ask you simply if creating the branch is harmful? My goal is to develop, test and document PoS, while exploring its vulnerabilities and fixing them in a transparent fashion.
>
> Thanks for taking a bit of your time to read this message.
--
----------------------------------------------------------------------------
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 17:19:42

- reply

📅 Original date posted:2014-04-30
📝 Original message:On Wed, Apr 30, 2014 at 11:00:06PM +1000, Gareth Williams wrote:
> On 30/04/14 00:13, Mike Hearn wrote:
> > I do think we need to move beyond this idea of Bitcoin being some kind
> > of elegant embodiment of natural mathematical law. It just ain't so.
>
> I haven't seen anybody arguing that it is.
>
> Bitcoin is the elegant embodiment of /artificially contrived/
> mathematical rules, which just so happen to be very useful in their
> current configuration :-P
>
> Nobody is saying those rules are immutable. Just that it isn't sensible
> to undermine them by introducing imprecise and unpredictable elements
> like human politics.
As an end-user of Bitcoin, the whole possible value of a set of mathematical
rules has become completely trashed by the imprecise and unpredictable behavior
of buyers and sellers.
If the rules are not responsive to real human needs, bitcoin is worthless
as a long-term store of value because **my idea of value** changes over time.
This implies, in my mind, an absolutely requirement to attempt to gather
some useful signal from the human political noise.
How do you determine what that signal is, so you can **change the rules**
and the mathematics so it makes more sense?
You've got to deal with politics, one way or another.
--
----------------------------------------------------------------------------
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 17:17:33

- reply

📅 Original date posted:2014-04-07
📝 Original message:I understand the theoretical benefits of multi-sig. But if you want
to make this mind-numbingly simple, do it on the *existing* single-sig.
But why in the world do we not have a *business* that offers bitcoin
wallet insurance? The bitcoin world (and this list) ran around blaming
MtGox and users for being 'stupid' to trust mtgox.
So start a multi-level marketing business that offers *insurance* so
if your bitcoin wallet gets hacked/stolen/whatever, your 'upstream'
or whomever sold you the wallet comes to your house with a new
computer or installs the new wallet software, or whatever, or just
makes it good.
Now, if the **insurance underwriter** decides that multisig will
reduce fraud, and **tests it**, then I'd say we do multi-sig. But right
now we are just a bunch of technology wizards trying to force our own
opinions about what's right and 'simple' for end users without ever
asking the damn end-users.
And then we call the end-users idiots because some scammer calls them
and says "I'm calling from Microsoft and your computer is broke, please
download this software to fix it".
Multi-sig is more magical moon-math that scammers will exploit to con
your grandma out of bitcoin, and then your friends will call her a stupid
luddite for falling for it.
Fix the cultural victim-blaming bullshit and you'll fix the node bleeding
problem.
On Mon, Apr 07, 2014 at 10:15:15AM -0400, Eric Martindale wrote:
> We need to make it so mind-numbingly simple to "run Bitcoin correctly" that
> the average user doesn't find reasons to do so in the course of normal
> use. Right now, Coinbase and Bitstamp are winning in the user experience
> battle, which technically endanger the user, and by proxy the Bitcoin
> network.
>
> Multi-sig as a default is a start. It won't succeed unless the user
> experience is simply better than trusted third parties, but we need to
> start the education process with the very basic fundamental: trusting a
> third-party with full access to your Bitcoin is just replacing one
> centralized banking system with another.
>
> Eric Martindale
> Developer Evangelist, BitPay
> +1 (919) 374-2020
> On Apr 7, 2014 7:05 AM, "Mike Hearn" <mike at plan99.net> wrote:
>
> > My guess is that a large number of users have lost interest after they
> >> lost their money in MtGox. The 24th of February coincides with the
> >> "final" shutdown
> >
> >
> > Sigh. It would not be surprising if MtGox has indeed dealt the community a
> > critical blow in this regard. TX traffic is down since then too:
> >
> >
> > https://blockchain.info/charts/n-transactions-excluding-popular?timespan=60days&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=
> >
> > Judging from comments and the leaked user db, it seems a lot of well known
> > people lost money there (not me fortunately). I wish I could say people
> > have learned but from the size of the deposit base at Bitstamp they clearly
> > have not. A lot of Bitcoin users don't seem to be ready to be their own
> > bank, yet still want to own some on the assumption everyone else either is
> > or soon will be. So it's really only a matter of time until something goes
> > wrong with some large bitbank again, either Bitstamp or Coinbase.
> >
> > Some days I wonder if Bitcoin will be killed off by people who just refuse
> > to use it properly before it ever gets a chance to shine. The general
> > public doesn't distinguish between "Bitcoin users" who deposit with a third
> > party and the real Bitcoin users who don't.
> >
> >
> > ------------------------------------------------------------------------------
> > Put Bad Developers to Shame
> > Dominate Development with Jenkins Continuous Integration
> > Continuously Automate Build, Test & Deployment
> > Start a new project now. Try Jenkins in the cloud.
> > http://p.sf.net/sfu/13600_Cloudbees_APR
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
> _______________________________________________
> 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 17: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 17: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 17: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 17:16:00

- reply

📅 Original date posted:2014-03-23
📝 Original message:On Sat, Mar 22, 2014 at 03:08:25PM -0400, Peter Todd wrote:
> On Sat, Mar 22, 2014 at 10:08:36AM -0500, Troy Benjegerdes wrote:
> > On Sat, Mar 22, 2014 at 04:47:02AM -0400, Peter Todd wrote:
> > > There's been a lot of recent hoopla over proof-of-publication, with the
> > > OP_RETURN <data> length getting reduced to a rather useless 40 bytes at
> > > the last minute prior to the 0.9 release. Secondly I noticed a
> > > overlooked security flaw in that OP_CHECKMULTISIG sigops weren't taken
> > > into account, making it possible to broadcast unminable transactions and
> > > bloat mempools.(1) My suggestion was to just ditch bare OP_CHECKMULTISIG
> > > outputs given that the sigops limit and the way they use up a fixed 20
> > > sigops per op makes them hard to do fee calculations for. They also make
> > > it easy to bloat the UTXO set, potentially a bad thing. This would of
> > > course require things using them to change. Currently that's just
> > > Counterparty, so I gave them the heads up in my email.
> >
> > I've spend some time looking at the Datacoin code, and I've come to the
> > conclusion the next copycatcoin I release will have an explicit 'data'
> > field with something like 169 bytes (a bakers dozen squared), which will
> > add 1 byte to each transaction if unused, and provide a small, but usable
> > data field for proof of publication. As a new coin, I can also do a
> > hardfork that increases the data size limit much easier if there is a
> > compelling reason to make it bigger.
> >
> > I think this will prove to be a much more reliable infrastructure for
> > proof of publication than various hacks to overcome 40 byte limits with
> > Bitcoin.
> >
> > I am disclosing this here so the bitcoin 1% has plenty of time to evaluate
> > the market risk they face from the 40 byte limit, and put some pressure to
> > implement some of the alternatives Todd proposes.
>
> Lol! Granted, I guess I should "disclose" that I'm working on tree
> chains, which just improve the scalability of blockchains directly. I'm
> think tree-chains could be implemented as a soft-fork; if applied to
> Bitcoin the datacoin 1% might face market risk. :P
Soft-fork tree chains with reasonable data/memo/annotation storage would be
extremely interesting. The important question, however, is how does one
build a *business* around such a thing, including getting paid as a developer.
What I find extremely relevant to the **bitcoin-dev** list are discussions
about how to motivate the people who own the hashrate and bulk of the coins
(aka, the bitcoin 1%) to PAY DEVELOPERS, and thus it is good marketing FOR
BITCOIN DEVELOPERS to remind the people who profit from our efforts they need
to make it profitable for developers to work on bitcoin.
If it's more profitable for innovative developers to premine and release
$NEWCOIN-blockchain than it is to work on Bitcoin-blockchain, is that a valid
discussion for this list? Or do you just want to stick your heads in the sand
while VC's look to disrupt Bitcoin?

2023-06-07 17:15:59

- reply

📅 Original date posted:2014-03-25
📝 Original message:On Mon, Mar 24, 2014 at 01:57:14PM -0700, Mark Friedenbach wrote:
> On 03/24/2014 01:34 PM, Troy Benjegerdes wrote:
> > I'm here because I want to sell corn for bitcoin, and I believe it will be
> > more profitable for me to do that with a bitcoin-blockchain-based system
> > in which I have the capability to audit the code that executes the trade.
>
> A discussion over such a system would be on-topic. Indeed I have made my
> own proposals for systems with that capability in the past:
>
> http://sourceforge.net/p/bitcoin/mailman/message/31322676/
>
> There's no reason to invoke alts however. There are ways where this can
> be done within the bitcoin ecosystem, using bitcoins:
>
> http://sourceforge.net/p/bitcoin/mailman/message/32108143/
>
> > I think that's fair, so long as we limit bitcoin-development discussion to
> > issues that are relevant to the owners of the hashrate and companies that
> > pay developer salaries.
> >
> > What I'm asking for is some honesty that Bitcoin is a centralized system
> > and to stop arguing technical points on the altar of distributed/decentralized
> > whatever. It's pretty clear if you want decentralized you should go with
> > altchains.
>
> Bitcoin is not a centralized system, and neither is its development. I
> don't even know how to respond to that. Bringing up altchains is a total
> red herring.
>
> This is *bitcoin*-development. Please don't make it have to become a
> moderated mailing list.
When I can pick up a miner at Best Buy and pay it off in 9 months I'll
agree with you that bitcoin *might* be decentralized. Maybe there's a
chance this *will* happen eventually, but right now we have a couple of
mining cartels that control most of the hashrate.
There are plenty of interesting alt-hash-chains for which mass produced,
general purpose (or gpgpu-purpose) hardware exists and is in high volume
mass production.

2023-06-07 17:15:58

- reply

📅 Original date posted:2014-03-23
📝 Original message:> > Right, but there's also a lot of the community who thinks
> > proof-of-publication applications are bad and should be discouraged. I
> > argued before that the way OP_RETURN was being deployed didn't actually
> > give any reason to use it vs. other data encoding methods.
> >
> > Unfortunately underlying all this is a real ignorance about how Bitcoin
> > actually works and what proof-of-publication actually is:
>
> I understand that proof of publication is not the same thing as
> regular timestamping, but requiring permanent storage in the
> blockchain is not the only way you can implement proof of publication.
> Mark Friedenbach proposes this:
>
> Store hashes, or a hash root, and soft-fork that blocks are only
> accepted if (a) the data tree is provided, or (b) sufficient work is
> built on it and/or sufficient time has passed
>
> This way full nodes can ignore the published data until is sufficiently buried.
>
> > I think we're just going to have to agree to disagree on our
> > interpretations of the economics with regard to attacking merge-mined
> > chains. Myself, I'm very, very wary of systems that have poor security
> > against economically irrational attackers regardless of how good the
> > security is, in theory, against economically rational ones.
>
> The attacker was of course economically irrational in my previous
> example for which you didn't have any complain. So I think we can
> agree that a merged mined separated chain is more secure than a
> non-merged mined separated chain and that attacking a merged mined
> chain is not free.
> By not being clear on this you're indirectly promoting non-merged
> mined altchains as a better option than merged mined altchains, which
> is what I don't think is responsible on your part.
>
I can't speak for Peter, but *I* am currently of the opinion that non-merged
mined altchains using memory-hard proof-of-work are a far better option than
sha-256 merged-mined altchains. This is not a popular position on this list,
and I would like to respectfully disagree, but still collaborate on all the
other things where bitcoin-core *is* the best-in-class code available.
A truly 'distributed' system must support multiple alchains, and multiple
proof-of-work hash algorithms, and probably support proof-of-stake as well.
If sha-256 is the only game in town the only advantage over the federal
reserve is I can at least audit the code that controls the money supply,
but it's not in any way distributed if the hash power is concentrated
among 5-10 major pools and 5-10 sha-256 asic vendors.
I find it very irresponsible for Bitcoiners to on one hand extol the virtues
of distributed systems and then in the same message claim any discussion
about alternate chains as 'off-topic'.
If bitcoin-core is for *distributed systems*, then all the different altcoins
with different hash algorithms should be viable topics for discussion.
----------------------------------------------------------------------------
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 17:15:58

- reply

📅 Original date posted:2014-03-24
📝 Original message:I think that's fair, so long as we limit bitcoin-development discussion to
issues that are relevant to the owners of the hashrate and companies that
pay developer salaries.
What I'm asking for is some honesty that Bitcoin is a centralized system
and to stop arguing technical points on the altar of distributed/decentralized
whatever. It's pretty clear if you want decentralized you should go with
altchains.
I'm here because I want to sell corn for bitcoin, and I believe it will be
more profitable for me to do that with a bitcoin-blockchain-based system
in which I have the capability to audit the code that executes the trade.
On Sun, Mar 23, 2014 at 04:53:48PM -0700, Mark Friedenbach wrote:
> This isn't distributed-systems-development, it is bitcoin-development.
> Discussion over chain parameters is a fine thing to have among people
> who are interested in that sort of thing. But not here.
>
> On 03/23/2014 04:17 PM, Troy Benjegerdes wrote:
> > I find it very irresponsible for Bitcoiners to on one hand extol the virtues
> > of distributed systems and then in the same message claim any discussion
> > about alternate chains as 'off-topic'.
> >
> > If bitcoin-core is for *distributed systems*, then all the different altcoins
> > with different hash algorithms should be viable topics for discussion.

2023-06-07 17:15:38

- reply

📅 Original date posted:2014-03-13
📝 Original message:<cynic hat: on>
Every volatility bump messes up expectations of what a bitcoin is worth,
so why are we bikeshedding uBTC vs mBTC? Just be done with it and do mBTC
now, and plan uBTC for just after the next price spike to $10KUSD or whatever,
and then plan on rolling back to mBTC when the price crashes from altcoin
money supply inflation competition.
On Thu, Mar 13, 2014 at 09:45:54AM -0400, Jeff Garzik wrote:
> <vendor hat: on>
>
> Based on this seeming consensus, BitPay was headed towards uBTC
> internally, and hoped to coordinate messaging and rollout with others
> in the community. Ah well, proceed apace, and Bitcoin Wallet will
> catch up, I suppose.
>
> Multiple unit changes negatively impact users, but we are already there :/
>
>
> On Thu, Mar 13, 2014 at 9:34 AM, Wladimir <laanwj at gmail.com> wrote:
> >
> > On Thu, Mar 13, 2014 at 1:56 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> >>
> >> Resurrecting this topic. Bitcoin Wallet moved to mBTC several weeks
> >> ago, which was disappointing -- it sounded like the consensus was
> >> uBTC, and moving to uBTC later --which will happen-- may result in
> >> additional user confusion, thanks to yet another decimal place
> >> transition.
> >
> >
> > I've kind of given up getting any consensus about this, or even getting
> > people to care.
> >
> > Everyone agrees that a decimal shift would be good, but it's the same boring
> > shed painting discussion every time on how many decimals. In the end nothing
> > happens.
> >
> > I can't really blame Andreas for finally taking action and making the change
> > to mBTC. People in the community are familiar with mBTC because some
> > exchanges and price sites used mBTC (at least for a while when >$1000), also
> > mBTC seems to be catching on on reddit etc.
> >
> > Moving to muBTC (which in itself would be better because it is the final
> > unit change ever needed without hardfork) would require more coordinated
> > education effort.
> >
> > Wladimir
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> 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 17: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 17:14:46

- reply

📅 Original date posted:2014-03-25
📝 Original message:This *could* be a useful feature, but only if it's generalizable to
other processor architectures, and **in particular** has an implementation
using dedicated silicon that has a **public** open-source hardware layout,
so you can X-ray the chip, and confirm with a thermal imager that yes, the
encryption code is actually running where you think it's running.
I was *almost* convinced that the 'new key per address' was a good idea
to mitigate ECDSA side channel attacks. Now, however, I find it quite
plausible that intelligence agencies are promoting 'new key per transaction'
as a way to make sure all your keys are leaked all over RAM and the nearby
electromagnetic spectrum with side channels intentionally embedded in
commodity hardware.
If you want to convince me otherwise, then help me crowdfund an open-source
hardware Bitcoin ASIC that does the crypto and stores your private keys.
I expect the 'new key per transaction' crowd will be in for a rude awakening
when they finally understand the silicon area cost to do this securely.
Conclusion: Not only is 'de-prioritizing address re-use' BAD privacy, it
provides a social engineering/key leakage attack vector where someone can
track you down from the EMF generated by your bitcoin wallet when they send
you money.
If you think otherwise, let's build some ficking open-source hardware and
find out how much silicon this will cost.
Although it's probably more profitable to just build a bitcoin wallet
detector and keep your mouth shut.
On Thu, Mar 06, 2014 at 11:00:14AM +0100, Natanael wrote:
> You've heard of TRESOR?
>
> No, not Trezor.
>
> https://en.wikipedia.org/wiki/TRESOR
>
> Signing on the CPU, without touching RAM.
>
> - Sent from my phone
> Den 6 mar 2014 09:41 skrev "Mike Hearn" <mike at plan99.net>:
>
> > I'm wondering about whether (don't laugh) moving signing into the kernel
> > and then using the MTRRs to disable caching entirely for a small scratch
> > region of memory would also work. You could then disable pre-emption and
> > prevent anything on the same core from interrupting or timing the signing
> > operation.
> >
> > However I suspect just making a hardened secp256k1 signer implementation
> > in userspace would be of similar difficulty, in which case it would
> > naturally be preferable.
> >
> >
> > On Wed, Mar 5, 2014 at 11:25 PM, Gregory Maxwell <gmaxwell at gmail.com>wrote:
> >
> >> On Wed, Mar 5, 2014 at 2:14 PM, Eric Lombrozo <elombrozo at gmail.com>
> >> wrote:
> >> > Everything you say is true.
> >> >
> >> > However, branchless does reduce the attack surface considerably - if
> >> nothing else, it significantly ups the difficulty of an attack for a
> >> relatively low cost in program complexity, and that might still make it
> >> worth doing.
> >>
> >> Absolutely. I believe these things are worth doing.
> >>
> >> My comment on it being insufficient was only that "my signer is
> >> branchless" doesn't make other defense measures (avoiding reuse,
> >> multsig with multiple devices, not sharing hardware, etc.)
> >> unimportant.
> >>
> >> > As for uniform memory access, if we avoided any kind of heap
> >> allocation, wouldn't we avoid such issues?
> >>
> >> No. At a minimum to hide a memory timing side-channel you must perform
> >> no data dependent loads (e.g. no operation where an offset into memory
> >> is calculated). A strategy for this is to always load the same values,
> >> but then mask out the ones you didn't intend to read... even that I'd
> >> worry about on sufficiently advanced hardware, since I would very much
> >> not be surprised if the processor was able to determine that the load
> >> had no effect and eliminate it! :) )
> >>
> >> Maybe in practice if your data dependencies end up only picking around
> >> in the same cache-line it doesn't actually matter... but it's hard to
> >> be sure, and unclear when a future optimization in the rest of the
> >> system might leave it exposed again.
> >>
> >> (In particular, you can't generally write timing sign-channel immune
> >> code in C (or other high level language) because the compiler is
> >> freely permitted to optimize things in a way that break the property.
> >> ... It may be _unlikely_ for it to do this, but its permitted— and
> >> will actually do so in some cases—, so you cannot be completely sure
> >> unless you check and freeze the toolchain)
> >>
> >> > Anyhow, without having gone into the full details of this particular
> >> attack, it seems the main attack point is differences in how squaring and
> >> multiplication (in the case of field exponentiation) or doubling and point
> >> addition (in the case of ECDSA) are performed. I believe using a branchless
> >> implementation where each phase of the operation executes the exact same
> >> code and accesses the exact same stack frames would not be vulnerable to
> >> FLUSH+RELOAD.
> >>
> >> I wouldn't be surprised.
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Subversion Kills Productivity. Get off Subversion & Make the Move to
> >> Perforce.
> >> With Perforce, you get hassle-free workflows. Merge that actually works.
> >> Faster operations. Version large binaries. Built-in WAN optimization and
> >> the
> >> freedom to use Git, Perforce or both. Make the move to Perforce.
> >>
> >> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Subversion Kills Productivity. Get off Subversion & Make the Move to
> > Perforce.
> > With Perforce, you get hassle-free workflows. Merge that actually works.
> > Faster operations. Version large binaries. Built-in WAN optimization and
> > the
> > freedom to use Git, Perforce or both. Make the move to Perforce.
> >
> > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&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 17:13:35

- reply

📅 Original date posted:2014-02-10
📝 Original message:If you've got any ideas for a better forum, let me know.
MtGox is one of the largest public faces of the code being developed here. If
the public perception is that this is a bitcoin protocol flaw, then we need
some damned strong and compelling public arguments about why it ain't so. But
after some thought, that's not the critical issue I want to raise on this list.
If something about the implementation, the protocol, of bitcoin-qt or bitcoind
makes it easy for an attacker to mutate transactions and hard for an 'end-user'
such as MtGox to confirm payments, then we've got a fundamental user-interface
flaw.
We can get all indignant about RTFM or telling the users they are idiots, but
that's not really going to be good for long-term adoption and use.
My opinion is part of the development process should be to react to public
perceptions of how the code is being used (and mis-used), and how the market is
being manipulated, and try to improve it so the whole system is stable,
predictable, and friendly to users.
On Mon, Feb 10, 2014 at 01:45:58PM -0500, Jameson Lopp wrote:
> You have plenty of good points, but they are not relevant to this mailing list. I suggest you take them elsewhere.
> --
> Jameson Lopp
> Software Engineer
> Bronto Software, Inc
>
> On 02/10/2014 01:25 PM, Troy Benjegerdes wrote:
> > On Mon, Feb 10, 2014 at 08:45:03AM -0800, Gregory Maxwell wrote:
> >> On Mon, Feb 10, 2014 at 8:30 AM, Troy Benjegerdes <hozer at hozed.org> wrote:
> >>> Name me one single person with commit access to the bitcoin github repository
> >>> who is *independent* of any venture capital or other 'investment' connections.
> >>
> >> I am, unless you count the fact that I own some Bitcoin and some
> >> mining hardware as "'investment' connections" (and that case your
> >> comments are worthless).
> >>
> >> (By not naming anyone else I don't mean to imply there are no others,
> >> but I don't want to speak for anyone else. Nor would I necessarily
> >> expect the other part(ies|y) to step forward, since this mostly
> >> appears to be an invitation to step up and be attacked.)
> >
> > Thank you.
> >
> > I also appreciate your commentary[1], and willingness to list your investment
> > position. What I'm concerned about are people who have signed non-disclosure
> > agreements or who's salary/equity/whatever depend on people who are experts
> > at manipulating markets to take naive investors money.
> >
> > Independent is also a state of mind as much as it is about financial connections.
> >
> > What pisses me off here is that a huge amount of wealth just changed hands based
> > on MtGox's press release, and it stinks of insider trading. I still maintain the
> > best outcome would be for MtGox to AGPLv3 release their code, and then those of
> > us that understand it would be able to have a public technical discussion about
> > how to fix it, and MtGox would still maintain their intellectual property
> > ownership position.
> >
> > This, however, cuts off a significant revenue stream for people who take money
> > making market bets 5 minutes before the information goes public, so I expect
> > the likelyhood of such an outbreak of sanity is quite low.
> >
> > [1] http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/
> >
> >
> > DISCLAIMER: I have a significant emotional investment in copyleft/viral copyright
> > development models, and I expect to take a lot of money charging people to write
> > code I give away for free. I also occasionally make money from cryptocurrency
> > mining, but only when I can sell it in functional and transparent markets.
> >
> > ------------------------------------------------------------------------------
> > Android™ apps run on BlackBerry®10
> > Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> > Now with support for Jelly Bean, Bluetooth, Mapview and more.
> > Get your Android app in front of a whole new audience. Start now.
> > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
> ------------------------------------------------------------------------------
> Androi apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 17:13:34

- reply

📅 Original date posted:2014-02-10
📝 Original message:On Mon, Feb 10, 2014 at 03:40:03PM +0100, Isidor Zeuner wrote:
> >
> > What is the official response from the Bitcoin Core developers about
> > MtGox's assertion that their problems are due to a fault of bitcoin, as
> > opposed to a fault of their own?
> >
> > The technical analysis preluding this mess, was that MtGox was at fault for
> > their faulty wallet implementation.
> >
>
> I'm not a core developer, but I would certainly hope that those
> who have commit access to the Bitcoin repository don't let
> themselves be pressured by a company holding back user funds in order
> to get a patch included into the Bitcoin source code.
This isn't about developers.
This is about venture capitalists taking lots of money from unsuspecting
investors, and MtGox is in a psy-ops PR-war with multiple other exchanges
and lots of places that would like to take their market share and money.
Why do you want the 'official' PR-spin-war response approved by the official
bitcoin developer PR-firm, who's probably being paid by competitors to MtGox?
Name me one single person with commit access to the bitcoin github repository
who is *independent* of any venture capital or other 'investment' connections.
Fortunately for the rest of us, any dumb farmer can create a copycatcoin
Hell, if MtGox hosted their *own* fork of bitcoin I'd run that in a heartbeat.
And for full disclosure, I am available for consulting if anyone would like
assistance setting up and hosting an independent source code repository that
includes good automated regression tests.
-- Troy

2023-06-07 17:13:34

- reply

📅 Original date posted:2014-02-10
📝 Original message:On Mon, Feb 10, 2014 at 08:45:03AM -0800, Gregory Maxwell wrote:
> On Mon, Feb 10, 2014 at 8:30 AM, Troy Benjegerdes <hozer at hozed.org> wrote:
> > Name me one single person with commit access to the bitcoin github repository
> > who is *independent* of any venture capital or other 'investment' connections.
>
> I am, unless you count the fact that I own some Bitcoin and some
> mining hardware as "'investment' connections" (and that case your
> comments are worthless).
>
> (By not naming anyone else I don't mean to imply there are no others,
> but I don't want to speak for anyone else. Nor would I necessarily
> expect the other part(ies|y) to step forward, since this mostly
> appears to be an invitation to step up and be attacked.)
Thank you.
I also appreciate your commentary[1], and willingness to list your investment
position. What I'm concerned about are people who have signed non-disclosure
agreements or who's salary/equity/whatever depend on people who are experts
at manipulating markets to take naive investors money.
Independent is also a state of mind as much as it is about financial connections.
What pisses me off here is that a huge amount of wealth just changed hands based
on MtGox's press release, and it stinks of insider trading. I still maintain the
best outcome would be for MtGox to AGPLv3 release their code, and then those of
us that understand it would be able to have a public technical discussion about
how to fix it, and MtGox would still maintain their intellectual property
ownership position.
This, however, cuts off a significant revenue stream for people who take money
making market bets 5 minutes before the information goes public, so I expect
the likelyhood of such an outbreak of sanity is quite low.
[1] http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/
DISCLAIMER: I have a significant emotional investment in copyleft/viral copyright
development models, and I expect to take a lot of money charging people to write
code I give away for free. I also occasionally make money from cryptocurrency
mining, but only when I can sell it in functional and transparent markets.