Bitcoin Forum
April 23, 2019, 03:10:13 PM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 [92] 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 ... 170 »
  Print  
Author Topic: Bitmark  (Read 607153 times)
Este Nuno
Legendary
*
Offline Offline

Activity: 826
Merit: 1000


amarha


View Profile
November 09, 2014, 01:44:31 PM
 #1821

Is there a block explorer for this?

Is this tx in the blockchain? 3c83a7337302f5460e0e36ec98a55adc02ba112ee620ff654b5862e12be9a0dc

Yes, and no. http://bitmark.co:3000/tx/3c83a7337302f5460e0e36ec98a55adc02ba112ee620ff654b5862e12be9a0dc

It appears to be there now.
1556032213
Hero Member
*
Offline Offline

Posts: 1556032213

View Profile Personal Message (Offline)

Ignore
1556032213
Reply with quote  #2

1556032213
Report to moderator
1556032213
Hero Member
*
Offline Offline

Posts: 1556032213

View Profile Personal Message (Offline)

Ignore
1556032213
Reply with quote  #2

1556032213
Report to moderator
1556032213
Hero Member
*
Offline Offline

Posts: 1556032213

View Profile Personal Message (Offline)

Ignore
1556032213
Reply with quote  #2

1556032213
Report to moderator
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, which will follow the rules of the network no matter what miners do. Even if every miner decided to create 1000 bitcoins per block, full nodes would stick to the rules and reject those blocks.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1556032213
Hero Member
*
Offline Offline

Posts: 1556032213

View Profile Personal Message (Offline)

Ignore
1556032213
Reply with quote  #2

1556032213
Report to moderator
dbkeys
Full Member
***
Offline Offline

Activity: 387
Merit: 101


View Profile
November 09, 2014, 03:58:16 PM
Last edit: November 09, 2014, 07:46:48 PM by dbkeys
 #1822

Well we had another diff drop today after nearly 5 weeks... A quick feeding frenzy at 488 diff and back to 1953.  Wait another 5 weeks, rinse and repeat.  It's great for restricting the supply of BTM but surely this cycle is not healthy in the long run.

I'm holding a considerable amount of BTM so the fewer coins the better for me, but I'm trying to look past that and consider the long term health of the coin.  It's nothing for whales to stop mining LTC for a few hours and pick up some easy BTM when the diff drops and then return to what they were doing earlier.  

Seriously, BTM needs to do *something* to better manage it's hashrate. I would be willing to put money into renting hash to regulate/pump the average hash if enough of us pooled together to make it worthwhile.  Short term pain for long term gain.  You can't go on forever having 1gh/s for 5 weeks and over 70gh/s for 5 hours and expect people to hang around.  

No miners = no perceived value = no real value..  I sometimes feel that as good a job as the dev team is doing, they are too involved with the future plans for BTM and not looking closely enough at the nuts and bolts of actually producing a viable coin that is attractive to both miners and end users.  After all, if not enough people are willing to mine the coin to give it value, it has no value.

Agree ... achieving the block generation rate which is specified is very important, because, like you say, its a "nuts & bolts" aspect of a coin.  If BTM is to gain wider traction and adoption, it has to be reliable and perform as advertised to gain the trust of users.  What hash rate is on the network should not have such dramatic impacts on the transaction confirmation delay times; after all, that is a big  point of having a difficulty number: it regulates the block generation rate in the face of whatever hash power is there. Bitmark charter post states it should be about 2 minutes, IMO, this should be regardless of the hash-mojo miners are putting on the network.

Transaction confirmation delay has been conflated with coin production/emission. This is necessarily so when blocks carry a fixed reward which doesn't change over a long period of time. (i.e., bitcoin's 4 year halving, or bitmark's somewhat more sophisticated formula, which halves every 3 years, with intermediate decreases every 18 months).

For transactions to process expediently, blocks have to be produced by network consensus at a rate which is not too slow, which is why most ( or all?) alt-coins have aimed for lower confirmation times = higher block-generation rates. As long as the difficulty is matched to a given network hash power, blocks will be generated at close to the target rate and so transactions confirmed without unexpected delay.

Hash power of the network varies for many reasons. Primarily because miners seek higher profits and move their hash power around different coins as market prices vary, but also for many other trivial reasons, such as power outages, new hardware, etc. From the point of view of a single coin network which seeks to serve its users consistently and expediently, responding and adapting dynamically to network hash power changes and achieving control of the block generation rate / transaction confirmation delay times ought to be a high priority.

The aspect of regulating coin emission rate (CER) could be separate from transaction confirmation time (TCT) by a more dynamic block reward formula. Think about the blocks as trains on a commuter line. A train should arrive every 2 minutes, like clockwork (thus satisfying the users with reliable 'transportation' = expedient transaction confirmations). But how many new coins the train brings could be variable, being revised periodically;  (most likely based on coin demand as measured by network hash-power).  This part clearly needs further thought and elaboration, as to how much  and how often to vary the block reward and satisfy the overall absolute limit on emission and other economic supply-demand laws, but my main point is that TCT should not be dependent on CER policies.
batesresearch
Legendary
*
Offline Offline

Activity: 1876
Merit: 1058


View Profile WWW
November 09, 2014, 07:06:04 PM
 #1823

There are some Bitmark pokerchips now available at http://cryptochips.net Smiley

https://twitter.com/Yakpimp/status/525709295909089280



Received our pokerchip, great delivery and amazing quality!

Fallen down the crypto rabbithole!
locohammerhead
Hero Member
*****
Offline Offline

Activity: 531
Merit: 500



View Profile
November 10, 2014, 03:37:39 PM
 #1824

Well I think it's been long enough that we can consider this Bitmark experiment a failed attempt.  Linking block confirmations in retrospect was an absolutely terrible idea and the hope of a fair payout was a nice thought but was poorly done as there was no fail safe included to make sure that the difficulty could not get raped into oblivion again and again and again, rinse and repeat.  Until that is fixed multipools and farms will continue to force the difficulty up to unreachable levels for the smaller guys and will keep bailing when they themselves are no longer getting confirmed coins.

I've been mining BTM on and off since the start and once farms and multipools showed up on the scene the problem was blatently obvious and nobody on this forum seems to be talking about it.  Everybody is obsessed with this marking layer project.  I have a little word of advice for everybody here. 

Marking will fail if mining fails. 

Get that straightened out first, then i will come back to mine.  The longer the difficulty stays at 1953 the lower the network hashrate will be and the slower blocks will come, turning BTM into a extremely rare coin that only mining farms etc are able to obtain.  Guess what?  They don't share their coins either.

