Bitcoin Forum
May 27, 2017, 05:55:46 PM *
News: If the forum does not load normally for you, please send me a traceroute.
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 104 »
1  Bitcoin / Development & Technical Discussion / Re: I'm still having trouble understanding BIP66 fork and Bitcoin's legitimacy on: May 17, 2017, 11:57:54 PM
However, for what I understand the ledger is inaccurate. I got that much out of it. I've been trying to make sense of how that affects the value of Bitcoins mined prior to BIP66 being implemented in contrast to Bitcoins mined after BIP66 and how the multiple ledgers and the BTC value relates, but that might be for a different thread.
Hello Officer!

We are very sorry that our developers removed the dependence on OpenSSL and the backdoors that you've planted there. The community felt it would be better without backdoors or with backdoors that are controlled by us.

Sincerely,

/* illegible signature */

By the way: how is the coffee being served nowadays at NSA/CIA/other TLAs?
2  Bitcoin / Technical Support / Re: Bitcoin 0.14.1 client crashes and not reachable on bitnodes.21 on: May 17, 2017, 11:19:19 PM
My question is - should running my full-node makes a difference? Should I just delete the client and forget about it?

Any suggestions?
For you, personally, it would make a great difference. You would learn a great deal about computers and networking. Whether it is worth investing your time, only you can make a true answer.

1) Bitcoin-Qt's window getting black is due to the design decisions made by the Core developer's to keep the reference client tightly integrated. It is more of a cosmetic issue for vast majority of users who don't try to integrate with other financial software.

2) You computer is kinda crappy, from the vendor that is recently known to ship borderline-scam computers to meet marketing targets. Learn to make use of what you have or buy/assemble something better, even using older parts. Notwithstanding the above comment the reference Core client is quite well-optimized and serves as a decent hardware stress-test for CPU, memory, disks and their controllers.

3) Your network connection definitely seems sub-standard. Do you even have a real Internet connection or are you using some CG-NAT cheapie?

4) Avoid posting your actual IP address on this board. It is full of sharks who probably run all kinds of scans on your computer to find possible misconfiguration and steal your coins. There were all kinds of scammers offering remote help via TeamViewer (or similar tools) to rip people off.

The decision is really up to you.
3  Bitcoin / Hardware / Re: Delta vs WYE 3 Phase Electrical Service on: May 17, 2017, 10:37:56 PM
Thanks! I was looking for a diagram like that to better explain the Delta connection.
Bookmarked.
Well, enjoy your HTTP bookmark.

I just wanted to provide additional, mental bookmark, for those that are still confused. It is better to not call that weird asymmetric connection with single word "delta". It is properly called "high-leg delta" or "four-wire delta". The unqualified "delta" is a three-wire, no-neutral, type of service hookup. The eventual 4th conductor is just protective grounding, explicitly prohibited from carrying any significant current under normal operating conditions. In many high-power installation the "ground" is the actual ground of the Earth, there isn't any 4th conductor.

NotFuzzyWarm mentioned the historical origin of this weird service in the USA. The legacy of it still stays in the intentional and accidental misinformation in many sources on the web and even in many lower-level textbooks and training materials.

It looks like the original poster Hockeybum had already budgeted for electrical engineer's consulting expenses. For many people (not familiar with peculiarities of the North American grid) this would be an unnecessary expense, sort of a tax on lack of knowledge of trigonometry or calculus. Rest of the world wouldn't have to concern themselves with strangeness like "split-phase", "high-leg delta" or "corner-grounded delta". It seems like sidehack had avoided this tax by intentionally opting for the safest choice of "wye"  (known as "star" throughout the rest of the world).

For the benefit of future readers who want to avoid additional EE consulting expenses I have the following advice: search for a electrician who is at least familiar with things that are outside of "the code"/NEC . The good thing to ask for is a https://en.wikipedia.org/wiki/Zigzag_transformer or https://en.wikipedia.org/wiki/Scott-T_transformer
even if you don't plan on getting one. It will probably mark you as an "educated buyer" not as somebody who is relatively easy to bamboozle with jargon to buy both belt and suspenders to match their new Bermuda shorts.
4  Bitcoin / Hardware / Re: Delta vs WYE 3 Phase Electrical Service on: May 16, 2017, 08:42:43 PM
You may have difficulty obtaining/upgrading center-tapped delta service. Electric utilities don't like them because they are a source of asymmetry in the grid. Look at the transformer diagram in

https://en.wikipedia.org/wiki/High-leg_delta

