|
Ahh sorry I should have noticed some of the earlier comments. This is fantastic work. Congratulations. The only way I thought this was possible before was applying a malleability patch/some sort of fork or using refunds.
And this is being implemented in Quora?
|
|
|
|
|
I thought AT you were abbreviating Atomic transactions. Can you please send me a link?
|
|
|
|
|
malleability applies to any transaction, not just multisig. Because the miners can just slightly alter the tx without invalidating the script.
|
|
|
|
|
How is malleability not an issue? TX2 is a refund of TX1... thus TX2 spends the hash of the raw TX1 (The TXID). That txid in TX1 can be changed by the miners thus invalidating the refund holding the funds permanently hostage. So TX2 is invalidated and the counterparty doesnt sign again. The funds are permanently stuck. If this is somehow not the case, can you please explain why? I'm familiar with atomic trades and always assumed that was their issue (unilateral hostage commitment)
|
|
|
|
|
Can somebody fork this and start a coin that actually mines a more reasonable supply that makes investors happy?
|
|
|
|
|
Since this is NOT blackcoinpools fault, can we get OP to CHANGE the title of this thread please? I'm more than happy to reimburse if it wasnt done already.
|
|
|
|
Ok so I use encrypted email and it works awesome. i2p is also interesting. Maybe trying fixing bitmessage and fork it.  ...my friend just said look at retroshare. We have about 3 protocols so far. Check back with us for ideas and if you come across anything please come back and let us know. No reason why we cant start to reach out to help other projects as time permits. To easy make a alternative channel, there is should be something like a shared inbox. For main trade board. With bitmessage I use chan channel. I have not looking for yet. Perhaps something like chan exist in one of this 3 protocols. Well maybe we stay in touch. BitHalo and BlackHalo can save you the trouble of escrow handling. That way you can focus on your market platform. |
|
|
|
Announcement!
As promised, the encrypted messaging update will be released within ten to fourteen days. Included in this release is a one of a kind robust encrypted messaging system that is a first in crypto-currency. This system is a framework or protocol within the wallet that allows applications to be built upon it as needed by users. The release will have applications already built upon this framework, these applications will position CINNI as the leading crypto-currency in point of sale systems for both eCommerce and brick and mortar stores. (screen shots of the updated GUI will be available this week)
Included in this release are essential tools to conduct secure encrypted point of sale commerce and are all a first in crypto currency:
1) Encrypted messaging system in client with wallet to wallet messaging platform.
2) Encrypted order form sent wallet to wallet.
3) Encrypted invoice generation sent wallet to wallet.
4) Encrypted receipt delivery sent wallet to wallet.
Future release...est 3-6 weeks.
1) Combined wallet for both BTC and CINNI with multiple currency exchange rate support. (this will be the first ever in crypto-currency and will assist point of sale)
2) In wallet chat room.
Future release...est 4-14 weeks. (With this release we will become the best option in crypto-currency as a point of sale solution)
1) A second wallet designed as a "retail wallet" in addition to the "consumer wallet". This wallet is designed specifically for retail eCommerce businesses and is built on the encrypted messaging platform. (this will be the first "retail wallet" ever in crypto-currency and will lead to rapid merchant adoption of CINNI as a form of payment.)
2) Inventory management system for tracking supply in wallet client.
3) SKU number assignment with SKU pricing in wallet client.
4) Full receivables and reporting features in wallet client.
5) QR code generation in wallet client.
6) Export option into accounting software (i.e. Quickbooks, ect.)
Future release...est 12-18 weeks. (This will be an update on the routing of encrypted messages)
1) Optional anonymity features for "consumer wallet". This would allow for anonymity or (dark) send features similar to DRK coin or XC coin system.
2) Optional anonymization of data and messages. This system will use "messagenodes" combined with "masternodes" in the dark send feature. The "messagenodes" and "masternodes" will be paid in transaction fees and will be required to provide "proof of stake" by holding CINNI in wallets developing coin age (more details will follow).
Darkcoin and XC coin only anonymize half of the transaction (the actual transfer of payment). The communication between buyer and seller is left wide open and can be intercepted by a third party. There are ways to mitigate the communication risk however the communication risk to anonymity remains more significant than the payment risk to anonymity. The system being developed at CINNI will use the encrypted messaging system to allow CINNI to become the first ever completely anonymous transaction system.
Update: First screenshot of Encrypted Messaging GUI. The backend of the encrypted messaging protocol has been completed. The GUI is now being completed and we will have all screens shots up by Thursday evening. Final testing will begin after the GUI is complete. This is a glimpse into the progress that has been made. As we are ahead of development schedule, we have included in the soon to be released wallet update a feature originally scheduled for the second wallet release three weeks from now...the IRC chat box.  looks great. Will there be an option to diable in .conf the chatbox and prevent it loading or an alternative version that doesnt include it? Not everyone wants that in their wallet. And most important development would be to start using versions in wallet code, a brief release notes.txt, anything less just seems sloppy at this point.  Lol man this explains so much omg |
|
|
|
Ok so I use encrypted email and it works awesome. i2p is also interesting. Maybe trying fixing bitmessage and fork it. ...my friend just said look at retroshare. We have about 3 protocols so far. Check back with us for ideas and if you come across anything please come back and let us know. No reason why we cant start to reach out to help other projects as time permits. |
|
|
|
Interesting but Bitmessage is broken. Can be attacked and spoofing nodes. POW too easy flooding the network is a breeze.
This is not big problem yet. I use it long time and all ok and small holes can be fixed. But I think about alternative way to send messages, may be namecoin network can be used? Its a huge problem. Im just saying you really need to work around this for scale. The major problem you will have is days where messages will drop and nobody will connect. Luckily the more people that connect to Halo are logging in to Bitmessage. But still many messages get dropped their failure rate can be worse than 50%. Spoofing nodes and attacks are too much. So first of all fix the Bitmessage protocol by hashing the unprotected parts. And there is another fix which is outside the scope of this thread. But nonetheless wanted to give you a heads up. |
|
|
|
|
Interesting but Bitmessage is broken. Can be attacked and spoofing nodes. POW too easy flooding the network is a breeze.
|
|
|
|
|
Well I guess this coin proves people will buy anything
|
|
|
|
This is the future of crypto. Awesome work dzimbeck!
Thanks buddy! I'm just gonna keep coding. Soon they will realize it when its about a year too late. |
|
|
|
This is just a WONDERFULL JOB !!!  But something is missing David... Your BC address for donations, as you deserve some ! (I didn't find any address of you on BC threads, Reditt, nor on the blackhalo website) Thanks I appreciate it! The address is in the client  |
|
|
|
I have some concerns about BlackHalo:
- designed by one person working alone??
- white paper contains no technical details; it's not really a white paper
- no information on the type of public key/private key encryption
- no access to source code
- many new features that are largely untested in cryptocurrency systems
- I doubt one person could correctly implement all these features without any security vulnerabilities or major bugs
It's an interesting project, but I wouldn't trust any money to it.
Would you like to contact me personally? I did make it alone. dzimbeck@gmail.com. The source is so valuable that I was flooded with emails not to release. Furthermore, I can send you obfuscated code we can set up a time to discuss it at length. There is no security vulnerabilities at all. Composing transactions happens where each party makes their half. There is the temporary accounts for the futures and a locking system for bogus info as well as signature checking and risk reward like the malleability refund. My wallet already has multisig, the custom change system and two step and all the features you say dont exist. Download the client, email me, etc. IF somebody can get me in touch with head bitcoin people I can have them audit the code and compile it privately. But you have to realize this is multimillion dollar code. If i release source it will be cloned to an oblivion. Finally the white paper. There is no need to go beyond what I said because im only taking advantage of the scripting system and multisig. |
|
|
|
If someone missed from reddit.
BlackNode:
"
[]drunkonsound[S ] 2 punkty 1 dzień temu*
We will build out BlackNode and try to get a few nodes running it and start with a fork of the blackcoin core client. If it works well we will talk with Pavel and see how he feels about implementing it in the core.
We think being able to send money to users based on their email address using a federated and decentralized system will make using blackcoins much easier for the average user and hopefully increase adoption. This technology will be open source and hopefully will benefit cryptocurrencies as a whole too.
We are also working on plans to build out a system that would also make it easier to safely store backups using multi-signatures on these decentralized systems which would also make using crypto currency safer for average users. In the event they lose their wallet they would be able to recover a copy from a BlackNode. The idea being they could store backups signed by multiple close friends or family and they could request those trusted people to help recover their lost private keys from the BlackNodes. This would be worked on later though, our primary focus first will be resolving to easy to remember addresses.
We hope these together can make a low energy and quick transaction cryptocurrency like Blackcoin ready for a wider audience."
Starting to be interesting.
I am looking forward for it.
This is already implemented in Halo. The email system is built in we can just email them coins. |
|
|
|
|
So when will the world see? This technology benefits everyone. Of course it benefits dark markets and freedom lovers. But even moreso it benefits consumers and employers. It benefits people who have no way of buying crypto. It benefits china and removes the fear of a ban. It eliminates 3rd parties which brings the cost down of everything. So........ whats up
|
|
|
|
Ok, so after reading white paper... is this the gist of it: alice makes pk1 and pv1
bob makes pk2 and pv2
bob creates tx1 which puts funds into "temp funding account"
tx1 is not relayed
bob sends alice his pk2 and the txid for tx1
alice makes multisig account with bob's pk2 - "escrow"
alice creates tx2 which puts funds into "temp funding account 2"
tx2 is not relayed
alice creates tx3 which puts funds from tx1 and tx2 into "escrow"
alice signs tx3
alice creates txTimeout which puts 99.9% from tx3 to miners
alice signs txTimeout
alice signs tx2
alice sends bob tx3 and txtimeout, but keeps tx2 private
bob creates txTimeout2 which puts 99.9% from tx3 to miners
bob signs tx1, tx3 and txtimeout2
bob sends alice tx1, tx3 and txtimeout2
alice broadcasts tx1, tx2, and tx3
----
example 1:
alice sends bob £50 for 0.2BTC agreed by both alice/bob
alice puts 0.00005btc into escrow, bob puts 0.2btc into escrow
alice creates transaction paying herself 0.2btc from escrow
signs it and sends to bob.
after receiving money, bob signs transaction and alice is paid.
if no money is received... bob loses 0.2btc to locked account
Yeah thats about right lets see... it pays to 6a now not miners because we dont want collusion. There is many more little tricks to it than that and I do lots of things to avoid malleability. The escrow funding I think is about a thousand+ lines of code and maybe another thousand+ for escrow checking. 7000 lines total in the main. However example one is not double deposit escrow. Double deposit would be: Alice wishes to buy 1 bitcoin ($600) so she sets a contract with Bob 1 BTC purchase 1BTC deposit for him and 1 BTC for her. So Alice 1 1 Bob 1 $600 Bob starts out with the advantage but both are stuck in escrow Alice: -1 -1 +$600 Bob: -1 -$600 Deposits returned funds released to bob upon confirmation... Alice: $600 Bob: 1BTC |
|
|
|
Could you make the thing skinnable ? that would allow people to work on skins and let you work on the core....
Yeah I can publish the UI then they can make a new one in qt designer. |
|
|
|
STEP-BY-STEP (WITH IMAGES) INSTRUCTIONS TO SETUP BLACKHALO AND DO A CONTRACT
Very nice job for the explanation! So if the the contract expires you automatically get your BC back in case designer did not complete and did not cancel? No if the time limit expires both parties lose their coins. That is what makes the contracts unbreakable. The risk is always higher than the reward and the communication is usually filtered and encrypted. |
|
|
|
|
Show Posts