Lets not try to run before we have stopped crawling here...

ethought
Legendary
*
Offline Offline

Activity: 1316
Merit: 1000



View Profile
November 10, 2014, 04:00:46 PM
 #1825

I do agree - multipool hopping and difficulty spikes are not good for the coin or general miners. It is not a major issue though as it is easily fixed.

I suggest we implement the Kimoto Gravity Well or something equivalent sooner rather than later.
btcney
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500


DateCoin - The HOTTEST ICO


View Profile
November 10, 2014, 04:44:11 PM
 #1826

Well I think it's been long enough that we can consider this Bitmark experiment a failed attempt.  Linking block confirmations in retrospect was an absolutely terrible idea and the hope of a fair payout was a nice thought but was poorly done as there was no fail safe included to make sure that the difficulty could not get raped into oblivion again and again and again, rinse and repeat.  Until that is fixed multipools and farms will continue to force the difficulty up to unreachable levels for the smaller guys and will keep bailing when they themselves are no longer getting confirmed coins.

I've been mining BTM on and off since the start and once farms and multipools showed up on the scene the problem was blatently obvious and nobody on this forum seems to be talking about it.  Everybody is obsessed with this marking layer project.  I have a little word of advice for everybody here. 

Marking will fail if mining fails. 

Get that straightened out first, then i will come back to mine.  The longer the difficulty stays at 1953 the lower the network hashrate will be and the slower blocks will come, turning BTM into a extremely rare coin that only mining farms etc are able to obtain.  Guess what?  They don't share their coins either.

Lets not try to run before we have stopped crawling here...
Yeah, the development and stuff are great but mining sucks right now.

dbkeys
Full Member
***
Offline Offline

Activity: 387
Merit: 101


View Profile
November 10, 2014, 06:19:49 PM
Last edit: November 10, 2014, 06:33:02 PM by dbkeys
 #1827

I do agree - multipool hopping and difficulty spikes are not good for the coin or general miners. It is not a major issue though as it is easily fixed.

I suggest we implement the Kimoto Gravity Well or something equivalent sooner rather than later.


   The Kimoto Gravity Well (KGW) and the Dark Gravity Wave (KGW) are two options. On first blush, it would appear that DGW is the clear choice, since KGW has a time-warp exploit
Quote
In concept, DGW is similar to Kimoto Gravity Well, adjusting the difficulty levels every block (instead of every hundreds of thousands of blocks like Bitcoin) by using statistical data of the last blocks found. In this way block issuing times can remain consistent, despite high fluctuations in hashpower. However it doesn't suffer from the time-warp exploit.

   This should fix the TCT issue (Transaction Confirmation Times), but without further refinement, would also increase the emission rate. It could be a good time to implement more dynamic variable block reward. The block reward (BR) is already programmed to decrease every 18 months, in order to asymptotically limit the absolute total emission. This absolute limit should be respected, but perhaps a more responsive formula can be found for BR which takes into account demand for the coin, thus addressing coinsolidation's concerns.
   I would suggest a limit on the maximum coin generation block reward from the existing formula (Halves every 3 years, with intermediate reductions every 18 months), but with reductions such that even with a consistent block-every-2-minutes generation rate, the emission matches the coin volume that has been generated daily on average recently (so no huge spike in coin production). Whatever this block reward number is, it can be increased according to demand (not sure how to measure demand, but it could be a function of the hash power of the network), up to the maximum of  the now-existing asymptotic limits (now 20, later 15, 12.5, 10, etc)
   Perhaps the low end should also be capped, just for completeness, at maybe no less than 2 coins
locohammerhead
Hero Member
*****
Offline Offline

Activity: 531
Merit: 500



View Profile
November 10, 2014, 06:25:24 PM
 #1828

Good to see the community taking my comments into account.  I will keep an eye to see if KGW or DGW is implemented.  Plan to start mining it again when that happens.

Thank you for your positive responses!

LittleOto
Newbie
*
Offline Offline

Activity: 2
Merit: 0


View Profile
November 10, 2014, 11:24:58 PM
 #1829

Thanks for all the updates and your hard work!  Cool
coinsolidation
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250

Bitmark Developer


View Profile WWW
November 11, 2014, 02:51:53 AM
 #1830

perhaps a more responsive formula can be found for BR which takes into account demand for the coin, thus addressing coinsolidation's concerns.

This is my primary concern, Bitmark is not being used yet, in the wild we do not have 14,000 BTM required for usage per day - floating currency, btm being used by people for a purpose.

When demand is low, production must slow.  Currently mining produces a much more reasonable ~500 BTM per day, a tiny percentage of the planned emission.  For the currency's longevity this must be maintained.  When demand raises, production will naturally increase to the planned emission.  Here is our BTM Supply: 922860 BTM, and we had planned: 1732540 BTM - there is 809680 less BTM in the world.

In the interim, we have a fixed block reward, and a very slow block time.  This serves it's purpose and limits emission.

If an alternative formula can be created which limits emission when demand is low, I would be very happy to discuss it.  I personally have not seen one, and cannot find one.

I would also invite discussion on whether confirmation time is an issue or not,  I know for a fact that outside of a few people trading, the only usage of BTM is to pay for hosting at Crypto Cloud Hosting, and they do not mind the slow confirmation.  Thus, I ask, who are the slow confirmations actually affecting?

I would suggest that the issue is that currency mined now at such a slow speed has a production cost higher than market price-tag, and that the market price-tag when the currency is spendable (in a few weeks time!) simply is not known.  It is unknown, therefore possible that people mining now at a perceived loss, may in fact break even, make a loss, or make a profit.

There are two reasons to mine:
1: it is your service, if this is the case mine consistently as a service along with your fellow miners, take a small loss some times and a small profit others, so that it averages out profitable, choose the optimal time to sell.
2: you want BTM, if this is the case, you will always receive BTM when you mine BTM, if you believe it has merit then you know that it will be worth having.

Sincerely, I understand that you may be mining at a perceived loss, and that it can be a worry, and I thank those high difficulty miners who have persisted for their support.  Your support has been a huge help to the community, it's kept the blocks moving, but crucially, it has enabled us to maintain a very slow production rate when demand is lower, which has prevented BTM from going in to the all too familiar death spiral that happens when emission remains high regardless of demand.  Thank you.

Bitmark (reputation+money) : Bitmark v0.9.4 (release)
Este Nuno
Legendary
*
Offline Offline

Activity: 826
Merit: 1000


amarha


View Profile
November 11, 2014, 08:38:38 AM
 #1831

In short, I think everyone would agree that if there were an algorithm that could capture the dynamic supply based on demand issue and keep the target time at two minutes then assuming the algorithm was thoroughly tested and proven stable we would use it.

