21E14 [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-08-21 to 2015-05-07
💬 Posted a total of 7 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 15:33:24

- reply

📅 Original date posted:2015-05-07
📝 Original message:I am more fazed by PR 5288 and PR 5925 not getting merged in, than by this
thread. So, casting my ballot in favor of the block size increase. Clearly,
we're still rehearsing proper discourse, and that ain't gonna get fixed
here and now.
On Thu, May 7, 2015 at 9:29 PM, Matt Corallo <bitcoin-list at bluematt.me>
wrote:
>
>
> On 05/07/15 19:34, Mike Hearn wrote:
> > The appropriate method of doing any fork, that we seem to have been
> > following for a long time, is to get consensus here and on IRC and on
> > github and *then* go pitch to the general public
> >
> >
> > So your concern is just about the ordering and process of things, and
> > not about the change itself?
>
> No, I'm very concerned about both.
>
> > I have witnessed many arguments in IRC about block sizes over the years.
> > There was another one just a few weeks ago. Pieter left the channel for
> > his own sanity. IRC is not a good medium for arriving at decisions on
> > things - many people can't afford to sit on IRC all day and
> > conversations can be hard to follow. Additionally, they tend to go
> circular.
>
> I agree, thats why this mailing list was created in the first place
> (well, also because bitcointalk is too full of spam, but close enought :))
>
> > That said, I don't know if you can draw a line between the "ins" and
> > "outs" like that. The general public is watching, commenting and
> > deciding no matter what. Might as well deal with that and debate in a
> > format more accessible to all.
>
> Its true, just like its true the general public can opt to run any
> version of software they want. That said, the greater software
> development community has to update /all/ the software across the entire
> ecosystem, and thus provide what amounts to a strong recommendation of
> which course to take. Additionally, though there are issues (eg if there
> was a push to remove the total coin limit) which are purely political,
> and thus which should be up to the greater public to decide, the
> blocksize increase is not that. It is intricately tied to Bitcoin's
> delicate incentive structure, which many of the development community
> are far more farmiliar with than the general Bitcoin public. If there
> were a listserv that was comprised primarily of people on
> #bitcoin-wizards, I might have suggested a discussion there, first, but
> there isnt (as far as I know?).
>
> > If, instead, there had been an intro on the list as "I think we
> should
> > do the blocksize increase soon, what do people think?"
> >
> >
> > There have been many such discussions over time. On bitcointalk. On
> > reddit. On IRC. At developer conferences. Gavin already knew what many
> > of the objections would be, which is why he started answering them.
> >
> > But alright. Let's say he should have started a thread. Thanks for
> > starting it for him.
> >
> > Now, can we get this specific list of things we should do before we're
> > prepared?
>
> Yes....I'm gonna split the topic since this is already far off course
> for that :).
>
> > A specific credible alternative to what? Committing to blocksize
> > increases tomorrow? Yes, doing more research into this and developing
> > software around supporting larger block sizes so people feel
> comfortable
> > doing it in six months.
> >
> >
> > Do you have a specific research suggestion? Gavin has run simulations
> > across the internet with modified full nodes that use 20mb blocks, using
> > real data from the block chain. They seem to suggest it works OK.
> >
> > What software do you have in mind?
>
> Let me answer that in a new thread :).
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> 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/20150507/637e045a/attachment.html>

2023-06-07 15:28:59

- reply

