Bitcoin Forum
June 19, 2024, 09:56:58 AM *
News: Voting for pizza day contest
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 [282] 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 »
5621  Bitcoin / Development & Technical Discussion / Re: I might have the solution for making escrow in bitcoin easier on: January 19, 2012, 09:33:56 AM
Thanks DeathAndTaxes and everyone. I finally get that what I am proposing will require multisig adoption for it to work safely.

On that note, I hope that whichever implementation is adopted, that there is an escrow function also adopted that does not:


  • require 3+ parties just to perform a single transaction
  • there is no 'time limit' created on the transactions where all coins are returned (same thing as not having escrow at all)
5622  Bitcoin / Development & Technical Discussion / Re: I have the solution for making escrow in bitcoin easier on: January 18, 2012, 10:45:35 PM
My proposal would be for allowing this to happen automatically. So long as you can write your own data to the blockchain, this client feature could be implemented without altering the fundamental protocol, correct?

No because the protocol has no understanding of your Bitcoin fragments.  It would consider them invalid transaction and reject them (and any block which included them).

So there is no way currently to inject strings into the blockchain inside of valid transactions?

Sure but I don't see how that does what you think it will do.
How about explain it is nuts and bolt at the code level.

I'm re-discussing this with my group to make sure I understand the fundamentals before I argue anymore. I think I am more focused on the user experience more than the protocol itself and that is blinding me to the similarities of what I am proposing and the existing multisig proposals.

My idea would require that a key be split in half in a safe way, which is impossible without a third party, and that alone would make it unsafe, and it would also be simplified by current multisig initiatives. The thing I can't wrap my head around is why would someone need to 'confirm' a refund? Is this just inherent to the multisig functionality and unavoidable?
5623  Bitcoin / Development & Technical Discussion / Re: I have the solution for making escrow in bitcoin easier on: January 18, 2012, 10:20:43 PM
My proposal would be for allowing this to happen automatically. So long as you can write your own data to the blockchain, this client feature could be implemented without altering the fundamental protocol, correct?

No because the protocol has no understanding of your Bitcoin fragments.  It would consider them invalid transaction and reject them (and any block which included them).

So there is no way currently to inject strings into the blockchain inside of valid transactions?
5624  Bitcoin / Bitcoin Discussion / Re: Copyright lawyers lurking on Bitcointalk on: January 18, 2012, 10:18:08 PM
Did they ask you to pull the episode of The Good Wife?

I guess this is always a possibility but it doesn't mean their lawyers are on the site. The show just did a bit on bitcoins and the shows producers may have been monitoring the forums to see our reaction. This producer (or someone else affiliated with the show) probably saw the thread and took appropriate action. It's unfortunate but posting it on here was completely unnecessary since it was posted on the CBS website immediately after.

"The video you have requested is not available for your geographic region."

Yes, it was necessary. I still don't understand why the media industry treats the digital world, the internet, the old fashioned way. Geographic borders? On the internet? Really?

The entertainment industry is just taking a cue from world governments. They are the ones basing rules for internet based off of geographic boundaries. The entertainment industry is just exploiting it.
5625  Bitcoin / Development & Technical Discussion / Re: I have the solution for the trust/escrow issue in bitcoin on: January 18, 2012, 10:12:15 PM
Had you said "I know multi-sig solves the trust/escrow issue in Bitcoin" but I have a method to make it more user friendly we wouldn't be having this issue.

Good point. I'll update my original post and thread title to clarify this.


With mult-sig the receiver would issue an updated transaction (increment sequence number) and sign it.   To get the funds the sender would sign it.  This would invalidate the prior transaction and funds would return to sender.
My proposal would be for allowing this to happen automatically. So long as you can write your own data to the blockchain, this client feature could be implemented without altering the fundamental protocol, correct?


5626  Bitcoin / Development & Technical Discussion / Re: I have the solution for the trust/escrow issue in bitcoin on: January 18, 2012, 10:02:38 PM
Not at all. In my proposal, the crucial difference (a matter of convenience if nothing else) is that the receiver can send the fragment back without the participation of the sender.

A refund can be done via multi-sig also.