from the point of view of the utility. If you pull 200A each from the low legs (SA & SC on the diagram) than means 48kW of power on the a single primary transformer winding (PA & PC) but zero power on the primary windings PA-PB and PB-PC. This is inefficient use of the capital spent on the transformer(s).

So they will push you to either:

1) use very little (about 5%-10%) power on the high-leg. They will then use two transformers, one much smaller than the other.

2a) buy equal amounts of power through each of the transformer windings. That would mean the amperage on the high-leg will be different than on the low-legs.

2b) use symmetric hookup with all leg voltages equal.

The exact rules in the USA are state-dependent and utility-tariff-dependent. Most likely they will flatly refuse upgrade if they sense that you don't understand the basic trigonometry required to balance the load. Then you will be forced to get not only certified electrician but "engineering supervision" before they agree to upgrade the asymmetric service.

It may be worthwhile (moneywise) for you to understand the equations before you talk to the utility people. Avoid burning bridges by asking stupid question when talking with them. They can legally refuse or stall your install when hooking you up would significantly unbalance their grid.

5  Bitcoin / Mining speculation / Re: Possible Mining Location. Abandoned Smelter! on: May 15, 2017, 10:04:46 PM
The entire building is made from sheet metal and steel girders. Minimal wood fixtures. Most if not all could be replaced with cheap metal shelving so fire damage or ignition sources are negligible. Keep in mind this particular building was used to pour molten steel at temps over 2000 degrees! Almost as hot as a stack of Antminers!  Wink
I wasn't precise enough. I didn't mean "your equipment damages building" but "building damages your equipment".

That could be fire damage, water damage, dust/residue damage, etc. You are basically repurposing heavy, dirty industry facility into something much more sensitive to the environmental factors.

I have no first hand experience with coin mining facilities, but I do have experience with more conventional temporary computing/data centers. One of our facilities caused equipment damage via horse hair getting sucked into fans and seizing them. That was because the attached building was dual use: in an emergency it was used as a livestock shelter.

Edit: in another location we had equipment failures (this time mostly temporary shorts) caused by copper wire shavings/cuttings embedded in packed dust. The facility was used for wiring harness manufacturing (cutting, crimping, soldering, shaping, shrink-wrapping).

Edit2: on the flip side of the coin: in one another facility the hot-running computer equipment (no air-conditioning) was instrumental in fixing the water/mold damage to the premises.

In general I think you have a good opportunity on your hands. Just research some pitfalls of "brownfield" location before you actually move in. Good luck.
6  Bitcoin / Technical Support / Re: Bitcoin 0.14.1 client crashes and not reachable on bitnodes.21 on: May 14, 2017, 09:05:21 PM
On bitnodes.21.co - my IP (141.226.3.1) is reachable 1 out of the 4 clicking the "check node", and unreachable 3 out of these 4 "check node" clicks (which is an improvment, I guess). Any guesses why?
Don't give to much value to what is shown by https://bitnodes.21.co , that site isn't very reliable. For two reasons:

1) it is quite buggy
2) it was subject to various attacks and attempt to skew statistics, therefore it employs various strange algorithms to defend itself and other servers on their ISP

I have very reliable connection and frequently get less than 50% availability score on that site. It isn't completely useless, but it isn't even statistically correct.
 
7  Bitcoin / Bitcoin Discussion / Re: Why Bitcoin Core Developers won't compromise on: May 14, 2017, 07:33:44 PM
I think my argument is quite watertight concerning the non-power of full nodes, and I've never seen a LOGICALLY ARGUMENTED rebuttal to it, that doesn't confuse full nodes with users, or doesn't confuse it with the power game of a hard fork.
You've spent too much time arguing with dumbasses and marketroids which caused you to start believing in your own bullshit.

Almost from the inception people understood the importance of distributed node network, even if under centralized control:

1) ability for nearly anyone and relatively cheaply audit (in the accounting sense) the totality of the system.

2) distributed node architecture makes it easy and cheap to hide the actual expensive nodes (either due to mining or transacting/exchanging) from both attacks launched over the network.

3) not currently implemented by Core, but possible, the broadcast architecture makes it possible to use non-Internet methods of communication with super-extreme bandwidth asymmetry (high download but little upload).

Dinofelis, you clearly seem to have some academia background. But it must have been some theology school (or something equally anti-scientific) to be so unwilling to actually refer to the available references and verify your own assumptions.
8  Bitcoin / Mining speculation / Re: Possible Mining Location. Abandoned Smelter! on: May 14, 2017, 06:10:25 AM
I have following comments:

