I know this as a principle, and also hard-won wisdom from real systems.

But, it's easier than ever before for a system to get a 'true' time, drawing it from the rest of the world: network services, radio signals, sunrise/sunset times. Though small numbers of systems can be faulted or frauded out of sync, systems for which this is economically important (like large mining combines) can get it right.

So though ugly in theory and provability, the assumption that most miners can consult and be rewarded to use an out-of-band 'true' time may work in practice. Or, may work as one of many informal hacks that deter sluggishness-for-profit.


This is my intuition too. Since it is unpredictable when the miner's own next block, or a competitor's next block, will be found, there's no clear value other than 'now'  (or maybe 'now+average_lag') to improve your block's tiebreaking power.

The same heuristic may also work with other timelike measures. As with Bytecoin's proposal, a miner could record when (by local time) they see each transaction. (A miner might even issue their own 'tick' transactions at regular intervals.) When receiving two competing blocks, they could prefer the one whose transaction-mix suggests a mining-time closest to receiving-time.

How so? Also, assuming most nodes use a reliable out-of-band time source, who benefits from inaccuracy?

The 'true' time is a cooperative focal point that's hard to displace, barring such a large conspiracy that you're screwed anyway.


The point of anti-selfish-mining tactics is "anti-convergence", on chains preferred by the attackers. So suppressing "first blocks with a bad time" is a feature, not a bug.

Join the cooperating consensus, use the true time and broadcast any blocks you've mined (or chosen to build on) as fast as you can, or suffer.

For block-height ties, prefer the block whose locally-observed arrival time is closest to its internal timestamp.

Request: publish checksums of official builds to at least one, and preferably several, webpages authenticated by HTTPS.

A thread like this would count as one. The plain-HTTP sf.net files area does not.

The PGP-signed SHA256SUMS.asc is the right idea but requires extra steps to check.

That seems a rather large leap. Satoshi relied on statically fixing some things, and single-threading others (one block wins), to avoid confidence-sapping complexity. You're suggesting a mesh of nodes with only local knowledge can, by a (totally novel?) negotiation protocol, converge on some global minting schedule that all respect.

That might be possible, in theory or in practice - it's an interesting idea. But Bitcoin doesn't provide supporting evidence, unless I'm missing something. Some sort of game-theory analysis, or simulation, or evolved precedents in working systems, would be more convincing.

What would be most helpful in understanding Qubic would be if, like Bitcoin, the essential design decisions were documented in one reference doc. Also great would be some example narrative-transcripts/protocol-time-sequences of regular processes.

I predict that will be problematic, for at least two reasons:

(1) In a large distributed system with many transient failure modes, there can be non-malicious errors that inadvertently create double-spends. Destroying the associated value is quite a harsh penalty.

(2) When arbitrarily many followup transactions depend on a double-spent value, and then some time later the double-spend becomes evident (requiring cancellation): (a) unwinding all followup transactions is hard and disruptive; (b) future compromise of private keys would seem able to retroactively cancel true, honest transactions the holder thought had already completed before the compromise.


Very interesting. Is this based on any other consensus-finding system with any history or study behind it? Preference-aggregation/voting systems are hard.

Does this assume every provider generally knows about (and can judge the minting offers/actions of) every other?

My hunch is that the large uncertainty of supply, and potential for disagreements to leave providers confused or seeking network partitions, could prevent the necessary critical mass of stakeholders and community norms from emerging.

I can see that helping narrow the windows for problems, but it doesn't really answer what wins in disputes and how things resolve under network stress and malicious attacks.

Say the providers with transaction B are cut off for a few minutes around and after midnight, so they join the synchronization a little late. But they still have a 'valid' earlier timestamp. Did A get an advantage, becoming more likely to 'win', with its small head start?


Interesting, thank you, but I don't see an explanation how these peer-to-peer challenges result in a consensus determination of how many new qubics each provider receives. Is that in another thread/page?

OK, let's say a transaction 'A' arrives at one provider just before midnight, with a 1-minute-before-midnight timestamp. The synchronization process starts. Just after midnight, a conflicting transaction 'B' arrives at many providers, with a 2-minutes-before-midnight timestamp.

Is the more important factor B's earliest timestamp, the fact that only A was at any provider before the day's sync began, the relative computational power of the providers, or other arbitrary lags in the synchronization?

Also, how do providers demonstrate their relative computational power?

rEeAtyZkBb3Srw2EhiLAu3S6TFKRPPTcvD

Thank you for your quick answer!

How are the providers determined? Is it simple majority rule to resolve disputes?

If one transaction lands at one provider just before the midnight-synchronization starts, but then many other providers soon after midnight, if the one that landed before midnight a shoe-in to win, on timestamp alone?

If two providers have conflicting ledgers, which version wins?

I'm guessing this is what happened... though I would have expected, if the txn was rediscovered from a peer, for it to show up in gettransaction/getrawtransaction probes, especially after doing the long txindex rebuild... but it did not. (I received an `error: {"code":-5,"message":"Invalid or non-wallet transaction id"}` for gettransaction.)

