Search content
Sort by
Showing 14 of 14 results by aan
Brainstorming
I'd like to introduce a concept of a new feature called Account Control. This feature will allow to do different things with ur accounts. For example, u will be able to set a lock on an account to prohibit any outgoing transactions until a special condition met (e.g. an incoming transaction from a predefined account). Another example is Pooled Forging, when an account leases its forging power to another account.
Please, post here what u would like to see in Account Control.
I'd like to introduce a concept of a new feature called Account Control. This feature will allow to do different things with ur accounts. For example, u will be able to set a lock on an account to prohibit any outgoing transactions until a special condition met (e.g. an incoming transaction from a predefined account). Another example is Pooled Forging, when an account leases its forging power to another account.
Please, post here what u would like to see in Account Control.
I'd like to see spending limits. For example so that I could only spend a maximum of 100 NXT/day from an account. Trying to steal this account would be less profitable.
Hm.. well, now the 10 NXT transaction disappeared from my list completely. Never got 1 confirm.
That and my balance not updating.. something ain't right.
That and my balance not updating.. something ain't right.
It seems to me the balance doesn't (at least not immediately) update on the UI until you restart nxt/ look through the API.
Balance is not updating on the UI. I had 1117, sent 1000 + 30, still shows 1117.
API shows: (87 I think, which would be correct)
{"balance":8700,"effectiveBalance":87,"unconfirmedBalance":111700}
API shows: (87 I think, which would be correct)
{"balance":8700,"effectiveBalance":87,"unconfirmedBalance":111700}
Try F5 (refresh)
Refresh didn't help, but the balance updated after I restarted Nxt.
Balance is not updating on the UI. I had 1117, sent 1000 + 30, still shows 1117.
API shows: (87 I think, which would be correct)
{"balance":8700,"effectiveBalance":87,"unconfirmedBalance":111700}
API shows: (87 I think, which would be correct)
{"balance":8700,"effectiveBalance":87,"unconfirmedBalance":111700}
Quote
Let's wait when BCNext fix found bugs.
ok, but we need to extend the login screen, explaining the brainwallet.
otherwise we will have many users with simple phrases just for a test
and wondering why the account has coins or more worse why they are
gone. if users stating that nxt-coins are not safe to hold, you won't get
back the trust easily.
hear me now and believe me later...
Initial bugs are usual.. I am not saying everything is alright with Nxt, yes we may wake up tomorrow and see a crucial bug that fucks everything has been found, but unless such a thing has occurred, no need to scream..
Yes some people may lose their coins, yes some kids may be lost on the way from school to home. Is that the fault of Nxt or the school or the home!?!
How about adding a "make new account" button to the account window that auto-generates a passphrase with sufficient amount of entropy?
In general, what you said sounds like a good way to do all kinds of betting services. People not releasing their funds, or not releasing them in a timely fashion, would be just contained in the rules of the game. Some people will probably not release their money even if they get something in return, but that could just be subtracted from the winners amounts. And in many cases the service provider would be position-neutral, and the site could be run with zero capital. I wonder why this kind of thing doesn't seem to be standard by now.
Even without the use of a mediator this kind of system seems quite good to me. The risk the user of a site like this takes would be that he wouldn't get any of his winnings, but would get his own money back. In an extreme case the operator of the site could refuse to release anybodies money, but he wouldn't get it either. The whole site could also be shut down by the authorities, with the same result.
Even without the use of a mediator this kind of system seems quite good to me. The risk the user of a site like this takes would be that he wouldn't get any of his winnings, but would get his own money back. In an extreme case the operator of the site could refuse to release anybodies money, but he wouldn't get it either. The whole site could also be shut down by the authorities, with the same result.
I guess you fundamentally misunderstand how betting works. If I put a dollar on the line and you put a dollar on the line and then "I get my dollar back" I've just been scammed of a dollar, the one that used to be yours and you lost.
The idea that you're "protecting" my dollar by allowing the other party to steal my other dollar if they wish to do so is ridiculous. I wish no such protection, I wish to have the guarantee that the other party can't control their dollar, so I can win it. The other party wishes the same guarantee about me.
Basically betting is exactly the opposite of this scheme you're proposing. The fact that BitBet is doing thousands in bet BTC a month whereas an implementation of your idea doesn't even exist in practice should be sufficient empirical evidence that you're wrong. Why isn't it?
I think the method would do something valuable, although it is not a completely straightforward transaction which is based purely on trust.
The multisig protection would at least defend against a catastrophic loss, for example the site getting hacked and everybody losing their money.
Here is another example that jumped to my mind. It is also a kind of a bet. Person A makes a promise to send B a package in the mail and B makes a promise to pay one bitcoin. The other person is in effect betting on receiving the package and the other on getting the money. Person B pays 1.5 bitcoins to a multisig address. After he receives the package, he creates a transaction to pay 1 bitcoin to A and 0.5 bitcoins to himself. Both have an incentive to sign the transaction because they both get more than zero bitcoins.
The situation where either one of them refuses to sign the final transaction is a kind of an outlier which doesn't happen if the participants are acting rationally.
In general, what you said sounds like a good way to do all kinds of betting services.
Well, yeah, I was thinking about it since 2011... My plan was to start with BTC/USD futures, and then to expand into options, prediction market, betting, etc.
Never got around to it, though
I wonder why this kind of thing doesn't seem to be standard by now.
I wonder about that too... Perhaps people simply do not give a fuck.
Even without the use of a mediator this kind of system seems quite good to me. The risk the user of a site like this
In an extreme case the operator of the site could refuse to release anybodies money, but he wouldn't get it either. The whole site could also be shut down by the authorities, with the same result.
Well, it would be great to solve this problem...
For example, it is possible to give a trusted 3rd party an ability to return funds back to user, but only after a large timeout. Say, two years... It is possible that users and this 3rd party will collude, but presumable it will be detected before timeout, and so it is possible to punish this trusted 3rd party before timeout.
Would it be possible to return the money automatically after some period of inactivity, without any action by a mediator? This could also be included in the rules of the game, which the user would know precisely when he starts using the site. The site could also be run on any kind of shady web server in any part of the world, without a big risk by the user.
I personally would trust an automatic return of money more than any mediator, who could also disappear etc.
In my opinion, the worst thing in this scheme in general is that the winners have to wait for the losers to release their money. Of course this could be mitigated with the site keeping some amount of buffer funds available. And the buffer would be there just to speed up the payments, and not be an integral part of the operations.
Please elaborate further, how this could be done. We have no need for the coins before the maturity, so if there is no risk to us, or hassle to the user, we certainly want to give it a shot.
The basic idea is that funds are blocked in such a way so both service's and user's signatures are require, i.e. neither service nor user can move money on his own.
There is a risk that user won't unblock funds when he should.
Normally this isn't a problem as you can give user an incentive to unblock funds. For example, user deposits 110 BTC, puts 100 BTC into a bet, loses it. He still has 10 BTC on account, and he needs to unblock whole sum to get it.
However, there can be a problem with users who are stupid assholes, are dead or want to ruin service financially at their own expense.
I don't know how likely are these scenarios, but it's possible to try to fix it using a more advanced scheme, say, 2-of-3 signature: some trusted 3rd party can unblock funds when user isn't cooperating.
As for the tech side, in the most minimal way you can generate a private key from a user's password in browser and use it to sign multi-sign transaction. It is relatively easy to implement.
People did something like this via command-line interface... However, as far as I know, currently it isn't used in any of user-facing apps. blockchain.info has a page about escrow, but it isn't present in wallet.
In general, what you said sounds like a good way to do all kinds of betting services. People not releasing their funds, or not releasing them in a timely fashion, would be just contained in the rules of the game. Some people will probably not release their money even if they get something in return, but that could just be subtracted from the winners amounts. And in many cases the service provider would be position-neutral, and the site could be run with zero capital. I wonder why this kind of thing doesn't seem to be standard by now.
Even without the use of a mediator this kind of system seems quite good to me. The risk the user of a site like this takes would be that he wouldn't get any of his winnings, but would get his own money back. In an extreme case the operator of the site could refuse to release anybodies money, but he wouldn't get it either. The whole site could also be shut down by the authorities, with the same result.
I think there has to be some kind of way to store money more securely as more people get into Bitcoin. At least something like a separate device, like your mobile phone, to confirm larger purchases. Maybe some kind of bank where you can go and show your ID and they'll release your money to you.
Can someone help me? I've downloaded the latest version (Windows Installer 1.7) on Windows 7 (32-bit).
"The version of this file is not compatible wit the version of Windows you're running. Check your computer's system information to see whether you need an x86 or x64 version of the program, and then contact the software publisher."
"The version of this file is not compatible wit the version of Windows you're running. Check your computer's system information to see whether you need an x86 or x64 version of the program, and then contact the software publisher."
I had the same problem, and just downloaded the code and ran it from the command line.
I'm reading bitcoinj examples, and noticed this: "PingService .... sits on the network and when it receives coins, simply sends them right back to the previous owner, determined rather arbitrarily by the address of the first input."
What does this mean? What do I do to get the previous owner of the coins I receive, with certainty?
What does this mean? What do I do to get the previous owner of the coins I receive, with certainty?