It's not spamming they are passing messages through timestamps
There is no timestamp in transaction |
|
|
|
Yes, a network of low trust intermediaries like that has been proposed before.
Will it be implemented? Who knows. It's a lot of work.
There is only one reason for this not to be implemented: Bitcoin dies before it is implemented. Imagine in the future, all merchants in the world accepting VISA will also accept Bitcoin. It is trust-free, instant confirmation, no charge-back, very low tx fee (most fee will go to payment processor instead of miners). There will be discount for bitcoin users because of all these advantages over VISA. As user, you don't need to worry about foreign currency exchange because bitcoin is widely accepted. If there is any emergency, your family can deposit bitcoin for you to the payment processor, and it will be confirmed after 6 confirmations (I know you don't like soft-fork, but there is a soft-fork proposal to make 6 confirmations happens in 15 minutes). And of course, 1 BTC will worth at least US$10000............... |
|
|
|
It's just a naming issue. No matter how it is called, it will either do nothing, or invalidate the whole transaction.
Maybe OP_CHECKCOLOR could be defined If the top of the stack is TRUE and the output is of the wrong colour type, then replace the TRUE with FALSE. This means that this code works the same on old and new clients. Except old clients always verify as true. OP_TRUE OP_CHECKCOLOR OP_VERIFY Maybe I would call it a "meta OP code". Normal OP codes validate/invalidate individual transaction input. Meta OP codes validate/invalidate the whole transaction.
They already did it with the P2SH change. No, P2SH still works within individual input/output. My proposed OP_CHECKCOLOR works across all inputs/outputs in the same transaction. If the transaction does not follow the color rule, the whole transaction is invalid so there is no reason to further exam the validity of individual output. If the transaction follows the color rule, all outputs must also follow the color rule. Therefore, OP_CHECKCOLOR does not really need to modify anything on the stake. When it comes to validation of individual signature, OP_CHECKCOLOR is nothing more than OP_NOP1 |
|
|
|
With OP_CHECKCOLORVERIFY you can't use OP_DROP. But as you need it for backward compatibility, you need to use OP_CHECKCOLOR instead. (Which puts a bool on the stack)
It's just a naming issue. No matter how it is called, it will either do nothing, or invalidate the whole transaction. Maybe I would call it a "meta OP code". Normal OP codes validate/invalidate individual transaction input. Meta OP codes validate/invalidate the whole transaction. There are other discussion on OP_CHECKVALUE and OP_CHECKFEEVERIFY at https://bitcointalk.org/index.php?topic=181734.20 , which are also meta OP code. |
|
|
|
|
Will we see an implementation like this in the future?
1. There are 3 parties: Customer (Carl), Merchant (Mary), and Payment processor (Peter). However, they only have minimal trust with each other
2. Carl opens a micro-payment channel with Peter by depositing some BTC in escrow, waits for 6 confirmations
3. Peter opens a micro-payment channel with Mary by depositing some BTC in escrow, waits for 6 confirmations
4. Carl wants to buy something from Mary with 1 BTC
5. Since Carl does not trust Peter for 1 BTC, he will just release 0.01 BTC to Peter through micro-payment channel
6. Peter receives 0.01 BTC from Carl, and releases 0.01 BTC to Mary through micro-payment channel
7. Goto step-5 until 1 BTC is transferred. It is automatic and should take only a few seconds
8. Mary delivers product to Carl
Advantage of this system:
1. Peter can serve as many merchants as he wants. Merchants will put Peter's logo on their windows just like Visa and AE
2. By depositing to Peter, Carl can reach every supporting merchants immediately (after initial 6 confirmation)
3. Zero-trust instant confirmation
4. Save blockchain space and mining fee
5. Peter will take minimal transaction fee
If bitcoin is going to be successful, I believe system like this must happen. At that time, people can buy bubble gum with bitcoin
|
|
|
|
I am making a new proposal for colored coin soft-fork: https://bitcointalk.org/index.php?topic=253385.0To make it works with lightweight HW wallet, OP_CHECKFEEVERIFY is not enough because colored coin is not fungible with normal coin. In this case only OP_CHECKVALUE or OP_TRUE solution would work. |
|
|
|
Existing colored coin scheme relies on the order of inputs and outputs: https://bitcointalk.org/index.php?topic=106373.0;topicseen . There are few problems with this scheme: 1. Signature tag like SIGHASH_ANYONECANPAY cannot be used since the order of inputs in the final transaction is not known. 2. SPV nodes cannot verify colored coins 3. The whole transaction chain could not be pruned A soft-fork could solve these problems: 1. Redefine OP_NOP3 as OP_CHECKCOLORVERIFY 2. When a user wants to mint colored coin, he sends some coin to an output with a script of <color> OP_CHECKCOLORVERIFY OP_DROP OP_DUP OP_HASH160 <address> OP_EQUALVERIFY OP_CHECKSIG where <color> is defined as RIPEMD160(SHA256(script of previous output)) For example, if Satoshi wants to create a colored coin with his Genesis Block address 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa, <color> will be RIPEMD160(SHA256(76a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac)) = 653756a92059ba4f3086471bd3c9e8442e4da3d3 By hashing the whole script, colored coin can be minted out of any future payment scheme 3. It is necessary for Satoshi to sign the minting output to make the whole transaction valid. The transaction is not valid if he is signing with SIGHASH_NONE, or SIGHASH_SINGLE but not for the minting output 4. Redistributing colored coin is done just like normal transaction, with inclusion of <color> OP_CHECKCOLORVERIFY in appropriate outputs. However, the total value a specific colored coin in outputs must be equal to or less than the total value in inputs. If the value in outputs is less than inputs, some color coins turn back to normal BTC. The only exception is Satoshi decided to mint more colored coin with his address, so the total colored output value could be larger than the input value. 5. Coins of different color could be exchanged in one transaction. An output may bear more than one color using multiple OP_CHECKCOLORVERIFY (e.g. an 1 BTC output with color xxx and color yyy means 1 xxx coin and 1 yyy coin) 6. Using coins from other addresses, one may mint more colored coin than the coin he has. For example, with 10 BTC from address xxx and 1 BTC from address yyy, one may mint 11 yyy coins. Backward compatibility: For existing clients, the coloring information is just <random string> OP_NOP3 OP_DROP and will be ignored Possible extensions
1. To allow SPV verification of unique smart property (e.g. linking a colored coin with a real car), we need to ensure the uniqueness of the colored coin on the blockchain. A flag could be added to the minting and subsequent transactions to declare that only one UTXO may have this color at any time.
2. Sometimes you may want to restrict the total amount of a specific color coin in circulation. A flag could be added to the minting and subsequent transactions to declare that no more minting of the same color is allowed. (I'm not quite sure how this may work. Need more discussion)
These extensions require full nodes to keep an index for all colored coins in UTXO setEDIT: These are not needed as there are better solutions: https://en.bitcoin.it/wiki/Smart_Property |
|
|
|
So I was sitting here reading an article about securing your wallet, and I just started to wonder how many times someone has screwed up and lost their wallet.dat either by mal-intent or self-stupidity.
There can only be 21 million, but how many have already been lost forever? Isn't it possible that someone had 100 BTC in 2010 and then said "meh, this thing sucks" and just deleted the files from their computer? After all, it wasn't worth much back then so why try to sell a meager 100 BTC at that time?
Is there a way to determine how many lost Bitcoins there are?
/end random thoughts
I have a table here: https://docs.google.com/a/ij.hk/spreadsheet/ccc?key=0Ahdy3Je_nYdOdFVocm4yTzhZOW1waWd6SFJIVHUwYUE#gid=0Please donate if you like it |
|
|
|
It seems weird, but I've never been able to come up with a case that couldn't be handled by the current flags plus some small number of preparatory transactions. I'd be interested in seeing if anyone can come up with one.
Do you mean using multiple SIGHASH_ONE inupts? |
|
|
|
|
Currently, we have SIGHASH_ALL (sign all outputs, the default), SIGHASH_NONE (sign none of the outputs) and, SIGHASH_SINGLE (sign one of the outputs). However, it seems there is no mechanism for user to sign more than one, but not all outputs. For some advanced contracts, one may want to specify multiple but not all outputs. Do we need a SIGHASH_MULTIPLE for this, or could we accomplish this with current code?
|
|
|
|
Does it have to be one extra output per input?
As I mentioned, there could be multiple OP_CHECKVALUE in the same dummy output, e.g. <h1><n1><v1> OP_CHECKVALUE <h2><n2><v2> OP_CHECKVALUE ........ Couldn't you just have a single output specifying the fee for the whole tx? It would essentially do the same thing, and the OP_NOP/OP_CHECKFEEVERIFY would still work with zero output value and be pruned.
Interesting. This could be more efficient than my previous OP_TRUE solution since the miner won't need to transfer the fee once again. Just redefine an unassigned OP code to OP_CHECKFEEVERIFY (We don't need to consume an OP_NOP because the output is not supposed to be spent) That would make it somewhat complicated to do more-advanced contracts though... where not all inputs and/or outputs are known at the time of signing (like the lighthouse contract). Just more food for thought.
Yes, that would require the OP_CHECKVALUE or the OP_TRUE solution. |
|
|
|
I have a ugly but backward compatible way to implement the OP idea:
1. Redefine one of the unassigned OP code (e.g. 0xfc) as OP_CHECKVALUE
2. When signing of input value is required, add an extra output like "<TxPrevHash> <TxPrevOutputIndex> <TxPrevOutputValue> OP_CHECKVALUE" is added, with 0 bitcoin assigned to this output
3. If an output of this format is found when validating a transaction, the engine will check whether the value of the specified output is same as TxPrevOutputValue. If not, the whole transaction is invalid. If yes, the code remove the top 3 stack items.
More rules:
1. There could be multiple OP_CHECKVALUE in the same dummy output.
2. The whole transaction is invalid if the specified output is not found in the input list.
Advantage:
This is transparent to existing clients, making it a perfect soft-fork. For both old and new clients, the dummy output is provably unspendable and will be pruned from the UTXO set.
Disadvantage:
Bloats blockchain, and looks hacky
Any comments? At least I want to know if it works in theory
Does it have to be an extra output? Couldn't we just put this in the TxIn script being signed directly? Right now, a standard TxIn script is: PUSH(Signature) PUSH(PubKey) Couldn't we do: PUSH(8bytefee) OP_CHECKFEEVERIFY PUSH(Signature) PUSH(PubKey) Never mind, I just realized that that those op-codes don't get signed, so they can be altered without breaking the signature. I thought something similar (see my crossed out reply above), and found it won't work for the same reason |
|
|
|
|
I have a ugly but backward compatible way to implement the OP idea:
1. Redefine one of the unassigned OP code (e.g. 0xfc) as OP_CHECKVALUE
2. When signing of input value is required, add an extra output like "<TxPrevHash> <TxPrevOutputIndex> <TxPrevOutputValue> OP_CHECKVALUE" is added, with 0 bitcoin assigned to this output
3. If an output of this format is found when validating a transaction, the engine will check whether the value of the specified output is same as TxPrevOutputValue. If not, the whole transaction is invalid. If yes, the code remove the top 3 stack items.
More rules:
1. There could be multiple OP_CHECKVALUE in the same dummy output.
2. The whole transaction is invalid if the specified output is not found in the input list.
Advantage:
This is transparent to existing clients, making it a perfect soft-fork. For both old and new clients, the dummy output is provably unspendable and will be pruned from the UTXO set.
Disadvantage:
Bloats blockchain, and looks hacky
Any comments? At least I want to know if it works in theory
|
|
|
|
For the record Gox worked consistently well for me, done 3 withdrawals of non-negligible amounts and I got the money in my bank in 2/3 days. SEPA transfers, Europe customer.
Dates on these withdrawals? The three of them were done in June, while there was no "USD hiatus", but it was still a moment where people wrote in this forum about withdrawals taking MONTHS to clear, especially SEPA ones. As I said, not my experience at all: 3 separate and significant withdrawals cleared in 2/3 days (SEPA) in June, just as fast (or even faster I'd say) that pre-bubble. I need to say this because I've been reading so much FUD about Gox since April that I really don't know if I'm "the lucky one", or is just that there are thousands of customers of Gox (let do not forget they have tens of k's of customers ATM) that have no problems so they just stay quite, while the few that have delays obviously complain bitterly on this board. Then I read about people saying that "as soon as a big customer ask for a withdrawal Gox will be crumble", and this doesn't seem the case at all. Since April millions of $ have flown out of Gox without any problems, in fact all the reports for "delayed withdrawals" I see in here are for smallish amounts. BTW: I'm fully verified, including notarized docs. Bitpay and Bitinstant stop accepting mtgox means these big players have difficulty in withdrawal |
|
|
|
感谢 @jl2012 所提出的方案。我相信这种方案在双方不互信的大额兑换时是非常有用。但是我们的业务大多是小额兑换（15 BTC 以下），而且力求简化操作，所以不适宜于采用这样的方案。
我也明白. 但我相信只需兩年時間, 上述的方案會完全自動化, 成為標準方案. |
|
|
|
家住合肥的资深比特币玩家王尼玛，持有比特币 41391.58 BTC，是知名的比特币高帅富，但是王尼玛最近有一些烦恼。  后来王尼玛了解到了 Digcoin 时价交易行：不挂单！卖出比特币没有手续费！三次确认之后直接付款！ 如此的方便快捷，他和他的小伙伴们都惊呆了！ https://digco.in/exchange欢迎来 Digcoin 时价交易行卖币~ 其實有更好的方法, 而且你們和客戶皆沒有風險 (現在你們承受了因價格上升帶來的double-spend風險) 1. 客戶向交易所提供其public key (pubkey-1) 2. 交易所產生一個新的public key (pubkey-2), 加上客戶的pubkey-1, 產生一個2-of-2 P2SH地址 (address-1) 3. 客戶向address-1制作一個存款交易(tx-1), 但不廣播 4. 客戶把tx-1的hash及相應的output index告訴交易所, 並告知一個客戶獨佔的退款地址(address-2) 5. 根據客戶提供的hash及output index, 交易所制作一個交易(tx-2), 把tx-1收到的bitcoin以locktime形式發回address-2. (locktime就象期票, 有關交易在locktime後才生效) 6. 客戶收到tx-2, 覺得滿意後, 廣播tx-1 7. 交易所看到tx-1, 覺得滿意後, 經過數個確認, 承認tx-1 在locktime到期前, 如客戶想賣出bitcoin: 1. 客戶以pubkey-1簽署address-1, 把bitcoin發送到交易所獨佔的地址 (address-3), 稱為tx-3 2. 交易所以pubkey-2簽署tx-3, 並立即(*)發佈 3. 由於沒有double-spend風險, 交易所可以立即承認到賬. (* 其實不一定要立即發佈, 只要在locktime到期前數小時發佈即可; 不立即發佈還可做到micropayment, 參閱bitcoinj的最新發佈) 在locktime到期前, 如客戶想提早取回bitcoin: 1. 客戶把自己的地址 (address-4)告訴交易所 2. 交易所以pubkey-2簽署, 把address-1的錢送到 address-4, 稱為tx-4; 簽署後, 交易所不再承認tx-1 3. 客戶以pubkey-1簽署tx-4並發佈, 成功取回鎖定的bitcoin 在locktime接近到期, 或到期後: 1. 交易所因double spend風險而不再承認tx-1 2. 客戶廣播tx-2, 取回bitcoin 若交易所突然倒閉, 客戶只需等到locktime之後, 就可取回bitcoin. 除非是剛好在發佈tx-3後立即倒閉, 則沒有辦法了. 但風險已大大減低 現在bitcoinj已可做到以上功能, 我相信在兩年以內這種付款方式必成主流. 其實我很有興趣制作首個這樣的項目. (為簡化討論我用了很多術語, 如有不明白可再問) |
|
|
|
Overall a P2SH txout adds just 24 bytes to a transaction by the time you spend it. (21 bytes to encode the hash, 2 bytes of opcodes, and 1 byte to encode the length of the scriptPubKey when you eventually spend it) For the minimum size tx format, bare compressed pubkeys, it takes 158 bytes round-trip to create and spend a txout (44 bytes for the txout, 114 bytes to spend the txout) so the overhead of P2SH is just 15% Compared to the standard pay-to-pubkey-hash P2SH is actually 1 byte smaller because it doesn't need the OP_DUP, and it's still just as secure in terms of keeping pubkeys unknown against a ECDSA break.
Isn't pay-to-pubkey-hash (P2PH) more secure than P2SH? Stealing bitcoin from a never-spent P2PH address requires breaking of ECDSA, SHA256, and RIPEMD160 at the same time. For P2SH, one "only" needs to break SHA256 and RIPEMD160 to create a valid serialized pay-to-anyone script, and mine his own blocks before broadcasting it. (I know it's hardly possible to completely break SHA256 and RIPEMD160 at the same time, but theoretically P2PH is still secure than P2SH) |
|
|
|
All the time there are like 20KB, but sometimes even 99KB txs that are going across the network - and they are just a spam.
I know it's not an issue, but believe me, that if someone will decide to use it as a DoS attack method and will bother to implement this method, it will quickly become an issue. And how are you going to solve it then - how many days/weeks/months will you need in order to adopt a protocol to this specific threat?
It's quite amazing that after finding recently that node's memory can be attacked by sending him big txs, nobody has even bothered to try thinking of if, instead of just "oh, as long as it's the same size as it is, I'm fine with downloading processing, storing and even routing forward, all this spam".
I think those are not relayed by default if they are not paying enough fee |
|
|
|
|
Show Posts
