Show Posts
|
Pages: [1] 2 »
|
Hello Anyone who is looking to buy merits can contact me. Thanks
|
|
|
Hello
I would like to sell Full & Senior Member Accounts at a very good price.
If you are looking to buy Merits then I can help you out.
You can send me PM for further details.
Thanks.
|
|
|
according to blocktrail.com , there are already > 13% "v4" blocks. v4 corresponds to BIP 100 Are these actually BIP 100 blocks, or are they just putting v4 in the header? Also, is this already discussed somewhere? It seems important (at least, if these are actually v4 blocks) but I don't see any discussion anywhere. According to the wiki BIP 100 is still a draft. The wiki can lag behind though.
|
|
|
Short description:
Problem: declining BTC price makes escrowed markets too risky for vendors.
Imperfect/ broken solution: Hedging. The escrow (usually the market maker) sells the escrowed BTC on an exchange for USD. When the escrowed funds are to be released, he exchanges USD back to BTC.
Proposed solution: A BTC - BUSD exchange, where BUSD is a virtual unit tethered to USD as follows. To create a unit of BUSD the market maker must provably destroy either 1 USD bill (burn it on cam) or the corresponding amount of BTC. The escrow is then hedged on this exchange.
Long description: Problem Anonymous markets (the infamous SilkRoad and its lookalikes) rely on escrow heavily. The reason is that sellers are anonymous and thus it would be too easy for them to scam buyers. The escrow is released when the buyer has received the goods, which may be days or even weeks after the transaction. During this time, the BTC price may change significantly. If BTC declines, as has been happening a lot lately, the seller suffers a damage. In reality they either have to make prices a lot higher, which cripples the market.
Hedge: An imperfect solution, that was actually implemented by the original Silk Road, is hedging on an exchange. Thus the seller has an option to hedge his BTC for USD. The market owner has an account on an exchange, where he sells the BTC escrowed. When the escrow is released, he exchanges these USD back to BTC and give these to the seller, charging a small hedging fee. The problem - for dark markets - is that this exposes the market maker to a huge risk. In fact it is hard to imagine a large market operating like this without a possibility to be detected; whichever way they try to hide their activity, it'd be too different from a typical trader, and would stand out.
Proposed solution: What if there was a completely virtual exchange, but for fiat currency? While this is impossible, it is possible to get close enough to this for the hedging purposes. The market maker simply creates a virtual unit, let's call it BUSD, and opens an exchange BTC for USD. Like USD, BUSD is a centralized currency, which is issued by the market maker. However, unlike the USD issuer, we want the BUSD issuer not to be able to print as much BUSD as he wants, since otherwise it'd be hard for the market participants to trust him to keep the supply in check. In order to constrain the supply, the BUSD issuer is required to provably destroy a unit of USD for each unit of BUSD he issues on the market. This can be done either by burning the bills or by sending the corresponding amount (using the exchange rate at the time of sending) to a black-hole BTC address. He then creates as much as needed this way and sells it on the market for BTC. There will be buyers, since there is a need for the escrow hedging, and the supply can be as small as needed to keep the price in check. The price of BUSD will then be kept close (slightly above) to 1 USD for BUSD by the market: shall BUSD become too expensive, the market maker can issue more and sell (for a profit). Shall the price decline, he can buy back some with the BTC he has in reserve from having sold the BUSD. Clearly he can also charge fees
What remains to construct is a mechanism for auditing the exchange, that is, to proving that it is not selling more BUSD than he had issued. The simple way is what is already used in the BTC world: the market owner publishes the list of all balances. This should add up to the amount burnt (for which there's proof). If any participant notices that his balance amount is not in the list, he will shout out loudly, denouncing the fractional reserve.
Finally, several markets can unite to create a "burnt dollar" exchange, using colored bitcoins as a token for BUSD, and making the exchange independent from each individual market, thereby protecting the hedged funds from any of the markets getting shut.
|
|
|
[not sure if this is technical enough, but I find this subforum more sensible. If the mods find it too light, please feel free to move to the general discussion]
Assume that, close to the block reward halving, the following conditions hold: 1) mining technology is saturated, so that no significantly improvement in efficiency happens nor is expected to happen soon 2) the price is relatively "stable" and no major jumps are expected soon 3) tx fees make for but a small part of the block reward
As a consequence, miners operate on a very small margin, spending most of the reward on electricity.
Then after the block halving, mining profitability nearly halves, and many miners have to switch off their equipment. The equilibrium is reached when half the miners switch off.
The market of mining equipment is over-supplied, the prices drop to almost zero. Thus one can buy all those switch-off miners - that represent half the network hash power- for a very small cost. I don't know what's "very small" (there are always at least shipping or acquisition expenses to consider), but let's just call it N for now.
Assume an attacker acquires all this equipment. Now that he has 50% hashing power, what's the cost of running the attack?
Let's say he wants to mine k consecutive blocks. With 50% power he should expect to wait 2^k blocks before he gets these. Running half the network for that long costs (since we assumed miners operated on low margin before the halving) 1/2 2^k BR in electricity where BR is the block reward before halving. Since during this time he also gets half of the new block rewards, the total cost is 3/4 2^(k-1) BR + N
Putting some numbers here: current BR=25 BTC; we can take k=6 (now some big exchanges accept as little as 3 confirmations, I guess all the big ones accept less than 6), we get 3/4 * 800 BTC + N. Now given the discussion above I think it's not unreasonable to assume N<200BTC, bringing the total to 800BTC.
Note that the last time the block reward halved, assumptions 1 and 2 were not satisfied, while 3 was. Next time 1 and 2 are quite likely to be satisfied, and 3 is satisfied currenlty. One can also calculate waht is the effect of the tx fees; but it's easy to see that for it has to be of the same order as block reward to be significant.
what do you guys think? Did I make any major mistake in this calculation? Has this been discussed and dismissed before?
|
|
|
short version: Offering BTC swaps on Chinese exchanges: are there any (hidden) fees, limitation, requirements?
long version: Trying to profit from the bear market without trading (which I am not good at). I tried offering BTC swaps at Bitfinex, and I have no complaints apart from that the interest rate has become too low. Right now it is 0.0055% daily, which, in my opinion, is completely useless. (To put it more correctly, not worth the risk of keeping one's BTC on an exchange.)
On the other hand, OKcoin swaps market seems to offer 0.1% daily (and that at no fees as opposed to bitfinex' 15%), which seems pretty good.
So I am considering putting some BTC there, and I'm wondering whether there are any "surprises" waiting. Such as: - hidden requirements, like: you can't withdraw your BTC unless you do our KYC check. (I'd prefer not doing any verification, apart from email verification) - hidden fees - crippling withdrawal limits - ...
I haven't checked the other Chinese exchanges, but I'd appreciate any feedback/experience accounts on those as well.
|
|
|
subj
If pools themselves were getting their work from p2pool and then distributing it to miners, they would - still collect user fees just as they do - offer users strictly smaller variance of payouts
users of small pools would - not notice any difference except smaller variance - not need to know anything about p2pool at all
p2pool users would be a part of a bigger pool so get smaller variance as well.
It would also lower the entry barrier for new pools. Instead of starting off with offering users 0% of the network hashrate, they would essentially start with that of p2pool.
As a result, smaller pools would increase in number, contributing somewhat towards decentralization.
Basically the only rational reason I see that would make a miner join a large pool rather than a small one is reduced variance. This is important if the difficulty is rising fast and the miner needs to recover his investment in the first couple of months (or never). The idea above solves this problem(I think).
|
|
|
I read in this thread that for m of n P2SH to be standard it must have m<= 7 and n <=15. To get around this, would it be possible to have a P2SH m of n script where each of the m redeaming addresses is another m' of n' script? If such transactions are posible, then I'm pretty sure one can build a tree of 2-of-3 transactions to achieve m of n for any possible m and n.
|
|
|
I've been thinking about the possible use of the public nature of blockchain to mitigate corruption.
Imagine a country where the currency is bitcoin. The government has one public address for the country's budget. All the taxes one pays should be directly traceable to this address. Then all the outgoing transactions the government has to explain. Each recipient has to sign the explanation with his key. If he doesn't, the government better explains to the taxpayer why it paid someone not willing to sign for the money. It is easy (and desireable) to make it possible to make the transactions anonymized from some point. For example, the chief of a police unit signs for the salary fund for the current month, then distributes the money. Each officer signs for his pay, but then he is allowed to use a mixer (his spendings are henceforth private).
Of course not a complete cure for corruption, but it seem this could go a long way to help.
|
|
|
Hi, may be I just fail at googleing, but I can't find a proper technical description of how maidsafe is supposed to work. I'm mostly interested in the proof of resource and whatever is the analogue of "blockchain" for the safecoin (the "token"). I'm not looking for the implementation details or the source code, just a paper to read so that I can understand how it is supposed to work. Their whitepaper is pretty vague. It just says that Safecoin .... will be injected into network using the storage space related mining procedure. What is this mining? Also for Proof of resource it doesn't say how cheating is prevented, how the transactions are ordered, etc. It just says If any cheating is detected, the used_space will be changed to reflect that. But doesn't explain who defines cheating, etc. In short, I'd like to see a proper paper with all the necessary crypto details and proofs wherenever necessary. Does such a paper exist?
|
|
|
sorry for an English post: I thought I'd find the target audience for it here. You can reply in Spanish if you like (I'm learning Spanish) So the question is:
is there a stable bitcoin market in Chile ?
I'll be moving there for a year, and I'm considering using btc for money transfer: buy with my european bank account, sell there. For this I'd need a "stable" exchange in Chile. By "stable" I mean low spreads and that it's not going to disappear tomorrow; we all know the price is not stable.
thanks
|
|
|
hi,
can anyone explain me how to make an Nlocktime transaction?
I just want to send all my funds to myself to be spendable in a year or so. Since it's "all my funds" I want to make sure it's safe.
also, will the current version of multibit and bitcoin-qt handle correclty a already spendable transacion which had an non-0 nlocktime?
thanks
PS Why do I want to do this - to block myself from gambling
|
|
|
here's a suggestion of how to drastically remove the need of trust for online (collective) wallets.
Why:
Online collective wallets have the following advantages: - mixing of users' coins - free or cheap transactions between users, including - microtransactions, - off-chain (i.e., not polluting the bitcoin blockchain) - ease of use But they have the following big problem: * You need to trust the operator not to run away with your coins or to get hacked.
The following simple idea can remedy the latter drawback:
Instead of one server handling the user coins, several (say, n) online wallets pool together, and every withdrawal has to be approved by m out of n of them.
In a bit more detail: each user is identified by a public key, to which the private key is kept only in his browser. The public key is sent to n servers. Every server keeps the ledger of all transactions of each user. The user may chose one of the online wallets as his primary wallet; this wallet will provide all the user interface to him, and will take any charges that are applicable. Any operation the user wants to make is signed with his private key. The signed request is sent to all the participating servers. Deposit address for each user are "m of n" addresses. So each withdrawal has to be signed by m of n servers. The charges a users' primary server wants to apply follow the same process: if they are internal, all servers put it in their books. If they are external (withdrawals) m of n servers must sign the transaction. If the rules for the charges are agreed upon in advance, keeping the books is straightforward.
Shall the user's primary server go offline/get hacked etc., he can still request to withdraw his funds from the remaining servers, and they can process it (as long as the number of online/not compromised servers is <= m)
From simple online wallets/mixers this can be potentially extended to more advanced services such as banks, casinos, etc. with the same idea: all participating servers keep the book for all users; withdrawals are m of n.
|
|
|
hi all, I think I have a solution to the following two problems with current provably fair gambling sites: 1) in off-chain sites, the site can cheat the user trivially in such a way that the user will know immediately he'd been cheated, but will not be able to prove it to third parties. (e.g., the site can just update the balance arbitrarily or pretend the user had bet on a different outcome) ( see this thread, full of flame and troll) 2) For those sites that attract investors for a share of profit/loss (such as just-dice), there is currently no way to prove to the investors that the site is fair; for example, the site owner could play anonimously and win arbitrary large amounts (damaging investors). The solution would require third parties to run an auditing service online. Of course they will not be able to manipulate the game, only to verify fairness. I imagine different gambling sites running an auditing service for each other, or large investors running such a service themselves. The cryptography of the proposed solution is quite different from what is currently used; instead of hashing it would be based on signatures. Since writing up the complete proposal takes considerable time, I will do it only if someone is actually interested in implementing it. COding this will require substantially more work than for any of the current solutions; in particular, user-side JS cryptographic signatures (kind of like on blockchain.info) will have to be implemented. Please let me know here or by PM if you are interested.
|
|
|
here's a possible cheat for a site: change the game the user played. If the user bets on "high" ("red") and the result is a win, just pretend he bet on "low" (or "black" or whatever), so the result is a loss. Or change any other parameters of the game, such as odds. Keep everything else (hashes, etc.) the same.
The user would know he'd been cheated, but (s)he would have no way of proving it to anyone.
This problem does not exist with on-chain gaming sites, where the bets are made publicly.
I think this can be solved by introducing used-side private keys and randomness, but this complicates the verification considerably
or am I missing something here?
EDIT: realized that it's even easier to cheat: just change the balance to an arbitrary value. This problem does not exist in on-chain as well as in real-life casinos
|
|
|
subj. Fast-increasing difficulty makes it impossible to recover what you lose due to variance in time between blocks when mining on a smaller pool. So one is forced to choose a larger pool (=small variance) or straight PPS; good prices on PPS are also offered only by larger pools, for the very same reason.
ASIC producers are as much interested in network security as everyone else using BTC, so they need to make explicit support for P2Pool, may be invest in making the software easy to use as well.
|
|
|
Selling 60GH BFL single.
Ships from EU. Can ship international at your cost.
Included is a high-end PSU.
Escrow accepted (but please choose a reputable one).
edit: sold
|
|
|
|