Bitcoin Forum
March 28, 2024, 12:01:48 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 [15] 16 17 »  All
  Print  
Author Topic: BIP 16 / 17 in layman's terms  (Read 38981 times)
FreeMoney
Legendary
*
Offline Offline

Activity: 1246
Merit: 1014


Strength in numbers


View Profile WWW
February 24, 2012, 01:53:28 AM
 #281

Waiting 6 confirmations to get refunded might suck.  Especially if its the fault of the cashier.

Lol wut

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
Make sure you back up your wallet regularly! Unlike a bank account, nobody can help you if you lose access to your BTC.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500



View Profile WWW
February 24, 2012, 02:22:44 AM
 #282

Waiting 6 confirmations to get refunded might suck.  Especially if its the fault of the cashier.

Lol wut
I only carry a few BTC that are easily accessible from my phone.  The rest are on a locked down computer or paper storage.

Say I send 10 BTC to a shirt store to buy some shirts. It turns out I bought the wrong size shirt and so go to return it. They don't have the size I want and so I ask for a refund.

With cash, they can just give me cash back and I can go to another store and immediately buy something.

With bitcoin, if they credit my phone's wallet with the refund, I can't spend those coins at the store next door until I wait for 6 confirmations.  Depending on how many coins I have in my phone's wallet, this could be a problem.

Make sense?

EDIT: This has nothing to do with BIP 16/17

paraipan
In memoriam
Legendary
*
Offline Offline

Activity: 924
Merit: 1004


Firstbits: 1pirata


View Profile WWW
February 24, 2012, 02:32:48 AM
 #283

Waiting 6 confirmations to get refunded might suck.  Especially if its the fault of the cashier.

Lol wut
I only carry a few BTC that are easily accessible from my phone.  The rest are on a locked down computer or paper storage.

Say I send 10 BTC to a shirt store to buy some shirts. It turns out I bought the wrong size shirt and so go to return it. They don't have the size I want and so I ask for a refund.

With cash, they can just give me cash back and I can go to another store and immediately buy something.

With bitcoin, if they credit my phone's wallet with the refund, I can't spend those coins at the store next door until I wait for 6 confirmations.  Depending on how many coins I have in my phone's wallet, this could be a problem.

Make sense?

the coins can be spent after the first confirm. The 6 rule is to be sure they are deep enough so a double spend could not take them from you. You would pay the same fee with 1 or 6 confirms as the coins would have to age a little more if you wouldn't want to pay that.

BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500



View Profile WWW
February 24, 2012, 02:45:26 AM
 #284

Waiting 6 confirmations to get refunded might suck.  Especially if its the fault of the cashier.

Lol wut
I only carry a few BTC that are easily accessible from my phone.  The rest are on a locked down computer or paper storage.

Say I send 10 BTC to a shirt store to buy some shirts. It turns out I bought the wrong size shirt and so go to return it. They don't have the size I want and so I ask for a refund.

With cash, they can just give me cash back and I can go to another store and immediately buy something.

With bitcoin, if they credit my phone's wallet with the refund, I can't spend those coins at the store next door until I wait for 6 confirmations.  Depending on how many coins I have in my phone's wallet, this could be a problem.

Make sense?

the coins can be spent after the first confirm. The 6 rule is to be sure they are deep enough so a double spend could not take them from you. You would pay the same fee with 1 or 6 confirms as the coins would have to age a little more if you wouldn't want to pay that.
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)

payb.tc
Hero Member
*****
Offline Offline

Activity: 812
Merit: 1000



View Profile
February 24, 2012, 03:43:16 AM
 #285

Waiting 6 confirmations to get refunded might suck.  Especially if its the fault of the cashier.

Lol wut
I only carry a few BTC that are easily accessible from my phone.  The rest are on a locked down computer or paper storage.

Say I send 10 BTC to a shirt store to buy some shirts. It turns out I bought the wrong size shirt and so go to return it. They don't have the size I want and so I ask for a refund.

With cash, they can just give me cash back and I can go to another store and immediately buy something.

