Topic: Bitmark - page 66. (Read 622228 times)

FYI:

We are holding a meeting to discuss these DEV requirements & plan how to address these challenges.

Meeting will be held in Slack @ 1500 ZULU Time tomorrow, Sunday 15FEB2015

Thanks

Thanks Mark - I was hoping you would jump in to help me specify that  

Thank you Medic.

Specific skills we could utilize quickly are (in no particular order): C++, Javascript, HTML/CSS, Go.

STATUS UPDATE:

The project has identified some development milestone which require additional resources to accomplish. If you are or know a experienced developer that is willing to contribute their time toward the collaborative development of our system, please reach out to me at: [email protected]  

Here is a brief Sketch of the systems / components required:

1) Marking Data Processing and Storage
```Data over HTTP -> Processing Scripts -> Storage

a) To the left edge we layer on auth as required, auth is outwith "core" requirements and the system, and can be developed later / iteratively.

b) In the middle, "processing scripts", read a marking in it's data format, clean any data, expand any short names, construct a transaction to do the balance swap, ensure transaction can be settled, action it.  This is "core" stuff required.
- note this step passes of much work to  (2) -

c) To the right edge we have storage, something like couchdb I feel will do fine now.  On that edge we can layer on caching, data export in different media types, and query engines like sparql.  (expose the marking graph)These are outwith the "core" requirements and system, and can be developed later / iteratively.

```
2) Multi User Wallet API
```Data over HTTP API <-> User + Balance State and Storage <-> Blockchain

a) To the left edge we have a RESTful HTTP API, munge of linked data and web2 style REST api.  Auth as required.

b) In the middle,  the "multi user wallet" part pretty much a state machine controlling balances and actioning transfers, then storing that state.

c) To the right, interface to the blockchain of BTM to handle withdraws and deposits.  Flow of data in both directions here.
```


markpfennig [2:55 PM]

Markus, markthis, any similar marking system are either just interfaces/proxies to [1] above, or UI wrappers around it.

markpfennig [3:02 PM]

1a) is really just rest/rww
1b) is pretty much just working with graph data and completing actions if parts of data match certain filters
1c) is graph storage, export as different formats, expose a graph of marking data
not too complex on 1 (edited)

markpfennig [3:07 PM]

2a) should just fall out as public class methods exposed over http in the nicest way possible, easy to do but hard to get right imho

2b) again isn't too hard, as long as it's tested to hell and back to be secure and have no errors (can't have balance affecting errors!) it should be fine

2c) again easy to hack, hard to do it right

markpfennig [3:08 PM]

1c, 2a, and 2c have been my hold up points, as want the right solution, and hard to envision or ideal software to do it or repurpose doesn't exist

markpfennig [3:08 PM]

massive disclaimer: my interpretation of "right" may not be needed, may be overkill, and may not be somebody elses idea of "right"


Additionally, as you can see Mark is diligently working to round up these resources through various other channels. I can assure you that we will deliver our flagship Site and API, among other things.  However, we need these additional resources ASAP, and as soon as we can fill these gaps we can launch our product. Our Project had No IPO / Pre-Mine, so our lack of funds impedes our ability to hire a freelance developer (as this is what would be done under normal circumstances).

Thanks to all of you who have supported Project Bitmark

I think it's really not a disadvantage, because otherwise there would be a lot of Bitmark without demand,
so yes i think it was and is a good idea.

I wish I could equate how much the price went down just because of the time I spent replying to your comment.


You could increase the price just by spending the amount of time you spent writing that up on helping out.

And you cant make any reasonable profits unless maybe you ask bitmex to add clearing of btm futures and later options so . . .

that kind of comment is better suited at the trollbox of an exchange where it may potentially see the eyes of people who could benefit you. I feel here its detrimental to us.

Anyway I came on here to say that I read through some papers by dbkeys and it seems awesome im learning some math notations just so i can understand it And if you think you have an improvement for bitmarks algo send me a PM. You should also send Gavin & Togami a tweet about it though, just please mention something about dbkeys' great work on the subject to them. Personally I think the amount of hashing power it would take to freeze the network is too much for the network to be in any great harm and am happy with low supply while demand is low.

