Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-19 Thread Bryan Bishop
On Fri, Jun 19, 2015 at 5:45 AM, Dr Adam Back wrote:

 payment protocol layer in my view.  (If thats not obvious to some
 lurkers I elaborate on that argument  amongst other things here: )

Someone might find it more convenient to consume that in the form of text

- Bryan
1 512 203 0507
Bitcoin-development mailing list

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread Bryan Bishop
On Thu, Jun 18, 2015 at 5:00 AM, Mike Hearn wrote:

 Dude, calm down.

Well hold on, his concerns are real and he seems perfectly calm to me and
others apparently.

 and Gavin already said long ago he wouldn't just commit something, even
 though he has the ability to do so.

Nobody is worried about Gavin or anyone else making commits to git
repositories. You'll notice that this wasn't even mentioned in the original
email you were replying to. Instead, the email was talking about commit
access, which is a property of GitHub's repositories.

So why did I say it? Because it's consistent with what I've always said:

(That's not a good reason.)

you cannot run a codebase like Wikipedia

Wikipedia is a top-down centralized authority-based hierarchy. That's
pretty close to what you're proposing. That's what everyone else is
disagreeing with. You seem to have switched your position mid-flight...?

This is not a radical position. That's how nearly all coding projects work.
 I have been involved with open source for 15 years and the 'single
 maintainer who makes decisions' model is normal, even if in some large
 codebases  subsystems have delegated submaintainers.

There are a number of reasons why that perspective is broken; throughout
our conversations others have repeatedly reminded you (such as in -wizards)
that forking an open-source repository is not at all like a hard-fork of
the blockchain. Anyone can be glorious leader of any repository they want,
that's how open-source works. However, it's critical that bitcoin users are
never convinced to trust BDFLs or anything else that can be compromised.
Should all bitcoin users suddenly start using software with BDFLs, even
multiple implementations with separate BDFLs, then those users can be
trivially compromised through their trust in those individuals and projects.

The alternative is that every developer and every user is personally
responsible for self-validation of the rules, checking for correctness and
validity. Happy coincidence that this seems to match the strategy of
operating the bitcoin network itself, which is to run a node that sees
everything and validates all the transactions. Anyone is able to find an
error in logic or flaw in the system rules, and they should make it known
as widely as possible so that others may evaluate the evidence and consider
which solutions preserve the important properties of the system. This is
not a matter of majorities or minorities; these arguments should be true
for anyone independent of who or what they are, or what level of
unpopularity they may have.

Anything other than this is somewhat radical, and I am confused as to why
others have been talking about developer consensus. I suspect that the
reason why they have been saying developer consensus is because they are
talking about the Bitcoin Core project on GitHub at the moment. But the
topic switched to contentious hard-forks already, which is not a topic of
repositories but a topic of the blockchain and network; and in the context
of contentious hard-forks it is clear why everyone individually must
evaluate the rules and decide whether they the software is correct, or
whether changes can trivially cause catastrophic broken hard-forks. These
lines of reasoning should be true for everyone, and not merely true for one
person but not another. Users, companies and developers must be aware of
this, even though it's different from their usual expectations of how
systems operate and are maintained. And it is important to be careful to
not misconstrue this to others because it is entirely possible to
unintentionally convince others that traditional and centralized models are
safely applicable here.

I realise some people think this anti-process leads to better decision
 making. I disagree. It leads to no decision making, which is not the same
 thing at all.

Well, if you're talking about the recent disputes regarding a certain patch
to hard-fork the blockchain, a decision to not include such a patch seems
like the very definition of a decision.

Gavin and I say - there is a process, and that process is a hard fork of
 the block chain.

I doubt that other bitcoin software maintainers would agree with that sort
of toxic reasoning; contentious hard-forks are basically a weapon of war
that you can use against any other collaborator on any bitcoin project. Why
would anyone want to collaborate on such a hostile project? How would they
even trust each other?

- Bryan
1 512 203 0507
Bitcoin-development mailing list

Re: [Bitcoin-development] Scaling Bitcoin with Subchains

2015-05-27 Thread Bryan Bishop
On Wed, May 27, 2015 at 9:16 PM, Andrew wrote:

 You should also keep in mind the big picture when it comes to
 decentralization. If the hard drives (or tapes) can only be produced by a
 small number of large companies like Western Digital or Seagate, then you
 can't really count those for a decentralized system. A truly decentralized
 system would have the devices needed to participate in (and verify) the
 system be easily created by a regular user of the system without relying on
 a central power. So for example, the hard drives needed to store the
 bitcoin transaction records should be able to be produced at a regular
 person's home on a 3D printer starting from just the raw materials. I don't
 know how close we are to this ideal, but just pointing out that it needs to
 be considered. This is also a reason why I like that Bitcoin uses the
 simple SHA sum for mining instead of a more complicated function such as
 scrypt. It makes it easier for small scale entities to understand and to
 produce the ASIC miners.

I am a huge fan of do-it-yourself at-home ASIC manufacturing. The original
4004 and earlier devices are within the scope of what could be accomplished
in a home environment. The homecmos project is an interesting glimpse at
these possibilities. Relevant-scale mining will most likely never be an
option for home manufacturing, but bitcoin wallets and other devices can
definitely be etched by hand or using maskless projector lithography.

Here's what the homecmos group was up to:

LCD projection lithography:

DMD lithography:

There's actually a method of doing this with conventional camera roll film:

- Bryan
1 512 203 0507
Bitcoin-development mailing list

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-08 Thread Bryan Bishop
On Fri, May 8, 2015 at 2:20 AM, Matt Whitlock wrote:
 - Perhaps the hard block size limit should be a function of the actual block 
 sizes over some
 trailing sampling period. For example, take the median block size among the 
 most recent
 2016 blocks and multiply it by 1.5. This allows Bitcoin to scale up gradually 
 and organically,
 rather than having human beings guessing at what is an appropriate limit.

Block contents can be grinded much faster than hashgrinding and
mining. There is a significant run-away effect there, and it also
works in the gradual sense as a miner probabilistically mines large
blocks that get averaged into that 2016 median block size computation.
At least this proposal would be a slower way of pushing out miners and
network participants that can't handle 100 GB blocks immediately..  As
the size of the blocks are increased, low-end hardware participants
have to fall off the network because they no longer meet the minimum
performance requirements. Adjustment might become severely mismatched
with general economic trends in data storage device development or
availability or even current-market-saturation of said storage
devices. With the assistance of transaction stuffing or grinding, that
2016 block median metric can be gamed to increase faster than other
participants can keep up with or, perhaps worse, in a way that was
unintended by developers yet known to be a failure mode. These are
just some issues to keep and mind and consider.

- Bryan
1 512 203 0507

One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.;117567292;y
Bitcoin-development mailing list

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Bryan Bishop
On Thu, May 7, 2015 at 9:05 AM, Mike Hearn wrote:
 Maybe you dislike that idea. It's so  centralised. So let's say Gavin
 commits his patch, because his authority is equal to all other committers.
 Someone else rolls it back. Gavin sets up a cron job to keep committing the
 patch. Game over.

 You cannot have committers fighting over what goes in and what doesn't.
 That's madness. There must be a single decision maker for any given

Hmm, git repositories don't quite work like that. Instead, you should
imagine everyone having a local copy of the git repository. Each
developer synchronizes their git repository with other developers.
They merge changes from specific remote branches that they have
received. Each developer has their own branch and each developer is
the single decision maker for the artifact that they compile.

- Bryan
1 512 203 0507

One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.;117567292;y
Bitcoin-development mailing list

Re: [Bitcoin-development] Block Size Increase

2015-05-06 Thread Bryan Bishop
On Wed, May 6, 2015 at 5:12 PM, Matt Corallo wrote:
 the maximum block size. However, there hasnt been any discussion on this
 mailing list in several years as far as I can tell.

Well, there has been significant public discussion in #bitcoin-wizards
on which is available in public logs, specifically
about why increasing the max block size is kicking the can down the
road while possibly compromising blockchain security. There were many
excellent objections that were raised that, sadly, I see are not
referenced at all in the recent media blitz. Frankly I can't help but
feel that if contributions, like those from #bitcoin-wizards, have
been ignored in lieu of technical analysis, and the absence of
discussion on this mailing list, that I feel perhaps there are other
subtle and extremely important technical details that are completely
absent from this--and other-- proposals. I have some rather general
thoughts to offer.

Secured decentralization is the most important and most interesting
property of bitcoin. Everything else is rather trivial and could be
achieved millions of times more efficiently with conventional
technology. Our technical work should be informed by the technical
nature of the system we have constructed.

I suspect that as bitcoin continues to grow in all dimensions and
metrics, that we will see an unending wave of those who are excited by
the idea of Something Different in the face of archaic, crumbling
software and procedures in the rest of the financial world. Money has
found its way into every aspect of human life. There's no doubt in my
mind that bitcoin will always see the most extreme campaigns and the
most extreme misunderstandings. Like moths to a flame or water in the
desert, almost everyone is excited by ANY status quo change
whatsoever. This is something that we have to be vigilante about,
because their excitement is motivation to do excellent work, not
simply any work. For some who are excited about general status quo
changes that bitcoin represents, they may not mind if bitcoin
decentralization disappears and is replaced with just a handful of
centralized nodes. Whereas for development purposes we must hold
ourselves to extremely high standards before proposing changes,
especially to the public, that have the potential to be unsafe and
economically unsafe. We have examples from NASA about how to engineer
extremely fault tolerant systems, and we have examples from Linux
about how to have high standards in open-source projects. Safety is
absolutely critical, even in the face of seemingly irrational
excuberance of others who want to scale to trillions of daily coffee
transactions individually stored forever in the blockchain.

When designing bitcoin or even some other system, an important design
target is what the system should be capable of. How many transactions
should the system perform? What is the correct number of transactions
for a healthy, modern civilization to perform every day? And how fast
should that (not) grow? Should we allow for 2 billion trillion coffee
transactions every day, or what about 100 trillion transactions per
second? I suspect that these sorts of questions are entirely
unanswerable and boring. So in the absence of technical targets to
reach during the design phase, I suspect that Jeff Garzik was right
when he pointed out a few months ago that bitcoin is good at
settlement and clearing. There are many potential technical solutions
for aggregating millions (trillions?) of transactions into tiny
bundles. As a small proof-of-concept, imagine two parties sending
transactions back and forth 100 million times. Instead of recording
every transaction, you could record the start state and the end state,
and end up with two transactions or less. That's a 100 million fold,
without modifying max block size and without potentially compromising
secured decentralization.

The MIT group should listen up and get to work figuring out how to
measure decentralization and its security :-). Maybe we should be
collectively pestering Andrew Miller to do this, too. No pressure,
dude. Getting this measurement right would be really beneficial
because we would have a more academic and technical understanding to
work with. I would also characterize this as high priority next to the
formally verified correctness proofs for Script and