But something like this has been a 'holy grail' PoW algo for a long time and I don't think there is even such an algo in an alpha testnet phase, let a alone ready for production.

If something like this can be done it would be awesome, and be a big breakthrough in cryptocurrency. If people want to start a project designing such an algo and testing it out on a new Pfennig chain, I'd support the project as best I can.
dbkeys
Full Member
***
Offline Offline

Activity: 387
Merit: 101


View Profile
November 11, 2014, 02:06:04 PM
Last edit: November 12, 2014, 02:17:12 PM by dbkeys
 #1832

   One thing I can say as a small miner is that it's just boring to have nothing happen for days as your rig whirrs away.  I wouldn't mind a one-week or a one-month (real-time) new mint coin maturity time, for example, as much as "work-work-work and nothing happens". Or even running sometimes at a small loss to support the coin and its network. It's just having nothing happen that's no fun  Undecided ...

   As far as I can tell, most of the discussions I have read about difficulty and difficulty adjusting algorithms also conflate transaction confirmation delay  with coin emission rate. This is necessarily so until different algorithms regulate 1) The clockwork "nut & bolts" of how often blocks are found="block generation rate"  and 2) how many new coins are rewarded on each block="coin emission rate".
   We all seem to agree that users want to get their transactions confirmed in a reasonable amount of time, and that, in this regard, faster is better. (Faster confirmation times than BTC's 10 minutes have been a "selling" point of alt-coins since the 1st alt). So an algorithm like DGW or KGW which keeps tight control of the block production rate enforces a maximum transaction delay time and keeps the blocks coming like clockwork is desirable ... as long as ...new coin emission is in some way commensurate with demand for the currency, so that there is no overproduction and thus no dreaded value death spiral.
  
    
   Here are links to what I'm reading to save some googling for others who might want to help out with this:
ethought
Legendary
*
Offline Offline

Activity: 1316
Merit: 1000



View Profile
November 11, 2014, 02:09:57 PM
 #1833

In short, I think everyone would agree that if there were an algorithm that could capture the dynamic supply based on demand issue and keep the target time at two minutes then assuming the algorithm was thoroughly tested and proven stable we would use it.

But something like this has been a 'holy grail' PoW algo for a long time and I don't think there is even such an algo in an alpha testnet phase, let a alone ready for production.

If something like this can be done it would be awesome, and be a big breakthrough in cryptocurrency. If people want to start a project designing such an algo and testing it out on a new Pfennig chain, I'd support the project as best I can.


I don't think a 'demand' based algo is possible without centralizing to some extent.

How do you even really determine demand anyway? Presumably a higher demand causes the price to increase. And a lower demand causes the price to drop. Hence the only way to really make an educated guess as to the current demand of bitmark is through its price or buy / sell volumes.

The only way the code could determine the movement of price and volumes would be running through a dedicated bitmark price api - or directly to exchange apis. Both are fraught with problems - for example what if the bitmark price api was DDOSed. Plus on a relatively thin market this is easily gamed. Sell down hard, drop difficulty then mine up more blocks etc...

I think there are reasons that the current difficulty algos are in place - because they work and are more or less fail safe. The KGW works very well and to this date I am unaware of anyone successfully exploiting the time warp issue.

When demand is low, production must slow.  Currently mining produces a much more reasonable ~500 BTM per day, a tiny percentage of the planned emission.  For the currency's longevity this must be maintained.  When demand raises, production will naturally increase to the planned emission.  Here is our BTM Supply: 922860 BTM, and we had planned: 1732540 BTM - there is 809680 less BTM in the world.

Agreed, a slower release of coins would be better. However this is only currently happening by mistake not by intent.

Would it not be better to intentionally drop the block reward and fix the difficulty swings? Then mining would be more consistent, and multipools / centralized farms would not have the advantage. I have seen this in many coins before and the KGW (or some variant) fixes the problem very well.

I would also invite discussion on whether confirmation time is an issue or not,  I know for a fact that outside of a few people trading, the only usage of BTM is to pay for hosting at Crypto Cloud Hosting, and they do not mind the slow confirmation.  Thus, I ask, who are the slow confirmations actually affecting?


If confirmation times are very slow new services will not come on board. So this is a circular argument to some extent. There are no services so why does confirmation time matter? New services will not come because the confirmation times are too slow... etc etc.

Not trying to troll, I just think all these problems - the difficulty swings, block rewards and confirmation times can be fixed with a very simple update. Add the KGW and drop the block reward. I would hate for these very minor, yet annoying, issues to get in the way of the great goals and progress bitmark is making on the marking project etc.


locohammerhead
Hero Member
*****
Offline Offline

Activity: 531
Merit: 500



View Profile
November 11, 2014, 04:05:55 PM
 #1834

perhaps a more responsive formula can be found for BR which takes into account demand for the coin, thus addressing coinsolidation's concerns.

This is my primary concern, Bitmark is not being used yet, in the wild we do not have 14,000 BTM required for usage per day - floating currency, btm being used by people for a purpose.

When demand is low, production must slow.  Currently mining produces a much more reasonable ~500 BTM per day, a tiny percentage of the planned emission.  For the currency's longevity this must be maintained.  When demand raises, production will naturally increase to the planned emission.  Here is our BTM Supply: 922860 BTM, and we had planned: 1732540 BTM - there is 809680 less BTM in the world.

In the interim, we have a fixed block reward, and a very slow block time.  This serves it's purpose and limits emission.

If an alternative formula can be created which limits emission when demand is low, I would be very happy to discuss it.  I personally have not seen one, and cannot find one.

I would also invite discussion on whether confirmation time is an issue or not,  I know for a fact that outside of a few people trading, the only usage of BTM is to pay for hosting at Crypto Cloud Hosting, and they do not mind the slow confirmation.  Thus, I ask, who are the slow confirmations actually affecting?

I would suggest that the issue is that currency mined now at such a slow speed has a production cost higher than market price-tag, and that the market price-tag when the currency is spendable (in a few weeks time!) simply is not known.  It is unknown, therefore possible that people mining now at a perceived loss, may in fact break even, make a loss, or make a profit.

There are two reasons to mine:
1: it is your service, if this is the case mine consistently as a service along with your fellow miners, take a small loss some times and a small profit others, so that it averages out profitable, choose the optimal time to sell.
2: you want BTM, if this is the case, you will always receive BTM when you mine BTM, if you believe it has merit then you know that it will be worth having.

Sincerely, I understand that you may be mining at a perceived loss, and that it can be a worry, and I thank those high difficulty miners who have persisted for their support.  Your support has been a huge help to the community, it's kept the blocks moving, but crucially, it has enabled us to maintain a very slow production rate when demand is lower, which has prevented BTM from going in to the all too familiar death spiral that happens when emission remains high regardless of demand.  Thank you.

"I would also invite discussion on whether confirmation time is an issue or not." 

It's an issue if you are not a mining farm or multipool who can't mine the blocks fast enough to confirm.  Waiting an entire month for 60-80 BTM is fucking absurd.  If you think that's a good idea, you clearly don't understand supply and demand.  Want to know why bitmark is only used to purchase web hosting?  It's because people can't get their mined bitmark to actually use!

Also if you notice the slow block times are not having the effect in price that you believe will happen.  This is due to dropping consumer confidence in the coin because people can't get their BTM.

If you have the hashrate to blow through 720 blocks then the slow confirms won't seem like much to you but if you don't you arn't operating at a "small loss".  The amount of time, energy and resources poured into mining actually comes out to a pretty substantial loss.

Este Nuno
Legendary
*
Offline Offline

Activity: 826
Merit: 1000


amarha


View Profile
November 11, 2014, 04:39:05 PM
 #1835

perhaps a more responsive formula can be found for BR which takes into account demand for the coin, thus addressing coinsolidation's concerns.

This is my primary concern, Bitmark is not being used yet, in the wild we do not have 14,000 BTM required for usage per day - floating currency, btm being used by people for a purpose.

When demand is low, production must slow.  Currently mining produces a much more reasonable ~500 BTM per day, a tiny percentage of the planned emission.  For the currency's longevity this must be maintained.  When demand raises, production will naturally increase to the planned emission.  Here is our BTM Supply: 922860 BTM, and we had planned: 1732540 BTM - there is 809680 less BTM in the world.

In the interim, we have a fixed block reward, and a very slow block time.  This serves it's purpose and limits emission.

If an alternative formula can be created which limits emission when demand is low, I would be very happy to discuss it.  I personally have not seen one, and cannot find one.

I would also invite discussion on whether confirmation time is an issue or not,  I know for a fact that outside of a few people trading, the only usage of BTM is to pay for hosting at Crypto Cloud Hosting, and they do not mind the slow confirmation.  Thus, I ask, who are the slow confirmations actually affecting?

I would suggest that the issue is that currency mined now at such a slow speed has a production cost higher than market price-tag, and that the market price-tag when the currency is spendable (in a few weeks time!) simply is not known.  It is unknown, therefore possible that people mining now at a perceived loss, may in fact break even, make a loss, or make a profit.

There are two reasons to mine:
1: it is your service, if this is the case mine consistently as a service along with your fellow miners, take a small loss some times and a small profit others, so that it averages out profitable, choose the optimal time to sell.
2: you want BTM, if this is the case, you will always receive BTM when you mine BTM, if you believe it has merit then you know that it will be worth having.

Sincerely, I understand that you may be mining at a perceived loss, and that it can be a worry, and I thank those high difficulty miners who have persisted for their support.  Your support has been a huge help to the community, it's kept the blocks moving, but crucially, it has enabled us to maintain a very slow production rate when demand is lower, which has prevented BTM from going in to the all too familiar death spiral that happens when emission remains high regardless of demand.  Thank you.

"I would also invite discussion on whether confirmation time is an issue or not."  

It's an issue if you are not a mining farm or multipool who can't mine the blocks fast enough to confirm.  Waiting an entire month for 60-80 BTM is fucking absurd.  If you think that's a good idea, you clearly don't understand supply and demand.  Want to know why bitmark is only used to purchase web hosting?  It's because people can't get their mined bitmark to actually use!

Also if you notice the slow block times are not having the effect in price that you believe will happen.  This is due to dropping consumer confidence in the coin because people can't get their BTM.

If you have the hashrate to blow through 720 blocks then the slow confirms won't seem like much to you but if you don't you arn't operating at a "small loss".  The amount of time, energy and resources poured into mining actually comes out to a pretty substantial loss.

But that's not true at all. None of the third parties who are currently working on establishing services based around marking have expressed much of a concern(if any at all) about the current network speed. In fact the only people as far as I know who have voiced any concern at all are miners. And I sympathize with them.

People can buy BTM right now on an exchange. People who are targeted to use marking and through that BTM aren't going to know or care what a 720 block confirmation time is.

The price has gone down over the last little while because there's little demand. There's little demand now because all of our projects focused on creating demand are still in development. Not because of any mining issues.
Este Nuno
Legendary
*
Offline Offline

Activity: 826
Merit: 1000


amarha


View Profile
November 11, 2014, 04:43:16 PM
Last edit: November 11, 2014, 04:53:52 PM by Este Nuno
 #1836

[20:44] dbkeys: So wondering why DGW or KGW was not implemented from the get-go since it seems to be a fairly standard feature on recent alt-coins

[20:50] amarha: it was suggested at the time by some

[20:51] amarha: mark wanted to only put proven tech in the core to start out with. and at the time KGW was known for having an expolit.

[20:54] dbkeys: DGW came later I suppose ...

[20:54] amarha: i think it was around then

[20:55] amarha: but wouldn't have have met mark's criteria as something that's been proven over time. especially as KGW had failed.

[20:59] dbkeys: New alt coins like bitmark are living in a different environment than when bitcoin started out. What worked for bitcoin and the early alts might not apply because so much more hash power is in existence and can be switched to different coins in minutes. The extremely slow adaptive diff algo of bitcoin served it because it was years for bitcoin to gain any traction. Simple CPU's were ok in the beggining

[20:59] dbkeys: and as ASIC came online (a process of many months if not years) the slow diffalgo was able to cope

[21:00] amarha: yeah, it was a different time. no alternatives existed then.

[21:00] amarha: this is a different situation i agree

[21:00] dbkeys: OK, bye for now, have to travel, will check in 8 - 10 hours from now.

[21:00] amarha: see you then :simple_smile:

[21:55] emdje: Why is DGW no option then?

[22:01] amarha: probably because it isn't or wasn't a proven technology

[22:01] amarha: and it also doesn't slow production

[22:01] amarha: it keeps production steady

[22:02] amarha: which is not good

[22:02] amarha: look at the drama now with monero

[22:02] emdje: Or maybe something similar as now. I don't know if it exists but I was thinking of a sort of 'two factor' retargeting. The mayor 720 block retarget would stay the same (average time of 720 blocks is used to determine new difficulty), but in between there are 9 smaller retarget points of 72 blocks. Maybe when it  takes 20% more or less time than it should that block is retargeted by 7.5% or something. (when all 9 smaller blocks are retargeted downwards this means a total correction of -50.42 %, when upwards a total correction of +91.7%) It still keeps production slow.

[22:02] emdje: the 10th block is then again the large retarged moment

[22:02] amarha: i was saying in the thread that maybe we can start up a pfennig clone and test some new tech out

[22:03] amarha: i can't offer much in the technical department though unfortunately

[22:03] amarha: but i'm interested in the idea

[22:06] emdje: Well cloning a coin is one step to far for me

[22:07] emdje: But maybe some simulating with existing data

[22:07] emdje: or virtual data

[22:10] amarha: the thing is that markpfennig's philosophy here from the start is not to implement anything until it's proven stable

[22:10] emdje: When all blocks would retarget downwards the 9th small block would retarget to 968,3810026. I would imagine that that difficulty is much more 'profitable' and attractive to miners

[22:10] amarha: we had previously toyed with the idea of creating a pfennig clone that we would push new tech in and see what worked well

[22:11] emdje: yes I understand but letting the project die a slow death, which I think it will if the hashswings will stay like this a couple of times is not 'stable' as well

[22:11] emdje: or manually retarget to lower value, nothing has to change

[22:11] amarha: the only issue we had was more of a moral one, that the coin would have no future as just a little brother to bitmark

[22:12] amarha: as of now since no one is using it there's nothing to kill

[22:12] amarha: the question is what will happen when people start to use it

[22:12] emdje: with block conformation times like this I don't see people using it

[22:12] amarha: mark thinks that demand will stablise the mining

[22:13] amarha: people use marks off chain though so it shouldn't have any effect in the short run

[22:13] emdje: demand is not produced out of thin air

[22:13] amarha: demand is going to come from products like markthis, the music website, the festivals ect

[22:13] emdje: correction, mining demand is not produced out of thin air :wink:

[22:13] emdje: you need mining

[22:14] emdje: I have been mining at a loss for 2 months now (high energy prices), so I had to stop mining BTM

[22:16] amarha: i understand, and that's unfortunate that it has to be like this. i think it's very inconvenient. but the alternative, say DGW, is going to cost people even more money. would wipe six figure amounts off the market cap in no time.

[22:16] emdje: Yes I think that is true

[22:16] amarha: it's either wait and see how demand effects the mining

[22:17] amarha: or do something drastic that will likely kill BTM(in my opinion). also i doubt many people who have been holding BTM are going to support the change. so the fork would likely fail anyway.

[22:18] amarha: right now isn't so important. but soon it will be. if the network isn't self fixing with demand, then there will be a real problem and we will be forced to change it.

[22:18] amarha: but right now there isn't a known algo that's going to limit production.

[22:19] amarha: we will actually have to design and test a new algo from the ground up on a new chain.

[22:19] emdje: People are starting to talk about the 'problem', so I think it will be a problem sooner than you might realize

[22:19] amarha: i agree it's a problem, but it's just that the alternative is probably worse.

[22:20] amarha: you and dbkeys both have interesting ideas about algos. but as far as actual existing solutions, i don't know of any.

[22:20] emdje: alright well keep my 'two factor' retarget concoction in mind

[22:21] emdje: mine is sort of an existing one\

[22:21] emdje: but double

[22:21] amarha: other than going PoS which i highly doubt would be supported by mark or many others since it's not really fully vetted yet.

[22:22] amarha: i definitely am interested in testing some new algos somehow at least. because we should also be prepared for the possibility that demand comes and the network doesn't fix itself.

[22:22] amarha: a plan b

[22:24] amarha: mark expects it to fix itself, i default to his experience and knowledge.

[22:24] amarha: i don't feel anything is guaranteed though

[22:28] markpfennig: We keep working and successfully lift demand, price-tag rises, mining at high diff becomes profitable.  Or, we keep working and fail, price-tag lowers to the point that low diff is optimal.

[22:29] markpfennig: it's not really anything to do with me, that's just the way it works.

[22:29] markpfennig: BTC is designed the same.  This will happen to BTC if the hashing reduces.

[22:30] androidicus: For my pfennig's worth - I mined BTM solidly from launch until about 2-3 weeks ago - I consider myself one of the _least_ short term / profiteering, P&D miners around... Since Dec 2013, I have picked a currency that I feel had/has value and mined and held whilst doing a bit of margin trading for fun. But even I have (being frank and transparent) had to 'duck & dive' a bit over the past few weeks owing to power costs etc. But I will return to mining BTM again shortly because I am an absolute believer in 'supporting the network' - with my power costs effectively being my fiat investment.

[22:34] markpfennig:
>i agree it's a problem, but it's just that the alternative is probably worse.

[22:36] markpfennig: that sums it up, there is no perfect, there's a design decision with trade offs.  1) have production slow when demand is low, 2) have uncontrolled production and consistent block times.
marking is off chain, slow chains don't stop us marking here or on polo,  slow chains become a problem when there are 2 or more well used marking implementations and a couple of services/shops accepting btm,  if that usage hasn't lifted demand, we have a problem.  If it does lift demand, we don't.

[22:36] markpfennig: That said, I did think of a potential alternative algo last night.

[22:37] androidicus: shudders :simple_smile: (edited)

[22:38] amarha: bitmark miners are on strike :stuck_out_tongue:

[22:39] androidicus: bring back Arthur Scargill :simple_smile:

[22:39] markpfennig: Proposal (would need tested first of course):
The network calculates the highest ever average hashrate, and the current hashrate, it sets the block reward to be max-block-reward/(high-hashrate/current-hashrate) and sets diff according to current average hashrate, say over xxx blocks so it smoothly changes (edited)

[22:39] markpfennig: net

[22:39]  markus: Block: 46154 Target: 69.91 GH/s, Hashrate: 1.79, 1.30, 1.52 GH/s, Performance: 3.04%
Diff: 1953.30771918, next: ~488 (confidence 10%) - Last Retarget: 80.98 hrs ago, change in 646 blocks (~708.33 hrs)

[22:40] markpfennig: 20/(69.91/1.52) (edited)

[22:41] markpfennig: 20/(69.91/1.52)

[22:41] markpfennig: 0.4348448 BTM per block

[22:41] amarha: highest ever average hash over what sample?

[22:41] markpfennig: if that went for a day, 720 blocks: 313.08825633 BTM today

[22:41] emdje: ''ever', so all blocks

[22:42] markpfennig: @amarha: same calculation as done currently, but taking in to account history too, so all sets of 720 blocks, which one had the highest overall hashrate, take that as sample

[22:43] markpfennig: currently we use the last 720 blocks only

[22:43] amarha: sounds interesting
NEW MESSAGES

[22:44] emdje: This does not affect the difficulty, only the block maturity. Meaning that the hash swings would stay the same but now the multipools have their coins much sooner?

[22:45] markpfennig: It would affect the block reward, in a situation where the difficulty changed much more adaptive,  e.g. kgw/dgw

[22:46] markpfennig: it's a measure of demand, current-hashrate = demand now, all time high hashrate = highest demand

[22:46] markpfennig: e.g. control the supply when the diff is low, today we'd have fast blocks under this, 2 minute average, but only 313 BTM created.

[22:46] androidicus: Interesting - I'm no expert on the math so respect the judgement of others...

[22:47] markpfennig: It doesn't really make sense TBH

[22:48] markpfennig: It would do as advertised above, but...

[22:48] dbkeys: at airport, couldn't resist peeking in ... I think two algorithms are needed

[22:48] dbkeys: we should stop conflating transaction confirmation delay with coin production

[22:49] dbkeys: crank the blocks out like clockwork (as much as possible) BUT vary the block reward according to some formula (algorithm 2)

[22:49] markpfennig: @dbkeys: the above does that

[22:49] markpfennig: Proposal (would need tested first of course):
The network calculates the highest ever average hashrate, and the current hashrate, it sets the block reward to be max-block-reward/(high-hashrate/current-hashrate) and sets diff according to current average hashrate, say over xxx blocks so it smoothly changes

[22:50] emdje: so two formulas

[22:50] markpfennig: if that went for a day, 720 blocks: 313.08825633 BTM today (  720 * 20/(69.91/1.52) )

[22:50] emdje: I get it now, would be good option

[22:52] androidicus: So this will be a config change - not algo change? i.e. Scrypt > X-Algo?

[22:53] emdje: Algo change would mean no asic miners, don't think people would agree to that

[22:54] dbkeys: how is hash rate determined  ??

[22:54] androidicus: Just that:
>Algo change would mean no asic miners, don't think people would agree to that

[22:54] dbkeys: I don't think this changes the cryptographic summered (hash function) at all emdje ...

[22:55] androidicus: That is what I am assuming...

[22:55] emdje: don't think so as well, or yes assuming

[22:55] dbkeys: meant "summary" not summered !

[22:55] androidicus: Which I shouldn't - assume, that is

[22:55] emdje: because mark deliberately choose scrypt to include asics

[22:55] markpfennig: @dbkeys: hash rate isn't determined, hashrate is a fact,  by looking at the difficulty you get a target hashrate, then you look at how quickly blocks are created under that difficulty to determine if the target-hashrate is too high or too low

[22:56] markpfennig: miners set the difficulty with their own hashrate

[22:57] markpfennig: @emdje: it's not a mining algo change, it's a diff algo change, ASICs would still work

[22:57] emdje: But if you retarget every xxx blocks you would average xxx blocks and not take  just the last one, hashrate whise right

[22:57] emdje: ok

[22:57] dbkeys: but hash functions have a degree of randomness, in, fact that is a design goal, therefore the "luck" in mining. I could find a block on the first try with an 8086 cpu... unlikely, but possible

[22:57] emdje: If you would just take the last one, someone with large hashing power could abuse that, by not mining that last block

[22:57] dbkeys: KGW and DGW look back a certain number of blocks, but give proportionally greater weight to closer blocks

[22:58] markpfennig: the last blocks hashrate isn't right, blocks are found at random times, on average meeting the average set (2 minutes).  So to set difficulty more frequently you just set it to change every 20 blocks say, but still considering the average over the last 720, so it lifts and falls smoothly

[23:00] dbkeys: also, when chain forks, hash rate is reduced in some proportion, until the contest is decided

[23:02] dbkeys: so @markpfennig you are saying that for any given difficulty (number of leading zeroes in the hash) there is an ideal hash rate that will find that target in the desired time (or desired block generation rate)

[23:03] markpfennig: yes, that's what difficulty is..

[23:03] markpfennig: net

[23:03]  markus: Block: 46154 Target: 69.91 GH/s, Hashrate: 1.79, 1.30, 1.52 GH/s, Performance: 3.04%
Diff: 1953.30771918, next: ~488 (confidence 10%) - Last Retarget: 80.98 hrs ago, change in 646 blocks (~708.33 hrs)

[23:03] markpfennig:
> Block: 46154 Target: 69.91 GH/s,

[23:03] markpfennig: http://api.bitmark.co/

[23:03] markpfennig: "difficulty": 1953.30771918,
       "target": 69911606440,

[23:04] markpfennig: BTC, BTM many others, all do it this way

[23:04] markpfennig: well.. that's what difficulty IS

[23:04] dbkeys: boy, I wish there are an "-h" (human readable) option for those big numbers :wink:

[23:04] markpfennig: 69.91 GH/s

[23:04] markpfennig: lol

[23:05] markpfennig: there is a slight problem with the new proposal

[23:06] dbkeys: conversely, given a hash rate (what is really out there in the network) there is an ideal difficulty that will (on the average) produce blocks in the desired time

[23:07] markpfennig: yes.. diff calculation allready work, if we had it changing every 24 blocks instead of 720 it would change much more smoothly and "correctly"

[23:07] markpfennig: but emission would be wildly wrong.

[23:07] markpfennig: unless a proposal like the above was in

[23:08] markpfennig: however, consider day 1-10, what's the incentive to add more hashing?

[23:08] dbkeys: right, then the TCT algo is mostly ok, but the emission / coin generation part of it is conflated with the TCT

[23:08] markpfennig: if you add more hashing, the block reward over time reduces, so it's not profitable, no reason to do it (edited)

[23:09] dbkeys: yes, it should be the other way. The more hashmojo is out there, the reward should increase, because there is more demand

[23:09] markpfennig: well.. no because on day one there's no all time high, other than one you set as a default

[23:09] markpfennig: so, work with me here

[23:09] markpfennig: day 1

[23:10] markpfennig: why would a new miner come on board?

[23:10] dbkeys: There would have to be endpoint absolutes.

[23:11] dbkeys: never more than 20 BTM reward or whatever the ultimate asymptotic limit as per the current block reward reduction formula is

[23:11] dbkeys: and perhaps never less than 1 or 2 or 3 BTM

[23:12] markpfennig: yes, never more than 20, we'd need that to cap emission at 14400 per day roughly

[23:12] dbkeys: yup, the ultimate appeal of the block reward formula is that it avoids inflation or in dollar fiat terms, QE1, QE2 and QEinfinity

[23:13] dbkeys: 85 billion new dollars every month ... :O

[23:14] dbkeys: but allow for more temporal-local variability to adjust supply for the demand and not over-produce

[23:16] markpfennig: the proposed algo has inherent in it that the highest ever average hashrate was profitable, and everything under it is unprofitable.

[23:17] markpfennig: any hash rate under all time high will always be unprofitable for miners (or perceived as)

[23:18] dbkeys: so the block rate probably should be changed every 24 or fewer blocks, (railcars in the train arriving like clockwork) but the payload (how many new coins each block brings) should be adjusted with a different criteria, probably the 720 or more blocks

[23:18] markpfennig: let's cut to the real problem
miners are mining at what they calculate as a loss,  1.5 GH is only producing 320 BTM per day.
under the new algo,  1.5 GH/s is only producing 320 BTM per day.

[23:19] markpfennig: still a loss

[23:19] dbkeys: but it means transactions are confirmed without unexpected delay

[23:19] dbkeys: and that spurs adoption of the currency and so more value

[23:19] dbkeys: surely an improvement

[23:19] emdje: Did you read my 'two factor' retarget idea, where in between the large retarget block there are 9 smaller ones to correct it slowly?

[23:20] emdje: what do you think about that?

[23:21] dbkeys: yes, saw that but have to ponder it a bit ... a lot of new info here for me :simple_smile:

[23:22] markpfennig: there is an improvement @dbkeys to one problem, but it creates a new one, mining is never ever profitable, there is no incentive to joining the network or improving hardware or anything

[23:22] dbkeys: In general, see two goals here: 1) reliable transaction confirmation delay and 2) emission commensurate with demand (in some fashion) so value is not destroyed by overproduction

