Transactions already require Proof of "work" however not in the exact way you are proposing. In order to get accepted into most nodes' mempools, and more importantly, in order to get confirmed, transactions must include a transaction fee relative to the size of said transaction. A transaction fee is, in effect a payment of money, and users must "work" in order to obtain said money to pay for the transaction to get confirmed.

With LN, it will likely be difficult to spend your last 0.00001 BTC, however once you have a channel open, it will be fairly cheep to spend 0.00001BTC if you have a significant additional balance within the channel. This is an improvement from the current state of Bitcoin because it is (and always has been for this specific example) prohibitively expensive to spend 0.00001BTC.
The cost of on-chain transactions will likely increase.

The costs associated with opening and closing LN channels will likely be significant.

The cost to get a transaction confirmed on the blockchain will likely go up from current levels (or else there would not be incentives to use LN in masse), and the amount of transaction space required to open and close a LN channel is much greater than getting a "normal" (eg a payment from one person to another, or a withdrawal from a business to several of its customers) transaction.

It was not long ago that businesses were relying upon 0-confirmation transactions, and had very little "credit losses" from doing so. The reason why this was generally safe in the past was because businesses could look at the transaction fee attached to a transaction, and very confidently predict if a transaction would confirm within ~3 blocks, even if the network had very "bad luck" in the subsequent three blocks.

Today, most transaction included in blocks cannot be predicted they will be confirmed three blocks ahead of time because the necessary transaction fee to get a transaction included in a block is so volatile, and has the potential to spike.

Also, the default settings of Bitcoin Core (which in part are in place due to realistic memory limitations) result in many transactions being dropped from many (most?) nodes' mempools that were expected to confirm quickly at the time the transaction was broadcast because of spikes in transaction volume and/or spikes in necessary transaction fees required to get a transaction confirmed. This means it is often trivial to double spend a 0-confirmation transaction that does not include a "RBF" flag that was expected to quickly confirm (within 4 hours/25 blocks) as of when it was broadcast.

For a business using Bitcoin Cash, the business can look at a transaction and reasonably infer if a transaction will quickly confirm, and nodes are not needing to drop large percentages of transactions from their mempools after they relay said transactions.

That is not the point. Lauda and minerjones (along with yahoonumbers) screwed up, and said they were going to impose losses as a result. The whole point of using escrow is to not allow losses resulting from someone absconding with funds.

Also, they did charge a fee, see this transaction, each of them "earned" around $215.


I am curious to know if anyone would be willing to use a particular escrow service if they knew there is a possibility a scammer would run away with funds, and the escrow agent would not cover losses when they failed to properly secure the money.

I would remove Lauda and minerjones from this list. They were both escrow for a deal that went bad, in which funds were lost, and lauda had announced the escrow agents were going to impose the losses on those they were supposed to be protecting against losses -- this very much defeats the point of using escrow.

Actually both of them were involved in a deal in which they acted as escrow, and were going to impose losses on their customers before they recovered money from the scammer...I would avoid using either minerjones or Lauda as escrow.

I would find it fairly unlikely that USDT will collapse in the medium future.

The bank balance of tether's bank accounts exceeded the number of USDT issued, per the blockchain, and matched what tether was claiming to have in the bank at the time, as of September 2017. The fact that tether can simply decline to redeem specific USDT, and the fact that money sent to tether before they issue USDT is not reversible (bank wires) means there are virtually zero scenarios in which tether gets hacked, resulting in losses to USDT holders.

This is somewhat speculation, but I somewhat suspect this is something the fee market will cause.


Businesses that process withdrawals on a 24 hour basis on demand from their customers, need to price withdrawal transactions on a "confirm next block" basis. If they price withdrawals on a "confirm within 3 blocks" (or something less), then (a) they can only process withdrawals every 3 blocks and (b) risk havoc being wrecked if transaction fees  rise between when transactions are broadcast, and the next 3 blocks, including the possibility of having their entire hot wallet tied up in unconfirmed transactions. If the business chooses to allow a certain number of chained unconfirmed transactions, they risk a more complex problem if the mempool situation gets so bad that many nodes forget parent transactions that are unconfirmed. Hot wallet implementations at many large businesses are setup so that employees do not have direct access to the hot wallet, but rather have access to a program that will in turn have access to the hot wallet, so selecting specific inputs is more difficult.

It is possible that some businesses estimate the required fee in a way such that after ~5 minutes from the time the last block was found, they have a better idea of the required tx fee for a transaction to get confirmed in the next block, and lower fees paid accordingly.

What terms are you interested in? Do you want it to be denominated in USD or BTC? How large of a loan do you need? It looks like you need the loan to be due in 60 days, is this correct? What interest rate are you willing to offer?