Also, I think that getting this out in the open on this mailing list
is an excellent step forward.

- Bryan
1 512 203 0507

One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.;117567292;y

Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-12 Thread Bryan Bishop
On Wed, Mar 11, 2015 at 11:09 PM, Gregory Maxwell wrote:
 For an emergency transition the user is probably better off with an
 explicit unstructured mass private key export, and a sweep function;
 and guaranteeing compatibility with that is much easier; and because
 it moves funds in one direction there is much less chance of going
 from secure to insecure.

I haven't looked at the existing sweep implementations, but it would
be unfortunate if sweep functions were not available that create at
least the same number of keys, or possibly more, for the purposes of
sweeping. I suppose there are different levels of emergency, where
perhaps you want to sweep all at once in a single transaction and lose
out on (already nebulous) privacy benefits. I say nebulous because
broadcasting a bunch of transactions all at the same time during the
sweep can compromise privacy even when the transactions have no common
ancestor outputs.

- Bryan
1 512 203 0507

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.
Bitcoin-development mailing list

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

2015-02-22 Thread Bryan Bishop
On Sun, Feb 22, 2015 at 8:11 AM, Adam Back wrote:
 away from that too) is how about we explore ways to improve practical
 security of fast confirmation transactions, and if we find something
 better, then we can help people migrate to that before deprecating the
 current weaker 0-conf transactions.