[23:22] markpfennig: any hashing added only makes BTM harder to mine

[23:24] dbkeys: have to find an algo that addresses that in #2 above ... more hash power ... larger rewards ?

[23:24] emdje: which means that if you want more btm you need a larger fraction of that hashpower

23:25] dbkeys: so you add hash power, net in strengthened and algo #2 increases rewards (up to the limit)

[23:26] markpfennig: why would you add hashing when it isn't profitable?

[23:27] markpfennig: is hashing profitable today: no, would it be under new algo: no

[23:27] dbkeys: if there is demand that means the value of the coin is going up, why wouldn't it be profitable

[23:27] dbkeys: ?

[23:28] markpfennig: consider:

[23:28] dbkeys: hate to go, have to board plane :confounded:    please save discussion for later digestion :innocent:

[23:29] emdje: There is wifi on the plane right :stuck_out_tongue:

[23:29] markpfennig: day 45, hashrate 5GH/s producing  14400 BTM per day at average profitability
I add 100 GH/s for 2 hours.
day 46, hashrate 5GH/s producing 720 BTM per day, at a (1/20th profitability) loss. (edited)

[23:30] markpfennig: everybody adds 45 GH/s between them, a 10x hash increase

[23:30] markpfennig: day 47 hashrate 50 GH/s producing 7200 BTM per day at loss (half profitability)

