<unnamed>

Public Key

npub1nqeart5fmxjzj4tejkp7fckp0qa4hw3gpha6espxudum2qlvvrhqvlnwve

Profile Code

nprofile1qqsfsv7346yanfpf24uetqlyutqhsw6mhg5qm7avcqnwx7d4q0kxpmspzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqd5c6nd

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:38:12 UTC

- reply

📅 Original date posted:2015-06-15
📝 Original message:Who is actually planning to move to Bitcoin-XT if this happens?
Just Gavin and Mike?
> On Jun 15, 2015, at 6:17 PM, Faiz Khan <faizkhan00 at gmail.com> wrote:
>
> I'm quite puzzled by the response myself, it doesn't seem to address some of the (more serious) concerns that Adam put out, the most important question that was asked being the one regarding personal ownership of the proposed fork:
>
> "How do you plan to deal with security & incident response for the duration you describe where you will have control while you are deploying the unilateral hard-fork and being in sole maintainership control?"
>
> I do genuinely hope that whomever (now and future) wishes to fork the protocol reconsider first whether they are truly ready to test/flex their reputation/skills/resources in this way... Intuitively, to me it seems counterproductive, and I don't fully believe it is within a single developer's talents to manage the process start-to-finish (as it is non-trivial to hard-fork successfully, others have rehashed this in other threads)...
>
> That being said I think it appropriate if Adam's questions were responded in-line when Mike is feeling up to it. I think that the answers are important for the community to hear when such a drastic change is being espoused.
>
> Faiz
>
>> On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop <kanzure at gmail.com> wrote:
>>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike at plan99.net> wrote:
>>> Re: anyone who agrees with noted non-programmers Mike&Gavin must be non-technical, stupid, uninformed, etc .... OK, go ahead and show them the error of their ways. Anyone can write blogs.
>>
>> I worry that if this is the level of care you take with reading and (mis)interpreting Adam's messages, that you might not be taking extreme care with evaluating consensus changes, even while tired or sleeping. I encourage you to evaluate both messages and source code more carefully, especially in the world of bitcoin. However, this goes for everyone and not just you. Specifically, when Adam mentioned your conversations with non-technical people, he did not mean "Mike has talked with people who have possibly not made pull requests to Bitcoin Core, so therefore Mike is a non-programmer". Communication is difficult and I can understand that, but we really have to be more careful when evaluating each other's messages; technical miscommunication can be catastrophic in this context. On the topic of whether you are a programmer, I suspect that ever since you built CIA.vc we have all known you're a programmer, Mike.
>>
>> - Bryan
>> http://heybryan.org/
>> 1 512 203 0507
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>> --
>>
>> My regards,
>>
>> Faiz Khan
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/6de7b490/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image1.JPG
Type: image/jpeg
Size: 22107 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/6de7b490/attachment.jpe>

2023-06-07 15:33:44 UTC

- reply

📅 Original date posted:2015-05-30
📝 Original message:> Why 20 MB? Do you anticipate 20x transaction count growth in 2016?
Do you anticipate linear growth?
> On May 30, 2015, at 6:05 PM, Alex Mizrahi <alex.mizrahi at gmail.com> wrote:
>
>
>> Why 2 MB ?
>
> Why 20 MB? Do you anticipate 20x transaction count growth in 2016?
>
> Why not grow it by 1 MB per year?
> This is a safer option, I don't think that anybody claims that 2 MB blocks will be a problem.
> And in 10 years when we get to 10 MB we'll get more evidence as to whether network can handle 10 MB blocks.
>
> So this might be a solution which would satisfy both sides:
> * people who are concerned about block size growth will have an opportunity to stop it before it grows too much (e.g. with a soft fork),
> * while people who want bigger blocks will get an equivalent of 25% per year growth within the first 10 years, which isn't bad, is it?
>
> So far I haven't heard any valid arguments against linear growth.
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150530/250c732e/attachment.html>

2023-06-07 15:29:41 UTC

- reply