📅 Original date posted:2015-01-21
📝 Original message:This is a response to a wonderfully insightful recent post by Joichi Ito,
the Director of the MIT Media Lab. In it, Dr. Ito, notably a former Board
Member of ICANN, offered his thoughts on "Why Bitcoin is and isn't like the
Internet" and asked a most pertinent question: "Whether there is an ICANN
equivalent needed for Bitcoin." As suggested in recent posts to the mailing
list, I believe there might be, but for a reason that may not seem obvious
at first.
Alan Reiner expressed the need this way: "I think one of the biggest issues
facing Bitcoin right now is not the lack of a 'killer app.' It is lack of
insurance options. Early adopters would like to believe that the majority
of users will hold their own Bitcoin, but I believe that is not a realistic
option when life-changing quantities of Bitcoin are involved. We should not
trust Grandma to secure her own retirement savings via complicated computer
maneuvers. More to the point, she should not trust herself or anyone else
(sic!) to hold it unless there is a strong protection against loss events.
Right now the solution is for Grandma to avoid keeping her money in
Bitcoin. Bitcoin needs a strong backbone of insured storage options so that
Grandma can confidently participate in this new technology." This is
certainly an observation to take heed of coming from the founder of Armory
Technologies.
The protection against loss events ought to be understood in the broadest
sense. What is needed is a disaster recovery mechanism. Andreas
Antonopoulos remarks expressed this candidly last year: "Bitcoin doesn't
have a middle of the road mediocre growth model. It basically either dies,
because of a fundamental flaw in the Bitcoin system. Not an external
factor, an internal factor: We blow it up by accident. And that could
happen... Bitcoin will play out in the next three years. In the next three
years we're going to see Bitcoin arrive on the global stage and make a
substantial impact, both in financial terms and in political terms. It will
happen. Or it will die. Either way. I'm not sure. In which case we'll
reboot another currency."
A body, not entirely unlike ICANN, can manage the nexus to the physical
world, and help address Bitcoin's catastrophic failure modes. Bitcoin's
coin ownership protocol would thus join the ranks of its payment protocol,
coin issuance protocol, consensus mechanism and inflation control that pose
no lethal threat to the ecosystem. In addition to their coin-agnostic
nature, I suspect the high valuation of large Bitcoin hubs relative to
Bitcoin's market cap at this stage in its lifecycle is partly reflective of
the sneaking suspicion that a custodial bitcoin (a bitcoin attached to an
identity) may be worth more than a non-custodial one. With this in mind,
I'll pitch in for the ticket should Dr. Ito decide to join the next month's
DevCore Boston conference aimed at supporting the future development of
Bitcoin. It's an hour's walk from MIT after all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150121/45fa2d7d/attachment.html>

2023-06-07 15:28:23

- reply

