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 - Dirk Diggler

Pages: [1] 2 3 ... 33
General FIMK Discussion / Re: Where have all the forgers gone?
« on: August 04, 2016, 11:08:41 PM »
Correct me if I'm wrong, but couldn't quite a small fish 51% attack the network considering the current total forging power?

Let me correct you here. 51% is a bitcoin thing, forget about that.
FIMK has a 720 block max rollback which basically says that after 720 blocks you dont have to worry about a double spend.

Why there is not that much forging? Thats simple look here how many fimk has gone into HEAT.
Heat ledger is not forging with that (says something about the team behind it  ;))

Can only draw one conclusion... Which is forge while you can, since its not likely getting any better after this :D

General FIMK Discussion / Re: Where have all the forgers gone?
« on: August 03, 2016, 09:23:40 PM »
Looks fine to me..

My only problem is, that IMHO I'm forging far "too much", considering how small a player I am.

Forks can always happen. But those resolve normally after some time.

General FIMK Discussion / Re: How to make HEAT the best.
« on: July 17, 2016, 03:29:43 PM »
I would love to discuss D-wave or other circuit symmetry to make quantum actual on a desktop.

it all seem trin-ary to me. ying yang and the border,,

So many ways to do this. Up-down - none, spin back forth - none,

but is it actually just time distortion.. ask cern

Already proven within the synaptic process of our brain.

In this point we have a quantum opportunity.

every synapses is a quantum computer - its not about numbers or computations quantity.

we get a good look at quality.

That stuff all is above my intelligence level  ;D

General FIMK Discussion / Re: How to make HEAT the best.
« on: July 17, 2016, 02:10:25 PM »
HEAT works on JVM so what is the original programming done in?

Plain Java.

if you are a nerd and want details   

Don't have the time to dive into this but I see the point you are making.

While its true that compression of numbers could potentially save lots and lots of space.
What is also true is that to make our storage backend run in a memory efficient manor we try and re-use heap memory as much as possible and re-populate heap memory from off-heap OS memory to have as little GC downtime as possible.

For this we need fixed sized variables where those optimizations don't work.
Also in HEAT there is no use of floating points, we only use whole numbers, you can't write financial software using floating points, you use cents instead (when using dollars for instance).

Using a JVM language and for the sake of code simplicity (simpler code is easier to debug) I don't think those solutions offer a net benefit, the drawbacks will likely be greater than what they offer us.

I have been looking at - what to learn or AI and Quantum.
Wolfram language or Lisp is great.
Shen is a very interesting Lisp combine that to go to Shen,!forum/qilang

I taught myself Scala this year (always try to learn two new languages each year).
Choice fell on Scala since it's the base language for Play! Framework which after extensive research turned out to be the best complete-package to solve all our cloud/backend needs for everything we now and in the future need to build out HEAT backend to million-user levels.

And Scala integrates naturally with HEAT since both are JVM based.

Never got to learn Lisp.
But since most higher level functional languages (Scala, Clojure etc) are based off Lisp principles, there is a big change that if you learn Lisp you have a better change of deeper understanding anything based off Lisp.

Greetings Fimkers,

If anyone has any question about the tech side of our new project.
I'll be happy to answer them  ;)

Is there a similar feature in FIMK?

There is phasing and account control which basically do the same thing, that code is in FIMK but its not enabled.

The things with these kinds of features is that when you enable it once you have to keep it enabled for eternity or a full blockchain scan would no longer work (unless you of course later disable the feature and manually code around those transactions remaining on the chain - but this could potentially be a lot of transactions).

I would think that would potentially slow down transaction processing.

That totally depends on the transaction processor architecture and transaction storage and balance data management.
As it stands now all major crypto currencies suffer from this since they all share roughly the same application architecture.

We are however working on a method that totally re-thinks the whole way you build up a crypto currency network, cant say anymore at this time  ;)

Technical Discussion / Re: Leasing in(de)finitely
« on: May 13, 2016, 01:29:08 PM »
The only risk with leasing for a million blocks is if the leased to account shuts down forging.  The lessee would then be stuck until the lease runs out before forging again.  There would need to be a way to cancel the lease or update the number of blocks.

