Brian Hoffman [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-04-09 to 2015-06-19
💬 Posted a total of 14 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:39:20

- reply

📅 Original date posted:2015-06-19
📝 Original message:damn he was just on the verge of solving the underlaying problem with Bitcoin and you interrupted his focus.
> On Jun 19, 2015, at 3:55 PM, John Bodeen <john-bodeen at uiowa.edu> wrote:
>
> from their website, humorous bits highlighted
>
> October 14, 2014
> In latest Hiatus new, the company has taken on yet another crazy project but this one is going to benefit the world in which it entered not long ago. The company had done a lot of research on crypto currencies, built one for itself, for testing purposes (GigasCorpCoin) and found the underlaying problem of Bitcoin and was poised to solve it. Company execs decided it would be a good investment to launch its own coin and back it itself.
> The company is currently in motion and will hire an expert to do some of the coding by October 14, 2015. Company President refused to be interviewed due to too much work that needs done for this secret and upcoming project.
>
> On Fri, Jun 19, 2015 at 10:34 AM, Jameson Lopp <jameson.lopp at gmail.com <mailto:jameson.lopp at gmail.com>> wrote:
> You are free to remove yourself; the URL is at the bottom of every email: https://lists.sourceforge.net/lists/listinfo/bitcoin-development <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>
> On Fri, Jun 19, 2015 at 12:41 PM, Gigas Gaming Inc. <corporate at gigasgaming.com <mailto:corporate at gigasgaming.com>> wrote:
> This is no longer a mailing list, this is a chatroom.
> Please remove this email from your list, you are now interfering with
> official company business.
>
> Thanks
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/aee1cdb9/attachment.html>

2023-06-07 17:38:12

- 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 17:33:44

- 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 17:32:19

- reply

📅 Original date posted:2015-04-07
📝 Original message:That was easy.
> On Apr 7, 2015, at 5:49 PM, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:
>
> Ok, false alarm. :)
>
> Sorry for the spam.
>
>> On Apr 07, 2015, at 02:37 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>>
>
>> On Tue, Apr 7, 2015 at 9:32 PM, Jean-Paul Kogelman
>> <jeanpaulkogelman at me.com> wrote:
>>> https://eprint.iacr.org/2015/310.pdf
>>
>> http://www.reddit.com/r/Bitcoin/comments/31rcuo/new_algorithm_for_the_discrete_logarithm_problem/cq4b52u
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> 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/20150407/c89e1df3/attachment.html>

2023-06-07 17:29:41

- 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 17:28:37

- 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 17:25:46

- 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 17:25:46

- 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 17:18:50

- reply

📅 Original date posted:2014-04-17
📝 Original message:"So my question to the community is, how invasive is this to bitcoin's
source code?"
I'd say not very considering you have regression testing mode.
On Thu, Apr 17, 2014 at 8:25 AM, Jorge Timón <jtimon at monetize.io> wrote:
> I'm implementing a new testing mode that produces blocks
> periodically. You can get what I have so far here:
>
> https://github.com/jtimon/bitcoin/tree/timed
>
> It depends on pull request #3824 with some improvements on
> CChainParams, but after that the changes required to add this new
> mode are very small:
>
>
> https://github.com/jtimon/bitcoin/commit/445321928a143cb9a6f56777cbb7479dd32c3bcd
>
> I guess I need a new genesis block, different magic numbers, etc. So
> this is definitely not ready.
> You can run it like this:
>
> bitcoind -timedtest -gen=1 blocktime=2000
>
> blocktime defaults to 1000 milliseconds for timedtest mode and 0 for
> the rest of the modes.
>
> What could this testing mode be useful for?
>
> Basically, simulations.
> For example, you could run several nodes implementing different mining
> policies. Let's say I want to mine 50% of the blocks with standard policy,
> 25% with policy A and 25% with policy B. I can run 1 one for each of
> one with block times 2000, 1000 and 1000 respectively.
>
> Maybe I want to detect performance bottlenecks by stressing this mode
> with as many transaction as can be processed, maybe removing the
> block size limits in the simulations.
>
> But this still doesn't serve for hardfork or double-spend attacks
> simulations without calculating any pow, which would be another
> interesting feature for a new testing mode.
> I would like to implement the new mode following as the concept of
> private chains described in freimarkets:
>
> http://freico.in/docs/freimarkets.pdf
>
> https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org#private-ledgers
>
> https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org#off-chain-transactions
>
> I know this could be considered a "non-bitcoinish" application and
> therefore be controversial as discussed in PR 3824, so I want to keep
> the conversation focused on testing use cases useful to bitcoin itself
> only: additional changes can be implemented elsewhere.
> One way I think you could support chain races simulations by using a
> private mode could be the following:
>
> 1) The private mode works like the timed mode in how often it
> produces blocks.
>
> 2) In private mode you replace the pow-related fields with a
> blockPubkeyScript and a lastBlockSigScript fields. In the genesis
> block, lastBlockSigScript is empty and the initial
> blockPubkeyScript can be an optional parameter like blocktime. You
> can set any valid script, probably p2sh, maybe with multisig to
> allow different nodes to sign.
>
> 3) In this context, longer chains mean "more work". Another way to
> see it is that all blocks just contain work==1 in them.
>
> So let's say we want to simulate an attack using 50% standard and 50%
> attacker blocks. You set up the private mode script to be a 1 of 2
> multisig and make each node sign always with the same private key
> (maybe an additional parameter).
> You make the attacker reject any blocks from height X that he hasn't
> signed himself to get the result you wanted: the standard node will
> produce blocks on top of the longest chain while the attacker will
> only hash on top of his own blocks.
>
> So my question to the community is, how invasive is this to bitcoin's
> source code?
> In my opinion, done properly could actually result (apart from getting
> the new features) in more readable code, not less, since you will
> probably need to make sure proof of work functionality is properly
> encapsulated during the implementation process (see PR 3839 for a first
> step on that direction).
> But, should I push a private mode to the core or just the timed one
> and implement the private mode elsewhere?
>
> Of course other comments on the parameters, defaults or any other
> design or implementation details are also welcomed.
>
> --
> Jorge Timón
>
> http://freico.in/
>
>
> ------------------------------------------------------------------------------
> 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/NeoTech
> _______________________________________________
> 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/20140417/b7b7e1bd/attachment.html>

