I have recently learned that any output with OP_RETURN is excluded from the fee/balance calculations and thus the value of any OP_RETURN output is simply transferred to the miners as a fee.
Interesting. Thanks for the update. I'll make sure I keep that in mind when talking about OP_RETURN in the future. So, it is possible to create an unspendable script, and thereby lock bitcoins up as permanently unspendable, but OP_RETURN is not the way to do it. No, that's not true. |
|
|
|
Also note that transactions can be created that don't pay to an address, but rather pay to a script. In particular, you can use OP_RETURN to create an output that can never be spent. This script OP code is used specifically to mark an output as "invalid". As such, it can immediately be removed from the UTXO, and can be considered "destroyed". https://en.bitcoin.it/wiki/ScriptProvably Unspendable/Prunable OutputsThe standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form: scriptPubKey: OP_RETURN {zero or more ops}
OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the UTXO set even if it has not been spent. I have recently learned that any output with OP_RETURN is excluded from the fee/balance calculations and thus the value of any OP_RETURN output is simply transferred to the miners as a fee. Example: https://blockchain.info/tx/139c004f477101c468767983536caaeef568613fab9c2ed9237521f5ff530afdSo this is not one way to destroy bitcoins although there are plenty of others as you pointed out. Any problem with your calculator  1 (1FC....) = 0.998 (1FC...) + 0.001 (destroyed) + 0.001 (fee) |
|
|
|
I think the IBM cards are basically dead, at this point. TC is now all about Intel TXT (sort of crappy) or SGX (not here yet but seems to have a much better design).
Nope, still sold and supported— and there was a new version (third generation) released last year. (I also have a second generation card to screw around with…) How much for such card? Is there any real service (bitcoin or not bitcoin related) on the web using these cards? |
|
|
|
Both the above questions did not answer my question D:
My question was:-
How does the patch get implemented ?
I think understand what you say , that people add their ideas to the Bitcoin blockchain.
But who decides which version to use ? If an update is published , and 51% of the people don't use it , obviously it needs to be denied.
Now my question is , does this 51% depend on hashing , addresses , nodes or what ?
FTFY. Blockchain is not a place to store "ideas" or "rules" Simply speaking, in most cases patches in bitcoin are applied like other open source project. These are usually security fixes which are usually adopted without controversial, or some optional functions like payment protocol. Some fixes, however, require vast majority of miners to support. Example: https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki . We call it soft-fork Some fixes require all mining and non-mining users to support. We call it hard-fork. Some proposed hard-forks: https://en.bitcoin.it/wiki/Hardfork_Wishlist |
|
|
|
If OP_ADD is allowed, the bulky 8-of-11 multisig is not necessary and some block space is saved
Can you explain this? How does OP_ADD simplify the security requirements? Oh, even OP_ADD is not needed. Public key of Alice is pub-a; pub1-pub7 are public keys of 7 oracles. For 4 of 7 oracles, the script could be: pub-a OP_CHECKSIGVERIFY OP_4 pub1 pub2 pub3 pub4 pub5 pub6 pub7 OP_7 OP_CHECKMULTISIG or equivalently, OP_4 pub1 pub2 pub3 pub4 pub5 pub6 pub7 OP_7 OP_CHECKMULTISIGVERIFY pub-a OP_CHECKSIG (actually the paper mentioned this: "Transaction of 1+(m of n) signatures would be non-standard") |
|
|
|
Part of my concern with resource control and IO complexity is that ultimately I'd like to have this virtual machine running inside an IBM cryptocard, with remote attestation... not just to protect the users from a cheating operator, but to protect the operator from being threatened by users that might want to try to coerce them.
I think the IBM cards are basically dead, at this point. TC is now all about Intel TXT (sort of crappy) or SGX (not here yet but seems to have a much better design). There are many discussion on TC here but I can't see any real implementation. Are all modern INTEL CPU capable to do TC? |
|
|
|
Paypal is just a subsidiary of Ebay, and the CEO of Ebay likes bitcoin. So that's great. More and more bitcoin lovers in the senior positions of major companies |
|
|
|
|
兩句謠言就可以影響你的投機決定, 你還是當做交學費, 好好自我檢討
|
|
|
|
|
As the one who proposed it, I do not think it will ever happen in Bitcoin. Actually the ONLY reason we may need OP_CHECKCOLORVERIFY is to allow SPV nodes to verify color in an easier way. However, SPV nodes could still verify color without OP_CHECKCOLORVERIFY. They just follow the transaction chain until they see the origin of the color.
If that's for a sidechain / alt-coin, there could be more elegant ways to do this. I had to put it in the script because that's the only location in Bitcoin where people could include arbitrary content.
|
|
|
|
It's funny that we just published a whitepaper explaining the technical details of such a solution. http://github.com/orisi/wiki/wiki/Orisi-White-PaperThere's also a basic implementation in the works, to be released today evening, or tomorrow. Our team has been working on that for the past three weeks  If OP_ADD is allowed, the bulky 8-of-11 multisig is not necessary and some block space is saved |
|
|
|
Back to the topic: small Bitcoin pools may use p2pool to decrease the variance. We may have many small pools that people could join, and these small pools are actually running under p2pool. We also have other mechanism to make pooled mining decentralized, such as getblocktemplate https://en.bitcoin.it/wiki/GetblocktemplateAnyway, I don't think decreasing block interval would make us more decentralized. There are already solutions. People are just too lazy, or they are just not economically optimal. |
|
|
|
|
1w MACD is crossing up, while 1d MACD is crossing down. Daily RSI goes below 70. It looks very similar to the chart of Sept 2013
|
|
|
|
Now since litecoin has 30 less value and 4 times more blocks to secure the received transaction that is equivalent to 1 bitcoin block you have to wait 120 litecoin blocks. So bitcoin is much more secure. (Note that proof of stake has precicely 0 security because one or more past stakeholders can use their stake and reorganize the chain from the point before selling at 0 cost)
This is completely wrong. Assuming the same orphan rate and the same hashrate share among honest and evil miners, one Litecoin block is as secure as one Bitcoin block. The mean block interval is irrelevant. There has been lots of discussion on this topic. Please search. No that's simply not true and discussed a lot of times. Based on your logic 1 bitcoin block is as secure as 1 litecoin block which is as secure 1 block of feather coin (which has been attacked multiple times) etc.. Feather coin is not secure because it's total hashrate is too low Please read Satoshi's paper, section 11: https://bitcoin.org/bitcoin.pdfThe probability of an attacker to success (q z) is just a function of p (% hashrate of honest miners) and q (% hashrate of the attacker). The block interval is NOT part of the equation.
Anyway as I said in my previous post this thread is about block intervals and decentralization and not block intervals and security. Please don't troll the thread.
Please at least have a correct understanding of block interval, before further discussion. |
|
|
|
比特币的死期不远了，赶紧来个51%，GHash转走所有的比特币，到各大平台砸盘
显然你不懂。 如果有人掌握了50%以上的算力，他能够比其他人更快地找到开采区块需要的那个随机数，因此他实际上拥有了绝对哪个一区块的有效权利。 他能够： 1、修改自己的交易记录，这可以使他进行双重支付 2、阻止区块确认部分或者全部交易 3、阻止部分或全部矿工开采到任何有效的区块 但是他无法做到： 1、修改其他人的交易记录 2、阻止交易被发出去（交易会被发出，只是显示0个确认而已） 3、改变每个区块产生的比特币数量 4、凭空产生比特币 5、把不属于他的比特币发送给自己或其他人 Bitcoin圈子就是太多這種只懂炒賣, 不懂技術, 道聽途說之徒. 這種人多是追漲殺跌, 被宰得一頸血 |
|
|
|
Now since litecoin has 30 less value and 4 times more blocks to secure the received transaction that is equivalent to 1 bitcoin block you have to wait 120 litecoin blocks. So bitcoin is much more secure. (Note that proof of stake has precicely 0 security because one or more past stakeholders can use their stake and reorganize the chain from the point before selling at 0 cost)
This is completely wrong. Assuming the same orphan rate and the same hashrate share among honest and evil miners, one Litecoin block is as secure as one Bitcoin block. The mean block interval is irrelevant. There has been lots of discussion on this topic. Please search. |
|
|
|
1、修改自己的交易记录，这可以使他进行双重支付
2、阻止区块确认部分或者全部交易
3、阻止部分或全部矿工开采到任何有效的区块
但是他无法做到：
1、修改其他人的交易记录
2、阻止交易被发出去（交易会被发出，只是显示0个确认而已）
3、改变每个区块产生的比特币数量
4、凭空产生比特币
5、把不属于他的比特币发送给自己或其他人
不明白, 為何中文論壇特別多這種應聲虫 |
|
|
|
Have you noticed the drop in hashrate lately.
yeah, sorry about that, I had to go out of town for work, just logged in to see that one of my miners is off-line  just keep the price steady for me for a few days and when I get back I will rectify the hashrate problem... promise  Hashrate always drops after every difficulty increase. Nothing unusual |
|
|
|
I hope you are not literally interpreting his words, with awkward google translation He's just pretending a little puppy, licking the feet of PBoC, begging for the dictator's mercy |
|
|
|
|
Show Posts