[23:31] markpfennig: there's zero incentive to add hashing

[23:32] markpfennig: so by the single add 100 GH/s action of one miner,  BTM would be unprofitable until the price on market hit 20x higher than it currently was

[23:32] markpfennig: and when that happens, I come back with another 100 or 200 GH/s

[23:32] markpfennig: repeat problem

[23:33] markpfennig: 99.9% of the time mining would be unprofitable, in a more exaggerated form of what happens today

[23:33] markpfennig: today we can go 4x max on diff, under this as it smoothly change, it can go 1000x in a day (edited)

[23:35] markpfennig: regardless, anything like this we could try with an alt - I'd say test chain but it'd need to be alt chain with market to get the demand aspect and see how the two worked together

[23:35] markpfennig: which detracts time from the project

[23:35] markpfennig: (if I do it)

[23:35] markpfennig: so somebody else may need to

[23:36] markpfennig: currently, as we know from BTC, if you have demand the network stays profitable to mine and blocks roll out on average

[23:36] markpfennig: our goal here, is to create a project with demand and currency with usage, so that BTM is the same

[23:37] markpfennig: rather than tweaking things so the network is perceived as working when the project isn't

[23:37] markpfennig: 99% of alts are dead because of no demand (usage), no amount of changing algos or calculations will change that, for them, or for us.

