<unnamed>

Public Key

npub1m6p5kgcd428x6pxyfege98zjmlwrdhp0gyz6pdnsvrvalscddnxqurdjn5

Profile Code

nprofile1qqsdaq6tyvx64rndqnzyu5vjn3fdlhpkmsh5zpdqkecxpkwlcvxkenqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsrqhmp0

Publishing to

relay.snort.social

nos.lol

relay.damus.io

Last Notes

2023-06-07 17:57:22 UTC

- reply

📅 Original date posted:2017-03-27
📝 Original message:On Mon, Mar 27, 2017 at 08:32:07AM -0500, Chris Stewart wrote:
> >I quite agree, and I would add that sometimes making yourself
> recognisable is far more important that merit.
>
> The intent of my original proposal allows you to reveal yourself *after*
> the BIP has been accepted if you so choose. You do this by just revealing
> the preimage of the author hash. As others have pointed out, you can't
> *force* people to use this process -- but we can make it a defacto
> requirement by the BIP maintainer. Just like how you can't *force* people
> to format their BIPs in a certain way, but the BIP maintainer has the right
> to decline them if they aren't formatted that way.
>
> > Today, BitFury's CEO threatened to sue developers if they didn't kowtow to
> > his demands to leave the PoW alone. This is unacceptable. Decisions have
> to
> > be made on merit and the interest of the project, and nothing else.
>
> I think everyone on the list needs to see that paragraph again, and let the
> implications set in.
We are talking about money here. Decisions in this project are
not made based on 'merit', they are made based on ROI. If killing
the project is more profitable, many of the actors involved are
obligated to their shareholders to attempt to kill the project.
Or maybe in this case, they might be obligated to their investors
to attempt to try to run all the competing miners out of business
and acquire a majority stake in the hashpower.
If Merit were actually important, I would hope we would be
talking about a way to finance development in a way that provides
real financial incentives for merit, rather than what appear to
be some perverse incentives that seem to be rewarding short-term
traders, conflict, and further consolidation of mining and
exchanges.
The other problem with merit is there are just about as many ideas
about what has merit as there are people judging the merit of the
project.
For instance, I think demurrage and increasing the money supply are
ideas with more merit, but those ideas are not profitable to existing
bitcoin investors, and thus are not seriously discussed.

2023-06-07 17:57:21 UTC

- reply

📅 Original date posted:2017-03-24
📝 Original message:On Sat, Mar 18, 2017 at 07:15:09PM +0000, Luke Dashjr via bitcoin-dev wrote:
> On Saturday, March 18, 2017 3:23:16 PM Chris Stewart via bitcoin-dev wrote:
> > There is inconvenience added here. You need to make a new email address,
> > you need to make a new github account to submit the BIP.
>
> GitHub doesn't allow people to have multiple accounts last I checked.
C'mon people.
Anyone remember when git didn't even exist and all we had was CVS,
subversion, and BitKeeper?
Get me a couple of motivated grad students who know Python and we can
turn a combination of Mercurial, BitTorrent, and pynode into a distributed,
leaderless, decentralized version control system that can let users
create a crypto key, anonymously propose BIPs, and then get paid in
crypto for the best commits.
Who else would contribute to a crowdfunding effort to do such at thing?

2023-06-07 17:52:11 UTC

- 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 15:30:08 UTC

- reply

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

2023-06-07 15:25:33 UTC

- 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 15:25:31 UTC

- reply

