Quote from: dzimbeck on May 09, 2016, 02:57:00 PM

Quote from: Kewde on May 07, 2016, 08:57:12 PM

Quote from: dzimbeck on May 03, 2016, 08:40:25 PM

Hey just wanted to swing by and say keep up the hard work. From one dev to another. The wallet looks nice.

If you need any advice on how to use the "cold staking" method of posv3 just lemme know(but via pm or reddit i hardly use bitcointalk). I finally did my first multisig stake last week in BLK(original pos3). Its here:
https://chainz.cryptoid.info/blk/tx.dws?6ef2849263110c5c6dc6443766be883ea1798851cba45ad6eda9903ba283762c.htm

Its pretty straightforward as you can see in the script.

I know how hard it is to code this stuff doing it first hand in Halo and am happy to see you have chosen bitmessage channels for markets. As we have been using them successfully for a few years now. You might want to modify your bitmessage to resubmit messages every 2 days. If you read the fine print, Bitmessage re-sends 2-4-8-16 day intervals or something like this. Which can result in lost messages if parties don't log in frequently. The network needs to always have a copy of outbound messages in contracts or else you can lose coins if the message you are sending is paramount to the transaction. Unless you are using blockchain messaging while in escrow. Anyways, its easy to modify. If I remember correctly it was only a couple lines to change.

Also, you might want to be careful in combining Tor with Bitcoin since I've heard there is a cheap attack that compromises anonymity.

It would be interesting to see how a person could correlate ip addresses that use all 3 (correlate tor, bitmessage and the coin network). I've always liked i2p the best.

I would be interested in reading the NIZKP implementation as I've always wondered how it can be applied proactively in a p2p network. (I'm fully aware of how zkp works and how the setup of nizkp works but am unsure of how tokens are transferred as I read about the minting and pouring process of zerocoin and was a bit confused.) And plus am wondering how the ip of a broadcast of a transaction can be correlated to a proof. (until there is mesh networks and 3d printed open source electronics there may never be true anon)

But I'm just musing aloud as usual...

Good luck y'all

Hi David,

The team really appreciates your kind words and input. I have noticed that BlackCoin is doing some great improvements too.

We're watching Blackcoin very carefully, everyone here agrees that we wouldn't be anywhere if it weren't for you guys. We're excited about the Blackcoin upgrade to the Bitcoin coinbase 0.11

We followed the Reddit thread about the cold staking, a very interesting read. We were bit confused by the term "cold staking", but multisig staking makes a lot more sense!

Our current implementation does not re-send after two days, I can't say for sure what we'll do to fix this issue but we're not very fond of the current BitMessage approach. We didn't implement the acknowledgment part of the protocol because they open up a gap for traffic correlation and active internal intersection attacks. The acknowledgment messages have a particular size and are easily recognized by an adversary.

There are very effective attacks that can quickly compromise anonymity in the original BitMessage design, we're not having that in ours.

We've made sure that coins can't be lost due to nodes not being online for extended periods of time. The sellers puts all the needed information to make a multisig address in the listing. The buyer then generates the multisig address and includes a signed transaction in the message. When the seller verifies the order he broadcasts all the transactions. No coins will ever be lost this way.

To combat message losses we devised a theoretical model that acts like acknowledgments but is more resilient. Take for example Alice and Bob. Alice sends a message 'Hey Bob' to Bob. When Bob replies he adds the hash of the last message of Alice he had in his message 'Oh hello Alice'.

A->B: message A
B->A: hash(message A) + message B

Now a scenario where multiple messages are lost:

A->B: message A
A->B: message A2 (not received by Bob)
A->B: message A3 (not received by Bob)
B->A: hash(message A) + message B

If Alice receives the message of Bob, she can choose to re-broadcast the messages. If she doesn't receive his messages then the cycle begins again.
When you're expecting an important message then we're generally assuming that you'll be awaiting a response.

Great reads on BitMessage and potential attack vectors:
Traffic correlation attacks: https://www.reddit.com/r/bitmessage/comments/3svc5g/do_confirmation_messages_make_bitmessage/
Forward secrecy: https://www.reddit.com/r/bitmessage/comments/3zzevp/forward_secrecy_for_bitmessage/
More forward secrecy: https://bitmessage.org/forum/index.php?topic=2981.0
Security Analysis of BitMessage: https://bitmessage.org/forum/index.php?topic=1666.0

