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 - Pohatta

Pages: [1] 2
FIMK Markets and trading / Re: FIMK deposit on heatwallet
« on: August 27, 2017, 10:52:26 PM »
Again I've been waiting a week for my withdrawal ... transaction id: 17635120709476982855

FIMK Markets and trading / Re: FIMK deposit on heatwallet
« on: August 01, 2017, 07:53:43 PM »
FIMK deposits will be automated at some point.

It would be nice if in the meantime you could get the manual one actually working. I've been now waiting OVER A WEEK for my withdrawal (transaction id: 12357195527129681031) to materialize. An email to didn't help (was not even avknowledged). It is rather annoying to pay 0.40% fee for this kind of "service".

General FIMK Discussion / Re: Warmach's Forging Pool
« on: May 25, 2017, 12:46:39 PM »
Excellent. Thanks!

General FIMK Discussion / Re: Warmach's Forging Pool
« on: May 23, 2017, 09:46:10 PM »
What happened to this pool? There seems to be no activity in the account for the last three weeks and also the web page seems to be frozen.

FIMK Client discussion / Re: Lompsa 0.4.10 Problem
« on: October 16, 2015, 08:35:17 PM »
Are you running with the local server on or are you using the remote servers?
If using the remote ones, it's to be expected they have been acting up these past two days.
I'm currently rewriting our deployment scripts (upstart, chef etc) we'll release them coming weekend likely so any one can use them to easily deploy FIMK/NXT etc..

If in doubt if the remote FIMK servers are working you can always check out since it connects to those same servers.

I really don't understand your techno talk, all I was saying is that I was unable to send a message from my wallet using Anyhow, it doesn't matter as I now tried it again (exactly the same way as few hours earlier), and it worked! Weird!

FIMK Client discussion / Re: Lompsa 0.4.10 Problem
« on: October 16, 2015, 11:01:49 AM »
Likely not related to Warmach's problem, but I can not send a message (incidently tried to send a message to Warmach's pool account!). I did it excatly the same way as previously.  Here's a screencap.

Yleinen FIMK-keskustelu / Re: FIMK markkinointikampanja
« on: August 23, 2015, 10:20:32 AM »
Voisiko ennen tätä markkinointikampanjan alkua uudistaa tuon Lompsan käyttöliittymän?

Ymmärrän toki, että toistaiseksi etusijalla on ollut alustan tekninen kehittäminen. Onkin saatu aikaiseksi markkinoiden kehittynein softa. Kiitos siitä. Mutta, mutta, tuo käyttöliittymä on suoraan sanottuna aivan karmea ja sekava. Erityisesti siinä on vaikea hahmottaa navigointia oman tilin, muiden tilijen ja yleisten lohkoketjutoimintojen välillä. Lisäksi aivan perustoiminnot (maksaminen, viestin lähettäminen) on "piilotettu" tasa-arvoiseen asemaan kaikenmaailman edistyksellisten toimintojen (joita 90% ei varmaan koskaan tule edes käyttämään) sekaan. Minun on hyvin vaikea kuvitella, että nykyisellä käyttöliittymällä FIMK:stä innostuisivat muut kuin pahimmat teknofriikit oli markkinointikampanja millainen tahansa.

In six months this incident is going to be forgotten UNLESS we have to keep explaining "943M, not a billion FIMK" to every single person we try to sign up until the end of time.   
Why would we need to constantly explain that? There would be a billion FIMK out, but 57M of them are frozen as they were in hands of a thief. There is no need to explain every new Bitcoin owner that there are huge amounts of Bitcoins "frozen" either deliberately (e.g. proof-of-burn) or by mistake (e.g., lost password). IMO it is a much bigger PR problem if the foundation starts actively deciding which transactions are valid.

It's not invalid transaction if it's part of the blockchain.

What we are proposing is an INVOLUNTARY transaction, not an INVALID one.  The proposed transaction is involuntary only because the thief does not want it to happen.

Again, it can not be done. That's the fundamental property of cryptocurrencies. Every transaction from an account (essentially the public key) is signed by the corresponding private key. That can not be faked.

by the deliberate injection of a block containing the desired thief-to-Foundation account transfers. 
It needs to be in the blockchain, not the client.

You don't seem to understand that no such (legimate) "desired thief-to-Foundation account transfers" can be made. Only way to proceed is to hard code something to the clients (as Dirk explained). And please do not "lecture" me on basics how cryptocurrencies work, I've done my homework already long time ago.

What I am proposing is that the Foundation picks a future block in the next day or two where they will ram in a block containing forced transfers from all the thief accounts to a single Foundation account.  This will create a fork in the blockchain. 

What do you mean by "ram in a block containing forced transfers from all the thief accounts to a single Foundation account."? They can not make a fake transfer accepted by other clients without hardcoding that to the clients. If on the other hand the special instructions are hardcoded to clients, then there is no need for making fake transfers. Simply hardcode to the clients that at certain block all the money from certain accounts are transfered to the foundation account. Similar way now the thiefs' accounts are blocked. If enough users are running the updated client, there will be no real fork.

There was a rollback in Bitcoin history.

Sure there was, but the question was for the Mt. Gox -case, where there was/is no known block, one could rollback to.

Am I missing something? 

I really don't understand what is the benefit of this "51% attack" -approach you are proposing (or maybe I don't understand what you are proposing). As far as I understand, you are proposing that with the help of forging power of the foundation, we'd make a rewritten history where the theft never happened. Even if that were succesful (I doubt it), what's the point? The money would be back in the hands of the dishonest user (and the the thief, he knows the passwords also). But then, is the foundation going to do the same every time someone declares a fraud? This really would be opening a can of worms.   

Rolling back the blockchain to 282229 would require hard-wiring FIMK transfers in block 282229 that sends FIMK from fraud accounts to Foundation accounts.

How is that possible without knowing the private keys?

Wouldn't a rollback also harm legitimate users or can the rollback be limited to only the affected accounts?

Rollback simply means that we delete the existing  blockchain after some point and restart from the point. So all transactions, forging fees etc. after the point will be deleted. I don't think that is the real problem here (as the transaction volume is so low), but the real problem IMO is that the rollback would return all coins to the user who not only screwed up himself/herself but more importantly cheated in the launch.

Pages: [1] 2