1) split profits and costs with the owner of the property. Offer to help maintain the property in a sellable/rentable condition: some cleaning and maintenance, especially windows, roofs and air ducts.

2) upgrade security. I don't know what exactly "abandoned" means in your case. You'll need to make sure that the location wasn't used by squatters, for warehousing some dangerous/toxic materials or is infested with some vermin.

3) recheck the fire safety regulations: alarms, access roads, etc.

4) make sure that you are actually dealing with an actual owner/deed holder, not some "defective lease holder"

The general idea is that when you'll bring your equipment into a location you want to be sure that it is going to stay there and work for you. You want to avoid the possibility of accidental destruction, theft or repossession in lieu of past debts.
9  Bitcoin / Hardware / Re: [SCAM] Foxminers? on: May 10, 2017, 01:06:35 PM
Don't mind MOST OF your reply much, actually.  No, I didn't have a horrible education, I opted out of CS in engineering school because I was cognizant that I was hitting a wall in hard engineering and wasn't trying hard enough in digital design, physics, calculus, etc, too busy having fun, and I had no $.  Reality check, almost everyone does hit a wall at some point where they realize they are just faking it if they continue to try to advance, learning how to do it pretty well but have stopped total comprehension.  

Did a different career for 5 years, went back and did CS business degree and had a very successful career in business software dev.  I pretty much quit giving a crap about hardware while mainframe programming for 13 years, because I was riding the fastest horse in the hardware world then, hardware not by me, but smokin hot MVS with serious capacity hardware for a many billions company and I focused on delivering high quality for my end users, and that went really well as I could actually communicate with them and deliver quickly and on target and with a low margin of error without 5 intermediaries like today's email writer management layers of bullshit overhead.

If ya saw no point, why did you reply? Did you read all my posts, or was it just time to be a dick to the new guy?
Ah! Greetings retired IBM-fanboi! In the IBM-universe I'm not a big MVS fan, I'm was more into running multiple copies of MFT or CMS under VM/370.

Let me start from the last paragraph. The reason I'm writing and responding to you is standard one for me: I know that for 1 poster here there are at least 10 readers who will read yours and mine posts with understanding. So when I'm personally addressing you (delicopsch56) it is more of a rhetorical device to address the plurality of you (named and unnamed readers of this thread).

In particular I'm writing for the benefit of young readers, who are still ahead in their life. They can still use their school time to "learn", not to "have fun". They can still avoid having "successful career" where maintaining employment was only possible with the help of regularly obliterating their own brain with alcohol (or other addictive substances or behaviors). I used to work in the entertainment industry and I can immediately recognize a bitter burnout. I've been on the meetings where people would small-talk about addiction rehab facilities like most of the employed people discuss vacation destinations.

There isn't much technical and mining-related to address in your reply. You've however very clearly and beautifully underlined the perils of technical fanboism. Most of the technical forums have fanboi discussion threads like Intel vs. AMD, ATI vs. NVidia, etc. delicopsch56 is an example of a dinosaur fanboi, from the days when various IBM-designed machines were bought under the assumption of "nobody ever got fired for buying IBM". IBM may even had "fastest horse" trophy for awhile, they still sell them under "z/Arch" moniker, but lots of people got fired for continuing to "buy IBM" where different, better, cheaper, faster solutions were available.

The simplest, easiest way to avoid burnout and being perpetually perplexed is to keep your mind open. Even if you don't have time or money to pursue a formal degree you can still greatly benefit from clicking around the "See Also" links in Wikipedia. And when you choose to "have fun", choose the activities that do as little as possible damage to your brain.

I want to personally "thank you" to all those people who gave the similar advice when I was young student in school. You most likely won't read it. All I can do repay it is to repeat it in an updated way, with modifications to match the changed technological landscape.
10  Bitcoin / Hardware / Re: [SCAM] Foxminers? on: May 10, 2017, 02:57:34 AM
I am not involved in the architecture design and strictly follow the node-size tech eg physical construction of the gates vs implementing actual circuits to explains 'why's' as part of the voodoo I do.
I avoid this type of argumentation (back-end, physical) not because it is inherently bad. I avoid it because historically in the Bitcoin milieu most bullshit was using this type of argumentation. Some of it was intentional, profit-motivated bullshit meant to deceive. Some of it was plain dumbassery and fanboism with no actual ill intentions, just mostly lack of introspection and inquisitiveness. The profit-motivated bullshit has now shifted to other crypto-coins with various discussions of "ASIC-proof", "memory-hard", "branch-heavy" and other post-Bitcoin bullshit.