With bitcoin, if they credit my phone's wallet with the refund, I can't spend those coins at the store next door until I wait for 6 confirmations.  Depending on how many coins I have in my phone's wallet, this could be a problem.

Make sense?

the coins can be spent after the first confirm. The 6 rule is to be sure they are deep enough so a double spend could not take them from you. You would pay the same fee with 1 or 6 confirms as the coins would have to age a little more if you wouldn't want to pay that.
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)

i would.

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

Activity: 1246
Merit: 1014


Strength in numbers


View Profile WWW
February 24, 2012, 03:51:40 AM
 #286

Waiting 6 confirmations to get refunded might suck.  Especially if its the fault of the cashier.

Lol wut

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.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
February 24, 2012, 03:54:04 AM
 #287

Waiting 6 confirmations to get refunded might suck.  Especially if its the fault of the cashier.

Lol wut
I only carry a few BTC that are easily accessible from my phone.  The rest are on a locked down computer or paper storage.

Say I send 10 BTC to a shirt store to buy some shirts. It turns out I bought the wrong size shirt and so go to return it. They don't have the size I want and so I ask for a refund.

With cash, they can just give me cash back and I can go to another store and immediately buy something.

With bitcoin, if they credit my phone's wallet with the refund, I can't spend those coins at the store next door until I wait for 6 confirmations.  Depending on how many coins I have in my phone's wallet, this could be a problem.

Make sense?

EDIT: This has nothing to do with BIP 16/17

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.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
rupy
Hero Member
*****
Offline Offline

Activity: 725
Merit: 500



View Profile
February 24, 2012, 08:38:41 AM
 #288

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.

BANKBOOK GWT Wallet & no-FIAT Billing API
Explodicle
Hero Member
*****
Offline Offline

Activity: 950
Merit: 1001


View Profile
February 24, 2012, 01:56:10 PM
 #289

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 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. Smiley
Technomage
Legendary
*
Offline Offline

Activity: 2184
Merit: 1056


Affordable Physical Bitcoins - Denarium.com


View Profile WWW
February 24, 2012, 02:06:56 PM
 #290

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.
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.

Denarium closing sale discounts now up to 43%! Check out our products from here!
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
February 24, 2012, 02:28:39 PM
 #291

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.

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.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
rupy
Hero Member
*****
Offline Offline

Activity: 725
Merit: 500



View Profile
February 24, 2012, 09:48:05 PM
 #292

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.

BANKBOOK GWT Wallet & no-FIAT Billing API
Rassah
Legendary
*
Offline Offline

Activity: 1680
Merit: 1035



View Profile WWW
February 24, 2012, 10:37:35 PM
 #293

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.

 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.
rupy
Hero Member
*****
Offline Offline

Activity: 725
Merit: 500



View Profile
February 25, 2012, 02:43:35 AM
 #294

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.

BANKBOOK GWT Wallet & no-FIAT Billing API
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500



View Profile WWW
February 26, 2012, 07:07:38 PM
 #295

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.
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

Red Emerald
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500



View Profile WWW
February 27, 2012, 07:12:30 AM
 #296

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.
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

'should' = mandatory parameter
'could' = optional parameter

pretty sure most APIs/protocols have both kinds.


Quote
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.

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

rupy
Hero Member
*****
Offline Offline

Activity: 725
Merit: 500



View Profile
February 27, 2012, 08:18:03 PM
 #297

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".

BANKBOOK GWT Wallet & no-FIAT Billing API
Luke-Jr
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
February 27, 2012, 08:33:33 PM
 #298

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".
The point of BIP 17 is that it is generic...

rupy
Hero Member
*****
Offline Offline

Activity: 725
Merit: 500



View Profile
February 27, 2012, 08:49:14 PM
 #299

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?

BANKBOOK GWT Wallet & no-FIAT Billing API
Pieter Wuille
Legendary
*
Offline Offline

Activity: 1072
Merit: 1170


View Profile WWW
February 27, 2012, 09:05:23 PM
 #300

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?

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.

I do Bitcoin stuff.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 [15] 16 17 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!