EDIT: changed title 0100000001d1b311d665b94ad270007deeaa696d487ea0bcd2d11e2c9a5407e7d25097f0ed000000006c493046022100a940f6147a70b98fa7f5bd0e76156ca71347207fca0336c93ce1b5165d653011022100ef0cc31be261178074e1cd854d4ea47e2b62d7ac5add4f1ae50474d841b60ce60121028f2bb71ec2c796cab46d5b61c28ad6cde73dacacf60f18943788053d6040eacdffffffff01009f240000000000dc4cc0010000000127478b07dae63322d1999419115cf287c69ff0f11de3f96d46df6926de61143c010000006b483045022100cca50bfed991240a7603eea19340f6e24102b29db2dfcc56fdfe549dacddcc6402207eefe2688670d349615ed184d1f84ac54365afd258524e55266c992ce2d68b7f012102ff9d6e0c33fb3cfc677857d2cd654db91fe051811433654d25442ee0182dac52000000000180969800000000001976a914751e76e8199196d454941c45d1b3a323f1433bd688accc5003007576a914fb99bed1a4ea8d1d01d879581fce07b27ab5357f88ac00000000
{
"txid" : "2bf4ff04b40d03ff71570877d8267aed91d3595d172737d096241d08277135e2",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "edf09750d2e707549a2c1ed1d2bca07e486d69aaee7d0070d24ab965d611b3d1",
"vout" : 0,
"scriptSig" : {
"asm" : "3046022100a940f6147a70b98fa7f5bd0e76156ca71347207fca0336c93ce1b5165d653011022100ef0cc31be261178074e1cd854d4ea47e2b62d7ac5add4f1ae50474d841b60ce601 028f2bb71ec2c796cab46d5b61c28ad6cde73dacacf60f18943788053d6040eacd",
"hex" : "493046022100a940f6147a70b98fa7f5bd0e76156ca71347207fca0336c93ce1b5165d653011022100ef0cc31be261178074e1cd854d4ea47e2b62d7ac5add4f1ae50474d841b60ce60121028f2bb71ec2c796cab46d5b61c28ad6cde73dacacf60f18943788053d6040eacd"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 0.02400000,
"n" : 0,
"scriptPubKey" : {
"asm" : "010000000127478b07dae63322d1999419115cf287c69ff0f11de3f96d46df6926de61143c010000006b483045022100cca50bfed991240a7603eea19340f6e24102b29db2dfcc56fdfe549dacddcc6402207eefe2688670d349615ed184d1f84ac54365afd258524e55266c992ce2d68b7f012102ff9d6e0c33fb3cfc677857d2cd654db91fe051811433654d25442ee0182dac52000000000180969800000000001976a914751e76e8199196d454941c45d1b3a323f1433bd688accc500300 OP_DROP OP_DUP OP_HASH160 fb99bed1a4ea8d1d01d879581fce07b27ab5357f OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "4cc0010000000127478b07dae63322d1999419115cf287c69ff0f11de3f96d46df6926de61143c010000006b483045022100cca50bfed991240a7603eea19340f6e24102b29db2dfcc56fdfe549dacddcc6402207eefe2688670d349615ed184d1f84ac54365afd258524e55266c992ce2d68b7f012102ff9d6e0c33fb3cfc677857d2cd654db91fe051811433654d25442ee0182dac52000000000180969800000000001976a914751e76e8199196d454941c45d1b3a323f1433bd688accc5003007576a914fb99bed1a4ea8d1d01d879581fce07b27ab5357f88ac",
"type" : "nonstandard"
}
}
]
}
So what I've done in the above is created a transaction that embeds a different transaction within it using OP_DROP. The inner transaction is as follows: {
"txid" : "8608a914d3e217ebfaa5cf04974a657d5b80b940fd46b9efee823feed43102ef",
"version" : 1,
"locktime" : 217292,
"vin" : [
{
"txid" : "3c1461de2669df466df9e31df1f09fc687f25c11199499d12233e6da078b4727",
"vout" : 1,
"scriptSig" : {
"asm" : "3045022100cca50bfed991240a7603eea19340f6e24102b29db2dfcc56fdfe549dacddcc6402207eefe2688670d349615ed184d1f84ac54365afd258524e55266c992ce2d68b7f01 02ff9d6e0c33fb3cfc677857d2cd654db91fe051811433654d25442ee0182dac52",
"hex" : "483045022100cca50bfed991240a7603eea19340f6e24102b29db2dfcc56fdfe549dacddcc6402207eefe2688670d349615ed184d1f84ac54365afd258524e55266c992ce2d68b7f012102ff9d6e0c33fb3cfc677857d2cd654db91fe051811433654d25442ee0182dac52"
},
"sequence" : 0
}
],
"vout" : [
{
"value" : 0.10000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 751e76e8199196d454941c45d1b3a323f1433bd6 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914751e76e8199196d454941c45d1b3a323f1433bd688ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH"
]
}
}
]
}
The inner transaction is fully signed and valid, sending 0.1BTC to 1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH(1) and spending a hefty 0.4BTC in fees. However since nLockTime is set to be a bit over 2000 blocks in the future it'll be some time before anyone can spend it. On the other hand since the first transaction is public, and will be embedded into the blockchain once someone mines it, provided the second transaction is mined after the first the existence of both transactions proves I threw away 0.4BTC in fees to the miners as once the transaction is made public the sender has no control what-so-ever over who mines it. Basically this is a more sophisticated mechanism to achieve the "trusted identities through value destruction" I proposed earlier ( https://bitcointalk.org/index.php?topic=91487.msg1007449), with the advantages that this implementation requires just two transactions and as long as nLockTime is set reasonably far into the future the value destruction will always be valid. The maximum value you can destroy in this manner, assuming the mechanism is known and there are miners watching the blockchain for these special transactions, is then a function of the number of blocks between the two special transactions. Basically a miner could work on getting mining successive blocks, then publishing the whole chain, however that becomes exponentially more difficult and expensive in terms of opportunity cost. 10 or 100 blocks should be plenty. Of course the expected value lost is proportional to the mining power you control, but mining power is pretty well distributed. An actual implementation can do better than just a simple OP_DROP. For one thing the message should go in the scriptSig to aid pruning. Secondly the inner transaction doesn't need to be provided in full; much of it can be snipped out if a template it used. Even the whole scriptPubKey can be left out if the output always goes to a known address. The minimum required length is just the ~80 byte signature and the 32byte tx id for the input, and at that point you can probably stuff the whole thing into one of the "isStandard OP_DROP" type proposals or similar. Either way, what's important is to agree on a standard so the value destruction is valid. EDIT: Just to make things clear, double-spending the inner tx isn't a problem. Remember that the whole point of this is to prove after the fact that you threw away bitcoins. If you double-spend the inner tx, you have no proof. EDIT2: Miners don't have a disincentive to mine the outer. After all, the inner can be published separately and put into the mempool whether or not the outer tx exists. The decision to mine the outer is orthogonal and subject to the same logic as any other transaction. 1) ...which is really throwing away another 0.1BTC... |
|
|
|
|
Also it's interesting how the difficulty of the hash satoshi found for the first block was significantly more than difficulty 1. Possibly the genesis block wasn't actually created on the date satoshi put as the timestamp, rather he picked a good headline for the coinbase and then ran his mining code for a few days to come up with a particularly difficult proof-of-work. Note how this does let you work out a rough idea of how much computer power satoshi had access to because the times headline and mailing list posts give an upper bound on the time it took.
|
|
|
|
Can a transaction be included into the same block that some of it's input transactions are included? Doesn't the protocol require that an txin dependency reference back to a prior block?
As far as I'm aware, it only requires a reference back to a prior transaction. It should still be able to reference that transaction if it is in the same block. If I'm mistaken, hopefully someone with more knowledge of the matter will respond here. Yes, a transaction can have an input in the same block. The reference client requires that the input come before the output, whether in a previous block, or in the same block. Philosophically, I prefer to think of all of the transactions in a block as being simultaneous, but officially, they happen in the order they appear in the block. The official view has a few advantages, such as avoiding loops. No, the official view is how transactions are actually processed in the code. When a bitcoin node receives a block it doesn't know about it tries going through the transaction list from beginning to end, processing each transaction as it goes. Thus if you are at transaction #4, the block transaction processor simply does not know that the output of transaction #6 exists at all and will reject the whole block if #4 tries to spend the output of #6 In addition remember that an input to a transaction is specified by giving a cryptographic hash of a previous transaction and the hash of a transaction includes the part where the inputs to the transaction are specified. Cryptographic hashes are one way, so if you have the output of a hash function there is no way to find a sequence of bytes for the input that gives that output. Since you can't do that creating a transaction loop just isn't possible. This property actually lead to an interesting bug. So, ask your self, where did the first input come from? Well, that's the special coinbase transaction, where coins are created in the first place, and the part of the transaction where the input would normally be specified is just a set of bytes that are ignored. Now normally part of the mining process puts some totally random bytes into that input, but it is possible, albeit very hard, for two transactions to have the same coinbase. Thus it's possible for two valid transactions to have the same hash, and what the Bitcoin software does in that case is simply overwrites the entry in the transaction database for the first transaction with the second. However a fix is being deployed where a coinbase input is now required to always have the block number as the first few bytes, so this won't be possible even in theory for that much longer. Satoshi should have done this in the first place, but contrary to popular belief he wasn't omniscient.  |
|
|
|
If you give up, at least post a scan of the bill here on the forums. Maybe someone can figure out how to decode it.
I would recommend against this, if he does this then he will certainly lose his funds. As I said if you give up. |
|
|
|
|
It's nice to have decentralized node and wallet software that people use and keep the network going, but there are hard limits on how big blocks can get and those hard limits are such that even the non-ultraprune client will work fine on relatively modest hardware. I've still got a full node running 0.7.2 (pre-ultraprune) just fine on a Amazon EC2 Micro instance with just 600MiB of ram. Right now it's using just 230MiB of ram and the load average is 0.05, trivial.
Since satoshidice was introduced blockchain growth has been a very consistent and linear rate of 4GiB/year, or a bit more than 10x less than the hard maximum of 55GiB/year. I suspect what we're seeing is fees are crowding out the worthless transactions. In any case, running a full-node will be easy even without pruning for at least a few more years now, and with ultraprune and the leveldb enhancements planned to go into 0.8 syncing the first time is now limited by bandwith, not CPU, so with a decent connection it just takes a few hours.
Yes, with a heck of a lot of resources you might be able to pull off a DoS attack on the current thousands of full-nodes simultaneously. But the second you do that you'll find people switching to tor and other ways of getting the block chain data out, and for that matter, find out how many nodes you don't know about are already running on tor. Mining pools already have lots of experience dealing with DoS attacks, and those attacks haven't done any damage to Bitcoin as a whole. It's really, really hard to attack a flood-fill network that just needs few dozen KiB/s to operate.
On the other hand if we don't solve the secure payment problem we will see a lot of malware targetting bitcoin payments, and those hackers will cause much more damage to the average guy just trying to send a payment than having slightly less decentralization ever will. Similarly the fact that P2SH and Gavin's dream of robust multi-device-authorization wallets isn't ever implemented anywhere will again cause far more problems.
When you get down to it news reports saying "hackers try to DoS attack Bitcoin network, Bitcoin running a bit slow, counter-measures are being deployed, no coins lost" are far less damaging to credibility than "thousands lose their Bitcoins due to new sophisticated malware attack"
|
|
|
|
|
If you give up, at least post a scan of the bill here on the forums. Maybe someone can figure out how to decode it.
|
|
|
|
FWIW I wrote some Python code that recreates the raw hex block header, the part that is hashed to create a block hash, from the output of the RPC interface getblock: import struct
import hashlib
bitcoin_header_format = struct.Struct("<i 32s 32s I 4s I")
def serialize_block_header(block):
"""Serialize a block header from the RPC interface"""
return bitcoin_header_format.pack(
block['version'],
unhexlify(block['previousblockhash'])[::-1],
unhexlify(block['merkleroot'])[::-1],
block['time'],
unhexlify(block['bits'])[::-1],
block['nonce'])
def calculate_block_hash(raw_block_header):
hexlify(hashlib.sha256(hashlib.sha256(raw_block_header).digest()).digest()[::-1])
Note the [::-1] to the byte order to change the endianness in a few places. |
|
|
|
I still think that we will switch up to 128 bit values to match future CPU-widths long before it makes any economic sense to do so.
It's very probable that future CPU's will never directly support integers greater than 64-bits. The width of a native integer is set by the width of a pointer, a memory address. 2^64 bytes of memory is simply an enormous number.(1) Now bus widths have even already been made larger than 64bits wide, but that's just how much data the CPU can move in one clock cycle, it has nothing to do with what numbers are actually supported. Having said that for what Bitcoin does just using existing "BigNum" libraries is perfectly adequate, and Bitcoin already has one internally for a variety of purposes. 1) Modulo some pretty remarkable advances in computing of course... 2^64 atoms of carbon works out to be 0.3grams, so if we one day build computers that truely are built on a 3d atomic scale it's conceivable. (current computers are essentially 2d due to how silicon chips are built layer by layer) Building such a computer has a lot of problems though, for one, with something that dense, how do you get the heat out? |
|
|
|
Of course, I haven't actually tried it for this. But I've absolutely done correlations of pure noise signals for range-finding and gotten usable results. Not every fix would be successful.
Yeah, I could easily be mistaken. My understanding was that all the high frequency noise that you system can't sample corrupts the low frequency noise you are trying to accurately sample, basically because filters are not perfect, but that understanding is second hand at best. Picking up pulsars requires costly enough equipment... enough that it would sort of moot the decentralization of it. (Well if equipment to observe the sun isn't too exclusive)
Yup... the amateurs find even off-the-shelf 2m dishes difficult to use to detect even known pulsars with lots of post-processing. Sun observation equipment could probably be done with something more like a sat-tv dish, which means the electronics are the hard part. Yup, the other problem is that few parties can observe more than one grid, so it would be hard to extend it world wide. There is still the idea of securely timestamping the GPS signal though, which may still have value. Good point re: GPS. People have even built GPS receivers from discrete parts and off-the-shelf uCs: http://lea.hamradio.si/~s53mv/navsats/analog.htmlYou're not limited to phase differences of 1/24KHz, assuming the anti-aliasing filters are correct— your phase resolution is only limited by the noise floor (quite excellent on modern sound cards) and jitter (not excellent, as you note).
Doh, yeah you're quite right. (what can I say, I've never actually done any of this) Of course, an interesting question is what is the effective noise floor of the grid, or more precisely, what is the noise you'll measure local to you and not the other people capturing the signal. (Of course, to get better phase resolution than just a fixed basis transform like the FFT will give you you'll need a fast non-linear solver for sinusoid parameters— but no worries, I've got you covered there: [er. link to be provided once the server comes back up]).
Server doing better? |
|
|
|
Meh. 2^56 operations would still be roughly the equivelent of difficulty 16 million. The idea that is "quite practical" is kinda a weak argument. You are talking building a network say 10% of the size of the bitcoin network would allow you to steal a couple dozen addresses per day. Of course that assumes that security can be reduced to 2^56 operations. I pointed out that even SHA-1 which has been known compromised since 2005 still requires > 2^61 operations.
Stealing a couple dozen addresses a day can give you serious amounts of money. There are addresses that have historically had amounts in the low millions assigned to them, and I'm sure the unspent-tx-out set has plenty of addresses with at least tens of thousands attached to them. Will coins be stolen. Sure in time but it won't be these "insta-hack" nonsense you espouse. The period of time between improved attacks is usually measured in years. So when security is reduced to 2^56 you will see the largest dormant addresses "remined" and then it really won't be worth it. Maybe in 4-5 years someone will improve the attack further and the medium sized addresses will be compromised. While this brings coins into the network it will hardly be this "instantly every RIPEMD-160 address is owned by a single person in the span of a few seconds.
It will take time and honestly won't be much different than mining now. There will be risk involved. Do I bought a $10K RIPEMD-160 cracker out of FPGAs? What if others get the best addresses first? What if BFL releases a RIPEMD-160 ASIC before I pay off my "rig". I would also point out that it would be decentralized. It would be the FIAT command from on high deeming RIPEMD-160 addresses unfit for use and therefore nulled. I would never, ever, ever support it. I would spend the last of my coins fighting it and if it still did happen I would have no reason to use Bitcoin. Bitcoin where wealth can be confiscated at will because the elites deem it necessary? I will go back to Gold. Many Goldbugs BTW fear this very idea that Bitcoin isn't truly Tangible. If it can be confiscated by decree then they are right.
That's all well and good, but when the difference to that stealing happening over a matter of years, or a matter of days or weeks is one paper, it'll cause the value of Bitcoin to tank all the same. Mining as we know it is carefully controlled and highly predicable, "mining" by attacks on cryptography isn't. Also, if a RIPEMD160 attack does happen, we have just two backup options: move to SHA256 for address hashes, or move to pure public keys, both of which are backwards compatible changes. If an ECDSA break happens we have no choice but to move to a new PK algorithm. Doing that is a hard-fork change if you want to be able to spend your coins, and thus this discussion will come up. Given how many people consider protection against inflation as one of the core principles of Bitcoin protection against the risk of inflation by releasing old lost coins will be discussed. You're hung up on the idea of it being confiscated by "decree", but plenty more are just going to worry about their wealth being confiscated however it happens. Of course all this depends on how many coins are lost; maybe it won't be an issue. Note that one way this all could be handled is to have the new rules in this hard-fork scenario only allow old coins to be spent on a schedule, with limits on the volume of such spending. You could say that after block n only transactions from weak to strong are allowed, and only xBTC of those transactions per block. (with the obvious tx fee competition happening) Or the rules could state that making the coins undependable only happens if a certain percentage of coins in circulation remain under weak keys beyond some date, thus limiting the possible inflation. We may find in such a scenario that that percentage is low enough that people aren't worried about the inflationary wealth confiscation. Of course coming to consensus in any case will be hard. Even just moving to a new PK algorithm will be bad enough. I really, really, really want to see the look on those Goldbugs faces when someone mines the first meteorite, or someone makes a breakthrough in gold nucleosynthesis... In the latter I suspect they'll start arguing that gold isn't gold unless it's totally free of trace radioactive contamination. |
|
|
|
Please provide a single example. It took roughly 15 years for MD5 to go from theoretical attack to "fully broken" and even today it requires a huge amount of computing power to cause a MD5 collision. At each improvement of the attack it still required a huge amount of computing power but the speed improvement over brute force grew by magnitudes. Almost like mining but in reverse ("difficulty" declined over time). Note this doesn't mean MD5 should be used, there simply are better safer algorithms but the idea that it went from academic to "instahack" with negligible computing power is simply innacurate.
Please name a single mainstream cryptographic algorithm (not some security through obscurity or proprietary solution created by an novice) which was broken wide open in a single step.
Name a single example of a broken public-key algorithm previously in wide use in the first place. Frankly we just don't know because we've yet to see a public-key algorithm broken in recent history. FWIW MD5 collisions can be generated in 2^20 time right now, trivial. More importantly though look at Bitcoin difficulty, which is of course a partial pre-image: the security of the network is just a matter of a few "bits" of difficulty, yet even just a single paper in crptography is likely to remove at least a bit or two of security from an algorithm. It's easy to see why an algorithm can go from secure to insecure overnight if that last step happens at the wrong place, while at the same time having warning is likely. Lets suppose for instance RIPEMD160 pre-image collisions went from 2^160 difficulty to 2^120: it'd be worrying, but still Bitcoin would be ok. Now another paper or six are published, and you're down to 2^70: rather worrying, but Bitcoin is still ok for now, if just barely. (the whole Bitcoin network has done about 2^66 SHA256's in total remember) One more paper though, another 10 bits, and suddenly stealing funds sent to address hashes is quite practical with just a few ten thousand in equipment, and each additional bit of security lost halves that difficulty. There's a reason the difficulty target is a number, rather than just a number of bits. |
|
|
|
What would be elite about this group. If ECDSA is broken wide open without warning Bitcoin is effectively dead anyways. Massive amounts of wealth would be transfered before any such new address type could be created. The probability of that happening is roughly zero. What is more likely is that ECDSA is "compromised" meaning that one can attack it faster than brute force (although still needing massive, massive amounts of computing power). One would essentially see "mining" of existing addresses a process which probably would take on the order of decades to "confiscate" all of it.
That is far preferable than some group of "elites" forcing their will on the people. I have enough government already. I don't need another one to worry about INSIDE my currency.
You're right that ECDSA will not be broken overnight; theoretical weaknesses will be found first, and those weaknesses will turn into something more concrete in the span of a few years. But your idea that the weakness will just be an issue of "attacking faster than brute force" is dead wrong: the margins between insecure and secure are enormous, yet this actually means that successful breaks tend to go from "theoretically broken" to "totally broken" in one step. This is nothing like mining as we know it, because the rate at which that happens is totally uncontrolled. In addition, without a plausible plan to deal with a problem like that we will see the value of Bitcoin collapse as the ECDSA weaknesses get closer and closer to an actual break. Like it or not in such a scenario killing off probably-lost coins is reasonable and the user-base has a real chance of agreeing to it. Or to be precise, the user-base will decide to adopt an alt-coin to replace Bitcoin that has those rules and and decide that the alt-coin has value and Bitcoin does not. This has happened before: the value overflow bug was "fixed" by everyone deciding to adopt a new alt-coin overnight, that happened to be almost identical to Bitcoin but without that broken rule. That alt-coin was so popular, and reasonable, we call it Bitcoin. |
|
|
|
I think we need to consider agreeing that some time after the signature algorithm shows weaknesses, we will delete all old coins to which the keys were lost. It's either that or have them all suddenly move to one party.
I don't think we need to agree to that at all. Who makes "you" (to mean not just you but anyone who feels they have the authority to control the wealth of others) to decide when wealth should be confiscated in order to protect others. You are the bitcoin "elite" you need to protect others by confiscating their wealth? You are talking about the role of a state. The elite protecting the masses by confiscating wealth through force. Bitcoin is dead if/when the "self proclaimed elites" out of fear decide they need to protect it by confiscating wealth.That's all well and good, but if ECDSA is ever broken there will very much be an elite group confiscating wealth whether you like it or not. The question is how much wealth do we allow to be confiscated? Some of it, or all of it? |
|
|
|
I would like to mention in this context something which does not get the attention it deserves.
It is plausible that the currently used version of ECDSA will be broken eventually. When weaknesses start to be found people will start moving their coins to more secure addresses. But the lost coins will remain where they are, and when it is finally broken, whoever does it will find himself with a huge treasure of coins. This isn't stable and is not how Bitcoin is supposed to work.
I think we need to consider agreeing that some time after the signature algorithm shows weaknesses, we will delete all old coins to which the keys were lost. It's either that or have them all suddenly move to one party.
For the record, I think discussion of that kind of thing is appropriate on the main development board. While technically it's a different cryptocurrency it's plausible that necessity would demand such a move and it's also plausible that the user-base would consider the economic principles as not changed enough to matter. After all, the assumption is the coins are lost, therefor ensuring they stay lost doesn't change anything for the majority of coins. Equally such a scenario is likely to have at least a few years of advanced warning as mathematics advances. |
|
|
|
|
Rational: Any attempt to "recover" lost bitcoins that involves rules like coin expiration and similar mechanisms changes the economic basis and thus results in an alternate cryptocurrency. Also, the threads are really repetitive and annoying.
|
|
|
|
|
The "intro to bitcoin" talk is one I've given once before; it's really a layman's guide to how Bitcoin actually works behind the scenes. Some of what the talk covers includes what actually happens when you "send" a Bitcoin, and why "send" is in quotes, what mining is actually for, and why even though "coins" are just digital data, they can't be copied and spent twice. You don't need to understand programming, let alone cryptography, although of course if the audience is interested I can go into those details as well. Equally depending on what the audience is interested in, and what the other presenters do, I can talk about the more prosaic details of how you actually buy and spend Bitcoins.
|
|
|
|
You need to think a bit harder about what exactly you are proposing and exactly how it would work... Here's a thought exercise for you: what's to stop someone from making their own recording of some grid fluctuations, archiving it, and replacing the grid hum in one sound recording with a different one from that archive?
"You need to .... " I stopped reading after that. Well, there's one more person for the ignore list... If you don't want to read what people think of your ideas then please don't post them. Sadly your idea does not eliminate the need to have a proof of work. You still need an attack resistant mechanism to assign significance to time even if you have a universal time source, moreover, having a common timebase doesn't make transactions actually arrive at a common time... and finally the grid is not a secure reference as its frequency is in-fact frequently changed in response to load (though if you have an attack resistance significance attaching mechanism that point doesn't matter). As a tangent, you may find interesting my little paper on how to use a POW chain consensus to turn any common reference signal/oscillator into a highly trustworthy clock: https://people.xiph.org/~greg/decentralized-time.txtNice paper, although the idea of using the sun as your sample source is really flawed unfortunately. The problem is the noise the sun emits is basically just thermal noise, so while you can try to make a good measurement of it to do cross-correlation you'll find out that your phase information is screwed up because there is no way to distinguish what is the sun and what isn't. You'd have better luck using an optical telescope, but then you'd run into the problem that there aren't any features on the sun that change sufficiently fast. What does work along these lines for time synchronization is to use radio telescopes to lock onto specific pulsars. Using multiple pulsars at once could give you enough information to resolve increasingly larger time intervals by comparing pulsars of different intervals and phase relationships. The requirement for a radio telescope though is a bit annoying... However... the electrical grid on the other hand would work just fine as it's a specific signal with fairly large variations distributed over a wide area. But as you say, you need the POW chain consensus to assign significance. Still I figure a cheap wall-wart with AC output - rather than the usual DC - and a resistor divider could be connected directly to a soundcard line-in port with no issues. With a standard 48KHz sound card you'll be able to resolve phase differences down to 1/24KHz, or 41uS, with some effort. In reality jitter in your sound card -> computer chain would be the limiting factor. Even professional sound cards have hundreds of uS worth of jitter. That said if what you want to measure accurately is external to the computer, you can just build some hardware that puts a pulse associated with your measurement on another channel of the same sound card and you can ignore the computer's timing jitter again, at least for relative measurements. FWIW I'm thinking of setting up a series of those monitoring stations with the data uploaded to a public server. It'd let people use that forensic technique themselves. Of course, that goes both ways... |
|
|
|
|
Yes, I saw that project, I'm curious to try it out myself, although I'll have to upgrade my computer first.
It's interesting that you found this bug by looking at the code. I mean, the results of it have been sitting in plain sight for, well, anyone to see. Heck, I'm kicking myself for not realizing it, let alone how Gavin and the other devs must feel. It's remarkable that Meni was the first person to notice and bring it to the attention of the forum after all this time, and even then it took your post for what he actually said to sink in.
Re: donations, I sent both you and the OP a BTC after applying your patch. Fortunately for Meni it took two tries for it to be obvious that the patch worked...
|
|
|
|
|
You need to think a bit harder about what exactly you are proposing and exactly how it would work... Here's a thought exercise for you: what's to stop someone from making their own recording of some grid fluctuations, archiving it, and replacing the grid hum in one sound recording with a different one from that archive?
|
|
|
|
From Hal's sig: Hal 157i5gK7iN4bNAN39Ahuoiq6Tx5TaQukTE So Hal, which one is your current Bitcoin address? Also, it's funny how every tx to 1HALook is obviously affected by this bug. |
|
|
|
|
Show Posts
