After having taken a deep breath of relief and step back from a few stressful weeks and to subdue my excitement of Hive.Loans on the near horizon for our community, it all finally "clicked" within my head a couple hours back in regards to me being able to justify to myself the whole push to to support only proposals that are doing the refund thing, and while I might be wrong but hopefully am not, it seems in doing so the developer gets his funding and then also still performs the HBD stabilizer function with the remainder..
In This Moment I Am Euphoric Retarded <---
(the worst part is BT offended me greatly inferring this, but was right at the time, couldn't see the forest for the trees, sorry)After that brief eureka moment and then feeling embarrassed I'd been unable to comprehend that before due to being blinded by taking an adversarial stance against the HBD experiment due to me not looking past it's name as it's intended function rather than the functions it was actually performing decently from there it was decided it would be worth a shot to implement the now network standard @good-karma (sorry for tag) DHF proposal refund formula into the Hive Smart Chain Proposal #164 with a bit of a twist, albeit not my most clever answer to a problem admittedly..
But one that serves dual purpose to allow for refunding as intended by the GK function to take place, but also to have the ability to be scaled back to provide any additional help, in the form of a couple guys that I've known for a while and know to be extremely talented GO programmers and blockhain engineers lined up a means of compensation for their time and efforts in helping me expedite and quickly bring to market this project faster than possible if it was just me slogging away at it.
That twist being that I wish to bring fourth the concept of variable refundability via provability of hours, meaning that on days I've got another developer (or if I'm super lucky, two, with them obviously getting paid / splitting that days funding between them assuming their hours support this, taking precedence over me being paid that day) helping me that refunding the DHF will be considered only after they are paid a fair wage, which I'll also log here, but not with their names but rather labeled as Dev #X as to not be posting people getting paid in case the tax man is present, for their time which will be agreed upon and shared with the community in order to help keep track of what funds are going to who when and for what work being done. Accountability to DHF and the HIVE community is something I beleive to be important in these community funded projects..
Detailed Records of how DHF Funded Days get Spent Should be Something We as a Community Should Normalize
All hours and work will be as stated above be verifiable not only to be transparent and be able to prove work is being done.. But also because I think if we're employing people at a network / community level they should be able to, at the absolute very least be able to produce proof for what they were doing or at the very least logs of where their daily hours while being paid by DHF were spent. The goal is to work 7 days a week, with a minimum 10 hours a day IDE or debugging time logged by myself with the exception of saturday where only 5 hours of development time need be logged to allow for some time to do something other than code to not deteriorate my mental health.
If it's just me working, as is standard with all my proposals, my work hours will be recorded and logged and I'll ask that anyone who is helping on any particular day do the same or at minimum hourly git pushes in order for not only my own hours but also any other developer working on the projects hours to be transparently placed where the community can verify not only that 2 (or more) devlopers were working on the project that day, but that refund amounts are being honestly calculated with this being provable.
While still entirely unsure if it will have much if any of an effect in increasing the proposals' chance of discovering the decent push of support required to surpass threshold due to a number of factors, the change in proposal come as an indicator, and is meant to show my understanding of why refunding the DHF is important, but also as a gauge on if some or all the top tier stake weight accounts are holding grudges against me or letting their own business interests take precedence over me being able to field a small team to get my Hive Smart Chain to the market in a timely manner. With 2 other developers already agreed to come on board at minimum a few hours to a few days a week to help expedite bringing not only decentralized HIVE based Smart Contract bytecode execution compatible with complete support for industry standard solidity smart contracts, but also relatively light weight side chain node software that will allow any user able to supply the hardware and minimum amount of bonded/staked HIVE into the HSC able to effectively become a block producing and validating witness on HSC, earning the lions share of the HIVE gas fees per block.
I've got the team and supports I need in place to get this thing rolling as early as Sunday or Monday, with my attention still primarily focused on the launch of Hive.Loans testing it's likely I'll have Lapingvino come in to clean up and audit my current HSC code until I can completely shift over to HSC, I've already had a running testnet on 3 different boxes in order to begin finding the quickest safe block time under load possible to proved feedback way quicker than ETH does, effectively smashing BnB in that regard already and the project state currently sits at a nearly functional proof of concept already built myself, with account creation via sending of HIVE to the HSC custodial account acting as a trigger for creation of new HSC addresses, and with Hive.Loans being pushed into public beta testing some time next week this should be sufficient in allowing for majority focus to fall onto getting HSC into private testing phase and then subsequently launching the public beta which will serve as a soft roll out.
About the only thing I lack at the moment to bring this all together and get not only myself but the 2 friends (more than likely either, or working with me, but possibly both on some days if I get lucky with their scheduling) to give me a hand on expediting this release is funding to cover a few months of R&D.. Effectively some funding to be able to compensate the guys via being able to pay them for their hourly work as a thank you for offering to help me rather than expecting anyone to work pro bono.. while also being used to cover costs for my development hours, infrastructure and living expenses within the development window.
Building a Blockchain that Runs Using Input From HIVE?
Bring in a Seasoned Veteran to Help Code and Consult!
It's more than feasible that with the help of a few of guys who not only have a long while, but that hold some serious creds and experience than I do in building blockchains, with my one Canadian developer friend out on the east coast, who goes by the handle xplioted within the greater community, who upon me mentioning that I was building a side chain for HIVE generously offered his time and knowledge to help me part time or when I got stuck on something.
He happens to be the developer behind a couple will known crypto currencies. With the most notable including DigiByte and CLAM actually happens with 2 or 3 months we'll join the ranks of networks able to hop aboard the DeFi hype train, With the absolutely overpriced and centralized dumpster fire that is Binance Chain being the target to steal it's user base from by educating them that a faster, cheaper and actually decentralized alternative to risking their money on a known to be centrally controlled Binance Chain seems like a ridiculous choice when educated on the smart contract capability recently coming to fruition on the HIVE network.
I'm extremely fortunate to have developer support from guys as talented as xplioted as well as lapingvino on my dev team and offering to help. My other partner on this project who expressed wishing to come in part time to help me optimize the GO code the HSC is being written in is Lapingvino, who was ultimately one of the main people other than xplioted who pushed me away from having a go at the HSC in Javascript in favour of GOlang.. For complex projects like this that are better suited for strictly typed efficiently compiled cross platform capable executable type languages.
Had used GO in a number of other smaller projects in the past and enjoy it more than other strictly typed languages like solidity. While classically JavaScript is my "go to language" for things due to the incredible speed bonus I generally can knock out prototypes using it, however given it's the absolutely worst and atrocious number handling language I know of and the fact the HSC as a whole would suffer if I wrote it in Javascript in both speed and ability to natively compile multiple operating system executables from the same code without modification I believe tackling it with the team using GO is very likely the best decision.
With my knowledge of HIVE after working with it and the last network for as long as I have, combined with the past experience of the other 2 for sure willing to help guys on the teams experience in GO coding and having built multiple times their own successful Blockchains damn near got a dream team of experience in place to build this for our community in rapid succession.
It probably goes without saying but the benefit and orders of magnitude increase in HIVE demand this project once word gets out after some aggressive marketing takes place after we move out of beta testing and start really decentralizing the HSC network with nodes set up to be easy to configure and run making the bar for entry realistic for people who perhaps haven't the sysadmin experience required to run other more involved type crpyto software a clear and concise instruction set, and provided they have the 500 HIVE to invest into the network to prove they're financially invested in the network both as a means of providing them with authority but also acting as a pool in which to charge fines should nodes attempt to break from consensus or maliciously send states that aren't intended or able to be cryptographically linked to the HSC chain.
Once we're into beta testing focus will shift to populating the side chain with dApps for lots of users I reckon, my developer focus at that time will then be creating the gateways and bridges required to interface with all side chains within our own ecosystem as a sign of prefering to be partners and cross compatible within our own ecosystem, which I believe is way greater of importance than a mad dash, winner takes all type situation where people are acting out of fear of lack of abundance rather than in a "build up the HIVE team as a whole and no one goes hungry" type mentality I've chosen to focus on over competition and total market cornering.
An Unintended Potential "Conflict of Interest" Resolution
Unbeknownst to me, or rather at the time of starting this I'd only heard a small amount of info or whispers pertaining to one of our top tier core developers @blocktrades (effectively the lead dev / project lead of HIVE) (sorry for tag) also had a smart contract on HIVE project in the incubation phase also enabling the execution of smart contracts. As far as details on how exactly he's tackling this I'm still not 100% and need to reach out to him to see exactly how he's doing it.. (derp It was a bit late when I finally got around to going to PM him, So hopefully he'll drop in and fill us all in on what he and his team are working on or link so we can go check it out).
Although from briefly conversing a while back about it with him, my takeaway understanding (please correct me if I'm wrong) was that his smart contract project architecture is based off of plugin or executable running along side a HiveMind node which is a different approach then I am taking entirely, but with both projects certainly moving in what I believe to be the correct direction in order to really kickstart and generate great interest from the larger crypto ecosystem and draw them towards HIVE. A couple days back it sort of donned on me the potential conflict of interest that blocktrades might have been faced with depending on if my side chain was going to be viewed as potential competition to his projects.
Interoperability Within the HIVE Ecosystem and the World
I don't intend to have my project nullify nor be incompatible with the BT project or any other side chain here on HIVE, in fact I'm adding swap bridges to allow cross application swapping on existing HIVE side chain stuff like Hive-Engine, think of HSC as a possible web between projects currently here that can be connected not only our existing side chains all together, but also branch out and enable swapping with other further into the greater ecosystem crypto networks, as I believe just because both projects are capable of smart contracts execution they are far enough removed that each will find it's preferred use cases amongst the members of the community. When I can get some more info on if you plan to support any sort of popular interoperability protocols provided you're open to it, would gladly work on linking our 2 chains through IBC or some other popular protocol in order to facilitate swaps from one to the other, in order to allow HIVE users to easily take advantage of services or other potential plasma or atomic style swap bridges that might find their way on to either of our smart contract platforms first.
In a sense by allowing interoperability rather than viewing eachother as competition we can split the workload of bridge building and getting HIVE Chainlink oracles and whatnot built, not to mention take advantage of what I suspect will be a decent amount of nodes on HSC and what I suspect to be nodes capable of pulling up data from HIVE chain states in the past faster than mine will.
Ball is on your court on that one though blocktrades, entirely up to you on if this is something you could see being leveraged to somehow provide your smart contract capabilities with some functionality that it could benefit from, or somehow save you development time in the what I consider imperative inclusion of smart contract capability on HIVE.
Ultimately if we're tackling this in a way where both offerings are not only compatible, but that compatibility in some way adds value to eachothers smart contract platfrom, perhaps with my sidechain able to send calls to yours in order to perhaps leverage HiveMind access or something in exchange for your chain being able to run it's oracles on my chain or be able to use it's atomic and plasma bridges out to the wider ecosystem?
Either way I'm extending the olive branch and proposing we leverage the strengths of the different angles of approaching smart contract integration here on HIVE, for our own projects not to mention for our community. As I suspect what we're both proposing will serve to be incredible ramp up of demand, orders of magnitude beyond what we see now, if we're objective about how we go about getting smart contracts on both our projects running here sooner than later, we as a community stand to scoop a good portion of market share from what will be unequivocal viewed as inferior offerings to anyone looking into ours vs theirs..
Stands to be said I'd rather not needlessly toss grit into each others eyes and act as if somehow the projects we're developing are a threat to eachother, I don't believe for a moment that is the case and given the greater HIVE demand almost certain to come from it, I don't think we've much to lose other than some perhaps non-existent preconceived notion that we're somehow not both building things with the same intention. Anyways man. Let me know regardless if my offering is accepted or you'd rather not bother with the interoperability and discarding any need to worry about competing, if not here, then in the other chat whenever you have time.
Have a gooder.