price is falling because of market accumulation, you know what happened next, and every time thinking it will go lower it goose very high and stays there
with market capitalization of decred, this only beginning
Topic: [ANN][DCR] Decred - Community Governance | Bitcoin Devs | Lightning Network - page 246. (Read 1201708 times)
October 09, 2016, 05:19:44 AM
October 08, 2016, 04:18:47 PM
... and the price is falling
October 08, 2016, 06:49:08 AM
Monday is getting closer.
October 08, 2016, 05:00:54 AM
Wouldn't be dcrticketbuyer better for ticket purchases ? It is supposed to set the ticket fees properly.
Dcrticketbuyer is working properly only unless nobody is using it. If there will be 100 dcrticketbuyers on the market, it will be a mess. You will either never purchase a ticket, or will pay a 1DCR fee.
Actually, the race of many ticketbuyers who trying to beat each other even worse than the rush on low prices. Because when the price drops low half of the tickets have 0.01 fee. Now imagine what will happens if full mempool of 4000 tickets will be using ticketbuyers.
It's like with trading bots. You can have some profits only if you are the only person who use it. If 10 / 100 / 1000 users use the same bot on the same market with pretty much similar configurations ( everybody will set something like 25-30 DCR max ticket price, +-0.25 dcr max fee etc ..), then you shouldn't expect much.
October 08, 2016, 03:07:17 AM
Wouldn't be dcrticketbuyer better for ticket purchases ? It is supposed to set the ticket fees properly.
October 07, 2016, 05:43:10 PM
LOL these three latest posts about ticket dynamic and fees is still Aramaic to me..
my wallet is on autopilot with pool voting - So not an optimal approach?
my wallet is on autopilot with pool voting - So not an optimal approach?
How many tickets do you have?
Pool says I have 200 live/immature tickets.
October 07, 2016, 05:25:58 PM
i remember a poor guy on decred forum mistaken to set ticket fee with ticket price... what a nightmare, fortunately now the limit is 1 DCR.
October 07, 2016, 04:14:01 PM
at last good price the average ticketfee was 0.3 - did I see right?
I set ticketfee at 0.045 , 0.085, didn't manage to get any ticket
usually I could always get by setting between 0.025 and 0.075
the last spree of ticket buyers saw a significant ticketfee increase
I set ticketfee at 0.045 , 0.085, didn't manage to get any ticket
usually I could always get by setting between 0.025 and 0.075
the last spree of ticket buyers saw a significant ticketfee increase
October 07, 2016, 03:45:55 PM
LOL these three latest posts about ticket dynamic and fees is still Aramaic to me..
my wallet is on autopilot with pool voting - So not an optimal approach?
my wallet is on autopilot with pool voting - So not an optimal approach?
How many tickets do you have?
October 07, 2016, 03:00:06 PM
When ticket prices are low, the demand for them is so high that the normal fee of .01 is just not enough to be successful in purchasing tickets.
October 07, 2016, 02:40:43 PM
LOL these three latest posts about ticket dynamic and fees is still Aramaic to me..
my wallet is on autopilot with pool voting - So not an optimal approach?
October 07, 2016, 10:15:47 AM
And 100%.
October 07, 2016, 07:09:20 AM
Cheating? I'd say manipulating the ticket price market or merely only rewarding miners 
October 07, 2016, 02:46:20 AM
Few words about the guy with the 0.9 DCR ticket fee if you know what i mean.
He is cheating. He buy only 1 ticket per block (in solo mode) with this fee. Just ignore him.
That's why I've added this tool called "Fees Explorer": https://dcrstats.com/
Check the Min and Average Fees in the last few blocks. And if you want to buy few tickets in the very next block, try to send purchase transaction with the fee higher than min but lower than average.
Please notice, that fees in that table are DCR / Kbyte (which u set with setticketfee command), so if you are using the pool, you will pay only 50% of that fee (because purchase transaction is 540 byte, which is ~~ 50% of 1 Kbyte).
He is cheating. He buy only 1 ticket per block (in solo mode) with this fee. Just ignore him.
That's why I've added this tool called "Fees Explorer": https://dcrstats.com/
Check the Min and Average Fees in the last few blocks. And if you want to buy few tickets in the very next block, try to send purchase transaction with the fee higher than min but lower than average.
Please notice, that fees in that table are DCR / Kbyte (which u set with setticketfee command), so if you are using the pool, you will pay only 50% of that fee (because purchase transaction is 540 byte, which is ~~ 50% of 1 Kbyte).
October 07, 2016, 02:30:10 AM
wondering if there are any videos i could watch about this coin? reviews and tech details ect ect
https://www.youtube.com/watch?v=Rin8cfA9wJI October 07, 2016, 02:28:08 AM
wondering if there are any videos i could watch about this coin? reviews and tech details ect ect
https://www.youtube.com/watch?v=Rin8cfA9wJI October 06, 2016, 10:35:34 PM
wondering if there are any videos i could watch about this coin? reviews and tech details ect ect
October 06, 2016, 10:12:08 AM
wow, go to the pump
October 06, 2016, 10:09:13 AM
October 05, 2016, 07:01:40 PM
Nice:
The dcrd syncin is rather slow right now so this is a welcome improvement
Good job devs
... And of course I can't wait to find more about future implementation of votebits in the next blog:
Quote
Speed improvements for the initial chain sync with the new database are substantial and vary based on hardware. We have seen speedups of roughly 5x for the initial chain sync on a modern laptop or desktop machine with SSD.
The dcrd syncin is rather slow right now so this is a welcome improvement
Good job devs
... And of course I can't wait to find more about future implementation of votebits in the next blog:
Quote
A key application of this voting will be voting on consensus changes, wherein stakeholders are given the ability to vote on consensus changes, effectively subjecting the act of voluntary hard forking to a vote. Further details on the process of enabling additional votebits will be made available in a future blog entry.
Jump to: