|
Borrowing in fiat to loan out bitcoins? SOunds like some nasty exchange-risk there.
General Financial Corp thought they had a good thing going by borrowing from the Canucks, repayable in CDN, to loan out DVC at twice the interest rate. Turned out the exchange rate was prohibitive, so they negotiated an even lower interest rate with the Martians, payable in MBC. But still exchange rates were killing them.
In the end, it turned out that they had to negotiate a loan payable back in the same currency - DeVCoins - as they were loaning out in order to have a viable setup.
After watching that all happen, I would be very cautious of any plan to borrow in one currency to loan out in another...
-MarkM-
|
|
|
|
Ahhh I think I understand devcoin a bit better now. I won't get devcoin for writing a song but if I made like a website where musicians could collabarate on open source music (like github with an in browser DAW?) that would be the 'foundation' of a devcoin project right?
I think songs qualify probably, just as novels would. If you write a score, with words to go with, that really is source code isn't it? The shenanigans I refer to in my previous post are more to do with the people who take your score and words, and run voice synthesisers and virtual instruments to produce a "recording" of your song as performed by their virtual singers and instruments, and then try to pass off that "recording" as open source without providing the code - the virtual singers and instruments and your score and words - that "recording" was compiled from... -MarkM- |
|
|
|
|
The users are not blameless, provide something really secure and the vast majority of them will not use it.
They don't care about security until after they lose their coins. Until then they just want total convenience, the easier a hacker can get their coins the easier it is for them too, for example a password easy to brute-force is also easy to remember, and having to use a GPG encrypted message to order things done with your coins is not worth the few thousand coins at risk... until those coins go missing...
-MarkM-
|
|
|
|
|
I don't understand the argument here. If all my capital is out on loan at some percent interest, why would I not borrow more money at less interest than I loan out at in order to be able to increase the amount I am loaning out and thus increase the amount of interest I am making? It seems to me banks do this all the time, getting bigger is a bad thing all of a sudden? What is the discrepancy? Is Patrick only loaning out a small amount not all that he has available?
-MarkM-
|
|
|
|
How do I get devcoins for writing music?
This could be interesting, as in my experience grpahical art and music both have historically had real problems with being "open source". In software where we say open source we mean that all of the raw stuff that gets collated/compiled together to form the final piece (executable) is the source code. But in my experience artists go to some pretty extreme lengths to hold back what seems logically to be the "source code" for their products. For example just as a programmer can combine if, then, else, plus. minus, and other pieces/components to make a program, an artist can combine violin sounds, piano sounds, oboe sounds, or even run code that produces such sounds, and compile all of these components into an executable music file. Similarly a graphic artists often takes a whole bunch of layers and layers them, or even takes a bunch of three dimensional models and generates a two dimensional image from a particular angle. But somehow we are often expected to believe that only the final image, not all the models / layers compiled together to create it, or only the final music files, not all the samples or synthesis algorithms composed/collated/compiled together to make it, are the "source code" for their final piece? So I guess my first question would be what exactly are you proposing to claim to be the "source code" of your music that makes it "open source" music? Will we get source code for the instruments, and a score that those instruments will play? Or what? -MarkM- |
|
|
|
I've been thinking about a similar method as part of the code for an exchange I'm working on, and it's almost correct other than if somebody has access to your database and knows your rules, they can insert or alter records in the database table that controls your payment processing service. The solution here would be to have the requests (database records) be nonced & signed. Preferably with both a server/application private key and a per-user private key derived from the users password.
Please look at Open Transactions system and maybe come help us get it widely deployed... -MarkM- |
|
|
|
If we can't trust the website giving commands into the hot wallet, [edited:]how can we trust that same website to collect and offer the hot wallet valid and intended commands to pull? You never fully can trust it, but you can make it more difficult for an attacker by having the hot wallet independently check the incoming commands for deviations from normal patterns which could indicate the website has been compromised. At the cost of requiring more manual human action you can add more safeguards, like requiring customers to pre-register their withdrawal addresses and transferring a list of valid addresses via sneakernet to the hot wallet every 8 hours. Now an attacker can't break into the website and send the hot wallet a command to withdraw all the bitcoins to some arbitrary address because that address won't be on the authorized list. I am not really convinced that you cannot set up the system to be trustable. For example if I base sending out of bitcoins on my having received bitcoin-tokens in a certain account, then it looks to me as if the only way I can get those tokens arriving in my account (and thus triggering a send-out-coins request) is if the hacker has the private keys of a user who has bitcoin-tokens. Those tokens in turn could only have arrived there through a properly signed transaction, and the signatures go all the way back to the account that actually issues the tokens. The whole point of all this signing is so the server does not actually have to be trusted... -MarkM- |
|
|
|
It's more the hot wallet I'm trying to understand. It is needed for the exchange to instantly process transactions directed by customers. So there'll always be a kind of command path going from website to wallet, no matter how far away you hide the hot wallet, and we'll have to trust that path we setup ourselves. A good hacker will find that path and command the bitcoind. So there's actually no need to trust our path if we can't trust our website.
Now, of course you can have the hot wallet pull for commands and transactions, but then.. how do you trust the content of those commands and transactions? Because, basically, that is that same public website with input from customers.
If we can't trust the website giving commands into the hot wallet, [edited:]how can we trust that same website to collect and offer the hot wallet valid and intended commands to pull?
The route I am going is to have the customers sign everything using their own private keys. If a hacker uses their private keys unauthorised that will be totally outside my control and I will have no way even to distinguish between a hacker and the actual customer, since to me the private key is the customer. This seems nice and safe from my end as service, but admittedly is not going to be very nice for people who let hackers get hold of their private keys. -MarkM- |
|
|
|
Well sadly Stephen was misinformed and likely turned a bad situation into a worse one. His talk of injunctions and criminal activity were simply false. I am just not certain if it was coming from a place of intentional malfeasance or simple ignorance.
Here: But once a corporation reaches insolvency, the fiduciary duties that once flowed to equity-holders divert instead to creditors. Again quoting the Delaware Supreme Court, "the corporation's insolvency makes the creditors the principal constituency injured by any fiduciary breaches that diminish the firm's value.
But once the moment of insolvency arrives, as the Delaware Court of Chancery has explained, "the creditors become the enforcement agents of fiduciary duties because the corporation's wallet cannot handle the legal obligations owed." The court continued: "Because, by contract, the creditors have the right to benefit from the firm's operations until they are fully repaid, it is they who have an interest in ensuring that the directors comply with their traditional fiduciary duties of loyalty and care." - http://www.faegrebd.com/8365tl;dr: Things change when your organization becomes insolvent. I am not a lawyer, but I'm aware that in the U.S., bad things can happen to you as an officer or director if you then take action after establishing insolvency that ends up further harming your creditors -- especially actions which might favor one creditor over another. Now customer funds are even more sacrosanct. My argument was that legal counsel should be obtained BEFORE paying out one single dime. Roman had reopened the site to allow ACH withdrawals so I was making the argument that the only way to stop it was to get an injunction filed. Personally, I don't have that many BTC involved and have already mentally booked mine as a total write off. I could see though how Roman might be persuaded because releasing USDs to depositors would mean some people (those with USD balances) would be less pissed off -- though others (those with BTC balances), would be more pissed off. But an insolvent organization no longer does what is best for the company or for its shareholders and instead is in dire need of legal advice before taking further action. It looks like that might be what then happened. I hope to cover this stuff for my Open Transactions server by taking the position that although the tokens representing assets are intended to do so in a non fractional reserve manner, nonetheless the actions of theives, acts of god, force majeur etc could contrive to force some of those tokens into being fractional (or even zero) reserve; but that each type of token is independent such that loss of dollars to back dollar tokens would cause only those tokens into being less thasn full reserve, whereas tokens representing assets not lost would remain fully backed. Not sure how long it would take though for the system to earn itself enough moneu to have that cast into legally airtight form... -MarkM- |
|
|
|
I've already stopped putting any funds in any Bitcoin service. It's obvious few of them have a clue how to secure their sites and there is no way to know who does and who doesn't.
Wrong. There is a way to know. But it requires the code for the entire system, from front end to back end, to be published for public scrutiny. And not just the program code, but the server configs and software versions and everything. In fact, it should be possible for the entire file system of every server to be available via public, read-only, anonymous FTP — minus the one directory containing the private keys and the one directory that holds the database table containing the users' personal information, if such a table exists. There is no reason that the remainder of the systems' contents shouldn't be held out for the light of day to wash over them. Security through obscurity is no security at all. Cryptographic algorithms are secure despite their method of operation being public knowledge. The same should be true of web sites. Please come help us get Open Transactions polished up... -MarkM- |
|
|
|
Sounds like the cold storage was deposited with pirate.
That was an obvious idea to jump to right off the bat but seemingly someone has traced some transaction(s) thought to possibly be the thief moving the coins, which would not really be possible if the coins had already been sent to pirate would it? It is amazing though the clever ways people come up with of making their coins accessible to hackers. -MarkM- |
|
|
|
The only people profiting from bitcoin are hackers. Fuck this shit.
I haven't lost anything yet from bitcoin but it does seem like hackers are just having a field day with it. As much as everyone hates Mt.Gox because of the cost to put money on there and the loss of anonymity, it seems like they have the best methods on there. I feel like bit floor should have known better than to have all of their coins in a hot wallet after btc-e and other hacks. Exchanges are damned if they do and damned if they don't. People want the convenience of being able to do instant withdrawals and transfers without any of the risk. Small Bitcoin services which hold large amounts of other people's BTC are hacker magnets and intruders know that such services are often one or two man operations without capital reserves to invest in infrastructure. They're soft targets. Security needs to be baked in from the day a service is created but many Bitcoin services are more concerned about rushing to market than they are about security (they probably tell themselves they'll invest in "proper" security once the profits are rolling in, not realising that a rapidly expanding business often makes little or no profit). Until Bitcoin service providers lift their game security-wise, people should severely limit the amount of BTC they store on such services. Bitcoins stored on a service are always at risk. You accept the risk of them being lost or stolen by leaving them on deposit with a service. Take a look at Open Transactions and help us make it more accessible to people. I notice this case is yet another Linode case, is there any reason to think there was any real vulnerability other than the fact of being hosted by a third party instead of being a server physically controlled by the operator of the service? -MarkM- |
|
|
|
MBC was going up in value so fast the GFC was still losing money having to pay back their loan in MBC, so finally after much heated negotiation they have convinced the Martians to denominate the loan in DVC, so exchange rates should no longer cripple their operation (since they loan out DVC to their own customers aka debtors). This looks like it has put them back on track toward long term steady growth. Latest figures will be up at http://galaxies.mygamesonline.org/digitalisassets.html as soon as calculation completes. -MarkM- |
|
|
|
This would be much less of a problem if base currency has potentially infinite monetary base. (E.g. 50 coins mined forever.)
50 coins per block forever is GRouPcoin; so the coin you need is already out there... -MarkM- |
|
|
|
|
As BTC difficulty skyrockets and profit margins get tighter maybe the marginal little extra one can make by merging more chains will start to look more worth while to miners, resulting in more and more of the merge-able chains getting picked up by miners so those chains that went into hiding can start to think about coming out in the open again as blockchains like they originally were and merged mining can start to do what it was designed to do: allow more chains to be deployed economically.
-MarkM-
|
|
|
|
|
Well yeah even between blockchains is possible with multisig of some kind apparently.
The hard part is anywhere that touches fiat.
So okay, if a bunch of coins each having 21,000,000 coins each just like bitcoin all want to try using this coloured thing, how do they go about issuing their 21,000,000 coins each as colours on your system?
-MarkM-
|
|
|
|
|
It seems like plenty, People can even use it to record an address for dividends to be sent to on a per share basis.
-MarkM-
|
|
|
|
|
You could try it with namecoin to prove the concept. As it already provides a way of transferring ownership of arbitrary labels, it should be almost ready to do this right off the shelf. You might not even need to add a namespace specificalyl for shares, you could treat each share as a hostname within the issuer's domain maybe or something like that.
Or for example as well as having knotwork already in there for my .bit domain I could add knotwork-share-0001, knotwork-share-0002 etc for a bunch of shares and people can use namecoin to change their ownership.
-MarkM-
|
|
|
|
|
Shares are inherently centralised though so really the issuer might as well simply run their own system recording the shares, p2p is overkill and needless expense since regardless the issuer is really the only person who can validate them and is the person who ultimately has to provide them with value / redeem them / back them / whatever.
-MarkM-
EDIT: It does sound though like people offering to act as brokers or passthroughs or some such thing could be useful for people who do not want to run open transactions clients themselves to nonetheless be able to get exposure to assets that are run on open transactions...
|
|
|
|
There were actually a bunch of blockchains that operated basically like shares, in that their value was implicit in the "reserves" (assets) of the issuer who "backed" them by buying them back using those reserves. The lack of merged mining enthusiasm though foreced them to retreat for now into Open Transactions form, pending sufficient transaction volume for transaction fees to become enough incentive for merged miners. Though also the Massively Merged Mining project is also partly intended for the purpose of eventually deploying so much mining power that these chains will maybe be able to come back out in public as blockchains once that project has massive amounts of hashing to put toward helping secure them. It is a pity since so far all indications are that they are a very successful way of setting up a coinage; they have been performing very well. (See http://galaxies.mygamesonline.org/digitalisassets.html for some tables of valuations.) -MarkM- |
|
|
|
|
Show Posts