The reality of year 2017 is that it takes about $99 (for Digilent Arty FPGA experimenter board) and about month's worth of free evenings to learn and understand all the requited basics of crypto-coin mining. For Bitcoin the heydays of profitable FPGA mining are over, but all the technical concepts are still valid. All the required software (and knowledge) are either open-source or available for free from the FPGA vendor under chip-lock license. It clearly isn't a replacement for a full graduate degree in a related engineering discipline. But it is more than sufficient to quickly and clearly recognize bullshitters posting here and in other venues.
11  Bitcoin / Hardware / Re: [SCAM] Foxminers? on: May 09, 2017, 06:53:19 PM
I don't want to dig much deeper, this old dog just flat didn't think about the multiple cpu\core overhead at all from a hardware design perspective.
Kinda noobie question, I'm still on board with SCAM SCAM SCAM but I don't follow processor dev for years, and I claim no EE,  I think I get the basics of tough miniaturization issue advances on these chips at a high level.
You may not like my answer, but I will be short and frank.

The primary reason has of your inability to understand has nothing to do with old age, not following the recent trends, etc.

You've simply received a horrible education and know nothing about the digital technology advances from made in the middle of 1950 decade.

You seem to only be aware of https://en.wikipedia.org/wiki/Von_Neumann_architecture first published in 1945 and you seem to try to translate everything into it, even if clearly the implementation uses different conceptual model. Bitcoin mining is a perfect example of problem better handled by https://en.wikipedia.org/wiki/Mealy_machine (from 1955) or https://en.wikipedia.org/wiki/Moore_machine (from 1956). Any discussion involving concepts like: caches, branches, CPU, I/O, threads, cores, etc. only shows that the person writing it doesn't know the technological advances from the middle of the previous century. In my school these are discussed in the 2nd or 3rd semester of education, literally during couple of of first lectures in the digital logic design (both theory and lab practice)

The primary advances in the power efficiency of the Bitcoin miner were:

1) to implement it as fixed program Moore machine on an FPGA. The FPGA device is itself reprogrammable, so it is still wasteful
2) to have the same fixed program Moore machine implemented without the waste of supporting reprogramming and take advantage of the fact that Bitcoin's 2*SHA256 is essentially self-testing, so even the standard chip-testing circuitry is not required.

Personally, I see no point of discussing advanced electrical engineering stuff without understanding of the basics.

When I was in school it was a common understanding that students with absolutely no contact with any computer are doing noticeably better than students who gained experience of computers via some horrible "home computers" programmed in BASIC with plentitude of GOTOs. There was this seminal paper "GOTO Considered Harmful" written in 1968 by Edseger Dijkstra and published same year by the Communications of the ACM.

I presume that you (and other otherwise educated people) suffer from some version of the above problem: lack of proper basic education in computer architecture. Sometimes I wonder how those people graduated with any real degree (not from a degree mill). But then I have to remind myself that nowadays there are plenty of accredited, real "humanistic/psychological/human-oriented" educational institutions that do grant real degrees.
12  Bitcoin / Mining speculation / Re: What price must BTC/USD be to get more ASIC manufacteurs? on: May 05, 2017, 09:16:08 AM
It is neither too complex or too expensive. The opposite is true: it is remarkably simple and remarkably cheap. The main problem facing the Bitcoin mining hardware manufacturers is that they cannot obtain proper design expertise, neither as employers or as contractors. Simply speaking: nobody really knowledgeable wants to work for/with them.

From my past discussions:

1) extreme short-termism and insistence on pushing contractual terms that are not technically appropriate for the product
2) psychological/social problems dealing with Bitcoin mining entrepreneurs: a strange mixture of pyramid/multi-level-marketing outlook with sectarian/religious fervor (imagine mixing AmWay with Scientology)

ASICminer people were the only ones willing to admit to difficulty hiring/contracting and only did that briefly and to Chinese-only audience.
13  Bitcoin / Development & Technical Discussion / Re: How to use properly secp256k1 library on: April 28, 2017, 06:31:30 PM
Right, using a using an integer multiply is needlessly slow but thats just the right idea.
Well, what I had in mind was not ADD/MUL instructions but addition and multiplication in a commutative field. From the way the posters in this thread use the word endomorphism, I presume that they were vaccinated for it and have immunity. Wink
 