[23:39] littleoto: joined #general

[23:39] androidicus: I cannot say that I disagree with that analysis!

[23:42] markpfennig: fact is, if we create real demand, it will work.
for example when the events or music project need their BTM, they buy a chunk on market, lifting the price, and taking that BTM out of the market and in to circulation / floating currency being used by people.  that lifts price, makes mining cost effective, hashrate returns

[23:43] markpfennig: as soon as high diff is profitable, we're out of the loop

[23:44] markpfennig: price would have to go up 200% or more above that high diff price to make the network spike at 4x our high diff,  such rises from our highs likely won't happen, it'll be more gradual (edited)

[23:47] markpfennig: aside: do remember this is BTC algo, BTC changes every 2 weeks with a 10 minute target, if their hashrate started to drop it'd quickly become unprofitable causing an exodus.  If BTC dived 20x on hashrate it'd take about a year to retarget. (edited)

[23:48] markpfennig: forcing two things: 1 - off chain transactions,  2- limiting supply until demand pushed price up to make miners return

[23:48] markpfennig: (our situation now)
johndec2
Sr. Member
****
Offline Offline

Activity: 352
Merit: 250


View Profile
November 12, 2014, 11:53:58 AM
 #1837

The above is all very interesting and illuminating but the one miner that was carrying the nethash through thick and thin, nicos, has dropped back from over 1 gh/s to around 200mh/s and no one can blame him for doing so.  Current nethash is roughly 350mh/s. That means 3 to 4 blocks a day at the current diff.  720/4 = 180 days (6 months) till the next diff change.

