Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bitcoin's $137k Jackpot

hackingdistributed.com

Post reply on HN
Print view View original

91–100 of 156 posts

Re: Bitcoin's $137k Jackpot

#91

Post by matt_wulfeck »

brg1007 wrote: post #50
aianus wrote: post #31

Earlier quoted context omitted.

> So each transaction costs 11000/2000=5.5 USD No, each transaction costs at most $5.50 USD. You haven't established any lower bound in your calculations. A better approach would be to calculate the average number of hashes required to mine a block and the power efficiency of the latest generation ASIC miners. Also, for what it's worth, $5 is much cheaper than a Western Union or SWIFT wire transfer so even this upper…

Meanwhile in Europe I'm paying 30 cents for bank transfers within the EU up to 50K.

That's a shame. I just transferred money from one bank to another here in the US and it was free. To my surprise it also happened instantly!

Re: Bitcoin's $137k Jackpot

#92

Post by achr2 »

enraged_camel wrote: post #49
Houshalter wrote: post #37

Earlier quoted context omitted.

The problem with confirmation is it trains the human to always press "yes". You need a system that only activates if something really unusual or wrong.

So instead of a yes/no confirmation, you force the user to explicitly type what they are doing, i.e. "Sell 610,000 shares of stock X for 1 yen each." This is similar to how Github forces you to type the name of a repository when you try to delete it. You can also configure a threshold such that the "hardcore" prompt kicks in only if the system detects that the user is trying to do something unusual, i.e. sell a stock…

Though I wish Github didn't do that for forks that are less than a few minutes old or have no commits...

Re: Bitcoin's $137k Jackpot

#93

Post by StavrosK »

enraged_camel wrote: post #49
Houshalter wrote: post #37

Earlier quoted context omitted.

The problem with confirmation is it trains the human to always press "yes". You need a system that only activates if something really unusual or wrong.

So instead of a yes/no confirmation, you force the user to explicitly type what they are doing, i.e. "Sell 610,000 shares of stock X for 1 yen each." This is similar to how Github forces you to type the name of a repository when you try to delete it. You can also configure a threshold such that the "hardcore" prompt kicks in only if the system detects that the user is trying to do something unusual, i.e. sell a stock…

I like what mycelium does. You type the amount, and there's a button that will change state on every press, and cycles though "generous", "normal", "economical" and "stingy" or something like that.

That way, a user doesn't have to know what value to use. You can also set this once in settings and never see it again, except as a report.

Re: Bitcoin's $137k Jackpot

#94

Post by nandemo »

CydeWeys wrote: post #81
vilhelm_s wrote: post #23

Earlier quoted context omitted.

Ordinarily transactions are broadcasted to the entire network for anyone to process. The miner who first finds a solution will get the fee for that transaction. I think the idea here is that you instead privately give the transaction to only your favoured miner. He will then try to hash it, and if and when he finishes it, he will broadcast the transaction and the solution to the network at the same time. Ordinarily t…

> I think the idea here is that you instead privately give the transaction to only your favoured miner. He will then try to hash it, and if and when he finishes it, he will broadcast the transaction and the solution to the network at the same time. That's not really a good description of how this will work. Each miner maintains a transaction pool of transactions that have been broadcasted across the network. Think of…

I might be wrong, but I feel you gave a lower-level (more detailed) description of "the idea here is that you instead privately give the transaction to only your favoured miner".

Re: Bitcoin's $137k Jackpot

#95

Post by xigency »

CydeWeys wrote: post #78
xigency wrote: post #46

Earlier quoted context omitted.

Yes, but that isn't the entire purpose of digital currency. It is just a part of Bitcoin.

I've been using central ledger currency systems (i.e. logging into my bank's website and issuing payments) for longer than Bitcoin has existed. Decentralization is the entire point of Bitcoin. Take that away and you aren't left with anything that wasn't already done long ago. What you're proposing is something that banks have already been doing widely for decades.

> Take that away and you aren't left with anything that wasn't already done long ago

And that is exactly my point. There are very interesting ideas in digital currencies/digital cash that have no representation in Bitcoin or at all.

By using Bitcoin, like using your bank's website, you still need an Internet connection to use your currency digitally.

However, it's possible to create a digital currency that doesn't have to be plugged-in to a network to operate. Being able to send an e-mail with a cash value integrated in its data is something that hasn't been done long ago, or even yet today.

Even better, some digital currencies could (conceptually) be sent in a paper letter as cash.

Whether the value is created algorithmically or by bankers is a separate, economic debate, and really less interesting, in my opinion, than the technology itself.

Re: Bitcoin's $137k Jackpot

#96

Post by derefr »

fiatmoney wrote: post #86
XaspR8d wrote: post #55

Earlier quoted context omitted.

> Worse still, the number of shares in Mizuho's order was 41 times the number of J-Com's outstanding shares, but the Tokyo Stock Exchange processed the order anyway. There are a lot of simultaneous errors going on here...

Stock exchanges really cannot be expected to track numbers of outstanding shares. One puts in a bid or an ask, indicating that one is willing to purchase or sell the given number at the given price, and an order type, indicating the manner to fulfil (fill-or-kill, limit to a certain price, take whatever outstanding offers are necessary...). This is more than enough nuance for a professional product like a stock excha…

Coming from a perspective of competitive multiplayer game networking, that seems insane. You can't trust the client. An ideal stock exchange, I'd think, would include the same sort of logic as a payment processor: blocking any orders that seem to be "not the sort of order this client would make", to prevent e.g. orders being executed by people who have illegitimately gained access to the account.