(If you're curious, here is how we accomplish those conditional accesses, we loop over the entries with https://github.com/bitcoin-core/secp256k1/blob/master/src/field_5x52_impl.h#L419 ).
It is more or less a software re-implementation of what CPU hardware does when accessing cache lines. Except that the hardware also does ECC check after read and re-computes ECC before write, even on the cheapest processors. (ECC being an Error-Correcting Code.)

Also this code looks like a good candidate to try use the new BMI (Bit Manipulation Instructions) available in the newer x86 processors.

Well we  wouldn't care about vectorizing signing in any case-- at least in Bitcoin land signing many messages at once is never a bottleneck (and really if you're designing something new where it is, merkelize your data and do a single signature (perhaps with an aggregated key).  Smiley
It is more of a view from your chair, where you don't see the necessity of easy vectorization. As an outside observer, not personally involved in the current battles, I can immediately think of two areas:

1) mining/pool server code is very much likely to benefit from vectorization (possibly variable-length vectors)
2) code embedded in portable/dedicated hardware or otherwise subject to either random hardware faults or intentional fault injection to extract secrets. In that case fixed-length vectors are the savior:
2a) 2-way SIMD where the payload consists of a one new signature and one known signature (from the list of benchmark/test problems). This is the best way to operate in the presence of random faults.
2b) 4-way SIMD where they payload is double of the above, each signing operation duplicated and then verified for equality at conclusion. This is the best way to detect intentional tampering via hardware faults.

I will not break too many NDAs by stating that many of those secret, highly secure processors are internally looking like "Z80 with SIMD" as a way to make the hardware and its programs hard to crack. For anyone working with no NDAs, targeting ARM with NEON is an excellent benchmark for writing and testing their code.

But lets say verification: At least on x86 style SIMD efficiently doing a fast table lookup (which is needed to exploit precomputation for state of the art performance) is not easily accomplished.   I haven't checked lately, FWIW, but by CPU vanity gen is as was previously just as fast at the GPU vanity gens due to exploiting optimizations like extensive precomputation.   Though it's possible to use pshufb to access small tables, big tables are another issue. Regardless, there is no way the compiler is going to do anything too interesting there on its own, beyond perhaps optimizing some copying loops that would better be eliminated.

(Not that I would discourage someone from trying, it would be an learning experience even if it failed)
I don't disagree with you, but I've observed that there were many unexplored avenues for further hardware-dependent optimization. In particular everyone seems to be sort of stuck at essentially one representation, where all the words of the a bignum are next to each other in memory. From my experience doing the two matrix transposes (one before and one after the actual EC computation) could possibly be a net gain. The intermediate representation would then have all the least significant words of bignums next to each other in memory)
Our use of types already means that the compilers existing assumption of the aliasing rule (no pointers of distinct types may alias each other except with char) already gets a lot of restrict's gain, as does the fact that everything gets build in a single compilation unit so the compiler can _see_ the actual non-aliasing of most things... I would love to use restrict but until about a month ago the situation with GCC was that restrict was blindly heeded, even when the compiler could _directly_ see that the values aliased, and it produced no warnings and would reliably "miscompile" code.  So restrict was something of a gratuitous safety footgun and no static analysis tool I have could help us catch the introduction of restrict errors.  I've been nagging GCC developers for a while about this and the latest development versions of GCC now include limited static analysis of restrict usage.

We do document which internal inputs are/aren't permuted to alias, with a hope of using restrict in the future.
Thanks for a very interesting data point and its explanation. By necessity I mostly work with for-pay compilers, not with GNU tools.
14  Bitcoin / Development & Technical Discussion / Re: How to use properly secp256k1 library on: April 25, 2017, 12:17:04 AM
G***it.  For Bitcoin talk moderators there is an edit button on every post right next to the quote button.  The edit screen looks almost identical to what you get when you quote a message.

After years of moderating I finally managed to reply by instead editing someone's post.  Sorry 2112. I'm going to try to get theymos to un#$@ things.   I have my reply but I don't have your original message. If by chance you have it, you could just repost. Otherwise we're stuck waiting for it to get fixed.

I am very sorry for this screwup.
Okey, let me try to fetch from drafts. I also got PM from "Guest" with what looked like your reply during composition. Post if you want to continue editing it, then I will delete the "Bitcoin Forum" quote below.

Edit: elided 2nd copy of my post now that Theymos had restored the accidentally deleted original.

Quote from: Bitcoin Forum
A reply of yours, quoted below, was deleted by a Bitcoin Forum moderator. Posts are most frequently deleted because they are off-topic, though they can also be deleted for other reasons. In the future, please avoid posting things that need to be deleted.

