I would not take this deal. This clause essentially allows you to back out of the deal if, closer to an actual fork it is clear that BU will be superior to Core, and does not allow Ver a similar out.

You are basically asking for a free put option on BU.

Please do not read any of this thread, nor research the current trading prices of trading pairs that you are quoting prior to posting here.

Yes there is a risk of no split (or that core will change the code in their repository after a split to be compatible with BU) on bitfinex, however I don't think that accounts for all of the discrepancy in price.

The executives at the various exchanges seem to believe that BU initiating a HF to be increasingly possible. The recently found blocks are pointing to momentum for BU.

I cannot predict the future, however I would not write off the possibility of a fork, as doing so would be reckless.

This kind of deal would be nearly impossible for either party to enforce, and there is the possibility that both parties would not even have the potential to be able fulfill their obligations in the event of a split because the loosing chain is likely to quickly die off

Verified.

Why would he be willing to do a 1 for 1 trade? The market rate on bitfinex (which I am fairly confident that you use) for BTU is 0.2102 while the market rate for BCC 0.758, both in terms of BTC. So for this to be a fair trade, you would need to offer him 3.6 BTU for every 1 BCC that ver gives you.


edit: no longer confident you use bitfinex; my prior presumption was due to a coinjoin transaction. It does however look like you might have withdrawn 50,000BTC from SilkRoad in Sept 2012, worth ~$610,000 at the time, or you may have purchased some coins from someone who did this.

8b1d30919a006a05220deff1c0cf909c10830e2ec4dd66ce310a5f657e2afd8b

I think by "uninteresting" they mean "unprofitable"

How diverse is your product base? -- if not very diverse then having a few extra products might not cause very much financial harm.

Do you have a way of tracking if someone is a repeat customer (also are your customers' identities verified)? -- If so, then you can assign each customer a risk profile based on their prior behavior. For example, a customer who has ordered from you multiple times and that has not ever had any kind of failed payment/deposit will probably have a higher chance of having their transaction confirm (or a transaction in the appropriate amount) than a customer who has a history of failed payments/deposits. Also if you have done business with someone many times in the past (and earned profit from this person), then the risk of someone trying to cause you financial harm would be low.

What you are describing sounds very similar to how Gemini will pre-credit some Bitcoin deposits for trading nearly immidiately after receiving the transaction. If this is something similar to what you are trying to implement (or improve), then you can look at the total value of the account verses the value of the deposit. If the deposit is under a certain percentage of the account's balance, then the amount under the certain percentage threshold might be able to be excluded from the total credit risk.

I think the terminology that you are using is not quite correct.

If you send three transactions from addresses that you control to three different addresses controlled by a single entity, then it may be possible to reasonably conclude that either the same entity sent all three transactions, that the same entity received all three transactions, or both, depending on the circumstances.

If the transactions that you send use more than one input, then it can usually be reasonably concluded which address is a change address, especially long after subsequent outputs have been spent. If two inputs are change addresses, then it is possible to reasonably conclude that a single entity controls a larger cluster of addresses than individual transactions might suggest.

If in one transaction, you send BTC to two different entities and no change address, it is sometimes reasonable to conclude this fact, and exclude both entities from being the owner of the sending addresses.

There are specialized tracking companies that do look at the blockchain that use even more advanced analytics (more specifically conclusions derived from these analytics techniques).

IIRC, an address being highlighted in red means that BTC ended up in a change address that is expected to receive BTC after the next change address that is expected to receive change from a transaction spent from your wallet.

This could be an indication that a transaction that you sent (that includes a change address) failed to confirm and has dropped from the electrum server's mempool that you are using for whatever reason. It could also be an indication that you directed someone to send BTC to a change address in your wallet that is not the next change address in line to be used.

Increasing the max block size will make it exponentially more expensive for spammers to continue spamming the network. Also as long as the max block size is sufficiently higher than the natural amount of transactions, spamming the network with transactions will be unprofitable to a small miner.   

This has been fixed.

Hmmm, it looks like I had to access http://2.bp.blogspot.com/-d0Ippz-2CN0/TWcO_2wZOiI/AAAAAAAAFZA/ZkU-bL3fUAk/s1600/eagle-4.jpg in order to view his profile. I think this could possible leak information about anyone who views his profile or a page that he posted in.

I will message theymos about this.

Who has their avatar hosted on a non-bitcointalk website? What domain is it hosted on?

Your site uses the Default Trust network to calculate trust scores. If this is what you want to do, then you can have your site determine who is in the DefaultTrust network by going to https://bitcointalk.org/index.php?action=trust and collecting a list of accounts that have a number of zero or greater from an account that only had DefaultTrust in it's trust list, and the trust depth set to 2. From there, your site will only need to parse the sent trust ratings of the few hundred people who are in the DefaultTrust network. The formula to calculate a trust rating is public, so your site should be able to calculate trust ratings without having to visit everyone's profile. Although it might get confused if someone receives their first negative trust rating on the same day that they receive a positive trust rating, so in these instances, you can have your site visit the person's profile to check the ordering of the received trust ratings.

edit: formula for trust ratings --> https://bitcointalk.org/index.php?topic=1066857.0

If you are logged in, if you read a thread, and a post in that thread subsequently gets updated, that thread will show up as being unread (but will not show up in your watchlist). Once all threads get archived/saved, the site can simply check for unread threads.

In regards to profiles, the site will need to view profiles one at a time the same way it would originally get this information. It might know to check the profile if it sees a new/edited post by you, which would reduce the number of times each profile would get checked.

There are many of these kinds of sites, probably hundreds. Most of them are most likely trying to host advertisements without having any original content, although some of these are probably also phishing sites and it is never going to be safe entering your password onto any of these sites.

Yes, exchanges (and users) could send some of their BTC to one address on BU, have that transaction confirm, then double spend that transaction spending those blockstream coins to a second address with a high enough fee for it to confirm, and subsequently have each transaction be dependent on each of those non-compatible transactions . Unfortunately that could turn out to be very expensive and impractical, especially if many people are trying to do this at nearly the same time, especially considering that many exchange customers will not like delays in processing withdrawals.

If there was something in the BU protocol that makes a BU transaction not compatible with a blockstream coin transaction, then this would solve the problem.

This is probably the best way to handle things. Once BU activates, the market will be able to decide which chain will emerge as the "winner" as the price will give the miners an incentive to mine on the higher priced coin.

In regards to what "blockstream coin" and "bitcoin unlimited" are called on the exchanges, I really do not think this matters, even if exchanges call either of them something other than Bitcoin for a long time. Although it is very likely that one chain will very quickly die due to the incentives associated with mining and the time it takes for the difficulty to recalculate.

I agree that there should be something to prevent replay attacks on the protocol level, both for the exchanges' sake, and for the protection of the end user. Although as mentioned above, one chain will likely die, and if this happens, replay attacks will be more or less a non-issue.

I don't think I have ever seen a cas dime sell for 0.37BTC...

Those who work for Blockstream can effectively block any proposal that does not benefit their interests. Or at least make it very significantly more difficult to get said proposal to get adopted. This effectively gives users the choice between the status quo and what those who work for Blockstream proposes. If the status quo is not what the community wants (like as is the case currently), then the community has little choice other than adopt what Blockstream wants.   

You accepted PayPal from him?