Bitcoin Forum
June 11, 2024, 02:36:37 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 [64] 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 »
1261  Economy / Speculation / Re: Estimated inflection point ( from the last bubble ) on: January 03, 2014, 12:54:33 AM
I'm seeing up indicators, especially on Gox. 

With Mt.Gox showing $860 right now, I expect the Bitstamp prices to ramp up as arbitragers even things out.

The sharp rise at Gox also indicates to me some fairly substantial uptake of Bitcoin in Japan -- shortly after geographically close China took its money transmitter businesses out of Bitcoin.  So I'm saying, 'hmmmmmm' and speculating that possibly some unknown channel is now satisfying Chinese demand for Bitcoins via Japan.

It's just speculation where the demand is coming from, but if it is Chinese demand, it's surprising; I'd have expected the limits on trading BTC in China to make it less desirable to Chinese. 

Then again, if you think Americans are distrusting and cynical of their government you haven't talked to very many Chinese people.  The demand for Bitcoin could be a 'vote of no confidence' in the Yuan and the Chinese government's ability to manage their economy. Of course that's even more speculation to justify the first bit of speculation, so I'm either really insightful or really off in the weeds.

1262  Alternate cryptocurrencies / Altcoin Discussion / Re: We have Subforums! on: January 03, 2014, 12:29:20 AM
And now the main challenge will be getting people to USE the subforums. 

The front page here is still 90% announcements.  There's supposed to be a channel for that now.
1263  Other / Politics & Society / Re: Will China go to war with Japan? on: January 02, 2014, 11:44:57 PM

Yes, since its barrel is almost 4 inches longer. A sniper rifle would still be better...

'Struth, but sniper rifles don't get issued to just anybody, and we were using the 5.56mm rounds with the M16s so the 7.62mm rounds for the sniper rifles would have been a supply issue. 

AK's were locally abundant, and the quartermaster could get ammo easily from the black market, which meant he didn't have to go through top brass and we could often have ammo in hand faster than if he had.  That had its down side too; some of the guys used AK's, which were sort of 'invisible' to paperwork for us, for ops that top brass definitely would not have approved.
1264  Other / Politics & Society / Re: Will China go to war with Japan? on: January 02, 2014, 11:29:01 PM
Even US special forces used captured AK-47's in Vietnam, lol

That was mostly about how distinctive the sounds of the weapons are.  US soldiers with M16 Rifles were easily identifiable in a firefight, but AKs sounded like the locals.  Because the US had better Infrared/Nightvision/C3I, we were confident of being able to tell friend from foe regardless of the sound, but hoped the Viet Cong wouldn't be able to tell who was whom in the dark. 

During daylight engagements, everybody wanted the M16s because they were a hell of a lot more accurate and more effective at longer ranges.
1265  Other / Off-topic / Re: Let's Count to 21 Million with Images on: January 02, 2014, 04:58:41 PM
1266  Bitcoin / Development & Technical Discussion / Re: Understanding Transaction #14 on block #141460 on: January 02, 2014, 12:25:28 AM


I like your code.  It's very clear, minimal dependencies, and conforming to language standards. 

It's usable for my purposes as is because I can write my own main function easily treating it as a library, but I think most people will actually want you to provide a "main" function that gets command line arguments and can be commanded to do a particular set of things. 

What I wanted to do is simple; list all the public keys in the blockchain.  Which makes my 'main' function about a six-liner I think. 
1267  Other / Off-topic / Re: Let's Count to 21 Million with Images on: January 01, 2014, 06:07:17 PM
1268  Bitcoin / Development & Technical Discussion / Re: Should nodes receive part of the transaction fee? on: January 01, 2014, 06:00:44 PM
I would truly like for there to be a way to do this, but Sibyl attacks are tricky to design around.  If you reward the last few nodes before the miner, then the miner has an incentive to put up a bunch of fake clients to "relay" it the last few steps before he gets it.  If you reward the first few nodes following the transaction origin then the transaction originator has an incentive to put up a bunch of fake clients to "relay" it the first few steps from them.

To minimize the Sibyl vulnerability you need to promote minimum-length propagation paths, so the "time to live" or "hop limit" *is* a relevant response.  With a "time to live" limited by the network the transaction originator doesn't reach as many potential miners if they consume the first bounce with a Sibyl node, so they have a disincentive to do that. 

But if a miner gets a tx with a "hop limit" of four, on the first or second bounce, there is an incentive for the miner to put up sibyl nodes to relay it the last two or three nodes to the miner.  And if a transaction originator knows she's directly connected to several of the leading centers of mining power (pool centers or ASIC farms that will probably make at least one of the next ten blocks), or even directly connected to blocks that are directly connected to centers of mining power, then she has an incentive to put up a few fake  nodes to "relay" it from her to the miners. 