2023-06-07 17:18:31

- reply

📅 Original date posted:2014-04-10
📝 Original message:Ok I think I've got a good understanding of where we're at now. I can
promise that the next person to waste your time in 30 days will not be me.
I'm pleasantly surprised to see a community that doesn't kickban newcomers
and takes the time to explain (re-explain) concepts.
Hoping to add *beneficial* thoughts in the future!
On Thu, Apr 10, 2014 at 12:59 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
> On Thu, Apr 10, 2014 at 6:47 PM, Brian Hoffman <brianchoffman at gmail.com>
> wrote:
> > Looks like only about ~30% disk space savings so I see your point. Is
> there
> > a critical reason why blocks couldn't be formed into "superblocks" that
> are
> > chained together and nodes could serve a specific superblock, which
> could be
> > pieced together from different nodes to get the full blockchain? This
> would
> > allow participants with limited resources to serve full portions of the
> > blockchain rather than limited pieces of the entire blockchain.
>
> As this is a suggestion that I think I've seen come up once a month
> for the past 3 years, let's try to answer it thoroughly.
>
> The actual "state" of the blockchain is the UTXO set (stored in
> chainstate/ by the reference client). It's the set of all unspent
> transaction outputs at the currently active point in the block chain.
> It is all you need for validating future blocks.
>
> The problem is, you can't just give someone the UTXO set and expect
> them to trust it, as there is no way to prove that it was the result
> of processing the actual blocks.
>
> As Bitcoin's full node uses a "zero trust" model, where (apart from
> one detail: the order of otherwise valid transactions) it never
> assumes any data received from the outside it valid, it HAS to see the
> previous blocks in order to establish the validity of the current UTXO
> set. This is what initial block syncing does. Nothing but the actual
> blocks can provide this data, and it is why the actual blocks need to
> be available. It does not require everyone to have all blocks, though
> - they just need to have seen them during processing.
>
> A related, but not identical evolution is merkle UTXO commitments.
> This means that we shape the UTXO set as a merkle tree, compute its
> root after every block, and require that the block commits to this
> root hash (by putting it in the coinbase, for example). This means a
> full node can copy the chain state from someone else, and check that
> its hash matches what the block chain commits to. It's important to
> note that this is a strict reduction in security: we're now trusting
> that the longest chain (with most proof of work) commits to a valid
> UTXO set (at some point in the past).
>
> In essence, combining both ideas means you get "superblocks" (the UTXO
> set is essentially the summary of the result of all past blocks), in a
> way that is less-than-currently-but-perhaps-still-acceptably-validated.
>
> --
> Pieter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/b0cab188/attachment.html>

2023-06-07 17:18:30

- reply