📅 Original date posted:2015-02-05
📝 Original message:This sounds horrible. You could basically monitor anyone with a wallet in a highly populated area and track them super easily by doing facial recognition. Yes you could photograph people but it's way more burdensome. Sorry to go off topic a little.
On Feb 5, 2015, at 3:50 PM, Mike Hearn <mike at plan99.net> wrote:
>> I'm imagining myself walking around broadcasting my photo and MAC
>> address while hucksters push payment requests to me for approval
>
> I hate to break it to you, but you broadcast a photo of your face every time you walk outside ;)
>
> Bluetooth MAC addresses are random, they aren't useful identifiers. If someone can see you, a face is a far more uniquely identifying thing than a MAC.
>
> "Payment spam" might be a problem. I can imagine a wallet requiring that such requests are signed and then spammers can be blacklisted in the usual fashion so they can't push things to your phone anymore. Anyway, a hurdle that can be jumped if/when it becomes an issue.
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150205/278936ec/attachment.html>

2023-06-07 15:28:37 UTC

- reply

📅 Original date posted:2015-01-19
📝 Original message:Damn if SPKI had won out we would be parsing S-expressions instead of X.509 certificates. ASN.1 is not fun IMHO.
> On Jan 19, 2015, at 3:56 PM, Gavin Andresen <gavin at bitcoinfoundation.org> wrote:
>
> On Mon, Jan 19, 2015 at 3:40 PM, Mike Hearn <mike at plan99.net> wrote:
>>> OK, I guess we can boil this down more simply. BIP 70 uses protocol buffers because I designed it and implemented the original prototype (with lots of input from Gavin and an earlier proposal by sipa). I used protocol buffers because, beyond all their nice properties, I used to work at Google and so was very familiar with them.
>
>
> What Mike said. Runner-up for encoding was JSON.
>
> XML+ASN.1 was Right Out, because lots of us hate XML and ASN.1 with a burning passion. Complexity is the Enemy of Security, and both XML and ASN.1 are too complex.
>
>
> --
> --
> Gavin Andresen
> Chief Scientist, Bitcoin Foundation
> https://www.bitcoinfoundation.org/
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150119/ea970d31/attachment.html>

2023-06-07 15:25:46 UTC

- reply

📅 Original date posted:2014-09-15
📝 Original message:I would agree that the in person aspect of the WoT is frustrating, but to dismiss this as "geek wanking" is the pot calling the kettle.
The value of in person vetting of identity is undeniable. Just because your risk acceptance is difference doesn't make it wanking. Please go see if you can get any kind of governmental clearance of credential without in-person vetting. Ask them if they accept your behavioral signature.
I know there is a lot of PGP hating these days but this comment doesn't necessarily apply to every situation.
> On Sep 15, 2014, at 9:08 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
>> On Mon, Sep 15, 2014 at 3:23 AM, Thomas Zander <thomas at thomaszander.se> wrote:
>> Any and all PGP related howtos will tell you that you should not trust or sign
>> a formerly-untrusted PGP (or GPG for that matter) key without seeing that
>> person in real life, verifying their identity etc.
>
> Such guidelines are a perfect example of why PGP WoT is useless and
> stupid geek wanking.
>
> A person's behavioural signature is what is relevant. We know how
> Satoshi coded and wrote. It was the online Satoshi with which we
> interacted. The online Satoshi's PGP signature would be fine...
> assuming he established a pattern of use.
>
> As another example, I know the code contributions and PGP key signed
> by the online entity known as "sipa." At a bitcoin conf I met a
> person with photo id labelled "Pieter Wuille" who claimed to be sipa,
> but that could have been an actor. Absent a laborious and boring
> signed challenge process, for all we know, "sipa" is a supercomputing
> cluster of 500 gnomes.
>
> The point is, the "online entity known as Satoshi" is the relevant
> fingerprint. That is easily established without any in-person
> meetings.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&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:25:46 UTC

- reply