Anybody think the price of BitMark is gonna come down a bit?

I'm thrilled they're updating the wallet.

NVC has about a 3 days wait before he coins mature and that''s reasonable - hopefully the new BTM wallet will be more in line with that

I still have some hope, and am glad supply is slowed whilst demand and development have been slow.  As they pick back up hopefully this will reflect on the network.

Same implementation as BTC, if anybody feels it's really wrong then working on patches or proposals and submitting them to Bitcoin / Litecoin / Bitmark would be the thing to do.

Thanks!

well - everyone certainly has abandoned it now - good idea - bad implementation.

The Bitmark chain was configured to penalize inconsistent profit driven indirect mining of BTC.  In other words if the diff drops and price rises, and everybody greedly jumps on to mine the coin then abandons the network, the penalty is that the coins mined are not released until after the difficulty changes again.  This nullifies incorrect "profitability" calculations. Net effect is that if mining stays roughly consistent or varies slightly then people get their rewards fairly and timely, if they try to game the system by profit switching then they get rewards tied up until either price and demand rise 4x to meet the target network, or difficulty finally retargets, or indeed mining becomes steady and fair.

LOL - I hope the new wallet fixes this. I have coins mined back around Xmas of last year and they only have about 130 confirmations - with the current wallet it looks like it will be late August before they're confirmed....

seriously - this is laughable...

Thank you.  Cryptexplorer removed.  Blocktree.io added.

The network production cost and price on market have almost equalized, on the next difficulty retarget the network should become measurably more healthy.

Bitmark 0.9.4 is preparing for release this week.

Just trying to get an idea of where the project is and do appreciate all the time people volunteer. 

By the way, I try to help by providing Bitmark support on services such as coinwallet.co & blocktree.io - but I admit I have pulled bitmark from miningpool.co as too many people not familiar with the difficulty problem would come and waste half a day mining with no reward and complain. Sorry if that is too 'nooby' for you.

Also, the block explorer http://cryptexplorer.com/chain/Bitmark listed in the OP is not working. And the other http://bitmark.co:3000/ behaves strangely sometimes, often not showing any blocks. Welcome to add http://www.blocktree.io/e/BTM (graph is a bit bare as no block has been found for over 24 hours  )

I'd like to stress that the Bitmark difficulty issue is common to Bitmark, Bitcoin and Litecoin.  The solution being worked on, kindly and voluntarily, by leathan and dbkeys is a common to all of these coins and may or may not have a technical solution.  Many people including myself view it as a social issue rather than technical, or more accurately a trade off where other factors such as supply constraint and network security are given precedence over transaction confirmation time.

We are grateful for their hard work, however long it takes, and value their focus on getting alternatives right, tested, and reviewed before promoting something with unknown trade offs which are seen as detrimental or bigger issues.

Thank you dbkeys and leathan.

markpfennig: Okay, plan to move forward:

I'm going to start stubbing out each full system we need in github this week, and documenting them in markdown documents and inline comments in code.
This will provide everything needed for others to join in, some paid help has been organized, and any community members who want to help can just join in and add in functionality to methods as they can or as they feel confident that it isn't a wasted exercise.
From my own side, this will effectively lock down and make public the specification for all parts of marking, and stop me making endless revisions, design changes, new techs and so forth, and create measurable public progress.
It's no good me putting out disparate parts which nobody can use or see how they fit together, so this approach will be more agreeable to anybody who wants to join in or keep up with what's going on. It'll also remove the bottle-neck of "me" from the project whilst enabling me to work on it.
Once the stubbed applications are added, I'll start dropping in working code where I have it, and adding tests to important parts.
I'm not going to set any deadlines, but conversely will be starting this process tonight or tomorrow morning, and following it daily from there.  Will reach end deliverables as they are done.

[01:44] markpfennig: As  I get these stubbed projects in to github - which equates to the architecture and outer classes/functions of each application with test data, we'll have a clear "to-do" of components/files which are complete or not.  For each one of those we'll be able to split it in to tasks which can be open for community to do (community includes me), or they can be assigned to paid help where needed.



