While practical testing is valuable, it should have no bearing on which BIP is accepted. These BIPs are protocol changes, and providing a stable implementation is the duty of the client, not the protocol. That being said, I'm confident that my bitcoind BIP 17 backports are more likely to hold up to testing, provided the signature check is sane (signing the relevant parts of the transaction), which would actually be a bug in the existing protocol if it weren't.
I'll see if makomk is up to this. His "coiledcoin" post implied he might be.
I'm not really up to anything right now. Coiledcoin's dead (probably together with new altchains in general), and it's not really worth starting anything Bitcoin-based at this point in time. I've suggested Coblee to consider BIP17 for Litecoin as an alternative to Bitcoin, let's see if we get anywhere with this. He might need some help to port and maintain the changes though, if he decides to implement multisig at all. Why not go a step beyond and make a clean start for the script engine in litecoin? Make all litecoin transactions be a p2sh style transaction. And clean up the cruft in the bitcoin script engine. Make it will tested, etc. Might be a good idea. I think you can talk to him about it. He said he would have more time soon to work on the client again. |
|
|
|
One word: Social ContractGeorge essentially is in a contract with society to help out. That he didn't have much choice in signing up or not, and that it is very difficult, if not impossible to cancel the contract by emigrating, are other questions. Social contract seems to be a convenient fiction. There is not even copy of the contract in existence let alone any evidence that anyone anywhere ever agreed to it :S I prefer to see society as being based on authority. In modern societies, democracy is a way to stop the masses rebelling. A sensible argument for progressive taxation is that if you grind the middle class and the poor down too far, they will rebel. George may feel that he is entitled to keep his money but if the authorities don't support hi, then George will have to pay up. I believe authority-based societies are a thing of the past (or soon will be). It creates this feeling of separation: there are "them" and "us". And as separation grows this division becomes more evident, "they" try to become a master race turning "us" into slaves. This is the end game in every authority-based society no matter how good it starts. Everyone should become their own authority. Why should some people born on the same planet tell other people what to do? F@#k "them"! In bitcoin society everyone is equal in front of the network. All conflicts of interest should be resolved the same way as conflicts in the blockchain are resolved! Yes by voting with your computer power. End of story. |
|
|
|
While practical testing is valuable, it should have no bearing on which BIP is accepted. These BIPs are protocol changes, and providing a stable implementation is the duty of the client, not the protocol. That being said, I'm confident that my bitcoind BIP 17 backports are more likely to hold up to testing, provided the signature check is sane (signing the relevant parts of the transaction), which would actually be a bug in the existing protocol if it weren't.
I'll see if makomk is up to this. His "coiledcoin" post implied he might be.
I'm not really up to anything right now. Coiledcoin's dead (probably together with new altchains in general), and it's not really worth starting anything Bitcoin-based at this point in time. I've suggested Coblee to consider BIP17 for Litecoin as an alternative to Bitcoin, let's see if we get anywhere with this. He might need some help to port and maintain the changes though, if he decides to implement multisig at all. |
|
|
|
if you implement both - both will have to be supported forever. you wont be able to choose a "winner" in a later stage
implementing both just adds more security risks without any benefits
you would be better off flipping a coin to decide which to use than implementing both
Well if support for one BIP goes down below 50% those coins will become available to redeem for everyone, at some point all of them will be redeemed rendering a particular BIP obsolete. Of course the bad thing is that some of those coins will be redeemed by hackers and not by the owners, but it might happen anyway only if just a single BIP is deployed and support for it goes away. As I understood BIP16 is currently stronger protected for this kind of situation. |
|
|
|
States and societies are not voluntary and not transaction based. On rereading this I don't agree with the second point. If not transaction based, what is the basis? I suppose this depends on the definition of transaction. Good question. Paying taxes and obeying laws are not transaction based activities but they are at the core of every society. Perhaps the basis is duty? Historically people felt a sense of duty to their tribe and would pay taxes and go and die in battle for the tribe. It still works that way across the developing world. Modern states seem to have stepped into the old tribe slot. People feel a duty to support their country with taxes and they take pride in their sons going off and being killed in conflicts that have no benefit to them or their families. Personally I think there is a "well there is no alternative" to why modern states work. If you want to live in a society with schools, roads, army and all the benefits of modern medicine, there are no alternatives to living in a state that charges taxes to support itself. If we apply this to bitcoin community, basically everybody is equal in relation to the network, network becomes the objective and just "state" so to speak. So if enough people on the network agree that they need a school they can set up a fund to donate to it and then elect a few people to build the school and hire teachers. If another group decides that they need a new road they would do the same. Note that only people who really need the school or the road would donate, not everybody. Some people would set up a fund to hire some armed guys for their protection and so on. So basically if the services that the state provides are so useful and so needed to the society, then the state should be able to earn money from the network the same way other people do, by providing services and doing some work. The difference from what it is now is that it's going to be voluntary and more transparent. |
|
|
|
Looking like the weekend Just bought a new server for US, once this is in we will get Litecoin up  Any news with the new server? |
|
|
|
Is it possible to also somehow close the hole about adding stuff into transaction before scriptSig by malicious nodes thus changing txID if modified transaction gets mined into block first?
Is it possible to address this in the future if not within BIP16? This can be fixed with or without P2SH of any kind. Yes that's what I thought as well, but since we are doing a major upgrade to the protocol it might be a good chance to take that into account as well. Or are you saying that the fix is very simple and won't require another heated debate and a fear of a chain fork? EDIT: if my question seemed like off-topic, I would rephrase it like this: How is this problem supposed to be fixed in the big picture (ideal situation in Gavin's OP)? |
|
|
|
|
Hi Gavin,
Is it possible to also somehow close the hole about adding stuff into transaction before scriptSig by malicious nodes thus changing txID if modified transaction gets mined into block first?
Is it possible to address this in the future if not within BIP16?
Thanks
|
|
|
|
Perhaps: "Litecoin-- faster transactions, lower cost-- Bitcoin's perfect compliment"
There is another hot topic - multisig transactions for better wallet security. What if litecoin implements BIP17 proposal? The bitcoin crowd seems to be slowly converging on BIP16. There is a heated debate over here: https://bitcointalk.org/index.php?topic=61125.0This might bring some life and interest back into litecoin and it will truly compliment bitcoin by selecting a competing solution. I think I have posted about it here a few days ago, but nobody seemed to pay attention. Coblee, what do you think? |
|
|
|
BIP 16 gives 5-10 times more room for transaction growth than BIP 17 before bumping into block limits. While somewhat incidental, I'd like to note that this seems to me to be a very strong, pragmatic argument in favor of BIP 16. From a theoretical perspective I also feel that BIP 16 is better. If the goal is to store code differently, it is best to handle this before execution by a preprocessor and not via a special opcode that changes execution flow in non-trivial ways. I have a very easy time implementing and feeling comfortable with BIP 16 as it only affects the way scripts are stored/loaded and not how they are executed. There are no new opcodes which can be used in unexpected places or unexpected combinations and there is no change to EvalScript, which is an argument that anyone who has actually tried to implement this function securely has to give a lot of weight to. I quoted your post Stefan in the new thread under general Bitcoin discussion here: https://bitcointalk.org/index.php?topic=61125.msg714569#msg714569It seams more heated and there are more participants now. |
|
|
|
What about this argument below from Stefan Thomas: BIP 16 gives 5-10 times more room for transaction growth than BIP 17 before bumping into block limits. While somewhat incidental, I'd like to note that this seems to me to be a very strong, pragmatic argument in favor of BIP 16. From a theoretical perspective I also feel that BIP 16 is better. If the goal is to store code differently, it is best to handle this before execution by a preprocessor and not via a special opcode that changes execution flow in non-trivial ways. I have a very easy time implementing and feeling comfortable with BIP 16 as it only affects the way scripts are stored/loaded and not how they are executed. There are no new opcodes which can be used in unexpected places or unexpected combinations and there is no change to EvalScript, which is an argument that anyone who has actually tried to implement this function securely has to give a lot of weight to. Quoted from here: https://bitcointalk.org/index.php?topic=60433.msg714522#msg714522 |
|
|
|
... and there are shady rumors about reasons for Gavin to support it ...
Is it something along the lines of CIA remote-brainwashing peoples without them even knowing it? That what I would think if I were a conspiracy theorist, but it seems too far fetched to believe... I have a practical question though, when multiple public/private keys are used to produce a single bitcoin multisig address, does it mean that all private keys originate on the same (potentially compromised) computer and then one of them needs to be transferred to a phone or another device? Or does the second key orginate from that second device? In this case what is the exact procedure to create a multisig bitcoin address for the end user? |
|
|
|
What frightens me is that there is no way back if we make this step and it turns out to be a wrong direction.
Please explain to me how ANY of the proposals (the original OP_EVAL, BIP 16, and BIP 17) are any different in the "what if we change our minds and want to remove support" case? ... Yes, since any of the selected proposals will be cut in stone (in order for multisig transactions of this type to remain spendable) we will have to stick to it indefinitely. What I meant is that by making this brave step into unknown with BIP16 we might be violating some other properties of original Satoshi script which we haven't even thought of. Staying within current framework with BIP17 it is safer to assume that those properties will remain intact. And as Luke pointed out it is still possible to make this transition later and support second type of multisig transactions or maybe new scripting system all together. |
|
|
|
IsStandard() is a permanent part of the protocol with BIP 16.
Can you elaborate why that's the case? If true, I think it's very bad. IsStandard() needs to be lifted at some point (probably when there is a suite of tests around each and every opcode that verify that it does the specified thing and leaves all execution context in a valid state). Gavin is correct that the actual function named IsStandard() could be removed or replaced. However, with BIP 16, all implementations are required to check for the specific BIP 16 standard transaction and treat it differently. +1 I'm still with Luke on this one. While Gavin admits that he would love to make IsStandard more generic (moving from pre-defined scripts to generic resource-constrained ones) he still leaves handling of multisig as an eternal "special case" for some reason. On the other hand this "special case" might just be a first step into another way of doing things, and if there are other "special cases" in the future it wouldn't look that odd. What frightens me is that there is no way back if we make this step and it turns out to be a wrong direction. With Luke's solution we are not making any steps into unknown, we just implement the feature within the current framework. This will allow us to have multisig as soon as we want it, while giving us more time to think what kind of steps and in what direction we want to make. |
|
|
|
If nations like Greece, Spain, Italy start mining bitcoins quietly and then at some point make it public rising both the interest in this technology and the exchange rate, then as all the fiat currencies devalue so will their debt! At some point they should be able to sell some fraction of their bitcoins and repay all their debt in EUR, USD or any other fiat. Just noticed this post here: https://bitcointalk.org/index.php?topic=40264.msg697324#msg697324which says that largest share of "unknown" blocks comes from an IP address in Spain. So maybe this is already happening... |
|
|
|
|
I'm wondering, which of the two approaches is easier to deprecate?
Or is it cut in stone after it is deployed?
Imagine somebody comes up with a new way of doing multisig in a year and everybody agrees that it's the right way.
Also what approach makes it easier to add new features on top of?
Think of the list of features for the next couple of years and see if the discussed multisig proposals fit nicely or not.
|
|
|
|
|
Mining is what protects public blockchain from forgery in the current design.
So it is essential for Bitcoin that mining remains (barely) profitable indefinitely.
|
|
|
|
|
By the way, what happened to lc.ozco.in?
I haven't been checking it for a week and have some coins there....
Does anybody now its IP address or the server is down?
|
|
|
|
|
Show Posts