📅 Original date posted:2014-09-15
📝 Original message:In the context of Bitcoin I will concede that perhaps it holds true for now.
I also never said the actual credential you receive from a government
agency is trustable. I completely agree that they are forgeable and not
necessarily reliable. That was not my point. I was referring to the vetting
process before issuance.
Just as you have behavioral characteristics online that contribute to
trusting an "identity" you also exhibit in person attributes, such as
physically being in a specific location at a certain time or blue eyes or
biometrics, that are valuable. You simply cannot capture those in an
online-only world. I don't see how you can deny the value there.
You are most certainly and undeniably the expert in the Bitcoin context
here so I will not even attempt to argue with you on that, but I just think
it's not realistic to ignore the value of an in-person network in other
contexts. You called it "geek wanking" with no qualifier "in the Bitcoin
context" so excuse me if I misunderstood your intent.
On Mon, Sep 15, 2014 at 10:33 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> It applies to OP, bitcoin community development and Satoshi.
>
> "value of in person vetting of identity is undeniable"... no it is
> quite deniable. Satoshi is the quintessential example. We value brain
> output, code. The real world identity is irrelevant to whether or not
> bitcoin continues to function.
>
> The currency of bitcoin development is code, and electronic messages
> describing cryptographic theses. _That_ is the relevant fingerprint.
>
> Governmental id is second class, can be forged or simply present a
> different individual from that who is online. PGP WoT wanking does
> not solve that problem at all.
>
>
>
>
>
>
> On Mon, Sep 15, 2014 at 9:32 AM, Brian Hoffman <brianchoffman at gmail.com>
> wrote:
> > I would agree that the in person aspect of the WoT is frustrating, but
> to dismiss this as "geek wanking" is the pot calling the kettle.
> >
> > The value of in person vetting of identity is undeniable. Just because
> your risk acceptance is difference doesn't make it wanking. Please go see
> if you can get any kind of governmental clearance of credential without
> in-person vetting. Ask them if they accept your behavioral signature.
> >
> > I know there is a lot of PGP hating these days but this comment doesn't
> necessarily apply to every situation.
> >
> >
> >
> >> On Sep 15, 2014, at 9:08 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> >>
> >>> On Mon, Sep 15, 2014 at 3:23 AM, Thomas Zander <thomas at thomaszander.se>
> wrote:
> >>> Any and all PGP related howtos will tell you that you should not trust
> or sign
> >>> a formerly-untrusted PGP (or GPG for that matter) key without seeing
> that
> >>> person in real life, verifying their identity etc.
> >>
> >> Such guidelines are a perfect example of why PGP WoT is useless and
> >> stupid geek wanking.
> >>
> >> A person's behavioural signature is what is relevant. We know how
> >> Satoshi coded and wrote. It was the online Satoshi with which we
> >> interacted. The online Satoshi's PGP signature would be fine...
> >> assuming he established a pattern of use.
> >>
> >> As another example, I know the code contributions and PGP key signed
> >> by the online entity known as "sipa." At a bitcoin conf I met a
> >> person with photo id labelled "Pieter Wuille" who claimed to be sipa,
> >> but that could have been an actor. Absent a laborious and boring
> >> signed challenge process, for all we know, "sipa" is a supercomputing
> >> cluster of 500 gnomes.
> >>
> >> The point is, the "online entity known as Satoshi" is the relevant
> >> fingerprint. That is easily established without any in-person
> >> meetings.
> >>
> >> --
> >> Jeff Garzik
> >> Bitcoin core developer and open source evangelist
> >> BitPay, Inc. https://bitpay.com/
> >>
> >>
> ------------------------------------------------------------------------------
> >> Want excitement?
> >> Manually upgrade your production database.
> >> When you want reliability, choose Perforce
> >> Perforce version control. Predictably reliable.
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140915/66d1dfaf/attachment.html>

2023-06-07 15:18:14 UTC

- reply

📅 Original date posted:2014-04-09
📝 Original message:How would this affect the user in terms of disk storage? They're going to
get hammered on space constraints aren't they? If it's not required how
likely are users to enable this?
On Wed, Apr 9, 2014 at 11:29 AM, Wladimir <laanwj at gmail.com> wrote:
> Hello,
>
> This is primarily aimed at developers of SPV wallets.
>
> The recently reported decrease in number of full nodes could have several
> reasons, one of them that less people are running Bitcoin Core for the
> wallet because the other wallets are getting ahead in both features and
> useability.
>
> It's great to see innovation in wallets, but it's worrying that the number
> of full nodes decreases.
>
> It may be that lots of people would support the network by running a full
> node, but don't want to go through the trouble of installing bitcoin core
> separately (and get confused because it's a wallet, too).
>
> Hence I'd like to explore the idea of adding an option to popular SPV
> wallets, to spin a bitcoind process in the background. This could be pretty
> much transparent to the user - it would sync in the background, the wallet
> could show statistics about the node, but is not dependent on it.
>
> In exchange the user would get increased (full node level) security, as
> the SPV wallet would have a local trusted node.
>
> Does this sound like a good idea?
>
> Is there any way that Bitcoin Core can help to accomedate this 'embedded'
> usage? Specific Interfaces, special builds - maybe add a walletless
> bitcoind build to gitian - bindings, dlls, etc?
>
> Wladimir
>
>
>
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/0039915d/attachment.html>