"Houston, we have a problem"........
Hulk Hobo
Newbie
*
Offline Offline

Activity: 57
Merit: 0


View Profile
November 12, 2014, 10:20:09 PM
 #1838

The above is all very interesting and illuminating but the one miner that was carrying the nethash through thick and thin, nicos, has dropped back from over 1 gh/s to around 200mh/s and no one can blame him for doing so.  Current nethash is roughly 350mh/s. That means 3 to 4 blocks a day at the current diff.  720/4 = 180 days (6 months) till the next diff change.

"Houston, we have a problem"........

Only if you're a miner and only in the short term. If (and it's a big if), marking is proven as a concept and goes viral, demand and prices go up and hash will follow price. This emission rate ensures that miners don't dump prices into oblivion as demand for BTM is just not there yet.
tdokta
Full Member
***
Offline Offline

Activity: 159
Merit: 100


View Profile
November 13, 2014, 06:14:44 AM
 #1839

The above is all very interesting and illuminating but the one miner that was carrying the nethash through thick and thin, nicos, has dropped back from over 1 gh/s to around 200mh/s and no one can blame him for doing so.  Current nethash is roughly 350mh/s. That means 3 to 4 blocks a day at the current diff.  720/4 = 180 days (6 months) till the next diff change.

"Houston, we have a problem"........