Tor and Bitcoin indeed form a bit of a troubled relationship, the key element to make it secure is having lots of people running their node as a hidden service. Most attacks with Tor and Bitcoin involve Tor exit relays. I agree that I2P is a better route to take, and we're closely monitoring the Korvi I2P router by Monero.
I'm assuming the cheap attack you are talking about is the one mentioned here: https://arxiv.org/pdf/1410.6079.pdf

Hehehe I'm a newb when it comes down to NIZKP, if you have some good reads for me, ship them over to me!

Thank you for popping by, we greatly appreciate it. It takes great effort to run and maintain open source projects, we recognize your spirit and wish you the best.

Regards,
Kewde and the team.

Okay so staking goes like this and its not limited to multisig, it just lets you have more control over staking in general. In this case you put the blocksignature into an output with 6a

Check for a block once per 16 seconds (more often makes no sense) you check your inputs/coins with:
checkkernel [{"hash1":n1},{"hash2":n2},...] which usually returns { "result":false }
or when you are lucky to create new block { "result":true, "kernel":{"hash":"hash", "n":n, "time":time}, "blocktemplate":"hex", "blocktemplatefees":fees, "blocksignkey":"hex" }

Then Halo creates coinstake tx, using info returned by checkkernel, as follows:
create empty tx set time to kernel time add the kernel input if you want add more inputs (this is a bit tricky so don't for now)

Now we need to know reward, so call getstakesubsidy coinstake blocktemplatefees
Continue to build coinstake add output to empty script, 0 coins add output to script "6a + blocksignkey", 0 coins
add outputs to your addr which is staking fees+staked coins+all your inputs
you can even send outputs to voting addresses if you like

Last step you call submitstakeblock blocktemplate, {coinstake} It will add coinstake to block template, recalculate merkle tree, sign block, and announce it to the network

Here is my example on BLK:
https://chainz.cryptoid.info/blk/tx.dws?6ef2849263110c5c6dc6443766be883ea1798851cba45ad6eda9903ba283762c.htm

I constructed that one with pyblackcointools although i realize your code is in c++ the theory is the same

Cold staking allows you to stake from multisignatue asynchronously signing. So think "staking device" or "staking with two computers". This would make it harder for keyloggers to get your coins because
there is one key on each computer

Bitmessage 2 day resending rule is modified by editing class_singleCleaner.py line 94
(216000 max age of object 60 hours) was being multiplied exponentially which can cause gaps and lose messages now we have a linear system

So that is how you fix that. I agree for acknowledgement, your fix is obviously superior. Very simple and elegant concept. Also consider you can just send a public key with each message. In Halo Bob and Alice exchange Halo public keys and they immediately have fully double encrypted messages. Like PGP. I should remind you that Tor exit nodes are currently controlled by nefarious forces. I've heard these attacks are not trivial and some people think Tors security was never jeopardized. However, I think Bitmessage is harder to attack than you are thinking. This assumes more nodes will start to use Bitmessage and I think they will. Ever since I started on markets, I've seen my connections to the network go up, perhaps from Halo users or just a general renewed interest in it. I remember sending many messages to Aetheros asking him to fix the message header mutation attacks that was crippling the network. Very happy he updated it, I've heard a few others also asked him and it prevented it from being abandonware.

By the way, is your version of Bitmessage in Python? Do you have your own fork/github? My version of Bitmessage is not online. But I only changed message resending and also made the datadir automatically local since I store everything in C:\BlackHalo including the data files of the blockchain and Bitmessage.

Anyways the security is still pretty tricky to compromise, when there is 100s of nodes on the network, messages will be passed from node to node, if all 100 of them are using the channel for markets, it becomes very hard to find out who the originator of a message really even is. Especially because they can send from the channel to the channel. So its like everyone is shouting in an open forum

I was considering using this for broadcasting transactions to the Bitcoin network as well. Instead of broadcasting directly to Bitcoin nodes, send the raw TX to Bitmessage and let them do it. This makes it harder to tell the originating IP address of the Bitcoin transaction broadcast.

You can combine Bitmessage with Tor. And you are right, that paper is the one I was citing.
Although you may be correct in thinking that IP addresses could be triangulated in Bitmessage.

I'm a bigger fan of i2p in any case

And personally I think we will never have anonymity until there is mesh networks. In the meantime a person can always buy their own dish for receiving wifi signals within lets say a 10 mile range. Of course that signal could be triangulated.

Mesh networks, especially 3d printed electronics with mesh networks is a hard core way to go. If only there was a way to encrypt an ip address or change a mac or ip address. People are forced to rely on isps who are now taught to give away all their personal info.

As you guys probably know, Halo is a commercial program, which im trying to get larger masses interested in decentralization. So I'm not honestly as concerned if someone triangulates an IP in my system.
However with that said, I always put all my energy into the security because I'm trying to maintain the principals of decentralization. Of course this is why I designed double deposit escrow, to remove middle men and make lying unprofitable and obviate lawyers and courts (and especially arbiters).

Also you might be thinking to yourself that Python with Bitmessage is slow because POW is slow in Python. Also there is a problem with the equilibrium of using POW when super fast computers can smash your network because the POW must be good enough for regular laptops.

So obviously that wont work.

My solution to this I think you will find is awesome and elegant. You force nodes to lock funds per kilobyte using checklocktimeverify.
So Bob wants to send a message to Alice, his message is 100 KB

Instead of some crazy POW, he is asked by the protocol to lock for example 1 satoshi per byte (of course we can increase this or have it based on some global rate set by a custodial wallet)
So he send the coins checklocktimeverify for lets say 24 hours. The coins first go to 6a or the bitcoineater(burn address)... then you "revive" them like a zombie.
So output is 6a checklocktimeverify 24 hours to (your address)

The network can confirm his coins are indeed locked to himself of the blockchain forgoing POW entirely.

I dont have the time to implement this, but would love to see it done because it fixes an obvious problem with Bitmessage. The only drawback is this might make main-net nodes exclude you but perhaps you can still do it on the main-net giving the option to use both methods and ignore POW when using POL (proof of lock?)

Lastly, I spent a lot of time trying to understand zero proof. It was only this amazing little paper that made me "get it". Its called "How to explain zero knowledge to your children".
http://pages.cs.wisc.edu/~mkowalcz/628.pdf

Not only does it explain zero, but it explains how to fake interactive zero and how to defend against it. And it explains it with the badass story of Alibaba and the 40 thieves.

To sum it up, that paper illustrates that zero is like having a tunnel that is actually a circle that is disconnected at first unless you know the passphrase. When you exit the tunnel you do so from right or left. But nobody saw you inside the tunnel.

Thus, if they say "we want you to exit out the left side", you do it. If they say "we want you to exit out the right", you do it. And this would be impossible without knowing the passphrase.

So by your ACTIONS you prove you knew a secret.

Applying this in a meaningful way is the part that I'm not sure of yet. If I prove I know my own age without telling you my age, can this be used for addresses as well? How?

The proof requires a public demonstration as the "asker of questions" must be there to randomly test the person with the burden of proof. Is there a way to perhaps generate the questions in a meaningful random way based on things they are unable to predict? (Perhaps their broadcast time they need to do their answers to questions off the hash of that combined with other hashes that they wouldn't have been able to predict making preparing for the questioning scheme pretty damn hard).

Obviously the future isn't predictable so there must be some sort of real time random data set to pull from on or off a blockchain. And perhaps one that can be confirmed in retrograde?

Non-interactive proofs I (think) have to do with setting up the "demonstration" in advance. So everyone runs their test of a really giant database of prescripted questions for the scheme? And correct me if I'm wrong but non-interactive requires a TRUSTED setup since I think there is a layer of obfuscation. So trust has to be placed that the person who set it up will not abuse his knowledge of the questions in advance allowing him to fake knowledge of facts pertaining to the Zero knowledge proofs.

I heard a rumor that you used zknips? But then I heard you had only used ring signatures. Then i heard all kinds of fud. I'm not sure what was true and what wasn't. In any case it would be interesting to know if you guys actually use zero knowledge in your code base? And how did you apply it in a useful way? I really could not understand zerocoins pouring and minting method... and I re-read the paper like 10 times.

I am a huge fan of i2p as well! And the checklocktimeverify idea and PoL

! The mesh network idea though and your concerns about IP tracking and mac signatures could be addressed in linux (standard procedure to use macchanger in kali for instance) and I think an entire OS with proxies baked-in is the solution (i2p). macchanger could be scripted on boot to rotate through different addresses so unique signatures are avoided. Custom distros for crypto is inevitable if security/anonymity is really a concern imo.