📅 Original date posted:2015-01-09
📝 Original message:> I think the observation about Target vs Bitcoin exchanges is a sharp one,
> but I'm not sure how your proposal helps. You say it's an optional
identity
> layer, but obviously any thief is going to opt out of being identified.
Let me translate it to this year's vocabulary. Think of BCIs as a
sidechain: let the legacy financial system migrate, to the extent desired,
to a more heavily regulated pegged sidechain with a stronger identity
layer. Let protocol-level rules regulate this nexus between the custodial
(sidechain) and non-custodial address spaces (blockchain). This isn't
entirely unlike the rules currently governing coin issuance i.e. coinbase
transactions. Let the market forces play it out. Iterate as needed. I
suspect that in retrospect it'll seem obvious. Many moons from now the
balance might shift between the two, but it won't matter much. The system
will have means to recover from catastrophic failure modes.
To help internalize such an evolution, please consider the layers the
Bitcoin protocol builds on top of: segment 52:32 ("The Internet is being
upgraded") of the BBC documentary "Inside The Dark Web" (
https://www.youtube.com/watch?v=qXajND7BQzk#t=3152). Kaspersky's comments a
few minutes earlier (50:06) aren't entirely out of context here either.
Clearly, the need is acute for Bitcoin to become institutional i.e. for
"billions of dollars of human value" to flow through it, as one Money 20/20
participant put it.
On Fri, Jan 9, 2015 at 2:00 PM, Mike Hearn <mike at plan99.net> wrote:
> This needn't be so, once an optional identity layer, modeled after the
>> Internet itself, is provided, as proposed in late August of last year on
>> this mailing list
>>
>
> I think the observation about Target vs Bitcoin exchanges is a sharp one,
> but I'm not sure how your proposal helps. You say it's an optional identity
> layer, but obviously any thief is going to opt out of being identified.
>
> For things like the Bitstamp hack, it's not clear how identity can help,
> because they were already doing KYC for all their customers. To take that
> further at the protocol level would require* all* transactions to have
> attached identity info, and that isn't going to happen - it wouldn't be
> Bitcoin, at that point.
>
> I think that long term, it's probably possible to defend private keys
> adequately, even for large sums of money (maybe not bitstamp-large but
> we'll see). You can have very minimalist secure hardware that would have
> some additional policies on top, like refusing to sign transactions without
> an identity proof of who controls the target address. Very tight hot
> wallets that risk analyse the instructions they're receiving have been
> proposed years ago.
>
> No such hardware presently exists, but that's mostly because
> implementations always lag behind a long way behind ideas rather than any
> fundamental technical bottleneck. Perhaps the Bitstamp event will finally
> spur development of such things forward.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150109/aa8619e3/attachment.html>

2023-06-07 15:28:22

- reply

📅 Original date posted:2015-01-08
📝 Original message:Alex Daley recently stated that "one of the problems with Bitcoin is that
it takes us backwards in the transaction chain. Suddenly, you're dealing
with something that's much more cash-like. If Target had been hacked, and
instead of using credit-cards, what was stolen from them were actually
bitcoins, that they have been storing Bitcoin addresses in their systems
and those systems were compromised, Target wouldn't just have a PR
nightmare in their hands. They would be out of business."
Of course, it needn't be Target. The scenario has played out with a number
of exchanges, and is a sword of Damocles hanging over the cryptocurrency
space. The recent Winklevoss Bitcoin Trust SEC filing warns that "the
Trust’s bitcoins may be subject to loss, damage, theft or restriction on
access. There is a risk that part or all of the Trust’s bitcoins could be
lost, stolen or destroyed. The Sponsor believes that the Trust’s bitcoins
held in the Trust Custody Account will be an appealing target to hackers or
malware distributors seeking to destroy, damage or steal the Trust’s
bitcoins. Although the Security System’s design includes various elements,
such as redundancy, segregation and cold storage, to minimize the risk of
loss, damage and theft, neither the Custodian nor the Sponsor can guarantee
that the Security System will prevent such loss, damage or theft..."
This needn't be so, once an optional identity layer, modeled after the
Internet itself, is provided, as proposed in late August of last year on
this mailing list:
http://sourceforge.net/p/bitcoin/mailman/message/32737796/
http://sourceforge.net/p/bitcoin/mailman/message/32742809/
I hope it is apparent that this is the killer app folks have been searching
for in vain. Like its Internet analogues, BCIs will not be created
overnight and without collaboration - and TNABC is as good a place as any
for it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150108/964d2eef/attachment.html>

2023-06-07 15:28:09

- reply

📅 Original date posted:2014-12-18
📝 Original message:I'll pick up where you left off, Jeff. The thought process behind the
Bitcoin Core threading model, platform support, libification, dependency
management, core data structures, DoS mitigation, script evolution,
scalability roadmap... just to scratch the surface, is likely never going
to be apparent entirely from the source code itself, and will not, in its
current form, be easily understood before digesting repository docs, repo
issues, pull requests, IRC logs, mailing list archives (open and closed),
forum posts, wiki articles, historical repositories, the foundation's
technical blog, whitepapers, to name a few. I'd rather not guess how many
have got a grip on it. If any, across the entire spectrum. It may be the
bottleneck to address. I encourage everyone to take a look at the C#
Language Design Notes* on codeplex. We'll know we've met the challenge when
folks are no longer digging up gmaxwell's IRC comments to understand the
rationale on nScriptCheckThreads, nor having to refer to sipa's
stackexchange to figure out chainstate & blockindex key/value pairs.
*
https://roslyn.codeplex.com/wikipage?title=CSharp%20Language%20Design%20Notes&referringTitle=Documentation
On Tue, Dec 16, 2014 at 5:59 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
>
> It can be useful to review open source development processes from time to
> time. This reddit thread[1] serves use both as a case study, and also a
> moment of OSS process introduction for newbies.
> [1]
> http://www.reddit.com/r/Bitcoin/comments/2pd0zy/peter_todd_is_saying_shoddy_development_on_v010/
>
>
>
>
> *Dirty Laundry*
> When building businesses or commercial software projects, outsiders
> typically hear little about the internals of project development. The
> public only hears what the companies release, which is prepped and
> polished. Internal disagreements, schedule slips, engineer fistfights are
> all unseen.
>
> Open source development is the opposite. The goal is radical
> transparency. Inevitably there is private chatter (0day bugs etc.), but
> the default is openness. This means that is it normal practice to "air
> dirty laundry in public." Engineers will disagree, sometimes quietly,
> sometimes loudly, sometimes rudely and with ad hominem attacks. On the
> Internet, there is a pile-on effect, where informed and uninformed
> supporters add their 0.02 BTC.
>
> Competing interests cloud the issues further. Engineers are typically
> employed by an organization, as a technology matures. Those organizations
> have different strategies and motivations. These organizations will
> sponsor work they find beneficial. Sometimes those orgs are non-profit
> foundations, sometimes for-profit corporations. Sometimes that work is
> maintenance ("keep it running"), sometimes that work is developing new,
> competitive features that company feels will give it a better market
> position. In a transparent development environment, all parties are
> hyperaware of these competing interests. Internet natterers painstakingly
> document and repeat every conspiracy theory about Bitcoin Foundation,
> Blockstream, BitPay, various altcoin developers, and more as a result of
> these competing interests.
>
> Bitcoin and altcoin development adds an interesting new dimension.
> Sometimes engineers have a more direct conflict of interest, in that the
> technology they are developing is also potentially their road to instant
> $millions. Investors, amateur and professional, have direct stakes in a
> certain coin or coin technology. Engineers also have an emotional stake in
> technology they design and nurture. This results in incentives where
> supporters of a non-bitcoin technology work very hard to thump bitcoin.
> And vice versa. Even inside bitcoin, you see "tree chains vs. side chains"
> threads of a similar stripe. This can lead to a very skewed debate.
>
> That should not distract from the engineering discussion. Starting from
> first principles, Assume Good Faith[2]. Most engineers in open source tend
> to mean what they say. Typically they speak for themselves first, and
> their employers value that engineer's freedom of opinion. Pay attention to
> the engineers actually working on the technology, and less attention to the
> noise bubbling around the Internet like the kindergarten game of grapevine.
> [2] http://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith
>
> Being open and transparent means engineering disagreements happen in
> public. This is normal. Open source engineers live an aquarium life[3].
> [3] https://www.youtube.com/watch?v=QKe-aO44R7k
>
>
>
>
> *What the fork?*
> In this case, a tweet suggests consensus bug risks, which reddit account
> "treeorsidechains" hyperbolizes into a dramatic headline[1]. However, the
> headline would seem to be the opposite of the truth. Several changes were
> merged during 0.10 development which move snippets of source code into new
> files and new sub-directories. The general direction of this work is
> creating a "libconsensus" library that carefully encapsulates consensus
> code in a manner usable by external projects. This is a good thing.
>
> The development was performed quite responsible: Multiple developers
> would verify each cosmetic change, ensuring no behavior changes had been
> accidentally (or maliciously!) introduced. Each pull request receives a
> full multi-platform build + automated testing, over and above individual
> dev testing. Comparisons at the assembly language level were sometimes
> made in critical areas, to ensure zero before-and-after change. Each
> transformation gets the Bitcoin Core codebase to a more sustainable, more
> reusable state.
>
> Certainly zero-change is the most conservative approach. Strictly
> speaking, that has the lowest consensus risk. But that is a short term
> mentality. Both Bitcoin Core and the larger ecosystem will benefit when
> the "hairball" pile of source code is cleaned up. Progress has been made
> on that front in the past 2 years, and continues. *Long term*, combined
> with the "libconsensus" work, that leads to less community-wide risk.
>
> The key is balance. Continue software engineering practices -- like those
> just mentioned above -- that enable change with least consensus risk. Part
> of those practices is review at each step of the development process:
> social media thought bubble, mailing list post, pull request, git merge,
> pre-release & release. It probably seems chaotic at times. In effect,
> git[hub] and the Internet enable a dynamic system of review and feedback,
> where each stage provides a check-and-balance for bad ideas and bad
> software changes. It's a human process, designed to acknowledge and handle
> that human engineers are fallible and might make mistakes (or be
> coerced/under duress!). History and field experience will be the ultimate
> judge, but I think Bitcoin Core is doing good on this score, all things
> considered.
>
> At the end of the day, while no change is without risk, version 0.10 work
> was done with attention to consensus risk at multiple levels (not just
> short term).
>
>
>
>
> *Technical and social debt*
> Working on the Linux kernel was an interesting experience that combined
> git-driven parallel development and a similar source code hairball. One of
> the things that quickly became apparent is that cosmetic patches,
> especially code movement, was hugely disruptive. Some even termed it
> anti-social. To understand why, it is important to consider how modern
> software changes are developed:
>
> Developers work in parallel on their personal computers to develop XYZ
> change, then submit their change "upstream" as a github pull request. Then
> time passes. If code movement and refactoring changes are accepted
> upstream before XYZ, then the developer is forced update XYZ -- typically
> trivial fixes, re-review XYZ, and re-test XYZ to ensure it remains in a
> known-working state.
>
> Seemingly cosmetic changes such as code movement have a ripple effect on
> participating developers, and wider developer community. Every developer
> who is *not* immediately merged upstream must bear the costs of updating
> their unmerged work.
>
> Normally, this is expected. Encouraging developers to build on top of
> "upstream" produces virtuous cycles.
>
> However, a constant stream of code movement and cosmetic changes may
> produce a constant stream of disruption to developers working on
> non-trivial features that take a bit longer to develop before going
> upstream. Trivial changes are encouraged, and non-trivial changes face a
> binary choice of (a) be merged immediately or (b) bear added re-base,
> re-view, re-test costs.
>
> Taken over a timescale of months, I argue that a steady stream of cosmetic
> code movement changes serves as a disincentive to developers working with
> upstream. Each upstream breakage has a ripple effect to all developers
> downstream, and imposes some added chance of newly introduced bugs on
> downstream developers. I'll call this "social debt", a sort of technical
> debt[4] for developers.
> [4] http://en.wikipedia.org/wiki/Technical_debt
>
> As mentioned above, the libconsensus and code movement work is a net
> gain. The codebase needs cleaning up. Each change however incurs a little
> bit of social debt. Life is a little bit harder on people trying to get
> work into the tree. Developers are a little bit more discouraged at the
> busy-work they must perform. Non-trivial pull requests take a little bit
> longer to approve, because they take a little bit more work to rebase
> (again).
>
> A steady flow of code movement and cosmetic breakage into the tree may be
> a net gain, but it also incurs a *lot* of social debt. In such
> situations, developers find that tested, working out-of-tree code
> repeatedly stops working *during the process of trying to get that work
> in-tree*. Taken over time, it discourages working on the tree. It is
> rational to sit back, *not* work on the tree, let the breakage stop, and
> then pick up the pieces.
>
>
>
>
> *Paradox Unwound*
> Bitcoin Core, then, is pulled in opposite directions by a familiar
> problem. It is generally agreed that the codebase needs further
> refactoring. That's not just isolated engineer nit-picking. However, for
> non-trivial projects, refactoring is always anti-social in the short term.
> It impacts projects other than your own, projects you don't even know
> about. One change causes work for N developers. Given these twin opposing
> goals, the key, as ever, is finding the right balance.
>
> Much like "feature freeze" in other software projects, developing a policy
> that opens and closes windows for code movement and major disruptive
> changes seems prudent. One week of code movement & cosmetics followed by 3
> weeks without, for example. Part of open source parallel development is *social
> signalling*: Signal to developers when certain changes are favored or
> not, then trust they can handle the rest from there.
>
> While recent code movement commits themselves are individually ACK-worthy,
> professionally executed and moving towards a positive goal, I think the
> project could strike a better balance when it comes to disruptive cosmetic
> changes, a balance that better encourages developers to work on more
> involved Bitcoin Core projects.
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> 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/20141218/2fbf1055/attachment.html>

2023-06-07 15:26:24

- reply

📅 Original date posted:2014-10-13
📝 Original message:When forgoing bootstrapping due to disk space constraints, you, and the
network, are likely better off -reindex-ing from current blk000??.dat files.
Which brings up an interesting point: The improvements related to the
headers first approach are likely to increase, how ever marginally, the
percentage of block exchange-related traffic, as it is less painful now to
be catching up.
It'd be interesting to see the statistics, not from a single node
perspective, but from the viewpoint of an Internet backbone provider, say
through the cables coming ashore in Cornwall. For the incurred bandwidth
expense would invariably trickle down to transaction fees in an equilibrium
model.
There is an opportunity somewhere in this.
On Sun, Oct 12, 2014 at 7:13 PM, Jameson Lopp <jameson.lopp at gmail.com>
wrote:
> Great work, Pieter. I've been spooling up several nodes per week lately
> and can testify that stalled downloads during initial syncing are a pain. I
> usually forgo bootstrapping on VPSes because I don't want to have to adjust
> the disk space allocation.
>
> With headers-first I'm saturating my home cable connection with download
> rates of 4 MB/s until block 295,000 at which point CPU becomes the
> bottleneck and it settles down in the 1 MB/s range.
>
> It took 6 minutes for my node to sync to block height 100,000
> 22 minutes to reach height 200,000
> 62 minutes to reach height 250,000
> 125 minutes to reach height 295,000
> 144 minutes to reach height 300,000
> 248 minutes to reach height 325,000
>
> - Jameson
>
> On 10/11/2014 07:34 PM, Pieter Wuille wrote:
> > Hi all,
> >
> > I believe that a large change that I've been working on for Bitcoin
> > Core is ready for review and testing: headers-first synchronization.
> > In short, it changes the way the best chain is discovered, downloaded
> > and verified, with several advantages:
> > * Parallel block downloading (much faster sync on typical network
> connections).
> > * No more stalled downloads.
> > * Much more robust against unresponsive or slow peers.
> > * Removes a class of DoS attacks related to peers feeding you
> > low-difficulty valid large blocks on a side branch.
> > * Reduces the need for checkpoints in the code.
> > * No orphan blocks stored in memory anymore (reducing memory usage
> during sync).
> > * A major step step towards an SPV mode using the reference codebase.
> >
> > Historically, this mode of operation has been known for years (Greg
> > Maxwell wrote up a description of a very similar method in
> > https://en.bitcoin.it/wiki/User:Gmaxwell/Reverse_header-fetching_sync
> > in early 2012, but it was known before that), but it took a long time
> > to refactor these code enough to support it.
> >
> > Technically, it works by replacing the single-peer blocks download by
> > a single-peer headers download (which typically takes seconds/minutes)
> > and verification, and simultaneously fetching blocks along the best
> > known headers chain from all peers that are known to have the relevant
> > blocks. Downloading is constrained to a moving window to avoid
> > unbounded unordering of blocks on disk (which would interfere with
> > pruning later).
> >
> > At the protocol level, it increases the minimally supported version
> > for peers to 31800 (corresponding to bitcoin v3.18, released in
> > december 2010), as earlier versions did not support the getheaders P2P
> > message.
> >
> > So, the code is available as a github pull request
> > (https://github.com/bitcoin/bitcoin/pull/4468), or packaged on
> > http://bitcoin.sipa.be/builds/headersfirst, where you can also find
> > binaries to test with.
> >
> > Known issues:
> > * At the very start of the sync, especially before all headers are
> > processed, downloading is very slow due to a limited number of blocks
> > that are requested per peer simultaneously. The policies around this
> > will need some experimentation can certainly be improved.
> > * Blocks will be stored on disk out of order (in the order they are
> > received, really), which makes it incompatible with some tools or
> > other programs. Reindexing using earlier versions will also not work
> > anymore as a result of this.
> > * The block index database will now hold headers for which no block is
> > stored on disk, which earlier versions won't support. If you are fully
> > synced, it may still be possible to go back to an earlier version.
> >
> > Unknown issues:
> > * Who knows, maybe it will replace your familiy pictures with Nyan
> > Cat? Use at your own risk.
> >
> > TL;DR: Review/test https://github.com/bitcoin/bitcoin/pull/4468 or
> > http://bitcoin.sipa.be/builds/headersfirst.
> >
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> 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/20141013/7e538cbd/attachment.html>

2023-06-07 15:25:35

- reply

📅 Original date posted:2014-08-20
📝 Original message:Thank you for your feedback regarding Custodial Identities. I will address
it to the mailing list for transparency.
Think of it as a 1-of-2 multisig edge case where Custodian Identities are
actively managed by the Bitcoin Assigned Custodial Identities
Authority/Regional Bitcoin Custodial Identity Registries. Once the optional
identity layer is integrated, there are so many applications beyond dispute
resolution, if you could effortlessly inject Custodian Identities into the
blockchain itself as easily as providing 1-of-2 public keys.
Bitcoin Custodial Identities can be applied to coinbase transactions as
well, in any or all jurisdictions, thus providing further incentive to keep
nodes honest, or enabling a recovery mechanism in catastrophic failure
events, such as a break in SHA-256. Custodians provide account addresses
out of unused address space further alleviating address collisions as a
psychological barrier to adoption. Custodial to non-custodial transactions
could behave much like the UTXO of a coinbase transaction, which has the
special condition that it cannot be spent (used as an input) for at least
100 blocks. It's based on open market competition, and there will probably
always be users willing to live outside of the BCI address space.
>>On Tue, Aug 19, 2014 at 10:23 PM, 21E14 <21xe14 at gmail.com> wrote:
>>
>>As suggested before submitting a BIP, I am sending this to the mailing
list.
>>
>>
>>Bitcoin is often described as “the currency of the Internet”, “the TCP/IP
of money”, or simply “the Internet of Money”. What is needed is an optional
identity layer — a Bitcoin Assigned Custodial Identities >>Authority, much
like the Internet Assigned Numbers Authority, to oversee global Custodial
Identity allocation. Such an authority delegates Custodial Identity Spaces
to Regional Bitcoin Custodial Identity >>Registries, much like the RIRs
(Regional Internet Registries) managing the allocation of Internet number
resources.
>>
>>A Bitcoin Custodial Identity (BCI) account address would consist of a
Custodial Identifier allocated by the BACIA/RBCIRs (much like a bank’s
routing number), and an account address (much like an account >>number).
Bitcoin Custodial Identities allow dispute resolution in the legal system
for transactions in the BCI address space. Free market would drive and
determine the demand for custodial accounts. P2PKH >>users not affected.
>>
>>Feedback is appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140821/03ee65c5/attachment.html>