So you need to create a disincentive for the miner to make sibyl nodes.  This could happen if the size of the transaction increases with each bounce (which a lot of these schemes will have happening anyway) and the miner is paid proportional to the *efficiency* (in tx per Mbyte) of his blocks.  With more incentive to keep the transactions short than incentive to add sibyl nodes, the miner wouldn't be putting up fake nodes in order to maximize profits. 

This also provides a disincentive for relay nodes to create Sibyl attacks.  If a relay node knows that the miner will only be putting tx with the shortest paths into the block, then they have a disincentive to lengthen the path, because if they do and the miner then gets the tx from elsewhere with a shorter path, the relay node that put up a sibyl loses. 

What it does not prevent is collusion attacks.  The miner will likely get a transaction hundreds of times before forming a block.  Of those, dozens may travel through a selected node that's directly connected to the miner. If such a relay node and a miner collude, then the miner can, in exchange for a kickback, prefer paths that run through that relay node - unfairly reducing the chance of reward for all non-colluding nodes.

And, finally, it creates a very complicated set of payments, which must be subject to more complicated feedback, which must in turn be fixed so there are disincentives to game the feedback mechanism.  To accomplish this in a way that's stable across diminishing block rewards, or even produces predictably sized aggregate block rewards, is nontrivial.   And it also adds the number of bounces to the signature checks that must be performed when checking transactions, and to the size of the blockchain, increasing the compute and bandwidth burden on all nodes.
1269  Bitcoin / Bitcoin Discussion / Re: what do we need to bring bitcoin to mainstream? on: January 01, 2014, 05:21:16 PM
As for volatility;  that may be a long-term problem.

Bitcoin, as a limited commodity, will never be less volatile than gold.   And gold goes up and down sometimes more than a hundred percent in a year. 

Bitcoin is lots more volatile than gold now, but into the future, I think the volatility will come down when it starts being valued for use rather than as a speculative instrument.  I just don't think it will ever be less volatile than gold.

In this area fiat currencies have a definite advantage; there are people watching the money supply and regulating it to minimize volatility.  Sometimes those people fail spectacularly, but more often they just inflate the currency a few percent a year.  Bitcoin has no such oversight.  In refusing the ability of central bankers to make spectacular failures or inflate the currency, we also refuse such help as they can give in minimizing volatility.   A cycle of boom and bust under a strictly limited currency supply characterized finance through much of the era of precious metals as currency.  Gold reserve notes, and fractional reserve banking, were among other things a way to try to get out of that cycle.  But with faith in that system trashed, we may be getting right back onto it with Bitcoin -- in a belief that the "natural" cycles of boom and bust will be shorter and less painful than those created by a failing central bank.
1270  Bitcoin / Bitcoin Discussion / Re: what do we need to bring bitcoin to mainstream? on: January 01, 2014, 05:07:50 PM
Ease of use should be as simple as having the cash register print a QR code, scanning it with your phone, and entering a PIN number (preferably on your phone rather than on the cash register PIN pad, but either works I guess).  I dunno if we can get there, but it would be worth talking to some of the people who provide software for cash registers.

Of course before they'll devote dev time to it they have to have customers who ask them for it too. 
1271  Bitcoin / Legal / E-sports settling with New Jersey over Bitcoin Botnet. on: December 31, 2013, 05:51:14 PM
http://www.bbc.co.uk/news/technology-25014477

