Holy Grail BOUNTY

[Xenland]

Lets just say I have dual use for BitMessage integration and I will leave the GUI to you.  The annoying thing about bitmessage is that it depends upon PyQt is and is a pain to deploy.   It would be nice if there were a Qt GUI for bitmessage that integrated at the protocol level... but I suspect that would require a bigger bounty and is outside the scope of this.

I don't suppose the creator can open up a HTTP/JSON API so we can interface into it with out creating a QT/C++ version of bitmessage? I'm not sure which one would be easier/secure

[1714890982]

1714890982

[1714890982]

1714890982

[1714890982]

1714890982

[1714890982]

1714890982

[marcus_of_augustus]

I know that OT uses 'mailboxes' for unsigned transactions and even invoices / messages etc.  Is the idea to replace the mailbox infrastructure with BitMessage?
Or would all messages be directed to a specific OT server identified by a BM address and thus simply replace the HTTP protocol for communicating with an OT server?

Probably read the OP of the original idea will bring you up to speed. BM is just for P2P price discovery, not settlement, escrow or clearing functions.

https://bitcointalk.org/index.php?topic=212490.msg2227866#msg2227866

[bytemaster]

Lets just say I have dual use for BitMessage integration and I will leave the GUI to you.  The annoying thing about bitmessage is that it depends upon PyQt is and is a pain to deploy.   It would be nice if there were a Qt GUI for bitmessage that integrated at the protocol level... but I suspect that would require a bigger bounty and is outside the scope of this.

I don't suppose the creator can open up a HTTP/JSON API so we can interface into it with out creating a QT/C++ version of bitmessage? I'm not sure which one would be easier/secure

It does have a json-api, but you still need to deploy the app.  I suppose if you used it without the GUI it might be easier to deploy.

[fellowtraveler]

I know that OT uses 'mailboxes' for unsigned transactions and even invoices / messages etc.  Is the idea to replace the mailbox infrastructure with BitMessage?

Absolutely not. OT's inboxes (and other boxes) are integral to the internal workings of OT. (And everything in them is signed.)

Bitmessage is an additional layer to be used for discovery, specifically for server-to-server wiring and cross-server exchange. It will be used with OT, inside this GUI (this thread), which will integrate with both of them.

Or would all messages be directed to a specific OT server identified by a BM address and thus simply replace the HTTP protocol for communicating with an OT server?

Absolutely not. Bitmessage will not change anything inside OT itself. Rather, this "holy grail" application will use both OT and Bitmessage.

Also, FYI, the Bitmessage communications will not be between OT servers, but P2P between OT users.

[JaSK]

Hello everyone

I wasn't able to post earlier because of the must-be-5-hours-online-rule but I claimed Bitmessage or/xor Bitcoin multisig via email.
bytemaster aparently has some interest in the bitmessage part so if it's alright with everyone I'll do the multisig integration?..

My GitHub nick is tuttleorbuttle but there's nothing to see yet apart from a few tests that show that I'm new to Git :p

[fellowtraveler]

I think the easiest way for us to divide up all the tasks is to use a system designed for that purpose.

"CIYAM Open" has offered to allow us to use their system for free, for the purpose of dividing up the tasks, so I suggest we take them up on that offer.

I have posted the project there. Please click here and sign up.

I ran into a few bugs, but they were very responsive about fixing them. If you have any issues, the lead developer Ian can be contacted via Skype (ian.who.net) or via email (ian@ciyam.org) or via PM (CIYAM Open).

I tried to add project tasks for each of the pieces discussed -- if I missed any, let me know and I will add them.

So far the donations for the bounty are up to 45.32, + 18 from Monetas == total of 63.32 BTC.

[CIYAM]

Just to let you guys know that I am online now (and will be for at least a few more hours - living in China it is around 9:45pm here).

If you can't reach my on Skype then most likely I am asleep - but I will respond to any email within 12 hours or so.

[JaSK]

Registered without problems, seems like a great service.

Question to fellowtraveler:
Are the Project Task Delivery dates final or did you just fill in a random date?

Minor glitch report to CIYAM:
When I write a note when bidding for a task I have to escape commas to not get an error message.
Bla bla bla\, blablabla.

[CIYAM]

Minor glitch report to CIYAM:
When I write a note when bidding for a task I have to escape commas to not get an error message.
Bla bla bla\, blablabla.

Ouch - I will look into this - in case it's relevant what browser?

In regards to the dates - you should provide the Delivery date that *you* are comfortable with (once accepted the Task will change to it). Be sure to allow time for review and rework.

[fellowtraveler]

Registered without problems, seems like a great service.

Question to fellowtraveler:
Are the Project Task Delivery dates final or did you just fill in a random date?

Minor glitch report to CIYAM:
When I write a note when bidding for a task I have to escape commas to not get an error message.
Bla bla bla\, blablabla.

I just put the "end of the month" for the date. I'm not going to hold people to that date. (But at some point -- e.g. 6 months later if it's still not done, then that's "not cool.")

[CIYAM]

I just put the "end of the month" for the date. I'm not going to hold people to that date. (But at some point -- e.g. 6 months later if it's still not done, then that's "not cool.")