With zmark and such I'm not sure. Here's some chat from the #pfennig channel though:

tdokta: kgw could work fine, its seems to work well in the GMC network, blocks flow, BTM profit over litecoin is down at the moment so not as likely on the radar of large hashing,

potential to change the block time to reduce numbers produced per day ?

----- January 30th, 2015 -----

[08:37] dbkeys: Yes, changing the target block interval time makes sense. However, it should be dynamic, ie, now when hashrate is quite low on the network, we could target 10x slower blocks (ie, 20 minutes) and as the hashrate builds up, eventually target the "normal" 2 minute blocktime

[09:45] dbkeys: cause if the demand & hashrate climb up again alot, would rather not have to hardfork again, right ?

[11:55] tdokta: yes, do it once and do it right so there is not a problem. but who knows, before then it may just pick up by itself with users (edited)

[19:52] emdje: Chance that it fixes itself is quiet low I guess

----- January 31st, 2015 -----

[02:27] tdokta: at this point in time i agree.

[06:18] dbkeys: I looked into emdje's suggestion, and I think I have a fairly straightforward answer. Poisson random events have an exponential probability function between events, such that the probability that an event takes longer than _t_ minutes is  _e^(-L*t)_ where L=1/Expected_Interval_Time

[06:22] dbkeys: So that, for example, the probability that a block is found (assuming well adjusted difficulty for the hashrate available) in the target time (2 minutes for bitmark) is P(X <= t) = 1 - P(X >t) = 1 - e^(-L*t)

[06:23] dbkeys: which, plugging in the number for Expected blocktime interval = 2 minutes  is:

[06:24] dbkeys: 1- e^(-0.5*2) = 1-e^(-1) =0.63212 or 63.212 % chance

[06:26] dbkeys: if we want to say something like, if a block hasn't been found in "y minutes" that means that there is only a 0.1% chance that its due to the variability of the Poisson random process, (rather than decreased hashrate), then we can set an arbitrary threshold, say  that 0.1% = 0.001 = e^(-0.5 * t) and solve for t

[06:29] dbkeys: t = -[ ln (0.001) / (0.5) ] = 13.816 minutes

[06:30] dbkeys: In other words, if 13 minutes 49 seconds go by without a block, we can be 99.9% certain that it is due to a change in hashrate, if the blocks had been coming fairly regularly at the set difficulty

[06:31] dbkeys: If we wanted to be 99.999% certain, then the calculation would be:

[06:33] dbkeys: .00001=e^(-0.5*t), yielding t= -[ ln (0.00001) / 0.5 ] = 23.026 or 23 minutes  1.5 seconds

[06:37] dbkeys: A practical heuristic might be, if a block has not been found in 20 minutes, adjust difficulty downwards (how to make sure that peers on network are on same clock and how much to adjust to be determined)

[06:42] dbkeys: Emdje suggest that the most recent block interval time be used relative to the target block interval time to adjust difficulty.  A heuristic rule could be develped that measures how far off in terms of multiples of 13.8 or 23 minutes this blocktime is and adjust accordingly.

[07:49] leathan: very nice !

[07:50] leathan: cant wait to try them i i bet 13.8 is more practical but i have no idea

For people not closely involved with the Bitmark project, in simple terms, what development is currently going on and what is planned?

And what is the ETA for the fixed difficulty algo / zmark / DGW - whatever it is being called?

Thanks

I'm working on that right now.

The plan in short, is to "stub" out the three major component systems in github with documentation, then have the working code added by myself, paid team members, and whoever wishes to join in and commit some work.

A process which will start imminently.

Otherwise I will simply work on endless revisions, prototypes, second guess myself, and we'll never have anything delivered.  By stubbing out the frame of the project and filling it in, I, and we, are committed to a set path forward, and the documentation allows anybody to contribute without me being a bottleneck.

Organize and get people working on different parts of the project.

who have some to give me and hold
bQAqjCqbanZLcSYnHZEo8uFUB35azSJ4YA BTM

thank you