Topic: BitBay OFFICIAL BITBAY Thread Smart Contracts Decentralized Markets Rolling Peg - page 279. (Read 542094 times)

BitHalo and BitBay article u might be interested to read.
David is the best coder after Satoshi.
BitBay coming fast!!!
https://news.bitcoin.com/4-platforms-believe-future-decentralized/

Awesome!
The rescan worked on the new install!
Thanks very much for your help dzimbeck and Munti!
 
Happy New Year!
Onwards and upwards!

Okay so if the sync is stuck, probably just restart the client and wait. If you continue to have the problem maybe some other software has interfered with it or its been a long time since you last connected. If that issue persists please send me your debug.log in the bitbaydata folder.

The thing about your keys, the Halo markets client uses two keys (not wallet.dat) so are you sure you are importing the correct file? When you set up the client I'm hoping you used the wizard since its instructive, you were asked to make two .private files. Those two files are your account (its multisignature). When opening a wallet, you should open both files. If the computer is new, and it shows a balance of zero and its fully synchronized and those two keys were manually loaded, there is a button on the bottom that says: "rescan" press that.

There is a documentation that came with the client.

I'm interested to know when you downloaded the 1.2 version. 1.2.1 runs as an update, the client (should)  automatically ask to update when you run it. But if it doesn't the update can be retrieved here: www.davtonia.com/blackhalo/bitbayupdate.exe ... thats the link to the updater... it should patch the client.

And lastly, you cannot import keys from Halo to QT and you certainly would not want to even if you could. Halo uses TWO keys, not wallet.dat its those two .private key files (and did you store those in jpegs? because then they are hidden inside jpegs). If you somehow were able to import the multisignature address manually by importing the public keys as "watch only" which im fairly sure you didn't do, that can cause your QT wallet to get corrupted IF it receives staked coins to it(this actually happened to me back in the day when i kept mixing wallets and sharing the same data directory... i had to create a special program just to extract the coins). Because then you won't be able to spend from the QT wallet since the wallet will try to spend from the multisig and not have the private keys that correspond from it. (QT only knows how to use single keys, either paytopubkey or standard addresses)

I'll leave your questions for David, but here is a link www.davtonia.com/blackhalo/bitbayupdate.exe
There's been a little confusion about version number because some of the updates only were ment for core team for testing originally. That link is the latest and should take your v1.2 up to v1.21

Edit: That is an update only, not a full download

Hi,

I just wanted to say I really like the BitBay concept and appreciate the work that's gone into it by the devs and the support of the community. I can tell that there is a lot going on with it and I wish the project every success.

However, I just have one or two issues that are proving a bit challenging at the moment, so any help with the following would be greatly appreciated:

1. My Halo client v.1.2 on my Vista PC (32 bit) is not syncing, it appears to be stuck at 85%. I've installed what I think might be the latest version on my Windows 7 (64 bit) laptop (v.1.21) and it's reached 100%. So, I backed up my private keys from the vista machine and I've been failing hopelessly at importing these keys into the client on the laptop?

2. Is there some definitive instructions anywhere for doing this?

3. Also, it would be helpful if there was a link posted here in the forum for the latest client download as when you visit the website, the download appears to be the v.1.2 and not the v1.21, which I can't seem to find anywhere now?

4. I've also installed the QT Wallet onto my laptop and it's finally synced up. So, I was wondering whether it is possible to import the private keys from my Halo client into the QT Wallet? I've tried using the [importprivkey] command in the debug console, but with no success? I get a code 5 error message? I presume you enter the command and then the private key, but I'm not sure what label etc to use, or whether or not I need to add the public key as well?

Anyway, right now it's a bit frustrating because I don't have access to my Bitbay coin balance, as the client with the balance in it is the one that is stuck at 85% and the client on my laptop refuses to acknowledge or recognise the backed up private keys. Maybe that's because the PC one isn't up to date?

Like I said I'm very supportive of the BitBay project and want to help where I can. So, any help with the above would be much appreciated.

Thanks

Yeah thats the point, its impossible to lose your coins. Because the wallet is just a collection of private keys. The only way to lose coins is either accidentally destroy it, lose it or forget your password. You dont need the "qt wallet" to empty wallet.dat, you can just extract the keys and spend them manually.

Hello,

  I just wanted to add that I have reformatted PC 3 or 4 times since I have used the Bitbay QT wallet and I have had 0 issues transferring my old wallet dat to the Bitbay directory after a fresh install.

Thanks

For the people who said they had an issue with the Qt wallet, contact me on via skype or pm me here and i can walk you through it. If need be we can go on teamviewer and i will take a look at it.

