Well this was just an example. Also I should mention that your client would be locking the funds. And its not dissimilar from "Parking" funds in Nubits, we can offer incentive for parking with manufacturers. One method is to use only one manufacturer at first to simplify the distribution. I'm mostly interested in mesh networks to be honest. That is exactly what I discussed with the other players. My solution works, its not "green addresses" per se but I agree even though it works it may not get adopted. That solution works around bitcoins weakness of trustless doublespend problems. What you are describing is a problem inherent in Bitcoin itself so the only other way is to make the device are party to the transaction in some way so it can trust the RAW transaction is valid. This way it doesnt have to wait for confirmations since it knows its holding a signature, hash or something that would prevent you from spending otherwise. Time locks are not permanent, they are only needed to create a connection with the hardware manufacturers server to prove you arent double spending on one of their devices.

So, no offense taken. I have yet to see a better solution. Perhaps I can come up with an additional one later and PM you when I do. After all knowledge should be free. So we are taking baby steps. Just start with what works and let the industry evolve. That solution works for your particular use case. Users can also do a double deposit contract with device manufacturers in advance. Then they would not need to use my above proposed method.

Bitcoin itself is highly flawed anyways, it doesnt have a very advanced scripting system, there is malleability which always needs to be worked around by protocols, there is major problems with botnets and sybil attacks, there is a scalabiity issue that is very complex to confront (im speaking of bandwidth issues in securing the blockchain) and so on.

With that said, they liked my ideas with mesh networks and added it as IoT which is a misnomer. The mesh netowork idea I had was working with hardware but not necessarily in real time. A good example is Blackcoins COLD Staking. This is something rat4 added some RPC calls for. Now I can do multisignature staking in Halo. We could then, use a device with the staker to sign the second sig. So this is a case where you dont need instant confirmations.

 To me, mesh networks are a dream goal if we even get close to that point this project will be a smash hit. So really my impression in starting this project was to start in mesh. If they really want to do this with me, we can change the world so its of great interest to me to see this follow through.

Lets be clear about this roadmap again:

*DEMO Smart contracting client(from BlackHalo)  --- Within a week. Trying to get it before ICO ends but not 100% sure.
*Markets(beta without advanced whitelists but with a kill switch/mod key) --- Within a month or two max. I've been working on this for Blackcoin, they coincide

The last two get worked on simultaneously with Hedging taking precedence:
*Hedging transition with the checklocktimeverify --- this is about a month... we can pull from NuBits, but we are dealing with a larger supply so that math has     to work out to manage all of everyones funds properly. If they pay my dev team I can have them work on this fork BEFORE I finish my markets which would greatly increase the speed in the fork.

*Markets with whitelists/double back on server --- one month after the main markets release. Its not a difficult implementation, its very elegant but there would also be some user interface feedback and bugs we want to respond to. This could delay one additional month so we will have to ask users to behave in our decentralized markets so we don't have to shut it down.

So give the above a total of 3 months. Realize I'm trying to underpromise and overdeliver. And you know I deliver if you read blackcoins subreddit

ONCE we are hedged, we can go for the mesh networks. We will now be capped at a billion dollars(thats my target price anyways) and be able to afford and utilize our connections to the hardware markets and we will indeed create an incentive system for setting up these networks.

Did you see the flow chart i posted a few pages back? Please read up on bitmessage channels and whitelists. Then realize im adding a burn layer to bitmessage(but the first version of markets will not have the burn layer because I want the nodes)

One working solution is to have your funds locked before you get to the gate(lock the outputs with checklocktimeverify). Different companies that issue services can partner with IOT manufacturers to have a series of second keys to hold for gates. Thus your primary account would have locked funds set aside for public events and interaction with IOT. This you could contact the manufacturer at any time to spend the funds (this could be automated even). So they cant hold your money hostage because the funds are set to convert back to a regular account on the expiration of the lock. Only the gate could unlock the funds so the raw transaction is valid. The gate only signs with parties that were confirmed in advance to be honest. Those parties would hold a double deposit contract with the manufacturer too. So a double spend at the gate would harm the party involved and reveal who double spent. It would also be highly unlikely because the spender would need to know the manufacturers key which they would always keep secret. Most definitely they would secure insurance for this too. Since they stand to profit much more than trying to trick a stupid gate for 10 bucks. Furthermore, the manufacturer would probably also put scripts in their outputs so their key would constantly be changing. It could be a hash to a secret or a key. This starts boiling down more to logistics. Manufacturers would eventually be part of a network and there would be a series of things that could be done to make the hash. Different manufacturers could use zero knowledge proofs to arrive at similar solutions to equivalent problems without revealing the secret.

Of course zero knowledge proof is not necessary at first to grow the industry. This is just an example of how this would work.

My multisignature exchange uses similar theories. Holding the second key for zero confirmation, but time locking in the outputs so hostage situations are impossible. Just add the layer I explained above where unlocking your funds is fairly easy as long as you have contact with their servers and if you cant unlock its not a problem because the funds revert back to you in the future. The gate can prove this on the block chain well in advance because most likely, your funds wont revert back for a while! If the gate sees you are at the block where you revert or past it, the gate declines your transaction for fear of doublespend.

Yeah well I have never been afraid of growing and facing new frontiers. My reputation is at risk mostly by association. Under-capitalization is a serious problem in crypto. This is one reason why I regret not selling at the peak of LTC or BC. I missed out on millions by not doing that. If I had millions, this entire crypto space would be a different story because I could work alone with my own dev team and keep it all in house. It would not be necessary to even license at that point.