📅 Original date posted:2014-08-23
📝 Original message:On Fri, Aug 22, 2014 at 09:20:11PM +0200, xor wrote:
> On Tuesday, August 19, 2014 08:02:37 AM Jeff Garzik wrote:
> > It would be nice if the issues and git repo for Bitcoin Core were not
> > on such a centralized service as github, nice and convenient as it is.
>
> Assuming there is a problem with that usually is caused by using Git the wrong
> way or not knowing its capabilities. Nobody can modify / insert a commit
> before a GnuPG signed commit / tag without breaking the signature.
> More detail at the bottom at [1], I am sparing you this here because I suspect
> you already know it and there is something more important I want to stress:
>
> Bitcoin has currently 4132 forks on Github. This means that you can get
> contributions by pull requests from 4132 developers. That is a HUGE amount,
> and you shouldn't ditch that due to not using all features of git :)
> To get a grasp of how much that is: When you search projects with more than
> 4100 forks, there are only 32 of them!
> You are one of the top open source projects, and you should be grateful for
> that and keep Github up so the other people can send you pull requests with
> their improvements :) Volunteer contributions need to be honored and made as
> easy as possible, for people are investing their personal time.
>
> Greetings and thanks for your work,
> xor, one developer of https://freenetproject.org
>
>
> [1] If you GPG-sign a commit / tag, you sign its hash, including the hash of
> the previous commit. So is a chain of hashes and thus of trust from all
> commits up to what is signed. It's pretty similar to the blockchain actually
> :)
> So Github cannot modify anything. If they did, the head of the hash-chain
> would change, and thus the signature would break. Git would notify people
> about that when they pull.
> Of course people can still ignore that warning and let Github rewrite their
> Git history. But people who aren't educated about this shouldn't be release
> managers. They should not even have push access to your main repository, they
> should only be sending pull requests. Thats is where the decentralization of
> Git is: In the pull-requests. The people who deal with them should verify tag
> and possibly even commit signatures carefully, and not accept anything which
> is not signed. Also, before deploying a binary, the very same commit which is
> going to become a binary has to be given a signed tag by the release manager,
> and by everyone who reviews the code. The person who deploys the actual binary
> needs to verify that signature.
> There is an article which elaborates on some of the ways you have to ensure
> Github doesn't insert malicious code - but please read it with care, some of
> its recommendations are bad, especially the part where its about rebasing
> because that DOES rewrite history which is what you want to prevent:
> http://mikegerwitz.com/papers/git-horror-story
>
>
This is why I clone git to mercurial, which is generally designed around the
assumption that history is immutable. You can't rewrite blockchain history,
and we should not be re-writing (rebasing) commit history either.
The problem with github is it's too tempting to look at the *web page*, which
is NOT pgp-signed, and hit the 'approve' button when you might have someone
in the middle approving an unsigned changeset because you're in a hurry to
get the latest new critical OpenSSL 0day security patch build released.
We need multiple redundant 'master' repositories run by different people in
different jurisdictions that get updated on different schedules, and have all
of these people pay attention to operational security, and not just outsource
it all to github because it's convenient.
There's no reason to *stop* using github, cause it *is* easy... but you want
to have multiple review of *the actual code*, not just signatures and see
if the changes really do make sense.
--
----------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' hozer at hozed.org
7 elements earth::water::air::fire::mind::spirit::soul grid.coop
Never pick a fight with someone who buys ink by the barrel,
nor try buy a hacker who makes money by the megahash

2023-06-07 15:25:29 UTC

- reply

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

2023-06-07 15:25:29 UTC

- reply

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

2023-06-07 15:25:28 UTC

- 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 15:19:42 UTC

- 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 15:17:33 UTC

- 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 15:17:19 UTC

- reply

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

2023-06-07 15:16:23 UTC

- reply

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

2023-06-07 15:16:16 UTC

- reply

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

2023-06-07 15:16:09 UTC

- reply