The Qt wallet is open source, you can go ahead and check it yourself. Your wallet.dat is only a collection of public keys. Its doesnt make sense to say you lost your Bay. Just go on block explorer, if you Bay is still there then its still there. If you have the old wallet, use your backup and everything will return to normal.

Also, i didnt make the Qt wallet, its just a standard Qt wallet.

I had the same exact problem when my hard drive crashed, had 6 wallets and only BitBay QT wallet failed to work and I lost all my Bay $. They tell me it is my fault and that I am too stupid to keep my passwords, funny how I got 5 other wallets to work fine. I got no help for this issue. Just consider it a loss, nothing you can do, wallet is glitched.

Did anyone help you?

It's in the OP under "Useful Links" at the bottom of the OP

Where can I find actual bootstrap file?

It uses encrypted email or bitmessage... depending on how they were contacted. If its through the markets people use both. The software works almost like thunderbird, managing your email and cleaning the halo emails from the inbox as well as encrypting them. Their utxos wouldn't be invalid per se. One party is delegated as the one to broadcast. A person can try to spend their inputs canceling the broadcast. Its done with a temporary transaction to prevent issues with fee changes. So if you look at my whitepaper at bithalo.org it talks about how this is done.
Future transactions can be made, malleability doesnt disable the bomb/timeout tx because the software will delete the keys anyways. And to further secure the bomb you can use an instant refund, a tx based off the funding txid. But nobody uses instant refund anyways since the person who pays more broadcasts. Canceling a broadcast doesn't do anything, it just wastes everyones time. Once the funds are in escrow there is no way out except working together.

The instant refund can also delegate someone as the broadcaster. Mind you none of this interferes with simultaneous deposit into escrow. After all, its ONE tx signed by two different people. (in theory we could do crowdfunding 100/100 signatures or use anyonecanpay signature schemes)

TX1
Bob---> Bob temp
TX2
Alice---> Alice temp

TX4
Escrow------------------->Timeout/Bomb tx presigned by Bob/Alice

TX3
Bob temp-------\
                        ---> Escrow Bob/Alice
Alice temp------/

The timeout is signed in advance before Alice releases tx1 raw. This prevents early broadcast. Only Bob can change txid of the bombtx disabling it.
But since the one broadcasting is the one with more at stake, it is counterintuitive and it also wont prevent parties from key deletion

Now this CAN be done with checklocktimeverify
using the temporary tx is still a nice idea for fee reduction but its not totally necessary since ive changed how that calculates in Halo

Bob/Alice--> multisig 2 of 2 checklocktimeverify until X timestamp then only redeemed by 1BitcoinEaterADIOS(for example)

Timestamps are better than blocks mind you as ive seen a slight inconsistency in block times which is unacceptable for timing end users on a specific destruction date.

Everything in Halo is extremely specific, the time starts from the timestamp arranged OR funded. Dont forget our timers need to match. So whichever is earlier. Checklocktimeverify could in theory change that timing protocol and we need to be careful on delayed sign/broadcasting

Bitbay only Complicates things BECAUSE funds can freeze changing the requirement to send certain inputs

And this changes at least twice a day!! So realize that Bitbay(pegged) needs to send at least 2 copies of the TX.
One with the current rate, the second with the rate changes in both directions on broadcast maybe even another copy with a timelock of 3 months to bypass any rate change with at least 10 points locked up respectively.

Under the hood this is like a Ferrari man. The whole advanced planning for these deals is meant to keep them trustless. I could literally talk for hours about protocol.

I've got a lot of work left to do thats for sure, it will be rewarding no doubt, but patience is a virtue.

How does your system communicate the transaction amongst the parties prior to broadcasting it? If one side takes his time could the other parties utxo's be invalid if they are making other transactions and the first isn't broadcasted yet?

No thats not correct. Both parties make the deposit in the same transaction. Its simultaneous. Withdraws are also simultaneous.

Its not impossible its just a choice, either or. The buyer im assuming makes the first step and deposits into the escrow correct? What's stopping the seller from not responding and buyer not getting his coins back?

The above scenario is impossible. Funding is not asynchronous, its simultaneous(two inputs from different parties to one account). And deposit levels are agreed to in advance. Even if a template automatically sets them, the software notifies you if there were custom deposits set and tells you to review them.

probably better to just provide option of which one they want.. How do you avoid the case where vendor does not want to match the escrow in dde but the buyer has paid it to multisig? Does it timeout?

Yeah 2 of 2 with the option to move it to a 2 of 3