Every now and then appears someone with the "new" idea of tainting coins. It's a very bad idea for multiple reasons. God, use the search button and you'll find a lot of threads about tainting.
What we need is an add-on for the Satoshi client and for the usual mining software to allow people melt-mining coins. That way we prevent the next "visionary" to taint our coins.
Melt-mining: mine a block and add a selfmadetransaction with all the coins you want to "melt" as fees. You need a tweaked client that prevents the selmadetransaction to be broadcasted but in your brand new mined block.
BITCOINS MUST BE FUNGIBLE.
This is one of the worst ideas I have ever heard. It's so obvious that the miner and the owner of melt coin is the same person. Even worse, imagine that your block is orphaned. You "melting transaction" is now known to the whole world with 0-confirmation. I wish you could mine another block to include it before any other people did it. |
|
|
|
Another one claiming for "tainted Satoshis".
We need urgently a coin melting mining pool in order to get protected for this kind of "visionaries".
You always have the freedom to setup a coin melting mining pool, and I encourage you to do so. However, joining your pool is voluntary. Unless there is a protocol change, my proposal will still work. |
|
|
|
Interesting approach, but there are some issues with this. Since the supply of satoshis is limited, this means that penny stocks aren't practical, since the coins that record their ownership will become worth more than the stocks themselves. Etc, etc.
When people trade "penny stocks", they will also consider the face value of the colored coin. For example, if someones wants to buy 1 colored BTC with 0.1 BTC, he has to pay 1.1 BTC to the seller. If 1 satoshi stock worths less than 1 satoshi, it either means the stock is worthless (people may trade in bigger unit, e.g. 10000 satoshi), or 1 satoshi worths too much (we need a hard fork to add more zero after decimal place) |
|
|
|
This colored bitcoin concept just doesn't seem right to me. Bitcoins are supposed to be fungible, and this takes away from that as well as causes unnecessary deflation.
One of the concerns I have is that it will make it easier (or at least more common and accepted) to track bitcoins that are "dirty" somehow (at least in some people's, or more importantly governments, eyes).
Bank notes are fungible but still traceable, so as bitcoin. You can not stop people tracking bitcoin with the current blockchain system. If we could not avoid, why don't we make good use of this feature? (Unless you have a better idea) For the deflation issue, the face value of colored bitcoin should be also considered in the transaction. For example, if you want to buy 1 colored satoshi with 10000 satoshis, you have to pay 10001 satoshis. |
|
|
|
Between on board thermal sensors/ADC/embedded serial number/mac address/device ID's there should be enough to get on with. With that lot the chance of any two devices hashing the same number is almost zero, and the chance of of one device generating the same number twice is tiny.
embedded serial number/mac address/device ID are known and fixed numbers and are not entropy source |
|
|
|
The question is, since bitcoin is fungible, how do we know the color of these coins?
Via a special coloring rules/algorithm. See here: https://bitcointalk.org/index.php?topic=114571.0Furthermore, if someone mixes 1 Red coin and 2 Blue coins and makes a single output of 3BTC, what is the color of the output?
Uncolored. Essentially you're scrapping your colored coins for underlying BTC in this case. How about paying transaction fee with colored coins? Will the miner claim it with the coinbase input? If you pay fee with colored coin miner will get this money fresh and uncolored, so don't do that with coins more valuable than underlying BTC  There are several solutions to transaction fees with colored coins: - don't pay fee. some transactions are eligible to be included into blockchain for free
- have a small amount of uncolored coins and pay fees with them. presumably your client software will do that automatically
- find someone to pay fee for you: you'll pay him colored coins, he will pay fee with his uncolored coins
This is relieving the debt of the color coin issuer and sounds not very ethical. If the colored coin is linked to a smart property, the property is also lost to no one. I have a new proposal, which every single satoshi has unique color: https://bitcointalk.org/index.php?topic=117224.0 |
|
|
|
Although bitcoin is designed as fungible, it is possible to assign an unique serial number to each atomic unit (aka satoshi). With this serial number, a satoshi may represent more than its face value (e.g. colored bitcoin, smart property, securities). Serial number has two parts: the integer part is the block number where the satoshi is generated, and the fractional part represents each unique satoshi. Taking the generation at block 110000 as example: http://blockexplorer.com/tx/4e10436ca8206a2dd760dd351210a5120a3824d4eb53011be0a7b9a33b368208There were 50BTC, or 5000000000 satoshi generated. Therefore, the serial number of these satoshi are #110000.0000000001 to #110000.5000000000. Tailing zeros are reserved. Here we define RULE OF INHERITANCE: In a transaction, the input sequence atomized to satoshi, with each satoshi has its unique serial number. The satoshi sequence is mirrored to the output, based on the output sequence. If transaction fee is paid (i.e. input > output), the fee is considered as the last output. In case of coinbase transaction, transaction fee is sorted after standard block reward, according to the transaction order in the block. Using the previous example, the 50BTC is completely transferred to another address: http://blockexplorer.com/tx/3abed8a3aa728e881a9ef85062fe11b79b490c885295c3c55fc6a534199a5dc5#i398943Therefore, 12WFtKBsRLtV8p1NwRqe7YwYdi1rjwTZhA inherits satoshis #110000.0000000001 to #110000.5000000000. Next, the 50BTC is split into two outputs: the first one with 5.2BTC and the second one with 44.8BTC: http://blockexplorer.com/tx/2faea2cc59b32f5cc19fd8aee85db3e82bbdccb32c52879fecddc592b172d981#i399136Therefore, the first output inherits satoshis #110000.0000000001 to #110000.0520000000, and the second output inherits satoshis #110000.0520000001 to #110000.5000000000. The next one becomes more complicated. The 5.2BTC output in the previous transaction is mixed with other inputs. There were two outputs, with 0.36BTC and 60BTC respectively: http://blockexplorer.com/tx/2ba980e8b17c46e671e8a09bef43815e26ae561facc35f415ef04b11bf4b7545#i405322Based on the rule of inheritance, the first output will inherit the first 36000000 satoshis in the first input (bfdc71884b80...:0). All the rest will go to the second output. Those satoshis #110000.0000000001 to #110000.0520000000 are embedded somewhere in the middle of the second output. To be precise, they are the #2171000001st to #2691000000th satoshis in the second output. (5.11-0.36+5.49+5.3+1.15+5.02=21.71) In the following transaction, the 60BTC is mixed with other inputs to make a single output of 954.27BTC http://blockexplorer.com/tx/03616a5d76508d45a0def171c29b3672714410c49648704eb766f2e74b4ed1fe#i406741Therefore, the satoshis #110000.0000000001 to #110000.0520000000 become the 81598000001st to 82118000000th satoshis of the output. (1.25+500+19+1+161.82+5.2+106+21.71=815.98) Here we use another example with transaction fee: http://blockexplorer.com/tx/afe357b19ca0b0c939b414d3dd63d523bb2a518237df51afc7d6f26098967c7dTransaction fee of 0.00574567 (574567 satoshi) is paid. According to the rule of inheritance, transaction fee is the last output. The last 574567 satoshis of input comes from transaction bcf2b1c4f75c...:0, which is the generation of block 99120. Therefore, the transaction fee is satoshis #99120.4999425434 to #99120.5000000000 The fee is collected by the miner of block 100035: http://blockexplorer.com/block/00000000000135cb86be36978e74a54cfd2b9143f827a589c9e27fde3463b753Since this is the only transaction with fee in this block, those satoshis #99120.4999425434 to #99120.5000000000 are embedded at the end of the coinbase transaction. Therefore, the coinbase transaction has satoshis #100035.0000000001 to #100035.5000000000 and #99120.4999425434 to #99120.5000000000, in the exact order. With this system, every satoshi has its unique identifier, or “color”. To make a lending contract, for example, the borrower will send a colored satoshi (e.g. #123456.1357924680) to the lender, and the lender will send the loan in the same transaction. The lender may sell the contract to other people with similar mechanism, and the borrower will repay to the address with the colored satoshi. We can also have decentralized security market with the system. Each satoshi sent from the issuer’s address is equal to one share. Although the serial numbers of these satoshis may not be continuous, it is still traceable. The issuer will pay dividend to the addresses with colored satoshis, and the shareholders will vote using the address private keys. Please note that this proposal has nothing to do with criminals/scammers tracing. |
|
|
|
Bitcoin from different inputs are completely mixed in a transaction. Assuming that Alice has 1 Red coin in a single output, and Bob has 5 Blue coins in a single output. To buy the Red coin from Alice, Bob will pay 1 Blue coin + 5BTC. Bob will also pay the transaction fee. Input 1. Address A (Red coins): 1BTC (Alice) 2. Address B (Blue coins): 5BTC (Bob) 3. Address C (Normal bitcoin): 10.005BTC (Bob) Output 1. Address D: 1BTC (Bob) 2. Address E: 4BTC (Bob) 3. Address F: 1BTC (Alice) 3. Address G: 5BTC (Alice) 4: Address H: 5BTC (Bob) Transaction fee: 0.005BTC Presumably, the 1BTC in Address D should be a Red coin, and the 1BTC in Address F should be a Blue coin. The 4BTC in Address E is a "change" from Address B and are Blue coins. The 5 BTC in Address G is the payment in normal bitcoin, and the 5BTC in Address H is the change of normal bitcoin going back to Bob. The question is, since bitcoin is fungible, how do we know the color of these coins? Furthermore, if someone mixes 1 Red coin and 2 Blue coins and makes a single output of 3BTC, what is the color of the output? How about paying transaction fee with colored coins? Will the miner claim it with the coinbase input? I understand the coloring part, but I don't get how this paves the way for distributed exchanges. What am I missing?
People having coins of different colors can exchange them securely via a simple bitcoin transaction which would be atomic. E.g. one person gives 1 red coin and gets 5 blue coins, other person gives 5 blue coins and gets 1 red coins, they construct a transaction, sign it, and once it is in blockchain trade is done. (If one person signs but other doesn't transaction would be invalid. If there is a double-spend, it would also invalidate whole txn. So trade transactions are in fact more secure than accepting bitcoins.) So what's left is order matching logic, i.e. allowing person which is willing to trade red coins for blue coins to find a person who wants the opposite. This is fairly simple to implement and straightforward. |
|
|
|
The card is very good for mining. However, mining with graphics cards will become useless very soon when ASICS are released within the next month or 2
Not for litecoin. The ASICs can't be used to mine LTC in their current form. When ASICs come out, all GPU will switch to LTC and the difficulty will grow exponentially |
|
|
|
|
You just include the preorder units in your calculation. However, these companies will certainly manufacture extra units for themselves to mine, since the marginal manufacturing cost for ASIC is very low. The difficulty will go up to 1000TH/s or 1PH/s easily
|
|
|
|
Transaction hash is everything you need to verify. If you can create two different transactions with same hash, it means SHA256 and anything depending on it (not only bitcoin) are completely collapsed. I don't know exactly what algorithm currently use merchants that are accepting 0 confirmations.
They may be using this algorithm:
After you receive the transaction tx1 sending X coins to my address:
"If a second transaction tx2 is detected (coming from another peer or a "watch" node) that spends any of the tx1 inputs and has different hash, then it's a double spend attempt"
This algorithm can fail to some attacks, because of possible signature malleability. A possible correct algorithm would be:
"If a second transaction tx2 is detected (coming from another peer or a "watch" node) that spends any of the tx1 inputs and does not have an output sending X coins to my address , then it's a double spend attempt"
Don't check the remaining outputs nor the transaction hash.
Best regards,
Sergio.
|
|
|
|
However, if the exchange is completely disappeared, the BTC in the multi-sig accounts will be lost forever. Therefore, we need some "emergency exit mechanism". When the multisig account is setting up, an additional condition is added: (e.g.) "After 1 Jan 2013, the coins in this account can be spent by signature of key U only".
If you held a pre-signed transaction that sends the funds back to you with a lockTime of 1 Jan 2013 that would work. Lets see... thinking out loud... Start by asking the exchange for a brand-new public key to use for their half of the 2-of-2 transaction. Call the send-coins-into-2-of-2 transaction "F" (for Fund). You create and sign that transaction, but don't broadcast it yet. Use it's transaction id to create a second, one-input-two-signature, lockTime=1/1/2013 transaction that refunds the coins to you. Call that "R" (for Refund). Send R to the exchange and ask them to sign it using that brand-new public key they gave you. The exchange checks the lockTime and then returns R and the signature to you. You check the signature, and if it is good, broadcast F (and keep the half-signed R someplace safe). If 1/1/2013 rolls around and you want your coins back, you sign your half of R and broadcast it.
I'd have to think a little harder than I want to right now about whether or not signing R knowing only txid==HASH(F) opens up the exchange to attacks. I can't think of any, but the exchange providing a signature when it doesn't know the details of exactly what it is signing makes me nervous. You could send the unsigned R and the signed-but-not-broadcast F to the exchange and trust that the exchange will not broadcast F unless they agree to sign R.
I think holding on to pre-signed-but-not-broadcast-yet transactions is a technique "we" don't think about enough. I read the previous discussion at https://bitcointalk.org/index.php?topic=6439.0 and https://bitcointalk.org/index.php?topic=1786Satoshi rejected the idea of OP_BLOCKNUMBER because of this: If the script language is not stateless, if it has access to any outside information that changes or varies between nodes, attackers can use it to fork the chain. The only exception is if it is always false before a certain time and permanently true after, which is implemented with nLockTime. Yes, he is correct. So it is possible to incorporate the idea of nLockTime into script? For example: 1. The coin can be spent by 2-by-2 multisig with key E and key U at ANY TIME 2. If block height >= x, the coin can be spent by key U. The 2-by-2 multisig, however, is still a vaild way to spend the coin. Therefore, the first condition is permanently true, regardless of block height. The second condition is always false before block height = x, and permanently true after. It is better than using nLockTime because the user can deposit to the script hash at any time, without the need of sending nLockTime transaction back-and-forth and storing them. It also avoids the problem of asking the exchange to sign an unknown transaction |
|
|
|
As far as transactions are concerned, there are no blocks, there is no chain, there is no height. This is not an accident or an oversight. Please search next time.
I think you totally misunderstand my proposal. Let me explain this way: A user does not fully trust the exchange but he wants to sell his BTC through the exchange. He wants to transfer the BTC to the exchange at the last minute before he sells. However, the exchange requires 6 confirmations to prevent double-spending. One way to do this is to have a 2-by-2 multisig account, which the exchange owns one of the keys (E), and the user owns the other key (U). The user will send his BTC to this multisig account. When the user wants to sell the BTC later, he sign a transaction by U to send the BTC in the multisig account to an account owned by the exchange exclusively. The exchange will complete the transaction by signing it with E. Since the user is not possible to double-spend, the exchange can accept it with zero confirmation and the user can sell his BTC immediately. However, if the exchange is completely disappeared, the BTC in the multi-sig accounts will be lost forever. Therefore, we need some "emergency exit mechanism". When the multisig account is setting up, an additional condition is added: (e.g.) "After 1 Jan 2013, the coins in this account can be spent by signature of key U only". That means in the worst case, if the exchange fails tomorrow, the user can get his coins back after 1 Jan 2013. Of course, in bitcoin world, time is measured by block height, not days. So the condition becomes "after block height > 220000, the coins in this account can be spent by signature of key U only". If the user tries to spend the coins today (block height = 201800) without involving the exchange, the transaction is considered invalid. And the following notice explains why we need this system: GLBSE is offline
For those worried about their bitcoin, please calm yourselves there has been no hack and your coins are safe and all accounted for.
I apologize for the lack of notice and the downtime, but there isn't much choice. We will update our users on Saturday. |
|
|
|
|
I wonder if a transaction script like this would be allowed: If block height < x, use condition A; if block height >= x, use condition B
This could be very useful as trust-free, zero-confirmation exchange wallet
Assuming the exchange owns private key E, the user owns private key U, and x is the block height of near future (e.g. current block height + 10000), a transaction script would look like this: If block height < x, 2-by-2 multisig with E and U is required; if block height >= x, U is required. A script hash is derived
The user will comfortably send any amount of coins to this script hash. If private key E was compromised, no fund could be stolen. Even if the exchange operator disappeared (like Torwallet), the user could get the coins back after block x.
If the user wants to sell the coins before block x, he will sign a multisig transaction to send the coins to the address of key E (or any other addresses exclusively owned by the exchange). Since it is bound by the multisig requirement before block x, the user is not possible to double spend. Therefore, the BTC is readily available for trading with zero-confirmation.
To avoid the risk of double spend or Finney Attack, the multisig transaction should be signed by the user well before block x is generated, e.g. x - 10. After that, the exchange will not accept it by zero-confirmation. However, it will still accept it after 6 confirmations.
This also works for online wallet providers, stock market, marketplace, or Bitcoinica-type services. It won't totally eliminate the risk, but people could then deposit a large amount of BTC to these services and spend instantly at any time.
EDIT: For a bitcoin buyer, the exchange will send the freshly bought coins to the his script hash. Therefore, the buyer is also protected, while he could also sell the coins instantly.
|
|
|
|
Again, someone lost >1300BTC due to misconception about wallet backup: https://bitcointalk.org/index.php?topic=110781.0It might be difficult to implement deterministic wallet in the next release. However, it is very easy to increase the key pool from 100 keys to 10000 keys. Adding 2 or 0 zeros in the source code will solve 99% of the problem |
|
|
|
Actually Linus exerts quite a bit of top down decisions onto the project. He's convinced of certain things and at times rejected patches because of his personal opinion.
The fact that Obama has veto power does not give me confidence in him either. I did not get into Bitcoins to trust another person with my money. You shouldn't use bitcoin in the first place: your money is stored in the block chain, and the chain could be rewritten by 51% of miners. |
|
|
|
ngzhang is it possible use the Lancelot board for other purposes like mining? I mean can it be used for controlling a ECA Reactor and pumps like Volt and Amps, and the Data from meters like PH Electrode, ORP Electrode, Conductivity Electrode and even output it to a small display/touchscreen?
I don't think Lancelot is good at these. But you can do all these with a $35 Raspberry Pi through USB |
|
|
|
This question has been asked repeatedly, repeatedly, and repeatedly; and the answer is no, no and no Hello,
in normal world money is printed and it has a value. And it doesnt bring problems when money burns. But bitcoin is different because the amount of bitcoins is limited.
So when in real world someone dies, leaving behind a bank account, the money wont be stranded. Except its black money. But even then more money can be printed.
But what about bitcoins that lie at addresses that doesnt have owners anymore? I mean wallets can be lost because pc crash and no backups. Or user dies and no one knows he has bitcoins. That means there must be a growing number of bitcoins that lie on addresses without owners. And noboday can take these bitcoins away.
So when this is true its only a matter of time until the bitcoins that can be used are going to an end. So bitcoins will raise in value because people need them to pay. But btc only has 8 numbers behind the dot and this will stop at some point too. So...
Am i wrong?
Thanks!
|
|
|
|
|
The forum should declare it as scam until they response and pay. People should never deposit large amount of money to a random anonymous service.
|
|
|
|
Scammer  |
|
|
|
|
Show Posts