Scenario: Users are using some system in a way that the system was not
intended to be used. Let me also further constrain the scenario and
suggest that the function (pretend that means instantaneous confirmed
transactions) that the user wants is impossible. So in this scenario,
is it your job as some developer to change the system to do something
it wasn't designed to do? I mean, you certainly weren't the one
telling them they should accept zero confirmation transactions. Also,
I make no claims as to whether this scenario maps accurately to the
current topic.

- Bryan
1 512 203 0507

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
Bitcoin-development mailing list

Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

2015-02-14 Thread Bryan Bishop
On Sat, Feb 14, 2015 at 1:04 PM, Adam Back wrote:

 That its highly complex to maintain strict consensus between bitcoin
 versions, does not justify consensus rewrite experiments

Correct. However, those maintenance costs absolutely do justify working
towards formal proofs of correctness for the existing implementation. These
plans are no secret and are publicly discussed, but I think it would be
instrumental to outsiders if the correctness plans and ongoing progress
could be mentioned whenever a warning is made about unjustified and
dangerous Bitcoin consensus rewrite attempts.

- Bryan
1 512 203 0507
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.
Bitcoin-development mailing list

Re: [Bitcoin-development] side-chains 2-way pegging (Re: is there a way to do bitcoin-staging?)

2014-10-22 Thread Bryan Bishop
On Wed, Oct 22, 2014 at 5:01 PM, Daniel Murrell wrote:
 p.s. I'm not trying to monetize this site. I just tried to make
 something I thought could be useful.