So you are saying that you don't have sufficient money to pay for the necessary medical care, and as a result will forego it? If so, that is rough.

If the above is true, the most simple way to pass on your bitcoin to your heirs would be to deposit your BTC into a US based exchange, have your identity be verified, and state in your will that anything of value in your gemini account is transferred to your nephew. If you use an exchange based outside the US, there is the risk that the exchange will not follow a US probate court order to transfer ownership.

If you do not want to store your bitcoin on an exchange, I would advise storing your bitcoin in a wallet that uses a word based seed (such as electrum) (the reason for this is it will probably be easiest for your nephew to transfer the wallet onto his computer), and store a backup in a safety deposit box, along with detailed instructions on how to get the wallet onto his computer, and to spend everything in the wallet into a newly created wallet. In your will, you can state that you want the contents of your safety deposit box given to your nephew.



I would also strongly suggest consulting with an estate planning lawyer about this. Transferring bitcoin to your heirs is very similar to transferring cash or other bearer instruments to heirs, which is something that has been done for a long time.

The only reason he is in jail in Thailand is because the US is trying to extradite him to the US. If he can successfully fight extradition, he will be released from jail in Thailand. If he does get extradited, he will face trial in the US, and potentially have to stay in prison for a very long time.   

Are you referring to theymos or satoshi?

I think it would probably be a bit of a stretch to believe theymos has 140k+ BTC. For satoshi, this would be well below the lower bound estimates of his holdings.

The terms of his auctions are not equitable.

I stopped taking his market place threads seriously when he tried to sell his ~1.89BTC debt owed to him by a defunct exchange for face value...

I bid $10,000 for 50,000 XRP under the following conditions:

• My bid expires 72 hours from the date of this post -- I believe the terms of the auction are such that this will not matter
• The payment deadline is extended to 24 hours from the time a payment address is provided -- I expect to be able to pay well within your 8 hour window, however I do have work during the day, and I cannot guarantee I will be in a position to pay you within 8 hours depending on the timing
• We either use a mutually agreed upon escrow, or you send first -- I will cover any applicable escrow fees. I would agree to Blazed or OgNasty, I believe both of which have sufficient reputation to handle a trade of this magnitude

If you do not agree to the above stipulations, my bid is invalid.

I would agree that forks generally do not meet the definition of a dividend, and reasonably should not be treated as such. This is very different from tax law, however under GAAP, dividends can only be paid out of retained earnings, which would not apply to bitcoin because "bitcoin" is not a company, nor does it earn anything.

I would also agree that the most appropriate way to account for fork coins would be similar to that of a stock split. I would say that treating fork coins as having a cost basis of zero is a very conservative tax strategy, although it would probably not match current law -- this will generally be acceptable to the IRS, and would not subject to you penalties/liability as long as your strategy results in you paying at least as much in taxes as what you owe under the tax code. This may be disallowed if you sold your bitcoin but not your fork coin because it would result in you having a lower tax bill than what I believe the law provides for.


There were many venues for price discovery for the various fork coins, for example, there were futures markets for all of the major forks coins, BCH, Bitcoin Gold, and SegWit 2x (that ultimately failed/did not occur), and many major, reputable exchanges offered spot trading after each fork occurred. A tax attorney can devise a good argument to value fork coins a certain way based on the various means of price discovery.

For publicly trading corporations, a stock split should result in greater long term shareholder value, so the price of bitcoin increasing after a fork coin is not a good argument for making the cost basis of a fork coin zero.

Another point is that it is not unreasonable for a fork coin to result in Bitcoin ultimately quickly dying after the fork coin is created, resulting in it not even being possible to move bitcoin onto an exchange to sell, and it would not reasonably match current tax law to have this fork coin to have a zero cost basis, and to have bitcoin have a high cost basis when its value is zero and cannot be traded. 

As a general rule, your debts will need to be paid/satisfied before any of your assets can be transferred to anyone named in your will. 

One problem is that theymos needs people who can be broadly trusted because admins can potentially do a lot of damage that would be difficult to undue.

One potential solution would be to give a small number of people real-only access to certain information that admins are usually able to access, and then handle the research necessary to do things like password resets so that an admin can have the necessary information to make a decision presented in a way that is easy/quick to verify. 

I am also unsure how comfortable cyrus is at publicly saying that x is an alt of y. This is generally more complex than simply looking at IP addresses. From what I can tell, theymos doesn't really like doing this either, however BadBear was rather good at this, and was generally accurate in his research. 
November 29, 2017, 08:07:39 PM GMT

It has confirmed

I am not exactly sure what you are trying to say (drunk?).

The OP is suggesting that if anyone advertises an ICO via PM spam then the relevant ICO thread gets locked. I am saying if this were to get implemented, a competitor could advise a competitor of theirs via PM to get their competitors thread locked.