📅 Original date posted:2014-03-28
📝 Original message:> Anyway the particular situation in which a single entity controls 40%
> of the hashing power should be rare. That's potentially dangerous for
> bitcoin and although changing the hashing algorithm would be painful
> and risky, I would be terribly scared of that happening if I was that
> entity. Letting my percentage of hash rate dilute as others grow would
> definitely be part of my plan.
I think *your* plan is an ecologically and socially rational plan. My
observations of irrational responses on this list lead me to believe
there is a single entity (which may be a cartel) which *effectively*
controls between 30% and 50% of the sha-256 hashing power and is quite
terrified of any alternative, and attempts to purchase, consume, or
eliminate any entities that might dilute it's controlled hash rate or
pose a risk of switching to a new algorithm.
We must have a system in which 1 to 10% of the hashrate can provide a
reasonable check-and-balance and competitive pressure to 90% of the
hash rate, or it's going to be fundamentally unstable, and we will
just re-create 'to big to fail' all over again.
> Although this is again completely orthogonal to the merged mining or
> not discussion, hashing algorithms are often mixed in the discussions
> against merged mining. If you had to introduce that hashing algorithm
> hardfork change you will probably chose something with similar
> properties than those of SHA256, like being easy to implement
> specialized hardware for it. You could even chose a memory-hard
> algorithm if you want to promote ASIC production centralization, but
> you can't chose an "anti-ASIC" algorithm because those don't exist.
> It is well known that any information machine that can be built with
> software can also be built with specialized hardware and viceversa.
> Sadly that kind of fallacy is often used to justify the ecological
> crime that starting a new chain with no plans of doing merged mining
> represents.
You speak of ecological crime without proposing any mechanism in which
the ecologically correct thing is also the economically rational thing.
If I could get real-time MISO market pricing for wind energy, I could
do this http://grid.coop/smartgridcmp-long.png and run a mining farm
on my farm.
I would like to propose we collaborate on developing secure mechanism
to audit energy sources for miners on a new chain called 'Ecocoin' in
which the block reward is proportional to how much energy the owner
of the newly generated block reward personally harvested from renewable
sources.
The reward curve will have to be calibrated and adjusted to minimize
the over all costs and fraud risk of auditing the energy input sources.
--
----------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' hozer at hozed.org
7 elements earth::water::air::fire::mind::spirit::soul grid.coop
Never pick a fight with someone who buys ink by the barrel,
nor try buy a hacker who makes money by the megahash

2023-06-07 15:16:07 UTC

- reply

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

2023-06-07 15:16:06 UTC

- reply