[Unsolicited administrivia follows.]

You have been posting this in a bunch of places for a while now, at
least three times today by my count on other mediums. I also observed
negative karma scores associated with these posts. Maybe you could
consider toning down the message frequency? I think by now everyone
knows you want them to use your site. I also think that in the limit
that it would be inappropriate for /everyone/ to post all possible
research sites, or even vaguely topical discussion sites, for every
paper posted. Personally, I would much rather have discussions happen
on the mailing list anyway, although if I had a different opinion I
certainly hope I would still send this message.

Thank you.

- Bryan
1 512 203 0507

Bitcoin-development mailing list

Re: [Bitcoin-development] BIP43 Purpose code for voting pool HD wallets

2014-09-25 Thread Bryan Bishop
On Thu, Sep 25, 2014 at 8:53 PM, Gregory Maxwell wrote:
 I've pinged some people privately but also pinging the list… no
 commentary on this proposal?

One possible reason is that non-subscribed users aren't able to access
the file through sourceforge. The attachment through their web
interface is giving back HTTP 500.


- Bryan
1 512 203 0507

Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
Bitcoin-development mailing list

Re: [Bitcoin-development] Reconsidering github

2014-08-19 Thread Bryan Bishop
On Tue, Aug 19, 2014 at 7:02 AM, Jeff Garzik wrote:
 As a first step, one possibility is putting the primary repo on somewhere, and simply mirroring that to github for each

Smaller first step would be to mirror the git repository on, which is necessary anyway before switching primaries.

- Bryan
1 512 203 0507

Bitcoin-development mailing list