📅 Original date posted:2014-04-10
📝 Original message:Okay...will let myself out now ;P
On Thu, Apr 10, 2014 at 12:54 PM, Ricardo Filipe
<ricardojdfilipe at gmail.com>wrote:
> that's what blockchain pruning is all about :)
>
> 2014-04-10 17:47 GMT+01:00 Brian Hoffman <brianchoffman at gmail.com>:
> > Looks like only about ~30% disk space savings so I see your point. Is
> there
> > a critical reason why blocks couldn't be formed into "superblocks" that
> are
> > chained together and nodes could serve a specific superblock, which
> could be
> > pieced together from different nodes to get the full blockchain? This
> would
> > allow participants with limited resources to serve full portions of the
> > blockchain rather than limited pieces of the entire blockchain.
> >
> >
> > On Thu, Apr 10, 2014 at 12:28 PM, Mike Hearn <mike at plan99.net> wrote:
> >>
> >> Suggestions always welcome!
> >>
> >> The main problem with this is that the block chain is mostly random
> bytes
> >> (hashes, keys) so it doesn't compress that well. It compresses a bit,
> but
> >> not enough to change the fundamental physics.
> >>
> >> However, that does not mean the entire chain has to be stored on
> expensive
> >> rotating platters. I've suggested that in some star trek future where
> the
> >> chain really is gigantic, it could be stored on tape and spooled off at
> high
> >> speed. Literally a direct DMA from tape drive to NIC. But we're not
> there
> >> yet :)
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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/20140410/10c46b57/attachment.html>

2023-06-07 17:18:30

- reply

📅 Original date posted:2014-04-10
📝 Original message:Looks like only about ~30% disk space savings so I see your point. Is there
a critical reason why blocks couldn't be formed into "superblocks" that are
chained together and nodes could serve a specific superblock, which could
be pieced together from different nodes to get the full blockchain? This
would allow participants with limited resources to serve full portions of
the blockchain rather than limited pieces of the entire blockchain.
On Thu, Apr 10, 2014 at 12:28 PM, Mike Hearn <mike at plan99.net> wrote:
> Suggestions always welcome!
>
> The main problem with this is that the block chain is mostly random bytes
> (hashes, keys) so it doesn't compress that well. It compresses a bit, but
> not enough to change the fundamental physics.
>
> However, that does not mean the entire chain has to be stored on expensive
> rotating platters. I've suggested that in some star trek future where the
> chain really is gigantic, it could be stored on tape and spooled off at
> high speed. Literally a direct DMA from tape drive to NIC. But we're not
> there yet :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/0927179b/attachment.html>

2023-06-07 17:18:29

- reply

📅 Original date posted:2014-04-10
📝 Original message:This is probably just noise, but what if nodes could compress and store
earlier transaction sets (archive sets) and serve them up conditionally. So
if there were let's say 100 archive sets of (10,000 blocks) you might have
5 open at any time when you're an active archive node while the others sit
on your disk compressed and unavailable to the network. This would allow
nodes to have all full transactions but conserve disk space and network
activity since they wouldn't ever respond about every possible transaction.
This could be based on a rotational request period, based on request count
or done periodically. Once their considered active they would be expected
to uncompress a set and make it available to the network. Clients would
have to piece together archive sets from different nodes, but if there
weren't enough archive nodes to cover the chain they could ratchet up the
amount of required open archive sets when your node was active.
I fully expect to have my idea trashed, but I'm dipping toes in the waters
of contribution.
On Thu, Apr 10, 2014 at 10:19 AM, Wladimir <laanwj at gmail.com> wrote:
>
> On Thu, Apr 10, 2014 at 2:10 PM, Gregory Maxwell <gmaxwell at gmail.com>wrote:
>
>> But sure I could see a fixed range as also being a useful contribution
>> though I'm struggling to figure out what set of constraints would
>> leave a node without following the consensus? Obviously it has
>> bandwidth if you're expecting to contribute much in serving those
>> historic blocks... and verifying is reasonably cpu cheap with fast
>> ecdsa code. Maybe it has a lot of read only storage?
>>
>
> The use case is that you could burn the node implementation + block data +
> a live operating system on a read-only medium. This could be set in stone
> for a long time.
>
> There would be no consensus code to keep up to date with protocol
> developments, because it doesn't take active part in it.
>
> I don't think it would be terribly useful right now, but it could be
> useful when nodes that host all history become rare. It'd allow
> distributing 'pieces of history' in a self-contained form.
>
>
>> I think it should be possible to express and use such a thing in the
>> protocol even if I'm currently unsure as to why you wouldn't do 100000
>> - 200000 _plus_ the most recent 144 that you were already keeping
>> around for reorgs.
>>
>
> Yes, it would be nice to at least be able to express it, if it doesn't
> make the protocol too finicky.
>
> In terms of peer selection, if the blocks you need aren't covered by
>> the nodes you're currently connected to I think you'd prefer to seek
>> node nodes which have the least rare-ness in the ranges they offer.
>> E.g. if you're looking for a block 50 from the tip, you're should
>> probably not prefer to fetch it from someone with blocks 100000-150000
>> if its one of only 100 nodes that has that range.
>>
>
> That makes sense.
>
> In general, if you want a block 50 from the tip, it would be best to
> request it from a node that only serves the last N (N>~50) blocks, and not
> a history node that could use the same bandwidth to serve earlier, rarer
> blocks to others.
>
> 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/20140410/34295a52/attachment.html>

2023-06-07 17:18:14

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