Recently E-sports released a game that had a botnet for Bitcoin mining built in (they're blaming "an employee who acted for personal gain"). 

One of their customers noticed his graphics card remained in heavy use even when he wasn't using the computer.

An investigation later, the state of New Jersey filed suit against E-sports for the takeover of customer machines.

Now E-sports is settling the case with New Jersey but "stresses that they do not agree with nor admit to the allegations against them."

1272  Bitcoin / Bitcoin Discussion / Re: Accredited investors starting to get interested in BTC.. on: December 31, 2013, 04:42:11 PM
Wrong.

ASIC miners are not able to process more transactions.  They are only able to make more hashes.  There is a huge difference. 
1273  Bitcoin / Development & Technical Discussion / Re: Understanding Transaction #14 on block #141460 on: December 31, 2013, 04:39:39 PM
The two blocks with the same number should both have the hash for the same previous block, because they are both built on the same previous block.  It is the subsequent block that will disambiguate them.  The subsequent block will be built on (and therefore contain the hash of) only one of the instances of the previous block. 

I do not know why both of them are recorded in the blockchain you're looking at, though; the blocks in orphaned forks are supposed to be completely unnecessary for building a complete record of transactions. 

If the blocks in orphaned chains are in the record you're looking at, then you need to be able to turn off your transaction recording and track two (or even more) blockchains.  If both of them have a successor, you look for 'grandchildren,' and if both of them have a successor, you look for 'great-grandchildren' etc.  Sooner or later, one branch terminates in a block having no subsequent block, so you then know the other branch is the valid one.  From there you go back to the point of the fork, start recording tx again, and go forward ignoring the terminated branch.

1274  Bitcoin / Development & Technical Discussion / Re: Consistent Estimater of Transaction Times - Block Timestamp? on: December 31, 2013, 03:57:41 PM
Further, the blocks are not necessarily sequential in timestamps.  Two blocks formed a minute apart could have the reverse order of timestamps if the two miners' clocks disagreed by more than a minute. 

That said, I think you can rely on block timestamps to within an hour or so for any normal transaction.
1275  Bitcoin / Development & Technical Discussion / Re: Should nodes receive part of the transaction fee? on: December 31, 2013, 03:28:14 PM
I'm of the opinion that the answer should be yes.  But "should" does not affect the reality.  In Bitcoin, they do not.

Also, it isn't clear how to demonstrate the degree to which a client is being useful. 

If you pay them for propagating transactions, then people will make fake (or meaningless) transactions to propagate, and your altcoin melts under a Sibyl attack.  If you pay them for propagating blocks (which seems possible) then the block propagation has to be reported somehow.  Someone pretends he's a thousand nodes, all propagating every block to each other by every possible path, in order to maximize his reward, and then the claims on the award require more bandwidth than there is in the next block.  Lose again.

 
1276  Bitcoin / Bitcoin Discussion / Re: Accredited investors starting to get interested in BTC.. on: December 31, 2013, 03:17:12 PM
This is bad.  

I mean, it would be good news if the Bitcoin network could handle it, but as of yet it is still limited to 7 transactions per second.

Picture a Snoop Dogg album going on sale for Bitcoin.  Day one, a million people try to buy it.  Each of them necessarily makes at least one transaction.  Most of them make at least two transactions because they have to buy Bitcoins first.   Two million transactions is about three times what our blockchain can handle per 24 hours, and that's even if miners start making 1M blocks instead of 250K blocks.  Which they won't do, because it isn't profitable.  

Meanwhile the network itself is melting under the strain as at least half a million people attempt to download the blockchain. 

Picture mainstream investors attempting to use Bitcoin as a financial network.  Same thing, EVERY day.  The Bitcoin network melts under the pressure, and we are all left holding the bag.  

1277  Bitcoin / Bitcoin Discussion / Re: "Current proof of work algorithm will not survive the year" Dan Kaminsky, 2013 on: December 31, 2013, 03:09:50 PM
SHA-256 based proof of work is a means, not an ends.  We use it to achieve a desired result - that being a decentralized network.  For the time being it is working.  Since production of silicon chips is very centralized, and it is well within the reach of many governments to amass a majority of hashing power. 

This.  Absolutely this.  If the US, or China, wants to take over Bitcoin, freeze its value relative to dollars (or Yuan), and issue as many bitcoins as they want just the same way they issue their usual currency?  A call to butterfly labs or somebody who can reverse engineer one of their chips, a gag order to prevent them from talking about it (if they even know about it), another call to Intel or somebody with a huge chip foundry, cut one big check, and done.  Anybody whose client rejects blocks where more bitcoins are created than their client thinks is kosher then finds themselves on the losing side of a chain fork.  And the updated client is available from your friendly neighborhood government offices.



1278  Other / Politics & Society / Re: Edward Snowden on: December 31, 2013, 02:58:48 PM

Edward Snowden for a National Medal of Freedom.  Write your congresscreature.
1279  Other / Beginners & Help / Re: What will you do if bitcoin "wins"? on: December 31, 2013, 02:56:15 PM
I was thinking of flying kites more often.  Going fishing occasionally.  And spending more time with my wife.  If there's really serious money in this Bitcoin thing, I won't have to worry about paying for house repairs anymore.  And I could set up a nice shop in my garage.
1280  Bitcoin / Bitcoin Technical Support / Re: Block Chain's Time Stamp is Nonsequential?! on: December 31, 2013, 02:49:32 PM
The whole purpose of public NNTP servers is to NOT disagree about the time.  And because there are thousands of them, I rather disagree about them providing a source of centralization.

In the same sense that the purpose of the Bitcoin network is to secure transactions. 

Pages: « 1 ... 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 [64] 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!