Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Schwede65

Pages: [1] 2 3 4 5
General Discussion / Re: Profits, Performance, Trust & Efficiency
« on: March 28, 2014, 10:28:58 am »
With the shares system we have an easy way to vote on anything.
With the TaPOS system the transaction ledger becomes immutable automatically over time as the ledger is confirmed by everyone on the network.
Generating the next block should be as efficient as possible to maximize dividends.
Transaction validation should be as quick as possible.

Shareholders vote (off chain) on a trustee.
Trustee generates blocks every 30 seconds (or at will..... no need to require any particular rate)
If trustee is compromised or shutdown, shareholders can elect a new trustee by broadcasting their vote.
Once a new trustee has 51% of the shareholders support the network continues.

As a trustee you cannot double spend (you will be caught and fired).
As a trustee you cannot perform Denial of Service without being caught and fired.
As a trustee you cannot be coerced without being let go.

As a shareholder this maximizes your value (dividends, transaction speed, no potential of forks).

A trustee is not a paid position and requires almost no resources to run.  A trustee could even operate behind a tor node.

The result is like a 'constitutional company' where the laws are entirely defined in the constitution and the 'president' can be recalled at any time and has almost no power even when in office.

This same process can be used to resolve when a hard fork goes into effect.   


this "trustee" is only one PC/IP?

why not having more of them and let them - 3, 5, 7 or 9 PCs - work together to share the multiple risks of running only one

as an example: the master-trustee is only doing the sequence of the transactions of the network
this master has to be back-upped by two silent master-trustees - second and third, who are going to work when the first master does not work anymore

after the correct order of the transactions the "slave"-trustees are finishing the transactions by generating the blocks into the chain

~18 days ago it was 42 also
15 days ago it was 42
today it is 37

So it went from ~0 days/day to ~0.3 days/day. I'm forecasting that the rate will continue to increase.

Your information is wrong.
It constantly swings all over the place. One moment it is 30, then 35 days and then 47 days.
Fact of the matter; the estimated difficulty is still dropping and since the snapshot the estimate hasn't been under 30 days. And that is 3 weeks ago!!!

This means the interest in the share is still getting less each day and the estimated will stay the same. It will only get shorter when only the few die hard miners are left mining this. You have no idea when this will happen. But it will take at least one more month and quite possibly 2 at least.

What you will see happen is the same as the Ron Paul Coin has had in the past. Interest is huge > everyone mines > difficulty shoots through the roof > everyone stops mining > difficulty drops to an extreme > takes a loooong time for the amount of blocks to have passed > the blocks is past > everyone drops onto the coin again and mines like crazy > rinse and repeat.

you're right on re:RPC. oscillations may become the norm for PTS since every snapshot will cause a shock to the mining market. The built in lag in retarget will cause oscillations, no way around it without hardforking.

However, the trend is currently towards increasing hashrate (and is continuing the trend toast pointed out)
Time to retarget: 27d 18:33:18 (2014-04-16 20:56:31 UTC+9)
Network hashing speed:
Last 100 blocks: 5,183,071.87 cpm ETA: 33d 16:33:40
Last  50 blocks: 6,287,297.60 cpm ETA: 27d 18:33:18
Last  15 blocks: 6,675,888.98 cpm ETA: 26d 03:45:22
Last   5 blocks: 6,937,143.86 cpm ETA: 25d 04:06:52

so over the past 100 blocks hash rate has been increasing, most likely due to discussions on new DACs and a corresponding rise in PTS value.

new numbers:

Blocks to retarget: 1589

Time to retarget: 32d 18:25:53 (2014-04-22 13:29:03 UTC+9)

Network hashing speed:
Last 100 blocks: 5,124,494.03 cpm ETA: 33d 12:08:23
Last  50 blocks: 5,239,885.17 cpm ETA: 32d 18:25:53
Last  15 blocks: 4,674,080.41 cpm ETA: 36d 17:37:48
Last   5 blocks: 4,034,575.72 cpm ETA: 42d 13:22:26

hashrate goes down - the real point is the blocks before retarget: 1589

General Discussion / Re: GET YOUR BTS XT Wallet Here!
« on: March 18, 2014, 08:51:43 am »
i don't want to needle someone...

...but please tell us the time frame to release BTS XT

Edit: this thread is relevant:

new KGW called DGW
coder please have a look here:

chaeplin wrote

Yay name is "DarkGravityWave"

Its not tested how can you trust it?

o.k. then forget KGW or DGW

only a suggestion:
implement a short time-retarget after 16 or 32 blocks with maximum swing of +- 50 %
regarding the difficult-average of the last 128 blocks

25% swing makes for smoother transitions.  but i think this is a better idea .

i think you have a good smoothing with the average-difficulty of the "old" last 128 blocks, but yeah - you are a developer of some alt-coins and though you have an excellent view on this PTS-coin

Edit: "Last 5 blocks: 3,401,343.71 cpm ETA: 59d 12:49:15" - Blocks to retarget: 1874
the 59 month are not far away ;)

new KGW called DGW
coder please have a look here:

chaeplin wrote

Yay name is "DarkGravityWave"

Its not tested how can you trust it?

o.k. then forget KGW or DGW

only a suggestion:
implement a short time-retarget after 16 or 32 blocks with maximum swing of +- 50 %
regarding the difficult-average of the last 128 blocks

hm, there seem to be problems with KGW


Cryddit wrote there:
"The kgw exploit is real.

The problem is that the software will accept blocks that are timestamped earlier than previous blocks, (for good reasons) up to the median timestamp of the previous 11. 

