[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)
... 
