I know LoyceV has put together a nice scrapable archive of the topics of this forum.

I want to do a analysis of the BTT forum. I could write a script to scrape the data from LoyceV's archive but I was really wishing someone could point me towards a fully downloadable database to speed things up. Does anyone have a reference?

Cheers!

I was surprised to see that buying and selling accounts is not prohibited in this forum. But looking into it I only saw offers that looked like scams (based on the red alert that flags on top of them).

So I'm wondering if there truly are account sellers. Or even buyers! Is this a liquid market? How much would someone pay on average for a M/Full M/Sr. M/Hero M/L account?

[time capsule]

Some days ago I asked for help with the building of a trusted clock using BTC. I got a few replies that helped a lot and led me to a solution to the problem. But my true goal is to code a program that acts like a time capsule. Its task is to safely encrypt data during a set period of time and decrypt it afterwards. Here it is in a more detailed form.

• Input (at t=now): release_date (UNIX time value), encrypt=True (bool).
• Output (at t=now): encrypt_key (type key).
• Input (at t≥release_date): encrypt_key (type key), encrypt=False (bool).
• Output (at t≥release_date): decrypt_key (type key).

Take some data you want to send to the future. Give the program a release date, encrypt your data with encrypt_key and throw the raw data and the encryption key away. Safely store the encrypted data. Wait. After the specified date, give the program back its encrypt_key and get back your decrypt_key to decrypt your data with.

Everything must be run locally.

Critical assumption: the user is good-intentioned right until they throw away the raw data, after which they feel an immense regret and become malicious.

The problem: make it as hard as possible to get decrypt_key before release_date

First idea (which led to the previous post): 1) make the program get the current date from a trusted source and compare it to release_date; 2) if time is up proceed to outputting decrypt_key.

This can be beautifully solved by BTC (or any other PoW-based cryptocurrency, really): after release_date, give the program the longest chain of block headers; the program will check the PoW, that the difficulty increase is coherent and that the time intervals are not suspicious (i.e. 10 mins on average, also if the last time interval is 2 days, it might suggest that a malicious user mined their own last block and faked the timestamp... a few details should be taken into account despite compromising accuracy). The beauty for me is that the program doesn't care if the chain is the longest or whether it's been confirmed by the network: it only wants the proof of work; and the good-intentioned user doesn't need to bother about calculating that PoW: miners do that for them!

This already makes for long-term reliable (though potentially very rough) time-checking method, but my task is to build a time capsule. I still face the issue of having to obfuscate the code responsible for producing decrypt_key. Sadly there is no way to avoid the threat of reverse engineering, especially for locally run programs. If a machine can follow the instructions in your executable, so can a talented enough human.

Second idea (here you BTC geeks might help out): using the lock_time parameter. The program can issue a transaction that's time-locked to release_date. How could I exploit this feature? Or to put it another way: what kind of information does the user gain when a transaction is processed by the network?

I came across some posts about a certain puzzle transaction that sent some good 32 BTC to 256 addresses.

What's the point in brute forcing all of these addresses. Aren't they empty?

BTC works because of PoW. Satoshi realized that consensus in a network could be achieved if the nodes committed computationallly to their version of the story. Using computational means to show how confident you are that you're speaking the truth prevents malicious nodes to influence the network with untruthful facts. But "computational" is too theoretical of a term. In reality, miners care, not about how many operations their calculations are taking, nor how long they're taking, but about how expensive the next block will be to mine. Really, miners use financial means to back up their version of the story. If their block is accepted by the network then the financial goods spent in the mining process are collected back with a profit; otherwise they're lost. Miners stake their financial goods to "prove their point".

Now, I guess many miners use traditional currency to buy all those nasty plastic high-tech gadgets that speed up their calculations. My two questions.

• Does this economically "link" in some way BTC to physical currencies?
• And more importantly. If the time comes that the traditional currencies are replaced by BTC, miners will spend BTC to buy their graphic cards and everything they need, so they'll actually stake BTC in order to prove their point. So in a fully bitcoinized economy, won't PoW be identical to proof-of-stake? Let's just obviate the immense pile of e-trash and the huge electricity consumption gap that separates both protocols in reality.

The title of this post should be "Will PoW converge to PoS?" but I liked a catchier version.

I'm new here. What's all about this merit count? How is it earned? I'm assuming it's linked to the quality/usefulness of your posts/replies? Their originality maybe? What are usually the subjects you'd get the more merit for posting about?

I'm intrigued by how these signature campaigns work.

How do these companies know you pasted their html in your signature and that they should pay you? Do they pay a fixed amount per post or a fixed amount per week? How much do they pay on average for each rank? Or is it not the rank but the merit which determines your income?

Cheers!

Is there a limit to how late a lock_time can be set to?

If not, suppose I send out a transaction that's time-locked to 1 day/month/year/decade into the future. To what degree of certainty will my transaction be eventually be included in a block? In particular, do later-time-locked transactions need higher transaction fees in order to keep the same probability of being included in a block at t ≥ lock_time?

Thanks!

A block header must be timestamped less than 2h into the future in order to be confirmed by the network. Is there a similar rule for transaction timestamps?

[Edit:]

I'm looking for a way that a computer could get a rough estimate of the current date and time with a very high confidence level, for example in order to verify the expiry of a contract by means of a computer program.

NTP^[1] is a popular protocol for synchronising computer clocks across a network. Despite providing highly accurate time measurements, NTP doesn't sign timestamps, which, in the context of my project, is a lack of reliability in that the nodes are susceptible to DNS spoofing^[2] or man-in-the-middle^[3] attacks^#, which are able to make the victim think it's communicating with someone else than who it's actually talking to, and thereby manipulate the victim's perception of current time.

After some deliberation I realized that the blockchain can be taken as a trustworthy log of past timestamps, the latest of which give a rough estimate of the current time. Thus –I thought– I could write a program that starts a Bitcoin node, requests from its peers the latest blocks and fetches the timestamps from their headers... done! Now, I'm pretty confident this method is robust against the attacks discussed in ^#, but I don't know how to formalise the method. Here's my idea.

In order for the method to equally apply to old and new users, let's assume that my computer starts a brand new node each time it wants to check the current time. Each time, it will DNS-lookup some node IPs and subsequently request the latest blocks from them, check their validity and, if positive, read the timestamps. This gives raise to the following question.

• What is the quickest way for my node to know that the blocks received from its peers have been validated by the network? Can it do so without downloading the full 400+GB blockchain nor compromising the robustness against DNS spoofing and MITM attacks?

My guess is that I could verify all the transactions, Merkle roots and headers of the blockchain provided by my peers; but still what would guarantee me that the branch that I'm looking at is backed by the network?


Despite the generic feeling of the question-marked questions, please note that my sole goal is to turn the blockchain into a trustworthy timekeeping log (a "clockchain", if you would), not running a Bitcoin node per se. It would be ideal to find a specific solution to the problem but the only approaches I have come up with are as generic as the questions up there.

Edit: I found a possible solution. Read it here.

 [1]: https://datatracker.ietf.org/doc/html/rfc5905
  [2]: https://www.imperva.com/learn/application-security/dns-spoofing/
  [3]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack