 Show Posts
|
|
Pages: [1]
|
Its not how bitcoin works, but its an interesting concept. Instead of having the whole world verify blocks, one could somehow use nodes in some proximity. One could call it local web of trust.
One worry is the bar thinks its getting paid because it's seeing false confirmations, when in reality it's giving away drinks for free because the transactions are never getting relayed to the rest of the network. Nope. A "confirmation" is a valid block with the transaction included, and a valid block includes a proof of work. The proof of work is far too valuable to waste trying to double spend in a bar. Except for 2 things: in rapid low-value retail environments where we're told 0 conf should be ok, and I know bars that turn over £2,000+/night. Plenty of easy pickings if you spoof a few confirmations by pretending to be the rest of the network. Are you aware that the block reward is currently worth 19200 USD? That's how much it costs to spoof a single confirmation. Nodoby is going to do that just to get a few free drinks in a bar. |
|
|
|
Its not how bitcoin works, but its an interesting concept. Instead of having the whole world verify blocks, one could somehow use nodes in some proximity. One could call it local web of trust.
One worry is the bar thinks its getting paid because it's seeing false confirmations, when in reality it's giving away drinks for free because the transactions are never getting relayed to the rest of the network. Nope. A "confirmation" is a valid block with the transaction included, and a valid block includes a proof of work. The proof of work is far too valuable to waste trying to double spend in a bar. |
|
|
|
So if nobody can steal anything, what's the problem?
What do you mean? The MITM spoofing the node gets to run away with all of the BTC that the pub took that evening. How? It can't get the bar's private keys, and it can't change the bar's receiving addresses. So how is it supposed to get hold of those coins? The bar thinks the man with the suitcase in the corner is actually a node. The bar is relaying blocks to the rest of the network through this supposed node. The blocks either get edited or just not relayed to the rest of the network. The man with the suitcase pretends to the bar that the block has been confirmed correctly. The man with the suitcase walks out with BTC. You need to read more about how bitcoin works. First of all, the bar doesn't send blocks anywhere since it doesn't mine. It doesn't even send transactions, it just listens for incoming transactions and incoming blocks. Secondly, transactions are signed before they're broadcast to the network. Once they have been signed, they can't be tampered with. So your MITM can't edit any transactions. What he can do is be selective about which transactions he forwards where. If he were to collude with the customers, he could help facilitate double-spending attacks against the bar, but as mentioned previously any such attack could quickly be detected. |
|
|
|
So if nobody can steal anything, what's the problem?
What do you mean? The MITM spoofing the node gets to run away with all of the BTC that the pub took that evening. How? It can't get the bar's private keys, and it can't change the bar's receiving addresses. So how is it supposed to get hold of those coins? |
|
|
|
Problem: Walk into a bar, pay for a drink, BTC vanishes into thin air because the node was spoofed or you got MITMd.
What problem? Nobody can steal a customer's money that way. The bar won't give the customer an address that the bar doesn't control, and the customer won't sign a transaction to any other address than the one he receives from the bar. Are you worried that customers will double spend against the bar? If so, it'll quickly be discovered by the bar. That's not the worry. A man-in-the-middle attack (MITM) means that what the bar thinks is a valid node to the rest of the bitcoin network is actually the perpetrator. That's the scenario we're talking about here - validating the pathway between user <--> node. I want the validation to remain trustless and to not require any external validation e.g. "I say my node is valid and here's my driver's license to prove it." - validation should be like the rest of bitcoin: trustless and distributed, built upon a cryptographically signed 'proof-of-x' function. So if nobody can steal anything, what's the problem? |
|
|
|
Today, blocks are distributed fast enough. If we scale to 10k TPS, blocks will need to be about 2 GB, right? Then it will take non-trivial time to transmit blocks over slowish links. That would put miners/pools based in countries with shitty internet connections at a disadvantage.
Miners can ensure that their peers know in advance about the txs they're mining. Then only the first few bytes of the txids would be necessary to uniquely identify them, and this is all that would need to be broadcast in bursts when blocks are found. Broadcasting the first say 5 bytes of the txid, instead of the full ~350 byte transaction, means a 98.6% reduction in necessary bandwidth. So 2GB -> 29MB. Ah. This is good! |
|
|
|
Problem: Walk into a bar, pay for a drink, BTC vanishes into thin air because the node was spoofed or you got MITMd.
What problem? Nobody can steal a customer's money that way. The bar won't give the customer an address that the bar doesn't control, and the customer won't sign a transaction to any other address than the one he receives from the bar. Are you worried that customers will double spend against the bar? If so, it'll quickly be discovered by the bar. |
|
|
|
Maybe I asked something too difficult. Thanks.
Something too easy, rather. This isn't the right subforum for it, try asking in techincal support. |
|
|
|
because they created a value for (addressX_input - addressX_output). You can get the balance of specific addresses via client but the way its calculated for everyone is through the blockchain
Ok, but their must be a way to grab the balance by querying blockchain.info ? By the way thanks for your info, it's really appreciated ! Have you looked through the blockchain API? Yes, I think the solution may be: http://blockchain.info/address/$bitcoin_address?format=json Which will return this: { "hash160":"660d4ef3a743e3e696ad990364e555c271ad504b", "address":"1AJbsFZ64EpEfS5UAjAfcUG8pH8Jn3rn1F", "n_tx":17, "n_unredeemed":2, "total_received":1031350000, "total_sent":931250000, "final_balance":100100000, "txs":[--Array of Transactions--] } And then, I isolate the "final_balance" value Not too sure how to implement it on a website tho, but I think it might be the way to go... JSON is javascript. If you know javascript, all you have to do is read the API documentation from blockchain.info and write the code. If you don't know javascript you must learn it :) |
|
|
|
Electrum. Or a paper wallet for long term storage.
just got electrum, but could You explain why is it safer? It uses other networks, which might be compromised, can they? It can be stored offline. So, It is secure, Oh and it doesn't download the blockchain. Not downloading the blockchain is like the biggest feature, +it doesn't have to be online. there are tricks for speeding up the blockchain syncing using bittorent and a dump of the blockchain: look up blockchain bootstrapping. Lots of tutorials available. Still, some people are not happy to have 16GB+ data on their HD. And for some people, downloading 16 GB takes loving ages. |
|
|
|
|
Today, blocks are distributed fast enough. If we scale to 10k TPS, blocks will need to be about 2 GB, right? Then it will take non-trivial time to transmit blocks over slowish links. That would put miners/pools based in countries with shitty internet connections at a disadvantage.
One solution is for the pool to have a "proxy" server with good connectivity in Europe or USA. Forcing pools to have a presence in certain regions other than where their miners stinks of centralization, so I think a better solution is needed.
My idea is to broadcast a the block header when a block is found, and broadcast the full block immediately afterwards. When a pool receives the header of a recent block that builds on the current block and meets the difficulty target, it can start speculatively hashing on top of that header without needing the whole block. The speculative hashing should be done with a special block containing only the block reward payout, to avoid including transactions with spent outputs.
If it finds a valid nonce before it receives the whole block, it must withhold it until it has the whole block and can verify the transactions in it.
If it does not find a valid nonce before receiving the whole block, it can discard the speculative block and resume normal mining with transactions included.
If it does not receive the whole block before a reasonable amount of time has passed (unlikely but not impossible) it should discard the header and resume normal mining.
I think the risk of receiving a header for an invalid block will be small enough that miners can safely mine speculatively. Since the header contains the proof of work, trolling miners by publishing a header for an invalid block or by withholding the block will be very expensive.
I don't know if this is a new idea or not, and I realize it's not a perfect solution. But I think it's better than nothing and it's one more optimization that can improve scalability. Please let me know what you think.
|
|
|
|
|
Det her høres ut som et prima eksempel på bukken og havresekken. Skatteetaten velger å tolke regelverket til sin fordel, og hvis vi ikke gjør som de sier får vi straffeskatt.
|
|
|
|
Perhaps China don't consider Bitcoin a virtual currency. |
|
|
|
|
So how much do I have to write before I get posting access to other sections?
I'm writing this post only for that purpose, really.
I'm not a newbie, I've just never felt the need to post anything here before. I've been active on irc for a long time. Oh and in case you're wondering - I'm not a spambot.
|
|
|
|
|
