Topic: BIP 16 / 17 in layman's terms - page 2. (Read 38982 times)

Too bad! EDIT: kind of proves my point, we didn't need it in the protocol!

Satoshi proposed this shortly before he disappeared. Unfortunately, it never got implemented for Bitcoin (yet). Today, it is alive and well in the form of merged-mining.

Yeah, it was more meant as a critique: if the bitcoin protocol was properly designed it would allow for alternate coins WITHIN the protocol to "make inflation possible" EDIT: without needing separate block chains.

Neither BIP16/BIP17 have anything to do with block construction, blocks are not signed, and coins/transactions are not mined. What you choose to mine your blocks with is your own, but certain alternative chains may be optimized for FPGA's or not. Furthermore, what your greencoin branch of bitcoins do or do not, is up to you.

Ok, nice to hear! So can I use it to sign blocks/coins that where mined with FPGAs in order to create a greencoin branch of bitcoins?

The point of BIP 17 is that it is generic...

When you make protocols/APIs based on "could" you sometimes try to solve everything. I think bitcoin urgently needs a low bandwidth protocol that can scale to millions of transactions per day without needing terrabit internet / petabyte harddrives. Everything else is prio 2, like extensions; which if they are added should not be "hardcoded".

In my 10 year time as programmer I have learned to discern between generic and applied code. Unless the BIP 16/17 application is implemented in a broader generic solution that doesn't make the protocol that much heavier and already has many other vital applications, it should be carefully be considered.

I'm just suggesting the developers focus on the complex and hard to solve core matters, and let the community build the "nice to haves".

I don't think "could" is being used to signify an optional parameter in this sentence.  What are you trying to say?

While a service can replicate the functionality that these BIPs provide, a service requires trust .  Requiring a minimal amount of trust is a pretty central component of Bitcoin IMHO

My issue is the 'could' in your first sentence. API's and protocols are about 'should' not 'could'. All of your examples can be solved without it too. Just because you can (could) doesn't mean it's a good idea.

 I am pretty sure you either totally misunderstood what this change is about, or have not thought enough about what requiring two completely separate security keys to sign a transaction could be used for. Think multiple signatures on a check, escrows without requiring a third-party, multi device authentication, etc.

Ok, I understand that a lot of thought has been put into this, but out of experience I can say that when many very complex solutions arise to one problem, it's often the problem that is the problem. There is no transaction system in the world that is secure, it's not mathematically possible. And adding steps to render transactions more secure/cumbersome can be done outside of the bitcoin solution, outside of the computer even, it doesn't need to be integrated into the protocol.

I would still recommend implementing a lighter transaction system that can scale, not a complex one that solves a problem nobody needs solved.

Step 1, I tell my client to send 5 coins to address XYZ.
Step 2, my client creates that transaction, signs it with the key it has, then sends it to my wallet service.
Step 3, my wallet service looks up my policy preferences, and since the transaction is more than 2 BTC but less than 10 BTC (my policy) it sends a text message to my phone asking me to look up and reply with code Q7.
Step 4, I pull my wallet service card out of my (physical) wallet, go down to row Q and over to column 7, read d013e7 and punch it into my phone.
Step 5, my wallet service verifies my reply, then signs the transaction that I had sent it earlier using the key it has.
Step 6, my wallet service now sends my double-signed 2-of-2 key transaction out to the bitcoin network.
Step 7, the bitcoin network checks that the two signatures on this transaction match the P2SH signature that was provided earlier, and the BTC shows up in the vendor's wallet.

You have a good point but the point is not entirely accurate. There is a distinction between clients and services, services can handle the security in other ways but clients can't! A good example is the blockchain.info webwallet, which recently added google authentication to their service. With clients it's a totally different story though, you can't add google authenticator to a regular client because there is no service to take care of the support.

That's why it actually does make sense to add protocol level support for multi-device authentication. Then it can be done in a "do it yourself" way, just like Bitcoin is meant to be. This is not just for that though, P2SH will enable escrow features also.

However, your point regarding the complexity is valid, although the protocol level implementation speaks nothing of the complexity for the user. I don't know how much thought the devs have put to how this will actually work from the user's perspective but I hope they have thought about it a lot. I mean, if this is one iota more complex than setting up google auth, then it's a complete waste of time. Only people who don't really need it would use it.

The truth is that the people who are most susceptible to having their computers full of keyloggers most likely have no clue about anything nor will they ever be using so called regular clients. The future of Bitcoin is web wallet services and server based light nodes, only so called nerd power users will be running the original clients. Do they need this? That is the question.

Although I think the problem of security applies to full node clients the same way as it does to server based clients, both could benefit from this a lot if it's made easy. If it's not made easy, all of this work is for nothing. If people want security and convenience they could just use a webwallet service with google auth, problem solved.

So in conclusion I would like to see someone explain to me how does signing transactions from multiple devices actually work, step by step? If this hasn't been thought out in advance, you have to be kidding me.

This has been proposed and discussed in depth already. Multisig solves the problem of one hacked device, and multiple hacked devices are much less likely. External security firms add centralization to the system and don't guarantee they won't be A) attacked physically or B) run away with the coins or C) screw up and lose even MORE coins. Even guns have a safety.

Ok, to me this seems like over engineering hell. You are trying to implement a really complex system to solve something you can't solve. Namely the: "guns don't kill people, people kill people" all over again. I humbly suggest the attention be put to scale the bitcoin transaction system instead, security can be handled by external solutions/third parties.

This is the wrong model.  The problem you mention is even worse today.  Even if you wait the full 6 confirmations, it will still be hours or days faster than waiting for the store and your bank to process a refund to your credit card.  Also, good luck getting cash refunds.  Most places mail you a check when refunding a cash transaction when the amount is over some tiny limit.

Sorry to be short. The silly part is the cashier waiting for the coins she accidentally charged you incorrectly to get 6 confirms. Obviously no one wants to wait 6 confirms in any situation.

Waiting any confirms at all in any small value situation where you can actually see the person is just rude and unnecessary. If a guy is willing to walk off without paying why both pretending to pay first? To get a 10 or 60 minute head start? Where you going to run after him and try to fight about it? It makes zero difference whether  cops get there 1 hour or 2 hours after the fact to take your report about the stolen groceries.

i would.

because as you say, an attack is unlikely (far less likely than credit card fraud).

If they are 1 confirmation deep, I know I can spend them. In fact I think i can spend them with one no confirmations. Thats not the problem.

Will a second merchant accept those coins in a transaction tho?  I don't think so. Otherwise they would be opening themselves to a double spend attack (which is still unlikely)