I feel like I have to explain myself a lot.
This is to be expected when you take people money in exchange for a service, and you don't deliver this service, or don't deliver it in time. You set the rules beforehand, your customers accept them when they engage in a commercial relationship with you, then both parties (yes, that includes you) have to abide by those rules. And the real problem is I have to spend a couple hours updating the block chain each time I connect to the internet.
Have you considered investing into a hosted server, or using a client that doesn't require a blockchain such as Electrum? Maybe you should wait until you have a proper setup before you propose commercial offerings that you cannot afford. |
|
|
|
|
Any reason why yesterday weekly interest payment on my account is still listed as "pending"?
|
|
|
|
No limit until the 6th on July, at the 6th of July, deposits will be closed for a unknown time.
If you want to attract new investors, maybe you should drop this from the OP. |
|
|
|
What branch is it built from? The ArchLinux package builds from git, but needs to know which branch to start with (preferably a stable one, so that the build instructions don't need to be changed at every release). Will that be put into master? |
|
|
|
|
You mean a > 20 BTC monthy deposit will get a 5.4% last weekly payment? Does that make 13.5% a month?
|
|
|
|
I figured, maybe the system remembers what files you access frequently and pre-caches them on load. I guess not...
It can, if you use something like preload (but it is not the Linux kernel itself that does that). |
|
|
|
(2) At least in Linux, the caching seems to hold between boots -- not perfectly, but I just tested it on my laptop and it scanned in 30s after a reboot. The only way I can get it up to two minutes is to do an explicit cache dump (gmaxwell pointed out that "echo 3 > /proc/sys/vm/drop_caches" does exactly that).
Caching does not hold between boots at all. But by dropping the caches using drop_caches, you are also probably dropping a lot of pages belonging to the libc and other shared libraries, which puts you into a worse situation than when running armory for the first time after boot if other applications have been started before it: those applications have probably already loaded some of the shared libraries pages you will need. |
|
|
|
FYI -- while I had downtime on vacation, I started playing around with LevelDB. I think I decided that changing the engine to maintain its own blockchain using leveldb is not only going to be extremely useful, but not terribly difficult either (the last round of blockchain engine updates properly modularized the blockchain management from the rest of the program).
--First and foremost, all these crashing issues can go away: I'm pretty sure they're related to "hacking" my way through the blk000X.dat files which are being maintained by another process out of my control (that's not to say I did it right or that it can't work, but it seems like an unnecessary situation).
--This also will allow users to connected to any full node, as long as it is 100% trusted -- it doesn't have to be localhost. The downside is, if it is localhost, you'll be maintaining two copies of the blockchain.
That seems like an important downside to me. If you are going to store the blockchain data, can't you replace bitcoind by incorporating the networking code directly into Armory? Once you handle the blockchain in armory, it makes little sense to keep a copy of the blockchain in bitcoind, since it will have no use. --Faster! The benchmarks I ran showed that a full scan can be done in like 15s even on a non-SSD. Granted, that's when much of the file is cached by the OS already -- but it's still faster than what I've got right now which also should benefit from OS caching.
The benchmark with cached data has no meaning. People don't stop and start armory all the time, the empty-cache case is the interesting one. I know I keep pushing back beta -- but it's for a good reason: I think Beta is going to get a lot of attention, and I don't want 5 minute load-times and 700 MB RAM usage to be the focal point of the discussions/reviews. I think I can get all this implemented in a couple weeks, then a couple more weeks of testing. Then a few of Armory's achilles heels will be gone!
Well, right now, one of the strong points in Armory is that it takes only 700k extra data in my home directory. If it now takes 3.1G (as bitcoind does), that's bad. And I'd be interested in looking at the cold cache startup time, as this is the one that will appear in benchmarks. |
|
|
|
|
Something is missing in the contract: the case of pirateat40 simply stopping his fund and reimbursing the principal. In this case, you should add that you will place a bid at face value for every bond. Right now, if pirateat40 choses to stop his operation without defaulting, the bonds become worthless while you can keep all the invested money.
Also, it would be great to let people the possibility to buy out if the interet rates drop too much. For example, for a change of more of 0.5 points, you should place a bid at face value for every bond for at least two weeks.
|
|
|
|
Can they SMS to international numbers then? I travel into Mexico at times and if I ever wanted to buy/sell there(mostly DF) it'd be handy I suppose.
I guess they can, since I am in France and they are based in Finland. |
|
|
|
I'm assuming both parties have their netbook or laptop with their BTC client, you see the cash, you send the BTC? They verify the incoming transaction then hand you the cash? Each with their own PC and BTC client would be preferable to avoid suspicion. I wouldn't trust someone merely showing me a block explorer of my address and their transaction...not on "their" PC at least.
No need. Look on their site: you just need to be able to send and receive SMS. The seller sees the money, sends a SMS to release the escrow, and the buyer receives a SMS saying that the escrow has been released, exchange is confirmed and money transferred. Two different secret codes are used (one to release escrow, one to confirm escrow release), so that even if only one of the two people has a cell phone the escrow can be released and the release verified. In my transaction, the seller used his smartphone to release the escrow, but he could have used a dumbphone as well. I'll probably try the service during my next trip abroad, where I will have cheap SMS but expensive 3G. |
|
|
|
You are the second person to report this problem. It's strange that the SelectCoins code has been in use for 8 months and there's never been a hint of a problem with it, but suddenly multiple people run into this!
Make me the third one. I sometimes see this problem after I accept to add a fee to a transaction, but had no chance to properly report it. |
|
|
|
What I want to know is how he got a tagline
Simple: I registered on this forum using the name in my tagline. However, when I started to use #bitcoin-otc a few days later, I did it under OneEyed as it has been my registered nick on freenode for more than 8 years. I also wander on other IRC channels at the same time, so I didn't want to switch nicks or to use multiple clients or connexions. In order to unify my forum and IRC names, I explained the situation to theymos and he kindly accepted to perform a name change. But to make sure I wasn't trying to deceive people I previously interacted with, he told me I had to wear this tagline for at least 2 weeks, which I find kinda cool anyway  |
|
|
|
Bottom line: seems to be a false alarm, Problem solved
Maybe you should update the title of the thread, to use something like "[SOLVED] Discrepancies in withdrawals listing" so that people don't freak out when they see it in the list of topics. |
|
|
|
Et je tenais toutefois à dire qu'à part ces délais excessifs pour les retraits en euros je suis un utilisateur satisfait de bitcoin-central |
|
|
|
Le virement demandé sera envoyé sous 48h, donc demain !
Merci de cette précision. Cependant, je ne trouve pas mention de ces 48h, ni dans les terms of service, ni dans la FAQ, ni sur la page permettant d'effectuer un retrait. Je ne trouve que cela : the Bitcoin-Central service will process payments and transactions as fast as possible, however, delays may happen and be beyond the Bitcoin-Central service operators control;
Je n'ai pas l'impression que « 48 heures » soit conforme à « le plus rapidement possible », ou alors il faut se poser des questions sur le dimensionnement de l'équipe ou sur l'automatisation de ces retraits Quoi qu'il en soit, il y a disconcordance entre la réponse apportée ici ("48h") et les terms of service (" as fast as possible"). Si vraiment ces 48h sont maintenues, peut-être faudrait-il le faire apparaître plus clairement. Édition 2012-08-06 : retrait du calendrier des paiements en fonction du jour de la semaine, qui dépend en fait des banques. |
|
|
|
May I ask, what country do you reside in?
France. |
|
|
|
However, his otc ratings are a confusing mixture of phony stuff used by sockpuppets and scammers (borrowing 0.3 BTC) and legitimate stuff (SEPA transfers, rating by DeaDTerra, etc)
When you have only a few occasions to use #bitcoin-otc (for €, bitmarket.eu usually has better offers), any rating is good to take |
|
|
|
Please remember that day-trading is negative-sum; that is, excluding the exchange, on average people lose.
If bitcoins are considered a currency, I'm not sure this is true, as the system isn't a closed one. Some people will daytrade while others will exchange only in one direction (compared to trading dividendless shares, where the only thing you can do after buying a share is sell it back). Everyone may win, and everyone may lose (except the exchanges, which always win). If the one-direction traders are included, it is definitely negative-sum. The speculators can only win if the one-direction traders lose. Why? Let's assume I have € and I want to buy something in $ because it is cheaper (quite a common scenario, when hardware vendors tend to sell something at $99.99 in the US and 99.99€ in Europe, when 1€ = $1.3), even when I include the currency exchange fees. In the end, I may be very happy and have made a good deal by having exchanged my € for $, while the person doing the reverse transaction may be happy because he made a good deal in selling his $ for € at a better rate than in bought the $ initially. This is a win-win, both for me and for the speculator. Why is that so? Because the hardware vendor is not included in the loop, he does not explicitely use an exchange. He will use the $ to pay his employees in the US, and the € to pay his employees in Europe. He may convert some $ to € or some € to $, but that would be small fraction of what he earns. |
|
|
|
According to the rules, I cannot participate because I haven't spammed the forum enough to gain full membership yet. If however you accept the risk of me having created my account a few days before this experiment so that I can steal those 2-3 BTC, you can send the token to 1MJS3FuUrWmyfvvRnm5gUYvpuFkYDzxCP4 |
|
|
|
|
Show Posts