Just to be be clear - it is *of course* up to the Project Manager how long to wait to accept or reject a task (the system only mandates that the date and time you offer must be >= to the suggested Delivery date and time).

[Xenland]

Preview of the first level menu.

Working on the OT HTTP calls, well researching then implementing.

[CIYAM]

Minor glitch report to CIYAM:
When I write a note when bidding for a task I have to escape commas to not get an error message.
Bla bla bla\, blablabla.

Bug swatted and please note that after you create a save a Project Task Bid you then need to click "Check Balance" (to verify the BTC address balance is what you think it should be) and then "Open Bid" (it can't be edited after it has been "opened" so be sure all the details are correct first).

For those who do not want to use GPG in order to sign up please use https://ciyam.org/open (i.e. HTTPS) or if you prefer to use Google or another OpenID account click on the icon to the right of the "key" instead of the key itself.

[solidaria]

Each time I love it more!
I'm proud of you guys. Each of you!
Let's build this thing! This Ideal!

I don't have almost nothing at the time. But i'll surely contribute. I'm with you!

[fellowtraveler]

If you guys check the balance on the Moneychanger project site (CIYAM Open) you will see there are now 63+ BTC available there.

There are still some tasks that people haven't signed up for -- please do so!

[neoranga]

I believe in this idea so I contributed founds to the bounty.
Let's go for it

[Loozik]

Probably read the OP of the original idea will bring you up to speed. BM is just for P2P price discovery, not settlement, escrow or clearing functions.

I have a couple newbie questions. Sorry for my English and non-techie jargon. I apologize if my questions make little sense. Please do not shoot me.

1. What will be the price and time (event) format of the data feed of the decentralized exchange?
Date,Time,Price,Volume
e.g. 2013-06-08,14:50:17 (what about milisecond or microsecond timestamping?),120.7676598765 (number of digits down to Satoshi denomination?),150000000 (volume traded in Satoshis?)

The reason I ask is I would like to find out which charting platforms can be hooked to the data feed. There is going to be a historical and real-time data feed available?


2. Who will aggregate and transmit historical and real-time trade tick data (is low latency possible)? After a few years the database can be many gigs of data for one symbol / instrument alone if transactions via Holly Grail are frequent.

[marcus_of_augustus]

Probably read the OP of the original idea will bring you up to speed. BM is just for P2P price discovery, not settlement, escrow or clearing functions.

I have a couple newbie questions. Sorry for my English and non-techie jargon. I apologize if my questions make little sense. Please do not shoot me.

1. What will be the price and time (event) format of the data feed of the decentralized exchange?
Date,Time,Price,Volume
e.g. 2013-06-08,14:50:17 (what about milisecond or microsecond timestamping?),120.7676598765 (number of digits down to Satoshi denomination?),150000000 (volume traded in Satoshis?)

The reason I ask is I would like to find out which charting platforms can be hooked to the data feed. There is going to be a historical and real-time data feed available?


2. Who will aggregate and transmit historical and real-time trade tick data (is low latency possible)? After a few years the database can be many gigs of data for one symbol / instrument alone if transactions via Holly Grail are frequent.

As far as I'm aware those details are yet to be determined. So far the tech has only just been established to negotiate asset-pair/clearing-server discovery on secure, unspammable broadcast (P2P) channels. Detailed protocols for negotiating on those channels are in development ... sounds like there might be an opening for your input?

Since the broadcast requires proof-of-work (around 3-4 mins on regular modern desktop) it will hinder bots broadcasting millisecond bids (unless they get some serious CPU crunching behind them)

[Loozik]

Since the broadcast requires proof-of-work (around 3-4 mins on regular modern desktop) it will hinder bots broadcasting millisecond bids (unless they get some serious CPU crunching behind them)

Maybe there could be two data feeds:
a) a raw (unconfirmed / without proof of work) data feed - this will report ticks (transactions) as they are effected with a high precision timestamp.
b) a delayed one (after proof of work)

I would not use the millisecond precision to place orders (I do not have the infrastructure to do so). I would use it only for strategy backtesting and optimization.

If you have 10 transactions occurring at a given second:
- a second resolution will not tell you which tick was 1st and which tick was 10th
- a millisecond resolution will tell you the exact order in which those 10 transactions were made, so a better automated (counter-bot, counter-whale) strategy can be devised.

[FreddyFender]

Since the broadcast requires proof-of-work (around 3-4 mins on regular modern desktop) it will hinder bots broadcasting millisecond bids (unless they get some serious CPU crunching behind them)

Maybe there could be two data feeds:
a) a raw (unconfirmed / without proof of work) data feed - this will report ticks (transactions) as they are effected with a high precision timestamp.
b) a delayed one (after proof of work)

I would not use the millisecond precision to place orders (I do not have the infrastructure to do so). I would use it only for strategy backtesting and optimization.

If you have 10 transactions occurring at a given second:
- a second resolution will not tell you which tick was 1st and which tick was 10th
- a millisecond resolution will tell you the exact order in which those 10 transactions were made, so a better automated (counter-bot, counter-whale) strategy can be devised.

Correct me if I'm wrong, the major reason that BM's PoW is integral would be to eliminate 'junk' transactions?