That is the better way indeed and not much extra work. It would in all cases require a hard fork.

Technical Discussion / Re: Leasing in(de)finitely
« on: May 13, 2016, 12:39:20 PM »
It's possible, did that already actually but this is not in FIMK atm.

The reason for the absurdly low number of blocks might seem arbitrary, which it actually is, since its simply the biggest number you could fit in a 2 byte SHORT.
The database uses a SHORT field to store the balance lease period which gives us the weird small number.

Why is it not possible to lease ones balance for more than 32767 blocks? How was that number determined?
Maybe I am missing something but wouldn't it make sense to be able to lease indefinitely and have a new transaction sub type "stop leasing"?
What if forging hubs don't include transactions (that would take their forging power away) into the blocks?

To answer that question: "Simple, the next the forger will include that transaction in a block".

The answer about the plugin could work, albeit that the NXT plugin system is very overrated (as is everything client related to NXT) and it would of course never work for your headless server nicely tucked away on some server you never touch.

The real solution is to change the balance lease field in the database from a short to an int and you could lease for millions of blocks.

Technical Discussion / Re: Node mapping
« on: May 11, 2016, 02:39:10 PM »

The easy way is to just hit my local node API and getPeers.

That is indeed the easy way but make sure to leave out the state or active param so you will get ALL known peers see

I then do the same thing for each of those peers.  Repeat. Repeat. Repeat.

On a network as small as FIMK and this even is true for NXT usually each peer will at least know about each other peer in the network.
I say know about and not connected since not all peers are connected, but usually they do know about each other.

What about connecting to each server via 7884? 
Do I have to use websockets?

FIMK has two modes for p2p connections, the old HTTP JSON connectors and the newer websocket connectors.
Both are available and will probably remain working for a long time, it might in a future version be more efficient to turn off the HTTP channel but i dont foresee that anytime soon.

Or can i GET/POST?

You can never GET, you'll be blacklisted for at least 10 minutes, when developing such a scraper this will cost you a lot of time.
Best when trying to code such a thing is to target 7884 on some machine you have access to, if you accidentally send a wrong POST or too fast and you're blacklisted you can restart that FIMK and the blacklist will be gone.

What kind of function calls are available on that port?

Function calls are hidden (not in any documentation afaik) the list is here What you want is the GetPeers call documented here:

And it should be done over POST, dont send too much requests or make a typo in the request since this API is protected against flooding or other misuse and it will blacklist you.

FIMK Markets and trading / Re: Crucial bug on CCEDK
« on: April 22, 2016, 04:40:01 PM »
I don't want to try it

Misunderstood you there, no its clear you don't want to do that.

FIMK Markets and trading / Re: Crucial bug on CCEDK
« on: April 22, 2016, 03:43:11 PM »
Probably it works the same way for selling to.

So you are saying you can game their system?
Have you tried it? It's the fastest way to know if that's the case.

Sure would be a fun fact to know.

That would sure help them to fix their system.

But always be honest  8) especially to those who've supported FIMK from the start.

FIMK Markets and trading / Re: Crucial bug on CCEDK
« on: April 22, 2016, 10:50:27 AM »
Mmmm, CCEDK has issues.
Might that explain what we are seeing here?

FIMK Markets and trading / Re: OpenLedger Trading Now Available
« on: April 16, 2016, 05:09:15 PM »
Thanks warmach for putting your time and efforts to this.
Hope it will be very successful  :cheers:

Yleinen FIMK-keskustelu / Re: Saldo ei näy Lompsassa
« on: April 15, 2016, 04:06:46 PM »
Could there be a better (than non-existent) error message, if java is missing?

Good point. And I dont see why not..

For later reference or anyone who wants to try  ;)
This is the part in lompsa that starts the server:

Yleinen FIMK-keskustelu / Re: Saldo ei näy Lompsassa
« on: April 15, 2016, 01:25:35 PM »
Case closed and welcome to FIMK.

Pages: [1] 2 3 ... 33