yes, nicos dropped down a lot as we have had a power surge and lost the power supplies to several of the machines, they are soon to be back online, although it will be difficult to continue with our full strength on BTM as market price is down and we need to cover costs, so some of our machines will be pointed elsewhere for this purpose. ... if BTM raises over us50c then it becomes cost covering for us, this is the minimum level that we need to maintain mining full time on BTM ,, but as suggested, 6month wait for coin release is a little too long, hopefully viral marking implementation or something significant happens before then and the network increases to a tangible level.
melvster
Sr. Member
****
Offline Offline

Activity: 350
Merit: 250


View Profile
November 13, 2014, 02:23:31 PM
 #1840

Since this coin has reached it's Q1 first quarter today, I thought I'd give a mini update from a developer perspective.  It's just my own personal view, and does not necessarily reflect view of others or the community.

I've been on this project for just over a month and first of all it's been a lot of fun.  First of all thanks to everyone that has taken part, particularly coinsolidation, who I am amazed has not collapsed of exhaustion yet!  The team is great to work with and everyone has their thing, it's a very enjoyable vibe.  The project area has grown from about 10 people to over 80 in the last month, with some people looking in and some more regular.  There seems to be quite a lot going on in the pipe line, and it's also seems to be operating in the way of a DAC (decentralized autonomous corporation).  So it can be full of surprises sometimes, and everyone can choose their own level of participation.  

Development seems to me to be going quite well.  There's lots of things being worked on and a regular stream of releases coming out, small and big, on the topic of marking.  I would say it's more on the smallish side right now, than the big, but that can change easily.  Markpfennig has a big release in trello that can be tracked, so that is something we're all looking forward to.  Poloniex did an excellent rollout of marking in the space of a few days.  Kudos.

We now have prototypes of marking on a number of platforms:

- slack
- irc
- twitter
- poloniex
- cli / shell
- web
- bitcointalk (yes you can mark here - shhh)
- browser based client side certificates (including android)

These range mainly from proof of concept to full production quality as in poloniex.

What I see as being in the pipeline is:

- email
- github
- android client
- soundcloud
- vimeo
- youtube
- much more!

And quite a bit more.  At the same time maturing the existing work, scaling it, making it robust, security etc.  It seems to get a little better each day, so hopefully that will continue.

Relationships seem to be going pretty well and we actually seem to be working well with lots of other teams.  From my experience that's a rare pleasure in free software, so I think that's a positive.

Our web integration I think is getting really quite strong and we are well placed to be one of the leading coins in the world of REST / Linked Data / Web 3.0 / Semantic Web (all those terms mean similar things) which some people believe is the next logical step for the web -- at least that's what we are betting on.

As with any new technology the transaction levels and users start slow, so the challenge is to increase that, over the next quarter.

I dont normally talk about price, but I think I will give what I see as guidance, take is as you will.  The coin is up almost 1000% in just over a month since I've been involved, which is a pretty decent rise.  Last I checked it was around 110k satoshis.  It's been as high as 250k.  I think a lot of the trading of this project is on *potential* and that's a pretty hard thing to judge, especially if you are not close to the technology at hand.  From a neutral standpoint I thought that when we hit 250k the price was probably ahead of the development at the time and I thought 200k was fair.  Since then imho dev has gone quite well, and I'd say fair would be around 250k sat. now.  So it's a good time to buy or mine cheap coins, imho.  A lot depends on the next 3 quarters, particularly the next quarter.  Watch the metrics primarily of implementations and users, growing tx numbers (mainly off block) and I'd say to a lesser extent mining / trading.  I'd look to consolidate the 250k level then take stock of where we are again.  Well I said more about price than I intended!

I've spoken to quite a few people (technical and non technical) about marking, from artists to geeks.  Most seem to really like the concept.  I keep hearing lots of creative ideas that are inspiring in the same way that bitcoin inspired me in the early days.  For example I really like the mark to tshirt designs that have been discussed.  Hopefully marking is an idea worth spreading and can attract creative people to get involved.  Anyone can help out and make this project what you want it to be.  

Just my 2 marks, hope it helps, looking forward to working with you all!

Just wanted to give a quick update on this a month further on.

*Again, this is my personal view as a developer and does not reflect the dev team or community*

I've been working on project bitmark roughly full time for the last two months and it's been a great experience so far.

During this time much of what I have been working on is probably at alpha quality proof of concept now, and part of the next steps are to refactor things into a more scalable production quality code base.

However, having done about 7 weeks solid including all weekends and many nights, I've decided to take some time out from coding.  The main reason is Im tired.

There are lots of interesting and exciting development in the project, but the one I was personally looking forward to, reference code for marking, has not materialized.  Also I have no ETA on when the first code will be available.  So, from my perspective it makes sense to concentrate on some other things I've neglected for a while and then get back to this project when it becomes a little more concrete.

Other developments outside bitmark that I think are important
- A basic REST interface it going into bitcoin, which is good news, and part of the goals of this project, still a LONG way to go there
- Changetip seems to be going viral with tipping and I personally think there's a overlap there

Still lots of exciting things in the pipeline, so I'm looking forward to seeing those become a reality.

I will revise my price guidance.  Previous guidance was based on strong growth in code, users, hashing, ideas, communications and relationships.  Since that time, although relationships have been strengthened, it has been at the cost of other areas, and in general the coin is in a contraction period.  My fair value is reduced to 100k based on a change in project direction which has seen a facebook / reddit clone with marking become the focus.  I'm not a buyer of this idea which I see as high risk compared with the previous plan of (Q1 marking reference, Q2 maturation, Q3 RESTful bitmarkd).  I think the coin will hit a bottom but dont know where that is.  Maybe we are there, maybe 50k sat, I'd see the ocean floor at 10k sat.  Any number of pieces of good news could see a bounce, however it's not immediately obvious what and when.

In summary, this is still my favourite alt, but as a developer it will be that much more an attractive project when some of the promise gets translated either into small amounts of actual code, as we saw in the first 2 months, or the schedule of what will be realistically delivered when becomes more apparent.
Pages: « 1 ... 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 [92] 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 ... 170 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!