Quote
Wrong:
x) r =a[ i ];
y) if (i) r = a[1]; else r = a[0];
z) if (i) r = a1; else r = a0;

Good:
a) r = i*a1 + (1-i)*a0;
b) r = i*a[1] + (1-i)*a[0];
c) for (j = 0; j <= 1; j++) r += (j == i)*a[j];

Right, using a using an integer multiply is needlessly slow but thats just the right idea.   Though it is possible to construct optimizations that are only faster if you can get away with a which is what I thought I was talking about here.

(If you're curious, here is how we accomplish those conditional accesses, we loop over the entries with https://github.com/bitcoin-core/secp256k1/blob/master/src/field_5x52_impl.h#L419 ).

Quote
vs. easy for the compiler to vectorize:
     ECsign(int n,signature [],message [], secret_key [],nonce [])
     each argument points to a vector of n objects of the particular type.


Well we  wouldn't care about vectorizing signing in any case-- at least in Bitcoin land signing many messages at once is never a bottleneck (and really if you're designing something new where it is, merkelize your data and do a single signature (perhaps with an aggregated key).  Smiley

But lets say verification: At least on x86 style SIMD efficiently doing a fast table lookup (which is needed to exploit precomputation for state of the art performance) is not easily accomplished.   I haven't checked lately, FWIW, but by CPU vanity gen is as was previously just as fast at the GPU vanity gens due to exploiting optimizations like extensive precomputation.   Though it's possible to use pshufb to access small tables, big tables are another issue. Regardless, there is no way the compiler is going to do anything too interesting there on its own, beyond perhaps optimizing some copying loops that would better be eliminated.

(Not that I would discourage someone from trying, it would be an learning experience even if it failed)

Quote
I just looked in the github at the actual header file and have one more question to ask: why not using "restricted" C pointers? In my experience that was one of the simplest and cheapest gains to achieve by switching the C pointers to non-overlapping FORTRAN semantics. It was standardized so long ago that nowadays everyone supports it.
Our use of types already means that the compilers existing assumption of the aliasing rule (no pointers of distinct types may alias each other except with char) already gets a lot of restrict's gain, as does the fact that everything gets build in a single compilation unit so the compiler can _see_ the actual non-aliasing of most things... I would love to use restrict but until about a month ago the situation with GCC was that restrict was blindly heeded, even when the compiler could _directly_ see that the values aliased, and it produced no warnings and would reliably "miscompile" code.  So restrict was something of a gratuitous safety footgun and no static analysis tool I have could help us catch the introduction of restrict errors.  I've been nagging GCC developers for a while about this and the latest development versions of GCC now include limited static analysis of restrict usage.

We do document which internal inputs are/aren't permuted to alias, with a hope of using restrict in the future.


15  Bitcoin / Bitcoin Discussion / Re: Why ASIC BOOST is necessary. on: April 24, 2017, 06:30:11 PM
Why would I ?  It catches on, no ?  The main goal of this catchy title was to indicate that it doesn't pay to censor me, but it can maybe serve other purposes. As long as I don't get *what* propaganda I'm spreading, I cannot find out whether I'd like to continue doing so or not, no ? 
Well, then don't claim here to learn when what you do is stirring the shitstorm with glee. You'll end up like cypherdoc, they kept edging him on until he lost cool and was quite legitimately censored.

If you can't live without propagandizing at least switch to something more defensible like "ASICBOOST is meh" or "ASICBOOST overpromises and underdelivers" or "How I learned to stop worrying and love the ASICBOOST".
 
16  Bitcoin / Development & Technical Discussion / Re: How to use properly secp256k1 library on: April 24, 2017, 06:03:41 PM
I did say unless there is a very strong validation framework.  (We have machine verified code in libsecp256k1-- but the tooling does not scale especially well, so far)
I don't want to get into word games. I understand your concerns, but I mostly disagree with emphasis in your statements:
a) stressing human/manual work over machine work
b) stressing verification/validation over automated/algorithmic generation of the high-level code

We are getting into the deep paranoia territory covered by Ken Thompson's "Reflections on trusting trust". If somebody wants to break your high-level code he can always sneak the required breakage into the build toolchain and build process.
 
On most modern platforms, including Intel's x86_64 parts,  accesses to an array take measurably different time based on the the value of address mod cache_line_size-- because loads are always of a full cache line, but data at the beginning of the cache-line is available first.  There are actual demonstrations of using this sidechannel to recover keys.
I think a miscommunication occurred here. I was trying to say that one can use any abstraction, e.g.

