For BTC.738, Maple is as cheap as it gets. Delivery in EU only BTC.500 for unlimited quantities, except over 500 pieces it is free  I will likely buy from you as soon as I like the market conditions and your price is still as competitive as it is now. I hope you'll have "VAT free quota" to germany left at that point. |
|
|
|
A big thanks to all those helping putting up ask walls around 50, the longer it stays under the better. Personaly, I am not taking that chance, but +rep for those who do.
Well I don't know, personally, I can't wait to cash in some coins for 10k a piece. I'm getting tired of not being very rich.This needs to be on a t-shirt. |
|
|
|
This weekend dip theory may be something that cannot be traded reliably anymore. Who knows. We'll see.
Unfortunately whatever happens on this weekend will make us none the wiser regarding reliability of this strategy. Just one more datapoint in a long series that is and will keep allowing statistically rather insignificant conclusions only. |
|
|
|
As a trading newbie i dont understand at all!
Looking at the wall image a couple of posts back, it seems like there is a vertical line to the right... that suggests to me that it would be hard for the price to move up.
The line to the left is way less steep... doesn't that mean it is easier for the price to drop?
How are you supposed to read these images?? Why do you all think the price is about to go up? What are you looking at??
"eating a wall" is not a bad profit opportunity: all the small traders are holding back, because they think: "wow, a huge wall. we're going to be stuck here for a while. maybe I'll trade the rage for a bit". They either sell a little bit right below the wall or wait. Now a big fish can come along and just gulp the whole wall. What might quite likely happen is all the small fish will be thinking: "wuuut! That wall got pulverized like it was nothing and now the path is clear to the upside, buy buy buy". So the price will shoot abover the point where the wall was quite a bit. The big fish can then start to take profit. |
|
|
|
Seriously if we go through $50... My fiends ask my everyday, can I buy? How much risk? Are you nuts? Dafuq is a hard fork?
Too much pressure, lol.
Tell them to make their own decisions and live with the consequences of their actions (or non-actions). |
|
|
|
resulting in that a lot of capital is freed up.
//DeaDTerra
no that much if you look past posts we did stay @ 90k usd lend most of the time whit some days above 100k we need a history data for loans per day both in USD and BTC that would be absolutely helpful |
|
|
|
Hello all,
I'm a programmer proficient in LAMP setups. Having built websites for large and small customers. I have always been facinated by Bitcoin and everytime I think up a new business venture for Bitcoin, one thing stops me. My lack of understanding for handling bitcoin and the server infastructure required. Obviously I dont want to be making any mistakes and the trouble is most my ideas result in me holding money is some sort of hot wallet. So what can you the bitcoin community suggest to me? I've learnt from the mistakes of others and I don't want to repeat history, so is there any direction I can go?
Regards
I guess it depends on the idea you want to implement, but most of the time, you can do away with hot wallets altogether. A good way to get started is; to print out a huge list of paper wallets (on an offline computer) and process any withdraw request from user manually. you can process deposits automatically with a third party tool ("bitcoin Notify" ? not sure of the name)that send a HTTP POST to your specified script when ever one of your wallets gets a deposit. this way you can be sure as long as the paper wallets are safe, your safe, even if your site gets hacked to shit. For this case (no automatic withdrawal by users necessary), you could use a similar but probably a little more elegant technique called type 2 deterministic wallet: a public seed can be on the server and is used to generate a sequence of addresses. A corresponding private seed (on a non-exposed machine) can be used to generate the sequence of matching private keys. In fact, I think you can just use electrum or armory (dunno if multibit has caught up yet) to "spend" the money. http://acceptbit.com/ uses this approach, for example. |
|
|
|
|
wow, I've only been lurking on the lending page for a couple of days. Hadn't seen $13,500 on offer at VIR before. Is that outside of the norm or not?
It seems USD demand is very low currently. Probably noone wants to risk going long on leverage with a (still possible) crash or at least decrease. Am I analyzing this correctly?
|
|
|
|
I wonder how these dumbasses survive life on daily basis.
A hard fork like this has caused the whole btc economy on hold. Potentially MANY transactions can be doublespended. If BTC had gone mainstream, it would have been $1millions lost in doublespending.
But double-spending doesn't lose any money. In fact, it doubles money, hence the name. It's all good! Here a coin, there a coin, everywhere a coin coin. |
|
|
|
Can't you see how stupid this is?  The thread is 19 posts long and only a single bid in the auction so far. I am considering giving up. Yes, you can scam each other as much as you want, I thought I would like to be a part of this community, but it is too much of a burden for a normal person to play this hide-and-seek. If anyone cares, the silver is now selling at about spot price, 20% cheaper than any dealer in the EU. By the way, the escrow was added. I am fine with John K. I can understand your concerns and I posted repeatedly in the "trust noone" thread that it's important to trust people and fuck it, people should just trust people, otherwise what kind of world would that be? However you need to understand there have been a lot of abuses of trust on these forums. This is due to the nature of the money we use as you will surely understand. With other forms of payment you usually have either chargeback capability or identifying information of the payment receiver. This is why you "cash first, it's like it has always been in the metal business" doesn't quite apply. Thanks for offering use of escrow. It's a rather easy way to make things possible (apart from building trust yourself here and/or on #bitcoin-otc). I'll have to find out who "John K." is, though. |
|
|
|
Hi all. Eesti Investeerimishobe OU ("Estonian Investment Silver Corp."), incorporated in Tallinn, Estonia 2009, seeks to offer European bitcoin users an unparalleled experience when shopping for precious metals. By this we mean that you can buy cheaper than from others and also less hassle. We respect all fine businesses out there, but intend to be the cheapest in Europe.
googling for "Eesti Investeerimishobe" turns up 2 results: this thread and a seemingly unrelated page about silver investing. Do you have a web-page? |
|
|
|
I take it you didn't watch the whole movie....
Are you suggesting Bitcoin will be defeated by an older version of the code? Oh wait...! hahaha. priceless! |
|
|
|
Currently the merchant just polls the transaction for the number of confirmations. The client never says "this one is non-reversible". This kind of monitoring system would require the client to make a judgement call.
I don't think you even need to change the client, it's about if the merchant delivers the final goods or not, so it could be an additional system that just checks the blockchain for possible forks. it's not quite that simple: which blockchain? |
|
|
|
I also understand why the 0.8 chain was chosen: if the 0.7 chains was chosen, double-spends would even now still be possible against merchants who are still asleep about the issue, which is worse. That's exactly the wrong way round. The 0.7 chain was chosen, because this would have happened if the 0.8 one would have been chosen. thanks, fixed in my post |
|
|
|
That particular theory, if correct, suggests that it's safer to have saved memory pools between loads
Would that have helped in this situation? The first spend had already been mined on the 0.8 chain, and so wouldn't have been in the mempool any more. Even if the mempool persisted when the miner switched to 0.7, the first spend wouldn't be known and so the double spend would still be added to the mempool when broadcast. Probably true. |
|
|
|
gmaxwell answered it: a large majority of mining power switched to running 0.7 -- which meant restarting the miners and clearing their memory pools. With the right dynamics, a rebroadcast would not repropagate because most nodes had not been restarted and would not rebroadcast it. Thus, those miners that restarted, started mining without it, and accepted the double-spend as a first-spend.
gmaxwell and gwillen just enlightened me a little further on #bitcoin-dev. The scenario seems likely to me now especially after I got the info that only about 10% of the miners had been on 0.7 before the split. They probably had the initial TX, but just didn't find a block in time. I also understand why the 0.7 chain was chosen: if the 0.8 chains was chosen, double-spends would even now still be possible against merchants who are still asleep about the issue, which is worse. A question still: rebroadcast? How does that work? Who would rebroadcasts the tx and triggered by what? That particular theory, if correct, suggests that it's safer to have saved memory pools between loads, to make the keep/drop decision deterministic.
Saved memory pools, or maybe something in the protocol that enables syncing of the mempool from other peers? Sounds good, but again I don't know enough. EDIT: fixed 0.7/0.8 mixup |
|
|
|
[..]
Hmm, that begs the question: why run the instances yourself in the first place? Why not simply ask a bunch of clients about their opinion about the latest block (height and hash or whatever) via the protocol itself? Would that also be workable or does that approach have a problem?
could be something like this be implemented on the client to measure a potential fork? probably. I don't know enough about the protocol myself to answer this question. But say you have 8 connections and one reports a different hash for the newest block (or a lower chain height)... this wouldn't in itself mean much. You'd have to have access to a larger sample, so maybe it'd make sense to implement this as a service with an api that publishes some kind of "alert level" to be used by merchants to halt accepting bitcoin above a certain treshold. |
|
|
|
Any guesses as to the reason it didn't show up in the pre-0.8 branch? I don't see any reason that the original transaction could be systematically rejected by one branch and not the other. Even transactions that hadn't made it into blocks in the pre-0.7 branch should still be in the nodes' memory pools and double-spends rejected.
Has this been answered? Indeed, this is a good question. Every client should have refused the second transaction, since it was a double spend. So what happened? A miner somehow received it and confirmed it because of the higher fee? Stupid question: did everyones 0.7-client crash (or restart or clear the mempool) upon failure to commit the big block? That would explain it, no? If that's the reason, maybe the "mempool" should be a "diskpool". |
|
|
|
|
I don't understand how this double-spend even worked. Shouldn't his first tx have ended up in both chains in the first place? Why wasn't it included in the 0.7 chain?
|
|
|
|
Shit, if someone had said to me last night we'd be back in 45-46 territory today, I would've laughed.
You probably would've laughed even more if someone told you that some dude managed to double-spend BTC 211. |
|
|
|
|
Show Posts
