|
By Nov.1 the US debt will have defaulted, so unless Ukyo didn't exchange the loan into USD, it will be worthless anyway.
|
|
|
|
|
Why don't we create another 5 threads on this topic, maybe that changes something.
|
|
|
|
Well, at least we won't have to get all worried about being listed on bitfunder..
BF is going to close too. It actually is not. |
|
|
|
As a non US citizen in a country that will discover bitcoin in about 10 years or so, I offer my services to be a proxy for US citizens portfolios.  Before doing that, I would advice you to read the SEC regulations: http://www.sec.gov/rules/interp/33-7516.htmWhat you suggest doing isnt any less illegal than what bitfunder and btcst where doing, no matter your nationality, and if bitfunder doesnt take any reasonabl action to prevent you providing a proxy, they will be just as liable again as well. The SEC can go fuck themselves as far as any non-US citizen is concerned. |
|
|
|
|
Da du im deutschen Forum unterwegs bist, nehme ich an dass du nicht US citizen bist und nicht von den Problemen mit BitFunder betroffen bist? Oder ist das Listing von Cado.AvalonB3 betroffen?
|
|
|
|
Market trading is closed. But, are we still supposed to be able to internally transfer shares?
I got word that people who have NASTY-PT shares can't transfer them to me. I have shareholders transfer them to me so I can exchange the pass-through shares for direct seats.
Trading has been halted according to the winding down plan. We will update the site code shortly to allow transfers to and from asset issuers on a per-issue basis where necessary. |
|
|
|
Is it still possible to transfer the shares?
No. Burnside has halted trading. You will need to wait until he provides the direct shares, and then import those. So once the shares are transformed to direct shares (which is supposed to happen on Oct.10) we can just follow the steps explained on the AM1 page ( https://bitcointalk.org/index.php?topic=253673.0) |
|
|
|
I am 20% down. I wonder who is actually at a profit  I was lucky enough to jump on the train when the site was even. |
|
|
|
|
So what's going to happen with COGNITIVE and COGNITIVE-PT (LTC-GLOBAL) shares?
|
|
|
|
|
Is it still possible to transfer the shares?
|
|
|
|
Wow, that fee is ridiculous. 1 BTC for a mostly automatic process that takes TAT a few seconds to execute.  And people wonder why stock exchange regulation exists. Well then try transfering a stock between the NYSE and an european exchange. |
|
|
|
to all share issuers at btc-tc:
cryptostocks.com is offering you a free move with your assets to cryptostocks! i have done this already with LTC-CHARTS. assets there can also be traded in LTC and DVC!
Wouldn't recommend going there |
|
|
|
|
Are you kidding with crypto-trade.com ?
It would be nice knowing more detailed plans considering BTCT halting trading in less than 7 days.
|
|
|
|
Isn't there a way to set up a server that generates the server seeds and sends them to just-dice, but that doesn't allow those seeds to be read out ahead of time, i.e. before they are sent?
You'll always have an entity that is able to determine the server seed. Can you explain why that is the case? Isn't there a way to set up as a system that, once it is running, doesn't allow changes to it anymore, i.e. it does what it needs to do (sending server seeds, reveal one if asked by player), but doesn't allow additional changes or attempts to read out data? If that is a problem that is provably impossible to solve (say, a know problem in CS), then I'm not going to continue arguing of course If you're sending the seed from another server it needs to be saved. That's worse than the current situation because you then have the seed on multiple systems. If you pull the seed from another server for each roll, it still needs to be saved somewhere. If we assume doog is evil, he would not be able to determine how long the seed is valid, but at least he got it. But that would only shift the responsibility to another entity. Also you can't prohibit reading the seed, since the server needs it the rolls and if the server gets it, ultimately doog gets it. |
|
|
|
Isn't there a way to set up a server that generates the server seeds and sends them to just-dice, but that doesn't allow those seeds to be read out ahead of time, i.e. before they are sent?
You'll always have an entity that is able to determine the server seed. |
|
|
|
Dooglus,
Is there anything you can do to fix the lag issue? many bets take 5-10 seconds to finish. I'm able to spam 5-10 bets in a row, and then have to wait 5 seconds on random bets.
You can see that it makes for frustrating gambling, and since that is our main product, what can we do address this service issue ??
Have you checked this: https://just-dice.com/#a12 |
|
|
|
So, what the rest of investors would think about trying with a 1.5% edge? It's going to be difficult to have doog agree on that as all the marketing of JD is based on the extremely low 1% edge, but I would love to hear your reasoned opinions.
I would totally agree. After all, this site is made for profit, so if profit isn't there, we need to change something. If gamblers switch to another site with lower house edge, there's also no profit. |
|
|
|
Please note: I'm not saying that's necessarily the case (that nakowa is cheating), but it's at least conceivable.
We should keep this possibility in mind. It would be great if doog could deliver more information about how the server seed is saved. I think a short, but noticeably invest/divest delay would be helpful.
Here's how it could work: Divesting is always instantenous. Your initial invest is as well. But after any divest, another invest has to wait 1 hour. That's all.
This sounds like a reasonable idea. You'd also have to set a waiting period for withdrawal to avoid the creation of new accounts to reinvest immediately. |
|
|
|
The system JD uses is close to as good as it gets (assuming proper implementation). This is possible to the standardization of strong cryptographic protocols (and hash functions, such as SHA).
You're using some strong wording there. Do you have any source or quotes to underline this or are you just wildly speculating? sha is currently the industry standard hashing algo. Quck google shows us that it is used in the most sensitive applications: The SHA-2 hash function is implemented in some widely used security applications and protocols, including TLS and SSL, PGP, SSH, S/MIME, Bitcoin, PPCoin and IPsec. i do not feel that my statement is so strong: again, assuming proper implementation, it is as good as it currently gets. There are no known, feasible attacks on sha. You understand what a hashing algorithm does? What about the input? the debate was: generation of numbers which determine if a given roll wins or not. i stipulate that as the sha has a uniform output distribution, the results are evenly distributed. Furthermore, due to the security of the algo, we are unable to predict the next roll without knowing the plaintext (clientseed+serverseed+nonce). Therefore, the generation of lucky numbers is fair, contingent on correct implementation (which i know is not a simple issue) I already know the clientseed and the nonce. If the serverseed is poorly generated you can use the best hashing algorithm available and I'd be able to predict the output. |
|
|
|
|
Please don't feed the troll. Just look away and go on.
|
|
|
|
|
Show Posts