But instead of giving up, I just take a new approach. BC was lagging for a while and most of us certainly didnt have the resources. So this deal made sense to me. I'm pretty certain by the ICO, that I would not have been able to do this without them.

One thing I can say to set people at ease is this: I'm already coding these markets for BlackHalo and BitHalo. So adding this coin is not so much of a challenge here. The rest of the road-map is very practical for me. If they like making money, they would obviously want to follow this road map because its the difference of money to be made with by following it is astronomical. Also, BitBay is an obvious and solid brand name. Why not be in first position?

The processing power for decryption and encryption and network throughput would be the only hurdle I forsee here. However, i think this is also going to depend on the hardware and the application. I'm certain there is a middle ground here. Hardware is the expertise of another one of our team members. I would want to defer to him on this one. If needed, I can certainly make our payload as light weight as possible for Bitcoin.

Yeah this is correct. And please look at my notes about multisignature and timelocks in the outputs. When you use that, the need to consult the blockchain becomes much less frequent if ever.

Yeah I got a deposit. If there wasnt a deposit I would not talk. Let me talk a little bit with the guys and see if/when they would like to be public. This seems to be a concern (I don't blame you guys). However one one hand for me at least, there is about 4 others and if this funds, it would trivial to pay me the rest of my fee. They would not really want to abandon this project simply because they have a stake in seeing it succeed and we are going to attempt to peg it to a major currency such as dollar or RMB.

It is a little nerve wrecking at times but I just try to keep calm and code my markets.

I believe I already answered this, im not able to monitor this thread constantly because I'm usually working. But yeah you can do zero confirmations with multisig because your device or you hold the raw transaction. It depends on the application/hardware. Best that you give me some example or use case and I can explain to you how I would approach it.

This isnt dissimilar from NightTrader multisig engine which I have made. I just dont have any front end for it. Controlling hardware in real time is fairly easy when you know multiple signatures are involved. Add this to checklocktimeverify and you can have outputs convert to different things based on blocks. Handling raw transactions where you hold the other signature can leave you secure with the fact that you can do zero confirmations.

Smart contracts take transactions to confirm but you wait for a couple confirmations. Try one in Halo and you will see what I mean. My contracts were done in May so I had a significant lean on Etherium anyways. But yeah I don't hold the funds thats cause for concern but I do know the parties involved and it would be irrational for them to walk and highly destructive to their reputations because some of them are fairly well known.


As for 60 second block times or zero confirmation transactions. That I can do thats all part of multisig when you have a device that holds a second signature it knows you can't sign for another transaction so it can send at any time and perform its actions asynchronously. Thats the beauty of multisig and hardware. IoT is a buzzword and IMO is not as complex as everyone is making it out to be for a majority of its every day applications.

Your house unlocking would be immediate... there is a difference when you are spending coins vs communicating with something using encryption.

Yeah you can make your own channels. Its more of a question of how much customization I allow for the channels like custom templates and stuff. It probably will take some time to get it to that level. I want to see NightTrader and BitBay markets popular and being used first.

Summer??! Goodness no. It will be anywhere from december to late january.

Thanks Jessica, I'm going to archive this and read it in my spare time.

Well hopefully i can keep my head above water. Its similar to blaming Peter Todd if things go south in Viacoin. I for one, would not blame him because markets are volatile. Especially if he was part of a team and was being contracted. For me to have my own coin would require a massive team of coders since I would want to rewrite Bitcoin so it can scale to the proportions of visa.

Anyways, thanks for the support its exciting none the less. My hands are getting tired from all the typing lol.

This all depends on what you are negotiating. And it may actually require waiting for confirmations. In BlackHalo, i make the client go to escrow after only a few confirmations. Its a series of 3 or 4 transactions and its outline how its done in my whitepaper that comes with the program or found at Bithalo.org

I'm hoping so... my marketing was very sluggish despite all the moves we made this year. But I think that we will break this market eventually. More and more people are realizing what we did. Its most likely unnoticed at first because not everyone even knew Bitcoin and Blackcoin had contracts lol.

Well there are a few techniques to this. With checklocktimeverify, there is a whole bunch of new types of spending we can do. For example, we can spend so coins convert to a different address later, we can lock coins for months at a time. A 2 of 2 multisig account can convert to a 3 of 3 or (really anything)... its all about how you want to program the device.

With that said, most devices will need their own key and will sign on its own behalf. This would be used for more than just spending money. Since you get a secure connection to the device, it can hold coins, it can perform contracts with you etc. Thus, using double deposit we can create a set of rules and protocols interacting with the device. One example is a hardware staking wallet with multisig. At Blackcoin they are working on this. Their lead dev rat4 already coded in multisignature staking. It was lovely. So that just needs to be applied in the context of a device. This is just ONE example. Losing your hardware need NOT lose your coins even in a 2 of 2 multisig since we can lock the coins to convert back to the users key at a later date.

This is inaccurate, im being contracted in BTC not bay. Also, if you read OP you will see that if we dont sell out (which I'm now thinking we will anyways), then all the unused coins will be burned. So nobody gets them. I will go ahead and have them confirm this here.

No it isnt too slow. Just go ahead and test a Blackcoin contract. Confirmations are about the same so is Blocktimes. You can fund and complete a contract before the first Bitcoin block. It all depends i suppose on how many confirmations you set the client for because it can even send on one confirmation.