a) ..... a1,a2,a3 .....
b) ..... a[1],a[2],a[3] .....
c) for (i = 1; i <= 3; ++i)
      ..... a[ i ], .....

so long as the compiled code has exactly same memory access patterns, regardless of the actual values stored in the a* variables. I am not claiming that the semantics cannot be changed by suitably abusing debugging or optimization flags in the compiler, dynamic linking or thread-local storage, or some other runtime mechanism like paging MMU, SMM, TSX, etc.

In the constant time parts of libsecp256k1 we use boolean operations to construct oblivious loads (which read all the data, and select the proper row with masking) whenever we need to access a table with a secret index for this reason.
Basically what I'm saying is this: assume i is in range from 0 to 1

Wrong:
x) r =a[ i ];
y) if (i) r = a[1]; else r = a[0];
z) if (i) r = a1; else r = a0;

Good:
a) r = i*a1 + (1-i)*a0;
b) r = i*a[1] + (1-i)*a[0];
c) for (j = 0; j <= 1; j++) r += (j == i)*a[j];

Again, I'm assuming no build-time shenanigans like compiling C code with C++ compiler with operator[] overloaded, etc.

Intrinsics do not allow you to control register allocation, and on many code the entire performance advantage of using the SIMD operations can be wiped out by unnecessary spills and loads. Compilers are getting better at it... but it's not necessarily a gain.  We've use assembly elsewhere in particular to get access to the carry chain flag, which is not otherwise easily exposed. It's not really a much of a maintenance burden since we use inline assembly that avoids having to deal with difference in the calling conventions between platforms.
Well, you definitely have a point here, especially about ADD/ADC and SUB/SBB, which I used in the past when re-implementing RSA. I also learned very early in school about keeping register pressure low and keeping vector units busy when porting Cray code to cheaper hardware and porting MATLAB prototypes into self-standing C. To me it is so natural that I keep forgetting that library like secp256k1 was not designed for easy SIMD-ification.

eg. hard for the compiler to vectorize:
      ECsign(signature *,message *,secret_key *,nonce *)
      each argument points to a single object of particular type

vs. easy for the compiler to vectorize:
     ECsign(int n,signature [],message [], secret_key [],nonce [])
     each argument points to a vector of n objects of the particular type.

I just looked in the github at the actual header file and have one more question to ask: why not using "restricted" C pointers? In my experience that was one of the simplest and cheapest gains to achieve by switching the C pointers to non-overlapping FORTRAN semantics. It was standardized so long ago that nowadays everyone supports it.
17  Bitcoin / Bitcoin Discussion / Re: Why ASIC BOOST is necessary. on: April 24, 2017, 04:28:20 PM
What I highlighted in your post from back then is a fundamental observation on your part I think.  But it would normally also lead to sufficient distributed antagonism so that no important changes can ever happen to the protocol.   The fact that there is now this immense pressure for segwit and LN means that this got centralized, no ? (in other words, that a non-immutable colluding consensus over change has been found, and obviously under the "leadership" of one or a few colluding entities pushing for it).
Not it "got centralized". It always "was centralized", "is centralized" and the "central controlling authorities" are resisting the pressure to decentralize.

Also, changes happened and will continue to happen to the protocol. Protocol is being kept intentionally vague, under-defined, long standing bugs aren't getting fixed. This is a normal, regular way to keep the current authorities in continuing control.

Perhaps you've earlier fallen for the past propaganda of "Bitcoin is set in stone" or "Bitcoin is defined by mathematics"?
18  Bitcoin / Bitcoin Discussion / Re: Why ASIC BOOST is necessary. on: April 24, 2017, 04:20:48 PM
I thought that was more or less established, so I took that for granted.  But as I said, my argument was not so much for asic boost by itself (I only looked at the theoretical calculation scheme without imagining that its hardware implementation would be seriously different from the standard way of doing so, as I said, i took that for granted), my argument was this:

"IF you consider asic boost such a phenomenal gain in efficiency that one could call it "an exploit" or "cheating" or whatever, THEN it is entirely wrong to stop miners from using it, because its mere existence lowers PoW security"

Note that the "if ... then ..." is also correct when applied to "if false, then false".

This thread was nothing else but a reaction to my argument being censored by people claiming that asic boost is an exploit and should not be used by miners, as it "lowered proof of work".  In as much as technically, asic boost is not doing anything, then it is not an exploit, and in as much as it does, then it should be used.  