Of course, these type of algorithms typically take far more than microseconds to run—but that's fine, as long as they take the same time for everyone.

Re: Bitcoin's $137k Jackpot

#97

Post by xigency »

Melkman wrote: post #77
xigency wrote: post #46

Earlier quoted context omitted.

Yes, but that isn't the entire purpose of digital currency. It is just a part of Bitcoin.

Almost all currencies are digital today. Bank notes are just a physical transaction mechanism. You could use Bitcoin notes if you want with the private key under a scratch layer. The big difference is exactly that Bitcoin has no central authority. If that doesn't matter to someone he'd be perfectly happy to use state endorsed currencies.

Digital cash doesn't have a scratch-off layer. It has information associated with its minting and mechanisms to be used in spending and transactions.

> ... perfectly happy to use state endorsed currencies.

Unless what you are looking for is a digital currency.

Being able to send $5,000 cash in the form of information is a separate issue from who controls the money supply. If someone wants to exchange that amount without having access to a distributed network of computers, is that more centralized?

What I'm saying is, I would be happy to use an information based currency, even if it means holding a key with a central authority, if it means being able to make free, anonymous transactions easily with a completely digital, offline currency.

That is not what Bitcoin provides. And it isn't possible to e-mail paper bills, either.

Re: Bitcoin's $137k Jackpot

#98

Post by xigency »

stale2002 wrote: post #45
xigency wrote: post #33

Earlier quoted context omitted.

Yes, and maybe that was the main obstacle to implementation. Reading some of the original literature, and glossing over the textbook, it seems like many of the issues involved with double spending and counterfeiters are _eventually_ resolved with someone going to jail, rather than being able to resolve the financial payments in order. A naïve solution - which might save some energy - what about using signed timestamp…

OK, but then you have to have an authority, and that authority would have power over you and the transaction! The whole point of bitcoin is permissionless transactions. It is to make transactions even if the authorities don't want them to happen.

No, I'm saying the authority would provide resources to enable transactions, not an authority that controls transactions, which is actually what the distributed network of miners does in the case of Bitcoin.

In this case, the authority would provide stamps for transactions.

Re: Bitcoin's $137k Jackpot

#99

Post by patio11 »

Cyph0n wrote: post #9
hughes wrote: post #2

This reminds me of a similar error from 2005[1] where a trader mistook the "price" and "quantity" fields of the trading software. Instead of selling 1 share for 610,000 yen, 610,000 shares were sold for 1 yen. The mistake cost around $225 million. [1] http://www.foxnews.com/story/2005/12/09/typing-error-causes-...

Damn that's huge. You'd assume that the software checks the dollar amount and asks for a confirmation, or better yet permission from a higher up, if it exceeds some value.

It got flagged multiple times and, each time, someone at the Tokyo Stock Exchange came to the conclusion that they didn't have the authority to countermand the order. The regulator was livid about this in the report.

Re: Bitcoin's $137k Jackpot

#100

Post by CydeWeys »

nandemo wrote: post #94
CydeWeys wrote: post #81

Earlier quoted context omitted.

> I think the idea here is that you instead privately give the transaction to only your favoured miner. He will then try to hash it, and if and when he finishes it, he will broadcast the transaction and the solution to the network at the same time. That's not really a good description of how this will work. Each miner maintains a transaction pool of transactions that have been broadcasted across the network. Think of…

I might be wrong, but I feel you gave a lower-level (more detailed) description of "the idea here is that you instead privately give the transaction to only your favoured miner".

The comment I replied to said several things that are wrong. I understand that it was attempting to give a higher-level overview, but it did so in a way that made things inaccurate. Let me break it down.

> Ordinarily transactions are broadcasted to the entire network for anyone to process.

Process is sort of inaccurate here (it implies mining). Transactions are broadcast across the network in a P2P manner amongst all full Bitcoin nodes, so long as they validate anyway. Miners themselves are running full nodes, and find out about transactions because they come across the P2P network.

> The miner who first finds a solution will get the fee for that transaction.

Miners aren't trying to "find a solution" to transactions. That description isn't accurate. What miners are trying to do is figure out what nonce to insert into a block (which includes a lot of transactions, along with metadata) such that the hash of the entire block is less than some very small target number. Understandably, this takes a large amount of tries, to the point where you have mining pools that distribute ranges of nonces across a large number of workers to pool their effort (i.e. distributed computing).

> I think the idea here is that you instead privately give the transaction to only your favoured miner.

This part is correct.

> He will then try to hash it

Nope. Transactions are static. They always hash to the same value. What the miner is doing is trying to find a valid block. The miner isn't doing anything to specific transactions other than validating them, which any full node does.

> and if and when he finishes it, he will broadcast the transaction and the solution to the network at the same time.

Nope. All valid transactions are broadcast by all full nodes as part of the normal P2P operation. What the comment was trying to talk about was broadcasting a valid block. There is no "solution" per se -- there's no guarantee that a nonce even exists that yields a hash below the target for any given set of transactions and block metadata. However, the transaction pool is constantly changing as more transactions are received, so constant churn in the transaction set as well as being able to run through the entire range of nonces each time guarantees that, with enough hashing, you will eventually find a combination that yields a hash that is sufficiently low enough. And then the block is broadcast.

Hope that clears things up.

Post reply on HN