Re: [bitcoin-dev] bitcoin-dev Digest, Vol 102, Issue 20
On Wednesday, November 8, 2023, < bitcoin-dev-requ...@lists.linuxfoundation.org> wrote: > delvingbitcoin.org is something I setup; it's a self-hosted discourse > instance. nice. > For what it's worth, I think (discourse) forums have significant > advantages over email for technical discussion: > > * much better markup: you can write LaTeX for doing maths, i love this aspect of discourse, but in all seriousness if you are relying exclusively on "web interfaces" for standard development of something as significant as bitcoin then there is something very very wrong. there is a reason why the linux kernel is hosted and run (patches) entirely via email. you *cannot* assume that every contributor will have permanent 24x7 high bandwidth internet. i am currentl operating solely off of a *mobile* LTE/WIFI dongle for example. it is PAYG *not* a contract. service is adversely affected by weather conditions and an "always-on web interface" is a serious problem. please please everyone: for goodness sake don't assume every contributor will have real-time permanent high-quality gigabit-speed internet just because in your country you happen to have that, ok? if you want graphs/maths you can use texstudio then *commit the latex into a git repository* or upload it somewhere online or ask someone to do so on your behalf. (i run libre-soc.org entirely self-hosted and made sure *all* resources are in git. mailing list (public-inbox - git), wiki (ikiwiki - git), bugtracker is the only one (i considered fossil and bugseverywhere) ah! i forgot! of course, there is fossil! https://opensource.com/article/20/11/fossil l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] bitcoin-dev Digest, Vol 102, Issue 15
On Tuesday, November 7, 2023, James Blacklock wrote: > Agreed, email lists are the way. Personally I love reading the email list; it is a great resource to know what kinds of technical discussions are going on in the community. I certainly hope we can just migrate to a different email list. i have a friend alain williams who runs lists.phcomp.co.uk and is competent at it. was the UKUUG Chair err 25 years ago? cc'd. the other lowest-common-denominator method is of course nntp newsgroups (eternal-september.org run an excellent spam-free one) and i do not mean "newsgroups via groups.google.com", i mean *actual* nntp newsgroups, you know, the ones that have been running for 40 years and everyone has forgotten even exist? :) they were and always have been distributed and distributable (and spam-free *if* run properly) and i am sure the owner of eternal-september would be happy to host/distribute bitcoin-dev. another idea is public-inbox which actually stores an entire mail archive *in a git repository* https://github.com/nojb/public-inbox public-inbox implements the sharing of an email inbox via git to complement or replace traditional mailing lists. Readers may read via NNTP, IMAP, Atom feeds or HTML archives. public-inbox can be "initialised" from a mailman archive so you can have the entire past history of messages in the git repo as well. it's really quite sophisticated. if anyone doesn't like "email bcuz old", or wants to remain anonymous, they can always get a protonmail account, use mail-forwarders, and TOR. and if they are happy to use nntp they can register on eternal-september.org, which then allows them to send and receive... and then use TOR-proxy. all doable *without* having to install something that will consume alarmingly high resources and cost a fortune in hosting every month. l. > > > On Tuesday, November 7th, 2023 at 3:20 PM, Luke Kenneth Casson Leighton via bitcoin-dev wrote: > > >> >> >> On Tuesday, November 7, 2023, < bitcoin-dev-requ...@lists.linuxfoundation.org> wrote: >> >> > Rooms can be E2E encrypted. >> >> please, NO. >> >> there are people who have such valuable skills that their >> lives are put in danger if they engage in encrypted conversations. >> >> additionally the entire point of an open project IS THAT IT IS OPEN. >> >> mailing lists are the lowest OPEN common denominator. >> >> l. >> >> >> -- >> --- >> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] bitcoin-dev Digest, Vol 102, Issue 15
On Tuesday, November 7, 2023, wrote: > Rooms can be E2E encrypted. please, NO. there are people who have such valuable skills that their lives are put in danger if they engage in encrypted conversations. additionally the entire point of an open project IS THAT IT IS OPEN. mailing lists are the lowest OPEN common denominator. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] bitcoin-dev Digest, Vol 85, Issue 4
(apologies i am subscribed digest) On Sun, Jun 5, 2022 at 1:00 PM wrote: > Date: Sun, 05 Jun 2022 04:18:04 + > From: alicexbt > To: Bitcoin Protocol Discussion > > Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable > Message-ID: > > > Hi Jorge, > > > Misinformation is false or inaccurate information, especially that which is > deliberately intended to deceive. > A combination of 'misleading' and 'information'. it's a classic technique that was refined by psy-ops well over 60 years ago. it should come as no surprise at all that it is being systematically deployed to undermine bitcoin. (welcome to the party, all psy-ops teams reading this: i admire your persistence and tenacity. you serve an extremely useful purpose of detecting flaws in the resilience of bitcoin and its development.) a potential solution is Trust Metrics. the most successful open source experiment in that regard was advogato.org by Raph Levien. i expanded it greatly so that any user could specify the "seeds" whom *they* trusted, rather than being forced to utilise the fixed hard-coded user ids in the advogato.org source code (this difference is extremely important for de-centralisation) public declarations of trust, and their propagation through standard Maximum-Flow Graph analysis, helps greatly to filter out the crap. advogato deflected heavy systematic and sustained spam attacks thanks to the simple expedient of users declaring publicly whom they trusted. a more advanced version of the max-flow concept came up a few years later called keynote (RFC2704) the similarity between trust metric evaluation and the bitcoin protocol is so remarkable that i am, frankly, slightly stunned that it was not added right from the start. it is ironic that the lack of integrated trust metric evaluation built-in to the bitcoin protocol is now hampering developers from being able to evaluate whom to trust when it comes to protocol development. l. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Fwd: NLnet cryotoprimitives grant approved
with many thanks to NLnet, the EUR 50,000 grant to research and develop Draft cryptographic primitives and instructions to the newly-open Power ISA has been approved. unlike RISC-V where full transparency and trust is problematic and there are many participants whose interests may not necessarily align, the OpenPOWER initiative, which has been in careful planning for nearly 10 years, is a much less crowded space and, crucially, does not require non-transparent membership of OPF in order to submit ISA RFCs (Requests for Change) [non-OPF members cannot participate in actual ISA WG meetings and certainly cannot vote on RFCs, but they can at least submit them. whereas whilst the RISC-V Foundation's Commercial Confidence Requirements are perfectly reasonable, the blanket secrecy even for submitting RFCs is not] we at Libre-SOC aim to use this process, based on taking apart key strategic cryptographic algorithms back to their mathematical roots, then applying Vector ISA design analysis and seeing what can be created. examples include going back to the fundamental basis of Rijndael, and instead of creating hardcoded custom silicon for MixColumns as is the "normal" practice, adding a generic Galois Field ALU and a generic Matrix Multiply system. another is to design instructions suitable for "big integer math" this in turn means that the resultant ISA would be ideally suited to the experimental development of future cryptographic algorithms for use in securing wallets and other purposes related to blockchain management. [as bitcoin stands we cannot possibly hope to compete with custom silicon dedicated to SHA hash production, however we would very much like to see a future version of bitcoin that uses far less power yet retains its high strategic value, and, at the same time, like e.g. monero RandomX, is better suited to a general-purpose Vector Supercomputer ISA, which is what we are developing] OpenPOWER's commitment to a transparent RFC process allows us to do that without compromising trust: no discussions that we participate in will ever be behind closed doors. if anyone would be interested to participate or collaborate on this, we have funding available, and welcome involvement in designing and testing an ISA suitable for securing bitcoin for end-users in a fully transparent fashion. l. --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Making the case for flag day activation of taproot
would it help by first setting a regular period of e.g. 6 months when only at that time would consensus rules ever be changed? not, "6 months from now taproot will be introduced', a rule, "*any* consensus change regardless of what they are (including NO change) will *ONLY* be made at regular interval period X months". this stops dead efforts by bots to announce "consensus! rules! are changing!" because if it's not at the exact time-period it's clearly bullshit. l. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs
(cc'ing over to libre-soc-dev) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018392.html On Thu, Feb 11, 2021 at 8:21 AM ZmnSCPxj wrote: > > i was stunned to learn that in a 28nm ASIC, 50% of it is repeater-buffers! > > Well, that surprises me as well. > [...] > So I suppose at some point something like that would occur and I should not > actually be surprised. > (Maybe I am more surprised that it reached that level at that technology > size, I would have thought 33% at 7nm.) it's about line-drive strength: lower geometries are even *less* able to line-drive long distances. > Another point to ponder is test modes. > In mass production you **need** test modes. > (Sure, an attacker can try targeted ESD at the `TESTMODE` flip-flop > repeatedly, but this risks also flipping other scan flip-flops that contain > the data that is being extracted, so this might be sufficient protection in > practice.) if however the ASIC can be flipped into TESTMODE and yet it carries on otherwise working, an algorithm can be re-run and the exposed data will be clean. > If you are really going to open-source the hardware design then the layout > is also open and attackers can probably target specific chip area for ESD > pulse to try a flip-flop upset, so you need to be extra careful. this is extremely valuable advice. in the followup [1] you describe a gating method: this we have already deployed on a couple of places in case the Libre Cell Library (also being developed at the same time by Staf Verhaegen of Chips4Makers) causes errors: we do not want, for example, an error in a Cell Library to cause a permanent HI which locks us from being able to perform testing of other areas of the ASIC. the idea of being able to actually randomly flip bits inside an ASIC from outside is both hilarious and entirely news to me, yet it sounds to be exactly the kind of thing that would allow an attacker to compromise a hardware wallet. potentially destructively, mind, but compromise all the same. beyond even what the trezor team discovered [2] it makes it even more important that wallet ASICs be Libre/Open. l. [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018412.html [2] https://blog.trezor.io/introducing-tropic-square-why-transparency-matters-a895dab12dd3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs
On Sat, Feb 13, 2021 at 3:01 PM Bryan Bishop wrote: > I don't see what you're talking about? None of your February emails > were sent to ozlabs according to the archives there. Threads for the > bitcoin-dev mailing list are stored here: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/thread.html ... i am very confused, and also did not mean to send this to the list at all! with many apologies for taking up peoples' time here. l. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs
On Sat, Feb 13, 2021 at 6:10 AM ZmnSCPxj wrote: > > Good morning Luke, morning - can i ask you a favour because moderated (off-topic) messages are being forwarded https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/ could you send these instead to libre-soc-...@lists.libre-soc.org? many thanks, l. > Another thing we can do with scan mode would be something like the below > masking: > > input CLK, RESET_N; > input TESTMODE; > input SCANOUT_INTERNAL; > output SCANOUT_PAD; > > reg gating; > wire n_gating = gating && TESTMODE; > always_ff @(posedge CLK, negedge RESET_N) begin > if (!RESET_N) gating <= 1'b1; /*RESET-HIGH*/ > elsegating <= n_gating; end > > assign SCANOUT_PAD = SCANOUT_INTERNAL && gating; > > The `gating` means that after reset, if we are not in test mode, `gating` > becomes 0 permanently and prevents any scan data from being extracted. > Assuming scan is not used in normal operation (it should not) then > inadvertent ESD noise on the `gating` flip-flop would not have an effect. > > Output being combinational should be fine as the output is "just" an AND > gate, as long as `gating` does not transition from 0->1 (impossible in normal > operation, only at reset condition) then glitching is impossible, and when > scan is running then `TESTMODE` should not be exited which means `gating` > should remain high as well, thus output is still glitch-free. > > Since the flip-flop resets to 1, and in some technologies I have seen a > reset-to-0 FF is slightly smaller than a reset-to-1 FF, it might do good to > invert the sense of `gating` instead, and use a NOR gate at the output (which > might also be smaller than an AND gate, look it up in the technology you are > targeting). > On the other hand the above is a tiny circuit already and it is unlikely you > need more than one of it (well for large enough ICs you might want more than > one scan chain but still, even the largest ICs we handled never had more than > 8 scan chains, usually just 4 to 6) so overoptimizing this is not necessary. > > > Regards, > ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs
On Wednesday, February 3, 2021, ZmnSCPxj wrote: > Good morning again Luke, :) > If you mean miner power usage, then power efficiency will not reduce energy consumption. > Thus, any rational miner will just pack more miners in the same number of watts rather than reduce their watt consumption. yes, of course. the same non-consumer-computing-intuitive logic applies to purchasing decisions for beowulf clusters. > Thus, increasing power efficiency for mining does not reduce the amount of actual energy that will be consumed by Bitcoin mining. arse. and if everybody does that, then no matter the performance/watt nobody "wins". in fact a case could be made that everybody "loses". my biggest concern here is that the inherent "arms race" results in very few players being able to create bitcoin mining ASICs *at all*. i mentioned earlier that geometry costs are an exponential scale. 3nm must be somewhere around USD 16 million for production masks. if there are only a few players that leaves the entirety of bitcoin open to hardware backdoors. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs
(hi folks do cc me, i am subscribed digest, thank you for doing that, ZmnSCPxj) On Wednesday, February 3, 2021, ZmnSCPxj wrote: > Good morning Luke, > > I happen to have experience designing digital ASICs, mostly pipelined data processing. > However my experience is limited to larger geometries and in SystemVerilog. larger geometries for a hardware wallet ASIC is ok (as long as it is not retail based and trying to run e.g. RSA, taking so long to complete that the retail customer walks out) > On the technical side, as I understand it (I have been out of that industry for 4 years now, so my knowledge may be obsolete) not at all! still very valuable > as you approach lower geometries, you also start approaching analog design. yyeah i could intuitively tell/guess there might be something like this which would throw a spanner in the works, it is why the grant request i put in specifically excluded data-dependent constant time analysis and also power analysis. > In our case we were already manually laying out gates and flip-flops (or replacing flip-flops with level-triggered latches and being extra careful with clocks) to squeeze performance (and area) ... ya-howw :) > Many of the formal correctness proofs were really about the formal equivalence of the netlist to the RTL; the correctness of the RTL was "proved" by simulation testing. thanks to Symbiyosys we are using formal proofs much more extensively, as effectively a 100% coverage replacement for unit tests. an example is popcount. we did two versions. one is a recursive tree algorithm, almost impossible to read and understand what the hell it does. the other is a total braindead 1-liner "x = x + input[i]", rubbish performance though. running a formal proof on these gave us 100% confidence that the complex optimised version does the damn job. yes we still do unit tests, these are more "demo code". now, the caveat is that you have to have a model of the "dut" (device under test) against which to compare, and if the dut is ridiculously complex then the formal model variant, which has to do the same job, ends up equally as complex (or effectively a duplicate of the dut) and the exercise is a bit of a waste of time... ...*unless*... there happens to be other implementations out there. then the proof can be run against those and everybody wins through collaboration. now, here's why i put in the NLnet Grant request to explore going back to the mathematics of crypto-primitives. many ISAs e.g. intel AVX2 have added GFMULT8 etc etc because that does S-Boxes for Rijndael. they have gone mad by analysing algorithms trying to fit them to standard ISAs. nobody does Rijndael S-Boxes any way other than 256-entry lookup tables because no standard ISA has general-purpose Galois Field Multiply. consequently implementations in assembler get completely divorced from the original mathematics on which the cryptographic algorithm was based. the approach i would like to take is, "hang on a minute: how far would you get if you actually added *general-purpose* instructions that *directly* provided the underlying mathematical principles, and then wrapped a Vector-Matrix Engine around them?". would this drastically simplify algorithms to the point where *READABLE* c code compiles directly to opcodes that run screamingly fast, outperforming hand-optimised SIMD code using standard ISAs? then, given the Formal Correctness approach above, can we verify that the mathematically-related opcodes do the job? > (to be fair, there were tools to force you to improve coverage by injecting faults to your RTL, e.g. it would virtually flip an `&&` to an `||` and if none of your tests signaled an error it would complain that your test coverage sucked.) nice! > Things might have changed. nah. this is such a complex area, run by few incumbent players, that innovation is rare. not least, innovation is different and cannot be trusted by the Foundries! > A good RTL would embed SystemVerilog Assertions or PSL Assertions as well. > Some formal verification tools can understand a subset of SystemVerilog Assertions / PSL assertions and validate that your RTL conformed to the assertions, which would probably help cut down on the need for RTL simulation. interesting. > Overall, my understanding is that smaller geometries are needed only if you want to target a really high performance / unit cost and performance / energy consumption ratios. > That is, you would target smaller geometries for mining. yes. > If you need a secure tr\*sted computing module that does not need to be fast or cheap, just very accurate to the required specification, the larger geometries should be fine and you would be able to live almost entirely in RTL-land without diving into netlist and layout specifications. hardware wallet ASICs. i concur. > A wrinkle here is that licenses for tools from tr\*sted vendors like Synopsys or Cadence are ***expensive***. yes they are :) we are currently wo
[bitcoin-dev] Libre/Open blockchain / cryptographic ASICs
folks, hi, please do cc me as i am subscribed "digest", apologies for the inconvenience. i've been speaking on and off with kanzure, asking his advice about a libre / transparently-developed ASIC / SoC, for some time, since meeting a very interesting person at the Barcelona RISC-V Workshop in 2018. this person pointed out that FIPS-approved algorithms, implemented in FIPS-approved crypto-chips used in hardware wallets to protect billions to trillions in cryptocurrency assets world-wide are basically asking for trouble. i heard 3rd-hand that the constants used in the original bitcoin protocol were very deliberately changed from those approved by FIPS and the NSA for exactly the reasons that drive people to question whether it is a good idea to trust closed and secretive crypto-chips, no matter how well-intentioned the company that manufactures them. the person i met was there to "sound out" interested parties willing to help with such a venture, even to the extent of actually buying a Foundry, in order to guarantee that the crypto-chip they would like to see made had not been tampered with at any point during manufacturing. at FOSDEM2019 i was also approached by a team that also wanted to do a basic "embedded" processor, entirely libre-licensed, only in 350nm or 180nm, with just enough horsepower to do digital signing and so on. since then, fascinatingly, NLnet has obtained a new EU Horizon Grant and started their "Assure" Programme: https://nlnet.nl/assure/ (our application may be found here): https://libre-soc.org/nlnet_2021_crypto_router/ in addition, betrusted (headed by Bunnie Huang) is also funded by NLnet and is along similar lines: https://betrusted.io/ NLnet is even funding LibreSOC with a 180nm test chip tape-out of the LibreSOC Core, with help from Sorbonne University and https://chips4makers.io https://bugs.libre-soc.org/show_bug.cgi?id=199 and we also have funding to do Formal Correctness Proofs for the low-level portions of the HDL (similar to c++ and python "assert", but for hardware) https://bugs.libre-soc.org/show_bug.cgi?id=158 the point being that where even one year ago the idea of an open source developer creating and paying for an actual ASIC was so ridiculous they would be laughed at and viewed in a derisive fashion thereafter, reality is that things are opening up to the point where even Foundry PDKs are now open source: https://github.com/google/skywater-pdk technically it is possible to use Open Hardware to create commercial (closed) products. Richard Herveille, most well-known for his early involvement in Opencores, was the Open Hardware developer responsible for the HDL behind the first Antminer product by Bitmain, for example. It used his RV32 core and i believe he also developed the SHA256 HDL for them. however that is different in that it was a closed product, not open for independent public audit and review. what i am therefore trying to say is that it is a genuinely achievable goal, now, to create fully transparently-openly-developed ASICs that could perform crytographic tasks such as mining and hardware wallet key protection *and have a full audit trail* even to the extent of having mathematical Formal Correctness Proofs. my question is - therefore - with all that background in mind - is: is this something that is of interest? now, before getting all excited about the possibilities, it's critically important to provide a reality-check on the costs involved: * 350nm ASICs: https://chips4makers.io - EUR 1750 for 20 samples * 180nm ASICs: EUR $600 per mm^2 MPW Shuttle (test ASICs) and EUR 50,000 for production masks * ... exponential curve going through 130nm, 65nm, 45nm gets to around $500k... * 28nm ASICs: USD 100,000 for MPW and USD $1 million for production masks * 22nm ASICs: double 28nm * 14nm: double 22nm * 7nm: quadruple 14nm you get where that is going. where higher geometries are now easily within reach even of a hobbyist ASIC developer, USD 20 million is a bare minimum to design, develop and bring to manufacture a 7nm Custom ASIC. full-custom silicon, as carried out regularly by Intel, is USD 100 million. this is not to say that it is completely outside the realm of possibility to do something in these lower geometries: you either simply have to have a damn good reason, or a hell of a lot of money, or a product that's so compelling that customers really *really* want it, or you have OEMs lining up to sign LOIs or put up cash-with-preorder. [my personal favourite is a focus on power-efficiency: battery-operated hand-held devices at or below 3.5 watts (thus not requiring thermal pipes or fans - which tend to break). i have to admit i am a little alarmed at the world-wide energy consumption of bitcoin: personally i would very much prefer to be involved in eco-conscious blockchain and crypto-currency products]. so - as an open question: what would people really like to see happen, here, what do people feel would be of interest to the wider bitcoi
