Interesting... space limitations have been against me for over a week now; even in low level assembly hunting a ghost bug down that would perform minor 'bit flips' on me due to what ended up being caused by a tiny fault in the circuit board lines baked from the factory. Well, a hairline lane circuit split can cause micro/nano bugs in the most bizarre ways.
This little fault was handing the arm processor mis-information. When dealing with negative floating point numbers in currency or mathematics in general it could be devastating and near impossible to hunt down if put into a production cycle without notice. In this case both floating numbers and an attempt to apply kernel protection on the faulty stacks - making for an interesting short project to say the least.
So, getting into this - mixing witchcraft, black magic, assembly juggle-sanity in general into an issue with the board operating the brain of the wallet having a fault wet design in circuit layout from the factory. You see,
Nano circuit reversing comes with a dash of "hexorcism" and many hours into deep analysis of what ended up being hairline fractures the line lays or wash cycle leftovers in nano-pi boards can cause bits to flip for no reason other than entropic digital evilness.
This issue, noticed when attempting to apply custom kernel stack protection to the my design of bitsafe wallet's nano-pi, has given me a moment to step away and discover that development of electronic currency is a very serious matter that could possibly have profound negative global impacts.
Before we begin, allow me to touch on a few things at play here in this document.
1: We witness first hand the negative impact and ponder on the possibilities that faulted or mis-printed nano-boards could play based on results the issues you will see render while attempting to apply kernel protections and ensuring application or trusted memory / kernel space when the fault is directly effecting the method of how numerical values are ordered. (and play with some algorithms to debug the faults)
2: Due to work involved in the processes of endless reversing hours caused by the above; or maybe accidental discovery (or enlightenment, maybe) for the first time ever I stood back and the fact is thought impact. Out of this rendered the most important lesson:
That the development of cryptographic currency is much more than a hobby, math, and some logic and code and in fact provides any individual the ability to s hake the foundations of economic, politics and a proven mathematical theory.
In fact the moment you execute your idea you instantly become part of economical and political system that can have profound positive or negative impacts globally.
3: A developers own individual thoughts, traits, bias and belief's play heavily yet ever so silently into each creation of the author. In this case, a realization of that a "hobby" in currency development is no hobby at by any means - but in fact has the ability to shake the foundation of proven mathematical theory, political science, community morale and economics on a global scale
I've made some private vaulted cliff notes on different ways #2 could be used in a targeted negative attack and the impact / result-aftermath that currency slipstream attacks can apply are intensely scary; yet surprisingly easy to execute by any single individual. I believe it's most fearing due to the simple fact that individual bartering systems have always and will always exist and they cannot be centrally governed by any authority but may be weaponized by any individual and used as a devastating act of economical warfare when applied with ill-intent.
With the above noted, let's get a bit more panoramic view of the whole system:
You may notice my style of writing is one in which technical-topic jumps a bit, that I will jump around but never leave the space of topic. This delivery method may be odd but this method serves strict purpose to the reader as means of proper delivery and cut-notes.
A document leading into the thought processes and change of currency development must be crafted correctly; and this is no such document; the hopping topics in the manner you will see may is due to the full notes are cut out - but to the point.
If you happen to be in the space of currency development, specifically nano-technology applying or micro tech even being a general hacker or penetration testing and and are having ghost-bug issues in micro-processing please reach out to me. The kernel protection modules that may dabble in the cryptographic currency realm I speak about below are by no means the only players in the oddity-hauntings of the stack in micro processing world. I have lots of research on the topic as sadly it's been forced upon me look into deeply.
Okay, laying some groundwork. First - the design of laying and washing and baking nano circuit boards can render the most bizarre mathematical and logical errors in the most annoying, entropic ways when rushed but are rather interesting to witness. I have found them to exist in the past due to rushed or factory quality assurance "hung over" time happens and products make it to markets with the plotter, stamp or wash misprints. They are tricky as well because not all circuit faults are appear "from birth" but can be enabled over time by micro-functional programming errors.
I refer to my personal experience here as the document is a snapshot of a tiny journey-to-crisis of cryptographic currency development as well as my view on other deciding factors that come to play when designing such an element.
The stance I'm left with from the research leaves me to to blame the oddity error or gap ghost that you will see below directly on a board misprint that has caused havok at bitsafe labs.
This blame being directly pointed on a faulted nano circuit hairline misprint from the factory could have caused, in theory, a race condition causing almost impossible to detect post-application chaos when dealing in mathematic logic - say, in this case, bitcoin or ethereum transactions. One can render any floating point or integer untrusted which is very serious when dealing with numeral values, like -.0089273 for example.
A micro-board ( nano-pi 1.3 ) was handed to me for free the other day. Success. Thanks!
Oh yes! - I was so excited; I'm running to the lab - grinning ear to ear - rushing with joy in hopes to roll out my blueprints and start working the mind into my cryptographic currency wallet and it's ecosystem.
Truth: only to fall into the most dark, and odd side of technological crisis; cycles of cascading post-boot segfaultsand number stability issues in assembly with no core dumps to even look for analysis due to limitations of stash areas to hold logs.
This misprint was turning a simple raspi-to-cypto transaction project into a hunt for assembly ghosts that would pull tricks like on me like change asm calls JE to JZ to and causing logical shift problems based on (unknown at the time it's fault being bad bake-in of the board lines) times it chose (unknown time functions) and drove me to pretty much re-create/solve the A-20 gate saga in x86 to ARM assembly in year 2017 (hah, Arm20 Gate Saga) . It was rather annoying but very interesting. The basic carry would compute, but numerally be ill and feeding a processor faulty functional data that it believes is sane and trusted could lead to massive miscalculations. This is not acceptable when dealing with currency and floating numbers.
Basic calls. Blown away and ignored or flipped.
A simple nono-pie had me twisted and I found myself trying to find empty address spaces without heap spraying to hard (will seg) due to the design of sigseg_when_fail being force enabled by my kernel protection application attempts by the errors in the lines - note: This happening while attempting to port a personally well respected and super brilliant spenderskernel protections from grsecurity's GRSEC and PAX into the wallet in a using the A6Core.
So, writing it off as a XED ghost I or maybe just a bad flash at time I did figure a way to finally get dumps in memory addresses that were readable in user space by just spraying faults across every and any open slot on the stack using the manhattan-algorithm as a factor of guess for allocation space (and luck) all while and taking heap snopshots as fast as possible then diffing them for the ghost.
The results of my findings have morphed my simple project of designing a wallet for bitcoin transaction in physical portable handheld form all-inclusive form into a fun & scary process and finally learning an important lesson:
First: Do not treat cryptographic economic design as your side project or a hobby as it's no toy and could have a global impact in financial, political and economical ways. Two totally different item play togehter here - the insanity brought upon me by hunting bugs in nano-tech to compile a secure kernel for a simple "physcial electronic currency" wallet and the lessons I learned about the world and responsibility of cryptographic economic design collide together and have impacts of such a design globally.
But with that noted Let's get to work on fracture lines shall we?
So... this issue had me hacking on wet work, general nano board tomfoolery and watching it with all of my years in the AI field, never see anything "play back with me", the way this little board was. Almost had me convinced that it was on purpose. Looney.
The mathematical entropic-timely jokes the board was playing would turn on and off it's ability to understand or willingness read arrays as zero indexed. Yes. You read that correctly. Starting at point 0 and sometimes -1 when nibble were called.
It took a while [15~ hours] for me to gain access to a lab which contains a ~2500x digital binocular microscope finally to view the hairline fracture in the circuit lay. Short of that, alerts would have been in transactional form in production of currency and root cause detection would have take a DBM or lite nano scope to see. That's fun. Nano rootkits, anyone?
But after washing and baking a new top pocket for the board and clearing the RV, it's towers and lines and inspecting the NOKIA-made LCD they were cleared from being evil from what I thought was Skynet in my lab.
My research ended with confirmation from of microscope on a nano-pi board and a pile of GDB traces-to-traps over and over in an attempt to find the reason of horseplay.
Bouncing back again and again util finally finding the line misprint was work. Once identified using a scalpel under the DBM was enough to etch off the error. So very odd.
So yes. I do get to, in the end - after fixing the wet issues, against all odds build the ecosystem into thebitsafe wallet! Minus a ledger for smart contracts.
We will get to that part, but excited as I am about this I feel it's my duty to warn other hackers out there about some things to watch for when oddity plays into design. So let's jump to important facts and general thought system belief systems first.
Please remember this: when designing a secure ecosystem for cryptographic currency a few things besides code, coin and mathematics are at play.
The moment you enter this door you instantly find yourself right in the middle long standing, ongoing political battle ran by two parties and must choose - central or decent - ledger technology belief roles.
Now you are faced with this choice. Should a blockchain technology be owned by a single entity trust or do you believe it should be peer to peer with no single entity able to control it?
Also, determine and prepare for global economical impacts of your design structure . before your venture inward. You must ponder deeply before embarking on the journey because your actions now could essentially build an economically-ill design that would effect other currencies like bitcoin and the the blockchain or ether on ethereum out and cause net worth or core prices to change due to holders of the currency having choice now to leave a ledger system for another. This can have a profound impact destroying both equity and worth equally on both sides.
There is a finite* amount of bitcoin. I have learned that when ever there is a finite amount of any item it's value will always be positive. It's lifespan may vary in worth greatly even crashing but - even if that value is negative (hurricane theory) it has value due to its limited amount. Due to the finite amount of possible bitcoin in circulation at a that exists based on block solves, some people believe that we will have a moment of singularity in mining bitcoin where it breaks very quickly causing the reverse-halving to happen. If we apply the mathematics behind the amazing, most talented minds on the planet in the fields of futurism and trans-humanism (the work of Dr. Ben Geortzel and Dr. Ray KurzweiI, for example) and artificial general intelligence then we will as humanity be at the point of computational singularity before some believe all bitcoin will be at its finite point of max output block solving.
This is interesting because when we do reach the moment a machine is as intelligent as one human mind it's applicable to all minds. Having roots in AI played on my design process as well - because in theory you could be creating a cryptographic currency economic layout for a digital entity.
Yes, I do know this sounds like sci-fi neurolinguistic techno-babel but the fact is all intelligent forms require a means of barter or trade in some way for to fill the gap object-obtainment. This applies both digital and physcial. According to Ray Kurzweil and his unlimited funding provided to him and team as the head of Research and Development at Google, he predicts 2025 will be the start of the singularity. His book displays in depth based on mathematically mapping out intelligent system design growth rates over the years and the exponential growth doubles each cycle. Point being: As crazy as it sounds, you may even unknowingly designing a trade for a digital organism. That's cool.
So, with the above in mind I quickly learned that although anyone can now create their own digital currency based on smart contracts with it and economic design comes more than code, coin and doodles I was faced with a dilemma.
As what I'm working on is not a toy project nor should it be treated as such and witnessing something as small as a hairline error cut nano board cause mathematical changes that could have had profound impact depending where applied I choose the GNU/Richard Stallman rule sets during design. So, designing a freedom-positive system with GNU mindset causes a fault in thought mentality because of my quest to apply precision and applying secure designs....
With my political system being decentralized currency, no one entity (blockchain example) should run the core and the ecosystem and architecture behind the bitsafe.systems ledger, chain or core - this became a topic of war as it's very dangerous to some and positive to others depending on which side you may lean to due to the ability to essentially render an entire crypto economy trust structure/ledger/chain/value worthless by proving an alternative ledger that accepts all contracts - hybrid and agnostic ecosystems could damage, preserve or skyrocket billions of dollars to no value even by accident.
Let's discuss the wallet fault issue area a bit and see where we stand on our thought system again afterwords.
Let's put it this way: My ARM hurts. I've been scratching at it.
So let's get into the kernel protection side of development here and toss in a custom kernel compile into the nano-board, in which I decided to use old trusty (and most respected by myself) spenders GrSEC+PAX ARM modifications on the board.
Welcome to segfault city. My name is sigseg-v, Im here he help you. May I please have your instruction set? (so that I flip it on you and cause havoc)
Is pretty much what this little board performing on me.
I starting thinking. Due to a (faulty?) (cronjob-errors?) (my mathematics off?) (random segfaults) - Well, 18 hours in GDB and having mini-awesome break throughs like determining that "mimmic x86" or in reality a faulty com. channel actually means that 4 bytes == 1bit in truth at any time faulty wet work can state that a bit must == four bytes to become a nibble that one can access using al-ah in assembly. This was twisting me. It's logic was so indecisive and random.
It was interesting to watch how a machine so tiny would react to the intelligence of a beautifully crafted kernel and stack protection system like spenders GrSEC and poor PAX -- Imagine a machine that would flip its array reading from zero based index to a one base randomly. PAX, by design will determine the user has left his protected space (raw board in this case) and has entered a protected ring because what should be, and was just a few moment ago " 0 1 2 3 = userspace_normalized " but fault from factory would cause an array to be read reversed (and reverse address space layout randomization detection is part of the kernel module's protection function) causing faults on perfect 0 index switches to count to 4 would (0 1 2 3) to panic!
This board likes to flip it up a little bit hit back with reversed arrays for no reason things making things like this:
I request an asm call for al[0] lowest bit please, accumulator low, 0 (a request for 1)
It's logical computation randomly would eq [ 3 2 1 / -0 ] or 1 2 3 / 4 ]
where / eq grand mal freeze up of entire board / os
Well I may positively state at this moment that the art of kernel protection on nano boards will provide an interesting 24+ hours for you. Battling bits to bytes to nibble bit flipping jump issues at random on upon requests in assembly that require reads of negative digits for results to continue its function.
Simple example: Let's take a function in assembly that reads negative numbers and makes calls to other functions based on the results. For this, lets use a function from the zero family like.. LT (less than) which when called to be executed registers N is set and V gets cleared, or N is cleared and V is set. Depends.
LT 0x7FFF5FBF6158 simple jump if less than or equal to the value of the contents of computation performed by function 0x7FFF5FBF6158 and act upon the result is a simple concept. (L * execute [func] an area in memory if the result of a computation previously performed is [L]ess than computation call)
It's basic arm assembly. Simple. Unless the board bitflips.
Well the battle I fought was due to the processor getting back faulty data from it's registers - cause entropic segmentation faults because the factory was off when a bit when designing the board. ZERO would = 0 if the board was acting correct and utilizing its standard zero based index array reading [0,1,2,3] but this fault was causing the an issue which flipped arrays *sometimes* where 0 would be -1 or 1 2 3 4.
Exploitation detection systems, like the one bitsafe uses would fire and catch a sigsegv the moment a canary would break and this became a huge problem in getting a stable kernel up for BitSafe GNU Linux on the nano-board that was faulty.
This played heavily on to build the worlds first physical hand held cryptographic wallet operating completely independent in between it's users agnostic to coin type.
OKAY. Solid. Here we are - post fracture fix. Build time.
It ends up with segfaults in the nano wet work, a lot of dirty playoutside of userspace and putting some hardware to the test to say the least.
Now im seeking out a ledger; solid blockchain technology to adopt and build into it's model. Ethereum's blockchain tech fills the void partially by agnostic smart contracts.. But I needed something more. I think I've found it. We will get to that, but first; this is my journey into that area. The hunt for the ledger / chain tech.
The BitSafe wallet now uses it's own wireless communication protocol and operates on it's on nano-wimax type technology and frequency to talk between one another. The last stage is adoption of a ledger tech.
I vow to 4 rules during this project:
0: GNU laws apply at all times unless it violates a security policy inside or outside of userspace, not applicable to design shell or circuit CAD.
1: Security policy must stay in place even if it means violation of first rule or removal of entire functionality weather it be wet or hard.
2: Users freedom of and control of ability of the cryptocurrency and device as a whole must maintain the highest open-and-free levels at all times unless of course ever touching the security stack
3: When initially planning the wallet design, I did not aim it for the average consumer at all. This was for hackers and crypto-geeks. In the end, it's the everyman crypto wallet.
We all know that items exist already in this market. Keepkey is sleek.
Trezor's, for example are awesome! They both provide the user quality protection of their crypto coin; but deemed fundamentally insecure and violate my model of security in the taint area; due to the devices they must run on.
A Trezor would be a perfect device for the average consumer if the item did not have to use a complex, malware infested desktop or laptop computer for means of broadcasting it's transactions.
I, although design my own so you would expect a natural bias; in all honesty actually have a great amount of respect for slush and team at satoshilabs - especially now after I've been exposed to a bit of the process they have mastered long ago.
There are fundamental and somewhat critical issues with cryptographic wallets available for purchase on the markets today, but this is not a paper about zeroday bugs in wallets so we will stick with a single issue: is that they all use a standard protocol for communication, unless acting 100% as a cold wallet and use the currency's blockchains or ledger for transactions pushing. I don't believe in forcing a user to a specific method or technology as I stand by the rules of GNU. A choice should be given. Control should be granted.
This is where my design changes the game. When using a bitsafe wallet, users make transactions to one another in one of two ways; line of sight with its own wimaxfrequency or by organic ethernet - but never touch the public ledgers as they are just that - public. Anyone may watch your spending habits and target you that way. This violates our security model in the privacy area.
A radical idea was built into the blueprints of the Bitsafe Wallet to protect the identity of the contracts and execute orders placed by it's users. This way anyone can use any type of crypto coin to pay for any service and the only time it ever touches the original ledger is to leave abandon it and join the bitsafe anonymous ecosystem.
The bitsafe ledger has no set system and is the reason I'm looking to adopt an existing chain technology called Krypton. It aligns to my needs and a vision of a muti-hybryid exchange system. Using multi-hybrid wallets will allow contract lanes for every type of currency and every type of broadcast and offer completely anonymous transaction system between users. You essentially disassociate your money from the ledger and join another organic ecosystem.
Giving true, full control of assets to the customer is a driving factor of development almost at the same level of security. BitSafe will not operate, own or have a central authority of any type over the ecosystem. The role we play post design is simple a means of transacting on a peer to peer, public clone but private send system.
Political argued into many wee-hours with peers, deemed technical possible and mathematically interesting this vision can be achieved by cloning the existing blocks of the currency or contract sent thus causing future executions or contracts of any type sticking between users involved in the push and the miners involved for fees only.
This holds up our model of giving true control to users and providing true privacy. The current debate is a tri-force: political belief in a central trust, a mathematical what if debate as in legend slipping or syncing incorrectly and: economical as prices will fluxuate dynamical once they leave their ecosystem and join a an architecture that supports multi-contracts.
I'm not doing this work for fun, or money. I have a vision and will see it through.
Now to the part that got me here. Let's talk about some fun semi-technical stuff.
I designed the wallet distro to be backed by its own custom tuned grsec+pax linux kernel which was not easy on nano boards for a few reasons but - as yes - although nano sports ARM, x86 fundmentally sits on the nanos and it's design concepts are in place and it's notable design to and ability to mimmic it closely is very well done you start to see problems when you get into things like nibble bit flipping jumps like jlz (jump if less than zero; JE, nautally will jump to the address space if the previous numerical compare operations renders a eqil bit either, nul -,-0 -nul or -nil ALL trusted to the natural way ARM handles values on zero based index arrays. [0,1,2,3] would equate to a single nibble but that's not the case in SOME operations on nano boards. Reason unknown; wont further dig into it personally but every once in a while the zero based index arrays are simply skipped and counters of registers start on 1 -1 pattern. Well, this causes issues ignored by all other items on the system except things designed to catch them. Like pax, which will trigger it's off by one exploit alert when it sees this type of activity during low level system calls or inter-process community between trust kernel module. Alerts in the pax protection of the kernel - default the nano it to lock up thus not saving it's core dump for me to reverse the root cause of the byte flip that ignores the zero based array.
It also plays a bit funny with higher level ah-^ codes for example that will at some points trigger extremely advanced and written to perfection kernel protections like spenders GrSEC mod; in which relies heavily on protecting specific things in exactX86 and is provided false positives constantly.
So, juggling assembly and opcodes changeups at random while array reading methodologies mid-call is no easy feat, but we must remember we are not operating on x86 here. I call arm ARMmimic x86.. Anyway the nano sports the arm6 L1 line of processors with something cache-clean.
Cache-clean was designed to reduce the requirement for invalidation on a context switch. The cache may be organized as a Harvard system with separate instruction and data caches, or as a single unified von Neumann cache.
Either way, cant disable it.. And GRSEC application to ARM is minimal, PAX has solid ports as does GRSEC but with out bug cache clean was wiping the scratchpad memory spaces out as well. It's what brought my attention to the assembly ghosts house.. Now the kernel protections available, or that I use for ARM are:
KERNEXEC, UDEREF USERCOPY, STACKLEAK, SANITIZE & REFCOUNT.
KERNEXEC worked the whole time.. Lines? path bypass? The fact that it's for Non-executable pages? maybe played a role.. who knows.. but STACKLEAK was having a fit.
Technically what was getting overwritten with nul was __all_pages, but specfically (and most annoying) was the TCM is a physically-addressed area of scratchpad memory
It's design is to sit right next to the L1 cache. So spaying the place up would segfault everythijng because a few modules of protection exist for ARM in the TCM.
These protections are the LPAE (large physical addy extention) and PXN (privledge never execute.) If he L1 cache gets pissy, it's a STACKLEAK problem and call for re-alignment. PAX uses LPAE to watch large physical address spaces and sends a sigsegv global when poisoned. With a fault board shifting arrays at random we would see PAX's LPAE first get called, then STACKLEAK, the LAPE alignment then a call for sigsegv (shutdown)
Arrrg..
So yeah, took a breath and made a choice of a debian base for the core operating system. The reason I chose debian is mostly due to my ancient roots in the core and understand it it's fundamentals, it's goals with GNU and am more comfortable in a debian system than anywhere else on this planet physically and digitally. Because of this relationship of the os, it's kernel and I it's the best choice to provide a wide audience to entrust billions of dollars on.
Second heavy factor is that debian works well with the family of boards. Specifically jessie-backports (or natualports, as each system will use wheezy-to-jessie) going forward. It's stability is proven and due to the fact that tuning grsec and pax on a nano chip is no easy feat and requires a rather large amount of unexpected assembly patches it's simple not possible to go adopt anything other than the elders. Packages are up to date and kernel is a 4+GrSEC+PAX all jammed nicely into a nano-pie on top of a NOKIA bleu lcd running jessie, debian GNU/Linux with stack protection on a =~4 kernel.
So, by pure chance and seconds timing I was handed a nano board from someones's pocket two days ago out of the blue during mid conversation. The guy pulls it out of his pocket, hands it to me and says too-da-loo. Non malicious intent as he is a trusted friend (I checked anyway, its all sketchy) - but not due to maltent. It's design is slightly ill-developed causing a mimmicx86 flaw that would trigger off-by-one false positives due to zero based index arrays not always being called in every call. But we will get to that in a minite; anyway.
Cool, I thought. Lets see what we can reverse and customize for the bitsafe ledger hurdle. Sooo, off to the the lab I went with nano in hand..
Once back at the lab, I tossed about 4 hours into the di-section and reverse engineering process of both wet and soft.. Right off the bat, I see bit flips.
ITS JUST A RVA BOARD WITH A NOKIA-MADE LCD ATTACHED TO A RAZ-NANO BRAIN. NOT VERY DIFFICULT. Right?
As hopes were low at the time due to the overhead of adding more physical parts to the unit has been halted across the lab. There are hanging whiteboards that literally say NO MORE HARD ADDITIONS DUDE. .. it's funny because im the only person at bitsafe yet still this is to demonstrate the point of getting to the finished state and into bake without a single new line draw.
I thought well let's try and reverse it it a bit more, maybe borrow some tech.. just get some ideas of the mapping in hopes to get some memory allocation somewhere to load a contract able ledger or blockchain of it's own inside the wallet itself and be agnostic to coin type too.
For whatever reason - at the time - not thinking it was circuit issue; either memory space limitations, or me trying to stick data into any available memory address possible thus causing stack data stashing or santa-issues or size limits (which is bad security practice anyway) to even power issues of having to build another bridge to the circuit allowing for a memory card was my last hope. Adding physical would have changed things greatly, because or sd-card - this needed to happen to deploy each individual wallet it's own containment, preferences, coin type, etc. But remember that whiteboard? I said... NO MORE HARD ADDITIONS!
So, although I don't recall writing it - and Im the only person who's ever been in this lab - it must be important.. so.. by whiteboards ideals I shall stick. I then sat down. Took a breath. And bang! Yes! if I just use the nano board as the back end gnu host for the lcd tech and the rvs+lcd as the front end tech visually then we could in theory have a full GNU system running with a micro-sd @100+ gigs of space on bitsafe wallet lickitty split.
To ensure it's security is divine it must be designed ground up by us and operate its own ledger. Were talking an entire soup to nuts from we board to rom boot-loader to the final satoshi spent control.
This was the #1 hold up. and I realized it fills a large problem blocking my vision of bitsafe - as my goal is to create a complete 100% compartmentalized self contained eco-system of cryptographic currency exchanging without having to rely on the on a outside at all (eco-breaking can mean standard wireless technology to unknown blockchain bugs) transaction ledgers like the blockchain; it plays a perfect role and has filled the gap.
AN IDEA OF THE SIZE OF THE NANO
COMPARED: APPLE TRACKPAD / MICRO USB CABLE
So onward we go! let's toss an electrical engineering hat for a moment on shall we?
To represent myself correctly: I am no such engineer in micro/nano tech by school. It was by force to learn electrical eng. and circuit design in two days. So, with that in mind - I'm a security exploit developer with deep roots in AI smart systems and hunt for hackers as a living. Remember, just dabbling with crypto-coin and can render unknown at the time issues.
To the board we go - Ok, so lets get this down right; goal was trying to solve the problem mathematically for a week non stop - never stopped to think physically adding a board to the stack - not into, ONTO.
ONTO did not break whiteboard rules. ONTO did not violate security model or posture. SIZE.... perfect, still fits in the cave.. DO IT.
And straight to issues we go..... I simply could not have the circuit CAD-compile possible way of combination of solder or binding in any way that made sense. My limitation in circuit space is as follows:
The circuit design dementions are:
MTW (min trace width): 1.9Mil
L2LS (line to line spacing): 2Mil
With a PCB Edge to Conductor limit of 2MIL!
The wallet, on a circuit level, needed to keep the controlled impedance tolerance around+- 8-10% or the batter life was like a few hours (2700mili and up sized batteries would be to big and up renders size-to shell issues) Vape batteries... maybe ..
Keep thinking. How do we bind a two indie boards together for co-existing data flow without size violation or breaking ohms law and blowing batteries... and how will this apply to outside userspace knowledge of the kernel running pax on the boards?
So, I had no space physically on my board. Mathematics were starting to get iffy on logicas I did have a way using the Manhattan Algorithm to store some data in memory addresses that were free during boot, it turned to poison.. This is because of spender/grsec's reverse address space layout entropy in real time (how they do this witchcraft, who knows..always impressed with spenders work). causing stack canaries to fail and segfaults to happen after minutes of solid uptime (unicron?)
An attempt to apply a 120/160 of Manhattan length - like sprayd half the board with pointers to next function - worked, but now keys were sitting userspace memory. So themanhattan coefficient needed to be around 4.2% of the routed length of 200^ keeping which kept me around the 0x80487414 - 0x100E23700 range every time. Hmm. entropic ASLR fail? Nope... a happy dance, vape and 10 minutes later (UNICRON?) ended up them out of userspace - segfaulted. dead in the water.. took longer though.
Below is a picture of the first boot of the kernel (basic, non-grsec/pax) form the nano to head with interprocess communication working perfectly.
So now back to manhattan algo-storage attempt; This was a valid option, but the wallet was seg faulting after 10 minutes of operation because half of the memory space of the manhattan coefficient (guessing on layout true design) would be wiped out by reverse address space layout random cronjobs or execution orders from PAX. Well, after hacking on that kernel for.. ever. i got it working. Stable. Like perfect.
There is a trick if any one ever reads this and happens to be a kernel hacker working on nano board technology in the crypto-coin area.... yeah, so
1: compile slowly. Even if it means drawing on with ptrace pulll when you dd write a pre-copiled version or attaching dtrace and using addlag..Slow the compile down and the stability will be fine (after 100+ mods to the kernel of course this gets realized).
Had the unit for 2 days, We are rocking we rolling lets get distro'd up.
Fate may play here, but 5 years ago an individual named Riccardo Belloli created...unknown to me up until a few days ago even existing a now abondonded project called.... "BitSafe Linux" (how dare he! :) which was a compact slip of debian gnu/linux designed to hold private keys and do basic transactions against early day bitcoind.
So I took that old git code, and built up a popping shiny GNU distro for the boards.
The GNU Linux BitSafe OS is an open-source Debian-based lightweight live distribution designed to provide an easy and secure complete environment to store and use your bitcoins from a USB drive, SD card or HDD.
Unlike other eedistros, BitSafe is thought to do nothing else other than keeping your bitcoins really safe. The crypted persistence partition used to store the wallet and the block chain is not mounted as home directory, it's only used by the Bitcoin client and other few applications related to backup and security (gpg and ssh). BitSafe takes care to dynamically mount and
Well.. were getting there..
1: unmount said persistence as needed, making everything else volatile: home, cache, temporary files, settings, browser... everything vanishes as you shutdown the host PC.
2: BitSafe comes with full networking support, wi-fi included, but you can also use it offline for even greater security. When you'll need your bitcoins, you just have to connect it to the net and let it catch up with the block chain.
3: It was under the GPL and offers 5 years old and not touched.
Had Immunity to software keyloggers. If you use the built-in soft keyboard to enter passwords, you are immune to hardware keyloggers, too
Multilanguage. The default build supports English, German, Italian, Spanish, French, Portoguese or Russian, but you can download the source and build your own localized version choosing any language supported by Debian Squeeze (BitSafe scripts are localized in english and italian only)
Debian based. You can add or remove your favorite software package with apt-get while BitSafe is running. If you wish, you can easly add them in the configuration file and build your custom BitSafe image.
Automatic crypted storage partition. Persistence for Bitcoin client and backup applications is provided by a 2GB secondary partition that is created and
mounted on-demand (asking for password) whenever you open bitcoin or any program that needs it, and gets unmounted when it's not needed anymore
TOR and Vidalia installed by default. You can lanch bitcoin with TOR networking Script to download and launch the Iceweasel browser with TORbutton and noscript extensions already loaded
... and a persistent screen locking password.
Perfect. It needs a remodel. But.. lets take it. https://github.com/rb1205/BitSafe is the original code and vm's)
Tearing down the os to the roots, compiling the pax/grsec/stackme bitsafe kernel into the build and in 15 hours birthed the complete containment, tuning it for the world of pi we now have a full system of individual, coin agnostic, contract-based ledger under one shell.
Oh boy. You fancy now. (just rvboard, not bitsafe)
A Peer to peer custom mini-wimax communication device that can make direct P2P transactions on a custom grsec+paxed up kernel sitting on a nice smooth debian gnu flashed to a pi-nano board that that uses in person secure entropic trusted handshakes based on xFlip patent. Yeah. Lets wrap this in a thing up.
xFlip solves man in the middle issues as wi-max requires of line of sight transactions due to it's technology being all contained, left one single issue will touch in a moment.
I then decided to make all bitsafe wallets allow two or more multi-sig anonymous handshakes if depending on availability of other units. It's multi-sig tech is are baked i code side now with in every transaction.
So, now we have a heavily hacked, stable, self contained OS, ground to wash to paste circuit design (minus the pie) to adopt the BitSafe Wallet.
... you have lite coin you want to trade for some ether instantly, or some bitcoin for some dodge on your own private blockch... wait.. the ledger.
I FORGOT ABOUT THE LEDGER. COMPLETELY. LOST THE MIND. SO..
This was the biggest set back. I NEED A CHAIN OF MY OWN. Years of development required for this.
Well, after hunting for days and building contract systems demos at the lab and failing all transactions if they ever even pushed I started the hunt for an adoption.
And boy did I find the perfect match. Stars aligned.
I would start looking into options but NO MATTER WHAT end up krypton. Not SEO end up, but for needs and purpose and vision. I have learned that the woman who created Krypton, covertress has a vision of her own smart contract technology she wishes to see executed as well.
http://krypton.rocks is the site; dev left in late '16 and https://github.com/covertress for the core as well. It's perfect.
Nice. and the only part holding bitsafe back from agnostic self containment being ledger based, it seems like the best thing to do is adopt krypton into a hybrid for the safe-core and port it into the wallet. Seeing now in theory every wallet can have 128GB of storage on micro-sd - and kryptons transaction footprint being so small it's almost aligned to the stars to fill the final gap.
I pinged her with an idea, we will see if the allowance of adopting her tech for ledger into the core is a positive gain on her end and hopefully have our iron-crypto bubble in your hands soon.
As the rest of my documentation on this topic touches deep technical aspects and has been deemed not of worth to post, I leave it here. If you are in this area of interest or do have assembly ghosts please reach out to me!