📅 Original date posted:2014-03-25
📝 Original message:Peter,
I think you and I both know there is WAAYY to much MONEY to be taken
from naive end-users by the companies that employ people who call
your concerns FUD.
And for everyone else, I want to apologize in advance for anything
I might happen to say that might be abrasive, arrogant, angry, or
'in need of moderation'. So for those who do not wish to hear or
read such things, delete my message now.
===================
disclaimer: strong language follows
===================
What the fuck Groupthink?
committee for GROUPTHINKPROFIT?
I'd rather have Peter Todd calling some developers idiots on the
list than some fucking idiots who get paid way to fucking much
calling 'end-users' stupid for believing MtGox. Hell, I was one
of these idiots that fell for a marketing scam by a company that
had a good story.
But here is the damn point. The Excecutive who was whining about
how his devs won't show up should probably consider hiring people
who make VOCAL points on the mailing list. Or maybe he should
consider that his developers might know his business model is
shit and if they DID say something, it would be CLEAR to the
world that only an idiot would use their companies services, and
kill the company.
Would you rather hear of vulnerabilities and scaling limits on
bitcoin-development, or would you rather hear about them by a
chorus of "They got hacked, their code must suck", but AFTER
the fact.
It seems to be an unfortunate fact of life that sleazy people
take a shitload of money from nice people. Moderate Peter and
I into oblivion at your own risk. Wouldn't you rather have us
pointing out obvious flaws than ignoring shit?
... But just remember, your employers probably make more money
by ignoring shit....
On Tue, Mar 25, 2014 at 03:47:15PM -0400, Peter Todd wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> OK, deal. You guys stop calling my concerns FUD, accusing me of having ulterior motives, etc. and I'll pay the same respect to you.
>
>
> On 25 March 2014 14:13:36 GMT-04:00, slush <slush at centrum.cz> wrote:
> >I fully agree, please keep friendly environment on this list. Btw I
> >also
> >met people who were making fun about Peter's reactions on bitcoin-dev.
> >
> >slush
> >
> >
> >On Tue, Mar 25, 2014 at 7:02 PM, Alan Reiner <etotheipi at gmail.com>
> >wrote:
> >
> >> I would echo the need for some kind of moderation.
> >>
> >> I believe Peter Todd is an extremely intelligent individual, who has
> >a
> >> lot to offer the Bitcoin community. He has a firm grasp of a lot of
> >> really deep Bitcoin concepts and his *technical* insight is generally
> >> positive. Technically. But the way he communicates on this list is
> >> *extremely* corrosive and breeds hostility. It makes it a scary
> >place
> >> to discuss things, with frequent, public ridicule of everything
> >posted.
> >>
> >> I agree that I would rather have a friendly environment to discuss
> >> technicals, even if it means losing additional technical insight.
> >> People who would explicitly insult other contributors intelligence
> >and
> >> character on a public list should be subject to some kind of negative
> >> reinforcement. Maybe there's solutions other than outright banning.
> >>
> >> -Alan
> >>
> >>
> >>
> >> On 03/25/2014 01:37 PM, Jeff Garzik wrote:
> >> > On Tue, Mar 25, 2014 at 9:49 AM, Peter Todd <pete at petertodd.org>
> >wrote:
> >> >> For someone with 'Chief Scientist' as their job title, I'm
> >surprised you
> >> >> think so little of hard evidence and so much of idol worshipping.
> >> > Peter, take this unprofessional, personal crap off-list.
> >> >
> >> > Mike's anecdote of hostility is not an isolated one. Just today, a
> >> > bitcore developer commented on "Peter Todd's ..apocalyptic vision
> >> > and... negative view on bitcoin" which turned off some other
> >> > developers from participating more interactively.
> >> >
> >> > As I commented on IRC, open source projects are no strangers to
> >people
> >> > who simultaneously (a) make useful contributions and (b) turn
> >> > potential contributors away with an abrasive or hostile attitude
> >> > toward others. It's an unsolved problem in OSS, that I saw for 15+
> >> > years in the Linux kernel community.
> >> >
> >> > For this list, as Mike suggested on IRC, introducing an openly
> >stated
> >> > moderation policy may be the one route.
> >> >
> >>
> >>
> >>
> >>
> >------------------------------------------------------------------------------
> >> 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
> >>
> >
> >
> >------------------------------------------------------------------------
> >
> >------------------------------------------------------------------------------
> >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
> -----BEGIN PGP SIGNATURE-----
> Version: APG v1.0.9
>
> iQFQBAEBCAA6BQJTMd1DMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
> cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhb89B/98Tb0Xncho+1cbja1K
> R9xYOKPhWU5EIuPr7zbpuQxufuM8hZsyFSo/ptnQnJ8EAJ2GvUUEnE2vDDjvqqJm
> vy5URtOwKc6ztBDrjtWToKCgBwpJTektWrJMu2FQaO5CV/4sHhVM4By8BoDvCNLt
> xeN7BccjvlDZ+2ggRaYt4P/QKctEyt9qZrdDmIsNxUa+bLzplHoqdoQMjQ2CUcUA
> T+/Lq7MH+vROJXqx7d3JSsZAQ59evQDyorvCrxNgfVbB7j10t1zr5r5viWUEDtZ5
> /9DAP92vpSCokmKWfSlysHbC4KEqWglWka7aSBLXmAVrJeFxJRojsLQbCKUUFrG0
> IigO
> =91oy
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> 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 15:15:59 UTC

- 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 15:15:59 UTC

- reply

📅 Original date posted:2014-03-22
📝 Original message: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.
--
----------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' hozer at hozed.org
7 elements earth::water::air::fire::mind::spirit::soul grid.coop
Never pick a fight with someone who buys ink by the barrel,
nor try buy a hacker who makes money by the megahash

2023-06-07 15:15:58 UTC

- 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 15:15:58 UTC

- 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 15:15:38 UTC

- 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 15:15:33 UTC

- reply

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

2023-06-07 15:13:35 UTC

- 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 15:13:34 UTC

- 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 15:13:34 UTC

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

2023-06-07 15:11:25 UTC

- reply

📅 Original date posted:2014-01-03
📝 Original message:I believe this is self-explainatory:
1) Bitcoin usually runs on port 8333. Why?
2) Bitcoin does not show in up http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml .. why?
3) What needs to happen to have someone from the Bitcoin foundation
to fill out the form asking for an assigned port (see
http://www.iana.org/form/ports-services )
4) what should the process be for new cryptocoins to get both default
port numbers, as well as P2P network identifier 'magic numbers'