However, memory mapped files share a lot of the same advantages you list:

1) independence of logical data from physical storage - yes
2) sharing of the dataset between tasks and machines - yes (you do need both endian forms)
3) rapid integrity verification - yes, even faster as once verified, no need to verify again
4) optimization of storage method to match the access patterns - yes that is exactly what has been done
5) maintenance of transactional integrity with related datasets and processes - yes
6) fractional/incremental backup/restore while accessing software is online  - yes

7) support for ad-hoc queries without the need to write software - no
ease of integration with new or unrelated software packages - no
9) compliance with accounting and auditing standards - not sure
10) easier gathering of statistics about access patterns - not without custom code

So it depends on if 7 to 10 trump the benefits and if the resources are available to get it working

James

It is difficult to get a man to understand something, when his salary depends upon his not understanding it!

Novak chose an LPC11u23 ARM, which is USB-capable and has a variety of ports and ADCs. It's in the same family as the ARM on the Avalon Nano and Ava6 control board (which I believe is LPC11u14? Going from memory on all these part numbers). I've worked with 8051 programmed from Windows, but not ARM programmed from Linux. He had a Linux toolchain set up, and before he left I believe he shifted it over to one of the general shop machines rather than his own box. I figure on utilizing the USB bootloader supported by the chip, so I can write code to it without requiring extra hardware - that also makes firmware updates in the future more possible.

So, I reckon if someone is pretty good with ARM, and maybe also c for some cgminer drivers, and has time to work on it in the next couple weeks, let me know.

why use a DB for an invariant dataset?

Well I haven't made any design or toolchain choices. All that was Novak's job, so I'm trusting his decisions and picking up where he left off. I do actually have degrees in embedded and programming so I'm capable, just out of practice. And either way, it's not happening for a BM1384 pod.

(and probably also code work, since the guy who's supposed to be helping hasn't gotten back to me in 3 weeks)

I handed it to Novak for firmware but he never got around to it and then he left for a freakin' sweet rocket scientist job

The hell has this thread become!

No, actually that's mostly explained by a combination of small-town upbringing (focus on Christian ethics, frugality and self-reliance) and 98th-percentile intelligence, which results in a low tolerance for idiots or lazy people and a general inability to relate to most folks even within my own generation. The facts that coffee tastes like burnt dirt and caffeine has no real effect on me anyway are mostly irrelevant to my attitude in general.

You're mixing up things. Probably because you don't really understand what the UTXO database actually does inside the bitcoin software.

Spreed of accessing the records is important for obvious reasons.
The traditional reason is that you want to verify new transactions/blocks quickly and efficiently.
And the new reasons, like hardware wallets or any kind of stealth payments.

The current approach from the satoshi's client, where the wallet is glued to the node and keeps track of its addresses, updating their balance as new blocks appear - IMHO this solution has proven to be unreliable. Plus is totally unfeasible for private offline wallets.

An efficient UTXO database that can quickly browse through all the records is definitely a must for the next generation of bitcoin node software.
I am just not aware of any existing engines that would be ready to replace the currently used leveldb.
I think one eventually needs to be (and will be) created explicitly for Bitcoin. Just like sipa's secp256k1 lib was created explicitly for Bitcoin, as the originally used openssl's implementation wasn't good enough to handle a crucial part of the software.

A Miner Problem

Posted on March 2, 2016  by  Mircea Popescu   
  
As announced in #bitcoin-assets, BitBet was attacked earlier today through a transaction withholding mechanism. The attack unfolded as follows :

1. A BitBet bet (Jeb Bush will be Republicans' 2016 Presidential Nominee) was closed and resolved on 21 February. This created a list of winners with a reasonable expectation to be paid their winnings.

2. A first transaction was broadcast, to satisfy the claims of the winners, spending some inputs, and offering a fee of 0. This transaction was, as you'd expect, neither mined nor included in the mempools of most Bitcoin nodes.

3. A second transaction was broadcast, spending the same inputs as A1, including a fee of 0.0001, call it A2. For a ~1.5kb transaction, this fee is on the low side, so it perhaps could be argued that it not being mined would be expected. Nevertheless, transaction A2 was also not included in the mempools of most Bitcoin nodes.

4. As neither transaction A1 or A2 were mined after 54 (48) hours, a further transaction was broadcast, spending the same inputs as A1 and A2, and including a fee of 0.000175, call it A3. By any measure, a fee in excess of 10 satoshi per byte should be sufficient to have transactions mined. Nevertheless, contrary to expectation, transaction A3 was not included in either a block or the mempools of most Bitcoin nodes.

5. After a further 48 hours, a fourth transaction was broadcast, spending the same inputs as A1, A2 and A3, and including a fee of 0.00022, call it A4. Just like the previous three, transaction A4 was not either included in a block or advertised by most Bitcoin nodes.

6. After a further 16 hours, transaction B was broadcast, that included the same outputs as transactions A1-A4, but different inputs. Transaction B, like transaction A4, included a fee of 0.00022. Transaction B was advertised by most Bitcoin nodes immediately thereafter, and was included in a block within half hour of being broadcast.

7. Two hours after B was included in a block, transaction A1 was re-broadcast by an unknown third party. Twenty minutes later, the 0 fee, week old, not-advertised-by-anyone-ever transaction was included in a block.

On the basis of these events, the following allegations can readily be supported :

• That the notion of "a majority of Bitcoin nodes" is void of content, most of the relay network being under the control of the same entity and supporting functionality not contemplated by the Bitcoin protocol (such as selective mothballing of specific transactions).(1) This specifically means that "someone"(2) has the ability to nuke transactions out of the network irrespective of whether they are validly signed or not, directly replicating functionality already available to fiat governments in fiat payment processors such as Visa or Paypal.

• That a cartel of Bitcoin miners is deliberately and systematically withholding blocks for an interval of about 20 minutes to a half hour, so as to ensure themselves a (significant) advantage over any would-be competitors.(3)

• That neither above item makes sense or could long survive without the other, meaning that necessarily the culprit is one and the same. Note for the record that an entity controlling 51% of the network (as is by a large margin the case with the Antpool/F2pool cartel) can safely withhold blocks for an indefinite period – if a competitor publishes a longer chain all the cartel has to do is keep mining on its own, eventually they'll prevail.(4)

Note that there are no alternative theories that more parsimoniously explain the chain of observed phenomena, and consequently the validity of the above allegations is a matter of objective truth. One may disagree on the strength of subjective feeling, or put forth his own interpretations, but these – much as in the case of alternative explanations for biological evolution – suffer from a fundamental logical weakness.

Update March 2, 2016 18:49 UTC:  In a further development on this story, Bitbet has now announced a moratorium on payments until the issue is resolved. (N. ed.)

1. You should remember that the Bitcoin relay network has for many years been in very poor shape – there were as little as 60 nodes active last year around this time. Since then the situation has only deteriorated – the jury is still out as to whether BlueMatt's doohicky actually helped or hindered while it was functional, but there's no argument that the network degraded YoY.

2. Who, according to your own preference, may be the NSA or the Antpool/F2pool cartel.

3. The A1 transaction wasn't broadcast and then included in a block – at the time it was broadcast, the block containing it had already been mined – it simply hadn't yet been shared with the rest of the plebs is all.

4. 51% means that out of a day's 144 blocks, one has 74, and consequently gains a 3 block advantage over a competitor chain every single day..It is true that the cartel does not generally wish to advertise its presence (yet), and so to date they've avoided major reorgs. Bear in mind however that it is also the case that the remainder minority is not united but fragmented – so they don't actually need to resort to major reorgs.

I think it's very important to be able to browse through all the records in a shortest possible time.

This paper is a load of garbage. SHA256 is not an algorithm that tolerates 'approximation' which, if the writers had bother to do their research, they would have realised very quickly. Every bit at every stage is cucial, you can't just leave ones out that you think don't matter.

What they may have been meaning is that by using different types of adder in the A and E calculations the die size could be made smaller, but at lot of folks got this message a long time ago.

Sergio Demian-Lerner has discussed this in February of 2015 on his blog:

https://bitslog.wordpress.com/2015/02/17/faster-sha-256-asics-using-carry-reduced-adders/

Basically it is an interesting idea, but neither Sergio nor those 3 guys discussed how it could be affected by the overall pipeline design. It seems like those guys from UIUC considered only one (or maybe two) pipeline layouts (the alternate drawn in dashed lines).

Much better science would be to consider way more pipeline layouts including something extreme like 32-way pipelined ripple-carry-adder that adds two 32-bit integers in 32 clocks. It seems slow, but the area is unbeatable. At least those guys explicitly discussed area*delay products. But it doesn't seem like they carried this to the ultimate conclusion of power/hash rate and area/hash rate (or better yet price/hash rate).

But it is the only paper that I've seen that was actually brave enough to include the plain ripple-carry-adder (RCA) in the final comparison tables and graphs.

You left out the turntables.

Some of those bad boys can cost over 100k$. Love the ones with 4 tonearms. Prolly each for playing the owners specific type of record or music I guess. Toss in 4 of those 20k$ pickups ya linked to, woof...

Must be nice to find and supply a market like that....

As always, when there's a market, there's opportunity, and there's little to no presence on the low-volume, low-tech requirement part of the market.

As i've stated before on other threads, if there was a custom asic from the community, it could be done with either TSSOP or QFP, which would really be a hobbyist's boon. That, and the fact that everyone says it is expensive, but no-one has real numbers (apart from NotFuzzyWarm).

I just registered on OnSemi and they seem rather open about their process and even have FPGA to ASIC tutorials and such... It has been like, what, 10 years since the last time i touched an FPGA, and still seems like Spartan 3 is the hottest thing in the block. It shouldn't be THAT difficult to get a real quote based on a bitstream.... just sayin'

For the same reason Russians were sending troops across border when the ink on that agreement has not dried up yet.

The agreement was basically to regroup and resupply.  Rinse and repeat.

Do you seriously think Russians could not get this done?  I mean overpower Ukrainian army and get what they want, annex Russian speaking eastern parts of Ukraine.  I think they for some strange reason don't want to do it.  Maybe it was "under the table" deal with the Americans.  You know, we'll let you do whatever you want in Syria, but stop the aggression in Ukraine.

Who knows?  But either side could have resolved this conflict militarily by now.  Not sure why this conflict is being dragged for so long.
Maybe because it is making money for some people.

I don't think Russians will ever give up their claims to the Eastern Ukraine.  It is a good political posturing for Putin, you know "There are Russians in Ukraine that we need to help ...blah, blah...".  I think in the end Russia will control all of Syria and Iraq.  

Then they will turn their attention to Eastern Europe: Ukraine, Moldova, Baltic states.

IMHO, Washington dropped the ball on both Ukraine and Syria.  But Obama is not Putin.  He is a pencil neck comparing to Putin.

'Prolly should say that my extreme conservative approach to pcb layout comes from first making boards using tape on Mylar then cut Rubylith  back in the 60's through pretty much the late 80's, virtually all analog from damn near DC through RF. You learn fast to be up on best-practices eg. Be Damn Careful and never assume - verify it.

When them durn newfangled PC's showed up and eventually combined with photoset machines for making the layout masks it made correcting problems/errors a lot less painful... Nowadays, just get a 4-board proto run from PcbExpress or whoever and not bad at all to make changes. But Lessons learned stick.

My favorite and now deceased columnist who perfectly mirrors my views on the electronics design process http://electronicdesign.com/author/bob-pease
Pay special attention on using sims like Spice. eg, how-to and how not-to.

His works should be mandatory coverage in any EE program.

He is also the inventor and namesake of Chua's circuit one of the first and most widely known circuits to exhibit chaotic behavior, and was the first to conceive the theories behind, and postulate the existence of, the memristor. Twenty-seven years after he predicted its existence, a working solid-state memristor was created by a team led by R. Stanley Williams at Hewlett Packard.

remember internet posting always has a bit of:      


fuck you, you are a moron  


 as it is   built into the typing aspect and the delay of talking.


I am looking at the posts and reading from a different viewpoint then you or sidehack or anyone else posting here.



I find when one wants to really post precisely perfectly what they mean  the posts get too   long   like sloopy's posts tend to do.

 (@ sloopy not an insult I admire you for efforting to write correctly)  

Then they get skipped over or skimmed.   Like this post will be     and some may just see :   fuck you, you are a moron


So many posts seem short and nastly even when they are not meant to be that.


  Note this is a sincere post attempting to  calm the waters on the thread.  No tricky techniques here.