Kgw counts these as very fast blocks and adjusts the difficulty up by its 20% maximum.  Once.   But you can use that once to roll the timestamp back after five blocks that are long enough to drive the difficulty 20%lower each. 

So the exploit is to start mining your own block chain, time stamping several blocks into the future far enough to get the maximum downward adjustment of difficulty each time.  Then jump backwards in time getting the maximum upward difficulty once.  Rinse, repeat,  and your chain gets ridiculous low difficulty and you mine a whole lot of blocks while advancing your timestamp not much further than the main chain.

When the time in the main block chain catches up, you release your own chain and force a reorganization, which allocates to you all the coins mined for the last umpty ump blocks."

the DRK-dev eduffield is "cleaning" KGW for DRK: DarkGravity ;)

please have a look after this while implementing KGW in PTS, maybe DarkGravity works better

Your guys offhand remarks make me wonder if there is an ulterior motive for not trying to correct this. As suggested by user Schwede65 and FreeTrade, implement the Kimoto gravity well or something. Can that even be done at this point? If not, why?

I think the "is what it is" attitude is very concerning given your position.

Your coin has the potential to dry up. I don't know for sure, but the potential is there and if there is something you can do, you probably should.
i haven't found an answer to this concern - changing + updating this old fashioned PTS-retarget-time!

Edit: there is a huge amount of donations, then please call out a bounty to correct this flaw!

Edit 2: it's only a technical flaw - we need no more "blah, blah, blah..."

Unfortunately, there is nothing we could do to keep miners on board after a 60% price drop because miners are purchasing PTS just like everyone else, they just pay with electricity.    The only thing we could do is switch PTS to a proof-of-stake coin. 

We could try to 'talk up miners', but miners are economic actors who see that it is cheaper to get PTS by trading than mining and thus make different economic choices.

If the difficulty becomes a long term problem we can take measures to increase the transaction rate, but short of increasing voluntary transaction fees in an attempt to motivate additional miners there is nothing we could do.   It would be like asking us to stop the price of PTS from falling after the BTS-X snapshot.
but the PTS-difficulty-retarget-block-time is implemented like a dinosaur-thing from the good old times...
why not having the fine Kimoto Gravity Well / every block a fresh difficulty?

General Discussion / Re: MtGox is offline, any thoughts?
« on: February 25, 2014, 08:40:52 am »
This could be a bad week to debut BTS if the rumors tonight are true about MTgox's BTC. We could see a very weak market the next week and this could deter people away from the entire sector of cryptos.  Maybe a buying opportunity with BTS?
i think MtGox is bankrupt, i feel they are big dumbasses, because they have been btc-robbed on and at such a high level

we can be called lucky to have 3 or 4 other big btc-exchanges in these days, so that the btc-fiat-price will stay and stabilize at a good stage
though btc is the pathfinder and forerunner for the cryptos - yeah - this would be the great point for bitshares to realize decentralized exchange(s) - not only the crypto-currency must be decentralized - the crypto-fiat-exchange has to be the same!

BitShares PTS / Re: fast AMD OpenCL PTS miner released
« on: February 24, 2014, 05:50:48 pm »
my R9 280x doing 3650 and HD 7950 OC doing 3100 cpm which i think good but R9 290 OC doing only 3000 cpm, any reason ?
win 7 64bit 13.12 , i tried 14.1 and 13.1 , 13.6 but same.
i tried "a" 0 to 3 but its not gonna change the cpm rate
it's a windows-problem - linux is doing fine with the 290X working at ~4500 cpm
please read a bit more in this thread

BitShares PTS / Re: [ANN] - Fast PTS pool
« on: February 21, 2014, 05:18:50 pm »
my AVAST says after blocking the site in firefox:

Infektion blockiert
Infektion: URL:Mal

the pool is running fine with regularly payments, but the website...

BitShares PTS / Re: fast AMD OpenCL PTS miner released
« on: February 21, 2014, 10:00:39 am »


3 R9 290 Sapphire


Test Windows 8.1 64bits Drivers 14.1 SDK 2.9

Help help
1. please post your .bat-commands for the miner (-t + -a)
2. go back to catalyst 13.12 - 14.1 (beta!) doesn't work properly for my w7-64-rig

BitShares PTS / Re: BitShares-PTS 1.0 Release (2.18.2014)
« on: February 20, 2014, 12:28:48 am »
did i get it right, that the 28th of february is NOT a test of the bitshare-system with all the pts and ags around it?
is it the real launch-date for bitshares?

Not launch date, but snapshot date.  You won't get the BitSharesX software then, but you need to have all your AGS donations in and all your PTS in a wallet you control by then in order to get BTS from them when the launch occurs.
o.k. snapshot-date = 2014-02-28
for PTS and AGS?
what about the PTS mined after the 28th of february?
that PTS will only count for the next DAC - with a new snapshot-date?
is the AGS-generation closed at this date - though the donations to get AGS?

BitShares PTS / Re: BitShares-PTS 1.0 Release (2.18.2014)
« on: February 19, 2014, 11:00:11 pm »
March 1 will not have dl.  The ides of march is our target.  It has historic significance. 

You don't need the pts wallet.  We will provide the bts wallet at that time. 

Sent from my iPhone using Tapatalk

wow nice ;)

But the only date that is critically important is February 28th.
(long before close of business GMT)
Have every PTS in one of your own wallets by then.
Don't leave anything out on an exchange or they will get your BitShares!

(We can't repeat this enough.)
did i get it right, that the 28th of february is NOT a test of the bitshare-system with all the pts and ags around it?
is it the real launch-date for bitshares?

Pages: [1] 2 3 4 5