As I said, I took for granted that the gain was of the order of 20%, because that's the amount of raw calculations that one has to do less. I didn't consider that there were technical problems in realizing this, but that doesn't alter the argument that or it is insignificant (and then there's no reason to accuse those trying to implement it to cheat or to exploit) OR it is significant (and then my argument is that it should be used by all means).
Now you know first hand how does it feel when you fall hook-line-sinker  for propaganda and become and "useful idiot". This is exactly what you did and yet you persist in spreading the propaganda.

The real way to recover out of it is to admit that you have been had and cease to participate in propaganda operations. Any further arguments that continue to "ASS U ME" (made an ASS of U and ME) will show that you seriously lack introspection.

Edit: start by changing the title of this thread to something less authoritative.
19  Bitcoin / Bitcoin Discussion / Re: Why ASIC BOOST is necessary. on: April 23, 2017, 09:14:29 PM
What gmaxwell did with his covert-asic-boost post and BIP was a test balloon smeared with shit. The test was "how many flies can we catch with it" and on this measure it was a great success. It is greatly valuable in discovering who will write about it without having a foggiest understanding of electronic device manufacturing and operation.

So your stance is that 20% more or less efficiency doesn't matter in the electronics industry.  I have my doubts about that.  As I told you already, I think you are confusing the standard deviation on an individual chip, and the fact that the average over a lot of them, shifts.

I would agree with you that if the technique, used to gain 20% more efficiency, would INCREASE the dropout rate by 20% or more, then, yes, this is not a good idea.  But if you get the same per-wafer dropout (even if it is 20%), and your *average* efficiency increases by 20%, that's something that, in most competitive markets, wouldn't be neglected, I'm sure.  If all else equal, there's no reason NOT to profit from 20% more efficiency.
Look, I'm not Shelby Moore. You've spent too much time trading simplistic arguments with him, I will not be easily bullshitted.

Firstly, don't repeat the propaganda number of "20+%" gain. This is a pure marketing bullshit. Tightly coupling 16 pipelines will greatly reduce the maximum possible clocking rate or lowest possible supply voltage. Additionally the yield of useable chips will be lower. From my general observation of modern semiconductor devices the optimum number of coupled pipelines would be 2,4 or 8, hard to tell. 16 would be past "diminishing returns" and into a "diminishing" territory. I've seen full simulation and analysis made for a different chip (not related to mining) and after doing some substitutions I arrive at the first guess of "-2%", i.e. small loss from synchronous 16-way hashing.

Secondly, by the very fact of using "standard deviation" in you argument you show the depth of your misunderstanding. It is hard for me to guess what you don't understand. My two best guesses are:

1) you may be thinking in terms of some unimodal distributions, where in reality they are always bimodal or multi-modal.

2) you continue to use simplistic textbook statistical models in your estimates. "In statistics, a trial is a single performance of well-defined experiment (Papoulis 1984, p. 25), such as the flipping of a coin,..." This maybe a good approximation of one hashing pipeline pass, where one trial block header is processed in microseconds at the cost of probably nano-dollars. Yet you seem to use it completely exchangeably with chip manufacturing workflow that takes months and costs kilo-dollars or mega-dollars.

Please upgrade your arguments to something more professional. Thanks in advance.

20  Bitcoin / Bitcoin Discussion / Re: Why ASIC BOOST is necessary. on: April 23, 2017, 08:45:05 PM
You do understand that the propaganda was coming from the side that claimed to be a victim, right ?
But I agree with you that such a scheme is hardly going to hold up in court, as I outlined: it is too close, in my opinion, to standard techniques of key schedule re-usage.
Your mistake here is repeating the thinking about "side"s or even "two sides" or adversaries like in a civil lawsuits.

I'm going to quote recent thread by chopstick quoting me from 2012:
However development priorities are not very unified, as noted by one observer:

https://bitcointalk.org/index.php?topic=122013.msg1390298#msg1390298

    When I joined this forum I was completely wrong calling the Bitcoin core development team "Bitcoin bunker". Now that I understand the situation better I know that there's no single bunker. There are numerous one-or-two-person cubbyholes that may occasionally form the aliances to shoot at the occupant of another cubbyhole. The situation conforms better to the distributed paradigm inherent in the design of Bitcoin.
I shouldn't have used the word "propaganda", I should've used "marketing" before value. It would not imply less of "taking sides", and more of general "selling".
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 104 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!