My question is this. If a town wanted to just create its own currency, and take one bitcoin and 'color' (label) each satoshi in that bitcoin and call it a Foxy.
1. Then at the most there will ONLY ever be 100 million Foxies?? In theory you can take another coin and say that those are Foxies too. This isn't implemented in software now, but it is an expected feature. 2. And those foxies would not really be further divisible into smaller units?? Yes, that's a limitation of the technology... Although there are some alternative proposals. |
|
|
|
Next steps for this bond... It's been nearly a year now that I've been operating it. I've learned a lot, and had a great time running it for everyone. My goal has been to repay the principal and then some within the first year, giving every initial purchase a profit. Despite this goal, after almost a year of operation only 0.181 BTC of the initial 0.43 BTC price has been repaid on a per-bond basis. Even more upsetting is that in the nearly year of operation, that gap of 0.24 BTC is worth nearly 10x what it used to be in most fiat currency conversions.
Bottom line, this issue has lost bondholders money, and with the way difficulty has been going up, it is not showing much promise in terms of paying it back anytime soon. You shouldn't feel bad about it. Fixed-hashrate mining bonds are effectively a bet that exchange rate of a cryptocurrency won't go up. The reason is simple: if exchange rate goes up, total hashrate goes up and bond's dividend payouts go down. (Or, from a different perspective, higher exchange rate allows others to sell same hashrate at cheaper price.) So it can be used to hedge one's position. If you own both cryptocurrency and mining bonds on it, you profit either way: if cryptocurrency price explodes, you profit from it while mining bonds sink; if cryptocurrency stagnates, you keep collecting dividend. So, well, Bitcoin price shoot up ~20x, Litecoin price shoot up ~75x against fiat. So it is normal that bonds became worthless as people profited. Of course, some people did not understand that it is a hedge... But, well, how hard is it to understand that hashrate increases? |
|
|
|
As I said in another thread, the word "coin" here is the problem. People see coins as small, semi-worthless denominations of a larger unit,
Ever heard of gold coins, cretin? I guess they need rebrand them too... |
|
|
|
Oh really? I'll check that sometime. But it *does not submit again on refresh* I've just checked: you're wrong. I've just submitted two orders instead of one this way, both on litecoinglobal and on btct. It is easily reproducible: You need to wait until it shows redirect page, and then hit F5 before redirect happens Browser asks whether you want to submit form again. And it is trivial to reproduce multiple click on a button problem too. While we are here, I'll explain how it should be done: 1. There should be protection entirely on server side. You cannot rely on things which happen outside of your server. Doing a redirect DOES NOT solve the root problem. Blocking buttons with JS DOES NOT solve the problem. 2. Each form should get an extra field with unique ID generated on server. (If you feel like that you can make it server-signed, then it doubles as CSRF protection. But it isn't necessary. Any random ID is fine in this context.) 3. When server receives POST request it should check whether form with such ID was already submitted. If yes, cancel and show error. If no, add ID to database and perform the action. (If you use proper SQL database you can just rely on unique constraint: DB won't allow you to add ID more than once, so it is secure against all sorts of race conditions as long as SQL database is properly implemented.) People who write web applications usually only consider how it works in ideal case when communication is instant and there is no way to get it aborted in process. But they really should understand that client and server communicate with each other with use of a certain protocol. The fact that we have HTML and JS on one side and PHP on other side changes nothing, it is still a protocol. And so if you have a protocol message which submits an order, you need to consider a scenario where such message gets sent twice. As there is non-instantaneous communication there is no way to make sure that client and server state are synchronized (Byzantine general problem is applicable here), so... see above. Blocking buttons is only a cosmetic solution, you can't really rely on it... It's a bit easier to understand this when application is AJAX because at least you see an "API", but still developers fail to understand that communication between client and server isn't perfect. ICBIT.se got a lot of flak because of a problem with client and server state not in sync. |
|
|
|
Even if he refreshed the page, which is completely underestimating burnside if you think it would FWIW I once bought twice the amount by clicking 'buy' button twice. Apparently it DOES NOT detect double form submission. |
|
|
|
The BCTCT system glitched and paid out twice. I don't know if it was reversible, but please do the right thing and hold your coins for now.
Isn't it easier to reduce next payment(s)? Apparently you had enough coins. Some people have reinvestment programs so I doubt that you can cleanly reverse it even if nobody have withdrawn... |
|
|
|
|
ra2YSfsFJWSBzLPCtQcp4uZNoQ18y2ZcbJ
|
|
|
|
This is all kind of over my head here and possibly off topic, but to aid in anonymity in any mixer no matter the number of inputs/outputs and no matter who inputs the coins, what about the possibility of instead of immediately crediting the outputs, the mixer could issue a "receipt" that could be cryptographically printed on a smartchip or something. This "receipt" can be used just like physical cash and passed around in transactions with no record in the blockchain until it is redeemed to the mixer later, which adds anonymity and the convenience of physical cash.
It was mentioned above that you indeed can get better anonymity if you trust the mixer... That's just plain Chaumian cash. |
|
|
|
Dude, do you realize that you make it sound as if it was literally a Ponzi scheme? |
|
|
|
I even tried going back over previous whole page of posts be see nothing about Ubuntu at all. Mention of Ubuntu is in reddit comment: I did try, but devcoind process that I started on the server ended up consuming too much CPU and ultimately crashing. I think the latest release is either broken or doesn't work well under Ubuntu 12.04. I'm running 64 bit Ubuntu server 12.04 and I was using the Devcoin binaries provided on Sourceforge. I also tried compiling it from sources on Github but ran into compiler errors (wasn't missing dependencies)... Main issue is high CPU usage, while all other coin daemons are fine.. This is what prevents Devcoin support in ALTcointip on reddit. bitcointip is basically a web wallet for reddit users, with one twist: it is possible to pay coins just by adding one line to your comment like "+tip 0.1 BTC", and it is possible to pay that way even to a person who haven't yet created a wallet. So this helps to spread the word a lot. You know, when person receives a tip cryptocurrency isn't just a weird concept anymore. ALTcointip is the same thing, but for alt-coins. I think it would be cool to pay developers with devcoins, so it's a pitty that we can't get that working because of problems with devcoind. |
|
|
|
ALTcoinTIP goes live on reddit, but it doesn't include Devcoin because there was a problem with devcoind: http://www.reddit.com/r/ALTcointip/comments/1esl7u/altcointip_bot_now_live/ca3mq2wCan we help him to investigate and fix the problem? Is there a bounty for things like altcointip devcoin support? (I understand that general idea is that bounties go for open source things, but on the other hand cryptostocks got bounty even though it isn't open source so apparently it depends.) |
|
|
|
Так и не понял имеет ли смысл клонировать кошель на 100500 виртуалок чтобы хоть увеличить шанс POSа? В старой версии клонирование даёт очень небольшой прирост, доли процента. В новой -- хз, нужно считать. |
|
|
|
Isn't it possible to color any coin in the blockchain? Does it have to include the Genesis block only? Yes, it is possible to color any coin. We talk about "color genesis", not about genesis block. It is just an analogy: just as a genesis block is a start of a blockchain, "genesis transaction output" is a start of a new color. |
|
|
|
This is an interesting idea. But presumably the person who initially made the tx on the main chain would have to be the one that signs the tx that another person can redeem on the main chain. But that person cannot then transfer it to someone else because his signature won't meet the main chain's script requirement. In this respect, no data is really saved anywhere. But I could very easily be missing something. Well, I'll try again... Suppose we have two separate chains: Bitcoin and Fastcoin. Bitcoin is more secure, but isn't friendly to microtransactions. Suppose a market maker John notices that a unit of Fastcoin is more valuable than unit of Bitcoin, so he sees a profit opportunity in converting Bitcoins to Fastcoins and selling Fastcoins. He creates SPLIT transaction with 100 Bitcoins he has. Now he gets 100 Fastcoins, and he can then sell (or spend) them... Later he finds that Fastcoin drops in value: 1 Fastcoin = 0.95 Bitcoins. He now wants to convert Fastcoins back to Bitcoins. To do that, he first buys Fastcoins on market. Then he creates DESTROY transaction on Fastcoin chain. And then he creates a MERGE transaction on Bitcoin blockchain. MERGE transaction uses output of a previous SPLIT transaction, so on Bitcoin side it follows same conservation rules as a normal Bitcoin transaction. It is like sending 100 Bitcoins to yourself with additional condition. MERGE transaction needs to reference DESTROY transaction. Miners can check whether referenced DESTROY transaction was included into Fastcoin chain via SPV. However, note that Bitcoin strictly follows its own conservation rules, so you have same guarantees as before. It does not mean that we are using SPV for Bitcoin. What happens if there is a deep reorg on Fastcoin chain? When miners include MERGE transaction into Bitcoin blockchain, they will stamp Fastcoin blockchain at the same time. Miners who mine subsequent blocks will have to take this into account, i.e. if there is a fork they should be stamped chain as valid. So there is never a disagreement about what Fastcoin chain is valid among Bitcoin miners. This means that stamps-from-Bitcoin-chain can override Fastcoin's own PoW. On surface it seems to make Fastcoin less secure, but as TierNolan have noted, a delay can make attack-via-Bitcoin infeasible. I'm not 100% sure, but there might be a way to match PoW so that attack-from-Bitcoin costs no less than usual 51% attack. So here's what we get in the end: 1. Bitcoin is exactly as secure as before if MERGE transaction can never produce Bitcoin blockchain forks or orphans. 2. Fastcoin is just as secure as a merged-mined chain. 3. Fastcoin can use UTXO-based security if necessary, however it might be just an offload. 4. Overhead in Bitcoin chain is minimal. |
|
|
|
What is the move back purpose? To make sure that coins have more-or-less the same purchasing power. If coin1->coin2 conversion is possibe, but coin2->coin1 is not possible, then it is possible for coin2 to become significantly less valuable, and thus dead. Obviously, implementing one-way conversion is much easier, but not that much interesting. I assume there is a delay. You send back your coins and have to wait 100 blocks. The rule is therefore that return payments are valid if they are buried at least 100 deep in the alt-chain. Yep, but it looks quite a bit fragile. Moving money downward gets you cheaper tx fees and probably faster confirms. However, it makes it harder to spend. Merchants could have addresses on all the leaf chains. Markets would allow fast movement of money between leaves. Well, you can use same private key on all chains, but you need to negotiate whether merchant accepts coins from a particular chain. |
|
|
|
Хэшрейт неважен.
Для успешной атаки нужно выкупить 50%+1 монето-день из участвующих в генерации стейков, на сегодня это будет стоить примерно 240 тысяч долларов (нижняя оценка, верхняя - 400 тысяч долларов).
Почти правильно. Если количество активных стейков достаточно велико (возможно, начиная от 20000), то достаточно 25% активного стейка чтобы делать double-spend раз в месяц: https://bitcointalk.org/index.php?topic=152809.msg2014924#msg2014924Очень простой расчёт: имея 25% от активного стейка вероятность сгенерить 6 PoS блоков подряд = 0.000244. Если повторить атаку ~4000 раз вероятность успеха становится существенной.
Насчёт "на сегодня" я думаю вы ошибаетесь очень серьёзно. Какой средний timeweight стейков? Если существенно меньше максимального, то аттакер может существенно снизить количество необходимого стейка засчёт больше timeweight. (Мне просто интересно сравнить интеллект Бальтазара и Sunny. Рекомендуется инвестировать в ту валюту, разработчики которой умнее. Что Sunny ёбнутый на всю голову уже установлено.) |
|
|
|
{blockhash,index} is unique. As would be {blockhash,transactionhash} or even {transactionhash,blockheight}.
Thanks. {transactionhash,blockheight} is what I wanted to use, but wasn't sure. |
|
|
|
It's really just the same rule. You can't have 2 live transactions (those with unspent outputs) with the same hash. No, it is a different rule. BIP 30 essentially says that once all outputs are spent, it can appear again. But it is possible to create a transaction and spent all its outputs within one block, isn't it? Thus this transaction won't be live. Hmm, this is interesting. It basically says that "This is caught by ConnectInputs()", but is it? Perhaps it is meant that CheckInputs will detect transactions which try to spend same outputs, but in theory if transactions can reappear, it would be different outputs. So it is possible that line 2105 is a rule on its own... Basically from the view of the reference client, there is no need for the identifier to be unique forever. The only need for looking up transactions is to get their unspent outputs. Once the outputs are spent, they never need to be looked up again, so the identifier can be reused.
Yep. Unfortunately this doesn't work so well for colored coins... |
|
|
|
|
What can be an unique identifier of a transaction in view of BIP 30?
Apparently transactions with same hash can appear in different blocks.
What's about txhash+block_number?
Is it possible to have transactions with same hash in one block? BIP 30 doesn't say anything about it, but perhaps it is mentioned in some other rule.
If it is possible, then I guess the only identifier is a position in the blockchain, i.e. block hash + index of transaction within block.
|
|
|
|
|
Show Posts