If I have to try this again, I'll keep the node off the network before testing... but that raises the question: is there a good way to do that, using just bitcoind/bitcoin-qt options? (Total network 'unplug' isn't possible for this particular wallet which i can only reach via the network.) It looks like a maxconnections of 0 will be ignored. Maybe a single 'connect' option to a known-bad address, with no addnodes, will leave a client started but unconnected?


I didn't get around to trying a delete-all-txns. I'd pushed the unconfirmed transactions myself to blockchain.info -- so yes in fact they all appeared there. But after using pywallet to remove them locally, they would not return from my client via 'gettransaction', even though they were still effectively consuming earlier outputs.

I was able to craft a replacement double-spend transaction, via the bitcoind raw txns api, to compete with the 1st unconfirmed transaction. After issuing that, with a larger transaction fee, it was fairly quickly mined into a block, making the other 6+ txns orphans. My replacement transaction evacuated the affected wallet entirely... so I believe my problem is resolved, with all funds again spendable rather than stuck as unconfirmed change.

I'm guessing kjj's theory above, rediscovery of the key transaction from peers, was the main factor in the spendable outputs/balances remaining the same even after local transaction deletion.

Thanks for the rapid replies and suggestions!

Deleted the txns (several in a chain), allowed the rescan to complete. The client still shows the balance depleted, as if it still had the unconfirmed transactions. But, requesting the unconfirmed transaction by txid gives nothing.

I actually pushed the problem txns directly to blockchain.info, in the hopes that'd help them get mined... but over 16 hours later, no luck on any of the chain of 6+ txs (each dependent on the one before).

I've now also tried a full -reindex=1 -txindex=1 launch... still no luck. The needed prior output doesn't reappear in 'listunspent'... whatever pywallet did to delete the transaction didn't undo the record of that output being used... nor does -rescan, -reindex, etc.

I was hoping pywallet would leave things in a state where I could issue a fresh, higher-fee transaction as if the unconfirmed txns never existed... but now think I may have to do that with the raw txn api... and consider this wallet damaged by the pywallet txn-deletions.

Hi! I've tried to use pywallet (current jackjack-jj master) to delete some long unconfirmed transactions from my 0.8.1 wallet.dat, per the instructions at...

https://bitcointalk.org/index.php?topic=85689.msg944529#msg944529

After the deletions, the client no longer reports the transactions in 'listtransactions' or 'gettransaction'... so far so good. But, it doesn't seem to have rediscovered the still-unspent old outputs. A launch with '-rescan' didn't help.

Did I miss a step? Does something else about the 0.8.1 indexing need to be reset/rebuilt?

 

Do you think mining pools are holding the transaction for days -- and thus rejecting conflicts -- even though they're not willing to include it in blocks?

That would seem to be a waste, if there's zero chance of including it (as opposed to just waiting for block space, which because of many recent undersized blocks doesn't seem to be the issue).

I've issued some small-size transactions with ~0.00001 to 0.00003 txfees that haven't been confirmed after a few hours... the later ones depend on the earlier ones.

Other than waiting and hoping my client rebroadcasts to a willing miner...

(1) Will the pywallet forget-txid approach described by...

https://bitcointalk.org/index.php?topic=85689.msg944529#msg944529

...still work in the 0.8.1 refactoring? If yes, I'd locally-forget all the unconfirmed transactions, then reissue with higher tx fees (a double-spend-for-good).

(2) Is it worth adding another dependent transaction at the end, with an extra-large tx fee, in hope some miner does a value-of-all-together calc and pulls the earlier txns in with the last? (Any miners doing that, including dependent chains of txns 5+ long?)

Anything else to try? I'm flailing here!

Understood, thanks!

I more commonly see that "-beta" version-number suffix used as meaning, "this is a beta version of 0.8.1, the real 0.8.1 is coming later".  And, if "-beta" is considered part of the canonical version identifier, it would help to also include it in the announcement of availability, download file name, and Github branch name. (Even saying, "Beta-0.8.1", as a prefix rather than suffix, would help avoid conflict with common practice elsewhere.)

Tom Preston-Werner of Github has a nice attempt at formalizing the practices I'm most familiar with in his "Semantic Versioning" proposal:

http://semver.org/

I've installed the Bitcoin-qt client from the Sourceforge download...

http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.1/bitcoin-0.8.1-macosx.dmg/download

...with SHA1 matching...

5b47f0b7727a64893ac63068e39ebf126e8afdd1

The 'About Bitcoin' dialog declares it to be "v0.8.1-beta". Was this an error in packaging? Or are even final releases being called 'beta'?

Yes, external indexing by watching blocks should be a suitable workaround.

Thank you for a quick and definitive answer!

Looks like the raw transactions API could be useful to run a connected client, but keep signing keys elsewhere. (Elsewhere = only  occasionally connected in some limited hardened way.)

This would be easier if the connected client was able to 'listunspent' outputs available to arbitrary addresses.

Is there a way to register watched addresses in the standard client?

Or, could 'listunspent' be extended to take any non-wallet address as an optional parameter?