Even with only one party's consent?
5627  Bitcoin / Development & Technical Discussion / Re: I have the solution for the trust/escrow issue in bitcoin on: January 18, 2012, 09:57:41 PM
Using mult-sig you can implement EXACTLY what you proposed.  I am not confused.  There is no need to simplify anything. You send coins to an address locked by two private keys. The seller & buyer both have one key. Neither can access the coins without other private key.   Seller ships goods to buyer, and buyer then send his key to seller.   Seller uses pair of keys to gain control of funds.  There is no need for third parties in multi-sig (they could be used in a 2 out of 3 setup but they aren't a requirement).  Nothing is required other than the blockchain, updated protocol (w/ miner support), and updated clients.

Please take the time to read proposals before you shoot them down. It is quite clear you are not reading it.

I don't get it, isn't this the exact same as "neither can access the coins without the other fragment"?

Not at all. In my proposal, the crucial difference (a matter of convenience if nothing else) is that the receiver can send the fragment back without the participation of the sender.

As you can see, this is fundamentally different as it allows a more streamlined transactions interface for the client as well and does not require any communication between the two parties whatsoever.
5628  Bitcoin / Development & Technical Discussion / Re: I have the solution for the trust/escrow issue in bitcoin on: January 18, 2012, 09:52:59 PM
Using mult-sig you can implement EXACTLY what you proposed.  I am not confused.  There is no need to simplify anything. You send coins to an address locked by two private keys. The seller & buyer both have one key. Neither can access the coins without other private key.   Seller ships goods to buyer, and buyer then send his key to seller.   Seller uses pair of keys to gain control of funds.  There is no need for third parties in multi-sig (they could be used in a 2 out of 3 setup but they aren't a requirement).  Nothing is required other than the blockchain, updated protocol (w/ miner support), and updated clients.

Please take the time to read proposals before you shoot them down. It is quite clear you are not reading it.


Just because you were unaware of all the discussions involving multi-sig for last year or so doesn't mean you came up with anything new or novel.
I don't think what I am talking about is even related to the current discussions of multiple signatures. If you'd like to provide evidence of similarities, I will be more than happy to listen, but at the moment it seems you're just discounting something out of pure laziness.
5629  Bitcoin / Bitcoin Discussion / Re: March 2012 BitCon in San Antonio, Texas - News Thread on: January 18, 2012, 09:43:55 PM
Hey,

The sites down, any update on this?

I'd like to attend and possibly be a speaker or get a booth

Charlie

If you get to be a speaker, I want to be a microphone, so that I can blow you. </gay>
5630  Bitcoin / Development & Technical Discussion / Re: I have the solution for the trust/escrow issue in bitcoin on: January 18, 2012, 09:42:57 PM

There are a lot of details on how this would be implemented, and sounds like there may be some work done here already for split keys. What I am getting from your idea is that escrow could be done with no 3rd party whatsoever. Also, refunds could be back to the sender without any action on the senders part. This would be a great value adding functionality to the bitcoin client.

That is correct. Perhaps my explanation was too difficult for the previous posters to understand. Should I simplify it?
5631  Bitcoin / Development & Technical Discussion / Re: I have the solution for the trust/escrow issue in bitcoin on: January 18, 2012, 09:25:36 PM
This has already been discussed and potential implementations already exists.  It just requires multi-sig transactions.  Practical applications require changes to the protocol hence the discussion on OP_EVAL & P2SH.

Don't feel bad once when I was young I thought I invented secure key exchange without realizing it had already existed for a couple decades.

This has already been discussed and potential implementations already exists.  It just requires multi-sig transactions.  Practical application requires changes to the protocol hence the discussion on OP_EVAL & P2SH.

This.

For the record I've read https://en.bitcoin.it/wiki/Contracts and am also quite aware of what benefits multi-signature transactions will bring.

It is possible that through multi-signature transactions, a model that I am proposing could be more easily implemented, but I find no where in the discussions anything resembling what I am proposing.

All existing proposals as I know of require:

  • third-parties
  • agreement from both parties, even to return coins to sender

Please elaborate.
5632  Bitcoin / Development & Technical Discussion / Potential solutions for Escrow/Fraud issues on: January 18, 2012, 08:59:36 PM
I believe that modern escrow solutions are archaic at best and rely too much on the opinions of a possibly ignorant third party. I propose a feature to bitcoin that will remove the need for an external escrow solution, strengthening the economy and ridding our community of fraud once and for all.

I will call this proposition "coin fragmentation". To properly explain coin fragmentation, I must first briefly outline the process of a bitcoin transaction based on the current implementation:

  • Jon sends 1BTC to Mary
  • Jon loses access to that 1BTC
  • Mary gains access to that 1BTC

As anyone can see, this requires that Jon trust Mary first to provide whatever services she has offered, and as such opens opportunity for fraud and confidence trickery.

As you can see from the following outline, by inserting just two programmatic steps, we can  remedy this once and for all:

  • Jon sends 1BTC to Mary

  • 1BTC is split and locked into two individually worthless fragments

  • Jon loses access to that 1BTC

  • Mary must now provide promised services before Jon will release his fragment.


From this point, we have several possible outcomes. For simplicity, let's separate them by an honest and dishonest transaction.

Honest
  • Maria proceeds to provide services rendered, Jon releases his fragment. Maria now has 1BTC.
  • Maria does not provide services rendered, Maria releases her fragment. Jon now has 1BTC.

As is clear above, no additional complications arose from implementing this feature given an honest transaction.

Dishonest
  • Maria proceeds to provide services rendered, Jon does not release his fragment. Neither Jon nor Maria have the 1BTC until the other releases their locked fragment.
  • Maria does not provide services rendered, Jon does not release his fragment. Neither Jon nor Maria have the 1BTC until the other releases their locked fragment.

In the above outline, all monetary incentives to defraud have been removed.

With implementation of this feature, bitcoiners would be able to:
  • Trade safely and openly with complete strangers
  • Return incorrect amounts back to sender
  • Provide refunds
  • Improve negotiation and problem solving techniques
  • Enforce higher standards for service quality in the community



Thank you.


Matthew N. Wright
5633  Bitcoin / Bitcoin Discussion / Re: BitTalk.TV Interview with Zhou Tong of Bitcoinica.com on: January 17, 2012, 07:31:32 PM
We will no longer be receiving questions for the Zhou Tong interview. Thank you for your participation!

We'll announce the interview in this thread and on BitTalk.TV.

5634  Other / Politics & Society / [Announcement] SOPA Black-out, January 18th on: January 17, 2012, 09:46:49 AM
In an internet-wide effort to raise awareness to the negative effects of SOPA, the following businesses and websites from the bitcoin community will be blacking out on January 18th, 2012.


Post your business/website below and it will be added.

Thank you.
5635  Economy / Speculation / Re: bitscalper anyone use this ? on: January 16, 2012, 06:26:59 PM
Since when Bitcoins = cash by law in italy? So you can pay taxes in BTC?
By that logic, you should be able to pay your taxes in the US with Korean Won.

Only legal tender is cash. Legally I doubt that BTC exists at all. But I am curious to hear opposite expert views.

Indeed. Legal tender in any country would be considered 'cash', and 'cash' from a foreign country would be considered 'foreign cash'.

You cannot pay your taxes in any country (that I know of) with foreign cash.

Bitcoins are not cash. I don't know why anyone is even talking about that. The argument is not about bitcoin being cash, as facebook credits, wow gold, and prepaid cards are not cash either. They are stored credits however transferable to 'cash' and acceptable by non-government bodies as 'cash', hence the government may treat them as 'cash' for prosecution.

I degress, a country not accepting a certain form of payment for paying taxes does not mean that form neither is nor is not a currency in some country.
5636  Economy / Speculation / Re: bitscalper anyone use this ? on: January 16, 2012, 05:44:50 PM
It's totally illegal now because the parlament just approved laws that impose the use of cash up to 1000 eur, for more you have to use a bank account. So bitcoin = money laundering in italy = jail.

Since when Bitcoins = cash by law in italy? So you can pay taxes in BTC?



By that logic, you should be able to pay your taxes in the US with Korean Won.
5637  Economy / Speculation / Re: bitscalper anyone use this ? on: January 16, 2012, 11:47:31 AM
About time we had another BTC scam. And as usual there's no shortage of gullible users. "Of course it's too good to be true, but if we all chip in with small amounts we can still make this scam successful".

Reminds me of the forex scheme "Maria" was running here a few months ago. "Just deposit $1000 and run this random binary for guaranteed 20% weekly profit. Sorry guys, the system failed. Balance: 0."

One could argue a certain level of gullibility being a requirement to get into bitcoin in the first place. That might explain your findings.
5638  Bitcoin / Bitcoin Discussion / Re: Bitcoin in tv show -The Good Wife - Episode 3.13 - Finding Mr. Bitcoin on: January 16, 2012, 10:43:12 AM
Spoilers:

-Bitcoin is still an illegal currency,
-It is too much of a hassle,
-It was created by a lawyer who needs a lawyer,
-Super-cryptologists can embed secret messages in the bitcoin "code" using other people's computers remotely, and the IP addresses used are easily traceable for anyone who wants to look,
-In a world where you have a moderate stack of cash to plunk down, you can get a whole law firm's undivided attention and a one-day trial in a well decorated courtroom with a jovial judge and no jury when charged with a crime by the federal government.
-Software coders are fidgety asian dweebs who would proclaim they love a snoopy lawyer they just met.

and
- when you are accused of giving a bribe, you get ineptly questioned by a pretty investigator at whatever location you specify, instead of being woken up at 3am by g-men with guns.

+1
5639  Bitcoin / Mining / Re: Bitcoin BIP 16 /P2SH/ is bad, your action is needed! on: January 16, 2012, 10:40:30 AM
By the way last time I checked P2Pool was third in hashrate distribution (after DeepBit and BTCGuild) so convincing a few pool owners might still work for some time, but in a long run individual miners should be involved in decision making and everybody should understand the pros and cons of a particular approach.
Current global p2pool hash rate is around 70-80 GH/s. So it's less than 1%.

Just think: Theoretically here pretty soon you'll be able to drop $50k on 2 ButterflyLabs rack boxes and get that on your own.
5640  Economy / Speculation / Re: bitscalper anyone use this ? on: January 16, 2012, 07:45:51 AM
My personal feeling is that were this a legitimate service, the site owners would be content to sit back and let time prove their worth (a few concise explanatory posts would not be out of place). As it stands they are basically trying to win a PR war.

Sorry if this is seen as trolling. I just don't want people to get ripped off.

I don't think they're trying to do anything. They're just new here and don't know how we roll.

Pages: « 1 ... 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 [282] 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!