Suchmoon sees nutildah as expendable. She doesn’t care if he gets banned. She posts nonsense with the hopes that he will ignore my very specific warnings about what will happen if he continues to move his thread, hoping that the mods will blufff, but also not risking anything in terms of consequences if nutildah does get banned.

It should go without saying that suchmoon is not honest and doesn’t care about anyone except herself.

Based on my professional interactions in the business world, there is a very high probability that the OP is either an admin or a moderator trying to give advice to nutildah. If not this quoted post is most certainly a warning to nutildah.

I would tell nutildah to cut the shit and move on. It is not appropriate for your thread to be in currency exchange. This is not going to kill you. This is not something worth getting banned over.

The fed is currently engaging in QE, and will likely continue doing so for at least another 9 months based on their current plan. They won’t raise interest rates until after QE is stopped (or at least until they stop purchasing additional bonds).

For the fed to remove liquidity, they will need to either raise short term interest rates, or be a net seller of bonds (selling a bond would include redeeming it at maturity and not purchasing an equivalent amount). It appears it will be a long time until either of these will happen.

As long as the fed is either adding liquidity, or not removing liquidity, we will see additional speculation in financial markets.

It has also been noted that there are no capital controls throughout the west (eg europe), so if the ECB is engaging in QE, it is the same as if the fed was engaging in QE.

As has been mentioned by multiple people (including myself), LN is superior for retail transactions.

However when determining if the amount of time is acceptable for a retail establishment in terms of payment confirmation, it is more complex than the worse case scenario for when the next block will be found.

It is important to note that the average block time is going to be twice the average amount of time until the next block at any given time. So on average, over many transactions at an establishment, if the average block interval is 1 minute, the average amount of time until the next block is found will be 30 seconds -- about half the time it will be less than 30 seconds, and about 1/2 the time it will be longer.

From an operational standpoint, it is important to understand where the bottlenecks are, and how long they are. At a coffee shop for example, there are bottlencks at the line to place an order, and at the barista who is making various orders. In my experience, there is a longer bottleneck at the barista than there is to place an order. This means if there is a 1 minute block interval, the coffee shop could direct the customer to proceed to the waiting area after 5 seconds when the coffee shop is confident the transaction will confirm in the next two blocks. While the coffee shop is waiting for a confirmation, the order can be placed in the queue (as is the case today with cash/credit card txns), and once the order reaches the front of the queue, if the txn has not yet confirmed, it can be moved back one place in favor of another order (or the coffee shop can elect to accept the unconfirmed txn provided certain criteria is met, such as no blocks being found, and no recent double spends against them).

There is a similar bottleneck at fast food restaurants, and a similar procedure can be implemented. At dine-in restaurants where payment is typically made after the meal is consumed, waiting 5 or 10 minutes for a confirmation should not be a major concern.

A retail establishment is more complex. There is currently a single bottleneck and that is waiting in line for the clerk to "ring up" the items a customer is buying. In addition to "ringing up" items, clerks will also place purchased items in bags. One solution might be for the customer to "scan" the items being purchased prior to interacting with the clerk, paying for the items via a txn, and by the time the clerk has finished placing all items in bags (which will not happen until the clerk has placed all previous customers' items in bags), hopefully the txn will have confirmed.

Was your transaction non-standard or unusual in any way? Are you comfortable sharing the txid and blockchain the deposit was sent to?

I don't think bitfinex is very active on bitcointalk, but you can try posting on twitter and you might get their support's attention.

My calculations might be off, but I believe this is the post that received the 1,000,000^th merit. Congrats to Phil_S


My monthly source merit bank is 100 merit. The second that theymos updated my source merit to this allocation, this was my available source merit amount. Some amount of time after theymos updated my source merit allocation to 100 merit, I spent some of my source merit, and exactly 30 days after I spent this source merit, the amount of merit I spent will be returned to my merit source allocation exactly one time.

The monthly merit source allocation is set manually by theymos, although he likely used some algorithm to calculate each sources allocation. Each sources allocation is not going to change without some kind of intervention by theymos.

I have to say that I am proud of my work.

I am curious to see the stats for the year and/or 12 month rolling stats.

I would echo Dave's concerns about "protecting" children's money. If your child is growing up, as a parent, you need to "let" them fail so they will learn.

In my example, only two people were mentioned, but in reality, the number of people involved could be in the dozens, and there could be more than one required person making the request, and more than one person required to approve the request, and these people must come from distinct groups of people. Say for example, there is a team of 24 team members managed by three managers. The company might require that three employees request a transaction, and it must be approved by two managers. The employees could have a 3 of 24 secret that could be one of two secrets that are required to access a private key. Each of the three managers could have one secret that is part of a 2 of 3 secret that would e the other of the two secrets required to access the private key.

Having 24 team members would not be possible with multi-sig, and requiring a certain number of signatures from y distinct groups is also not possible with multi-sig.

So I guess a 2-of-2 multi-sig would be better than my simple example, but shamir shared secret is superior to more complex scenarios that might be more realistic in the corporate world.

Employee turnover is another risk to multi-sig. Anytime an employee leaves the company (especially if they are fired), the company would need to move their bitcoin to a new multi-sig address to reduce the risk their bitcoin will be stolen by a combination of rouge ex-employees.

This will change with taproot, but currently, multi-sig requires more block space.

If certain security measure are taken to ensure no one has physical access to the computer, and that anytime someone accesses the room where the computer is physically located that power is cut to the computer (wiping its RAM), an alternative might be to SSH, or otherwise remotely connect to the computer with the script that calculates the private key. This obviously comes with the pitfalls related to keeping your private keys on a non-airgapped computer. You might be able to reduce the risks somewhat by keeping the computer on a private network, and restricting which computers can connect to the private network.

Without allowing SSH/remote access to the airgapped computer, precautions could be taken to prevent a "smash and grab" theft, such as bolting the computer to the ground, remote camera monitoring of the room the computer is located in, and being required to be "buzzed" out of the room when you have signed the transaction, and probably others.

A better use case might be an employee having a budget, but needs some kind of approval from his boss to spend any money.

Realistically, the best solution would be a watch only wallet in a way somewhat similar to how n0nce described above. Although this scenario would mean that the boss, or approving authority would have complete control over the private keys.

If you want to guarantee that the "approver" cannot spend on their own, an alternative might be to implement shamir shared secret. The workflow might be as follows:
*The employee proposes a transaction
*The approver reviews and approves the transaction
*The transaction is loaded onto an offline computer
*The employee and approver review the transaction to confirm it is the same as the one being proposed/approved
*The employee and approver loads their secret onto the offline computer, which passes both secrets through a script that takes the following as inputs:
~secret 1
~secret 2
~transaction to be signed
*The script outputs the signed transaction, and the signed transaction is transmitted back to the employee who broadcasts the transaction to the bitcoin network
*The employee and approver both personally confirm that the RAM is cleared/wiped from the offline computer, removing their respective secrets from said computer

I think most merit sales generally stick out like a sore thumb. For example, whenever I see someone with one merit and 1000+ posts, I assume they bought their single merit. Or when I see an OP of some project, I assume they bought their merit. I also see some people with zero merit, 1000+ posts, and a copper membership.

I am not terribly concerned with someone buying a single merit. Someone ranking up to a junior member isn’t going to hurt anyone. My guess is that they want to avoid having to wait 6 minutes between their bounty posts.

Maybe Theymos could offer a lower version of a paid membership that is less expensive than a copper membership, maybe it could be called “bounty spammer”, cost $20 (in BTC) and give those who are wearing it the same abilities that a junior member has.

I don’t know if it is true that people are selling merit for $20/each, or if they are if they are able to actually get that much. If there is truth to that, I would say it is evidence of a market that is not vibrant and inefficient. I would see that as a good thing because it shows that it is difficult to trade merit.

I am not sure what has caused this. I think most likely, it is the result of self regulation and Theymos doing a good job of selecting merit sources who will not only refrain from selling merit, but also who will send merit to posts that are deserving of merit. Those who are capable of making good posts on bitcointalk, generally will have other skills that will allow them to make money by doing things other than selling merit.

Thanks. My time machine was malfunctioning.
I think the Spanish, Indonesian, German and Turkish sections get a decent amount of traffic (or at least have a decent amount of posts). Someone advertising might want to create translated ads that are in Spanish (for example) that are meant to be displayed in the spanish section.

The biggest opportunity would be for the gambling and altcoin sections. Being able to target those sections specifically would probably increase overall forum revenue over time. At first, only sections that meet certain traffic/post quantity criteria could be specifically targeted, and if there is demand for other sections, those sections could be specifically targeted as well. There could be an 'all other' group that advertisers could bid on that would be displayed in all non-specifically-targeted sections.

The documentation for the Binance API is here. The documentation will show you how to get the market data you need to feed into your bot, and how to place trades programmatically.

From there, you need to keep track of market data in your bot. How much market data you keep track of will depend on your specific trading strategy.

As a merit source, I get my source sMerit from theymos. It is his sMerit that he has delegated to me for me to send as I see fit, but I also need to follow his rules. The only rule that theymos has for merit sources that I am aware of is they cannot sell their sMerit, although I also follow other common sense guidelines when deciding which posts to merit that might be frowned upon by the community if all facts were to be made public, along with speculation by some people.

The forum also believes in a free market economy, and part of a free market economy is the ability to sell things, even if people do not like those types of transactions. This is a concept that I strongly support, as does most of the community as a whole. This however does not mean that I will not think of someone differently who engages in transactions that I do not approve of (such as selling merit). As I do not approve of people selling their merit, even if they are not a merit source, if I become aware that someone is (trying to) selling their sMerit, and have substantial evidence of this, I will likely leave negative trust and support flags against those engaged in this type of activity.

To put the above another way, I support people's rights to make bad decisions, and their right to do things that I disapprove of. Making bad decisions, or doing things I disapprove of will be subject to negative consequences however.

It is my understanding that selling merit will not result in the person getting banned. Theymos said he is not going to be moderating the merit system. I understand the consequences of selling merit as a merit source means the person will be removed as a merit source, and the consequences of selling merit as a non-merit source are handled by the community.

With the above being said, in many ways, merit is valuable. Having merit will often indirectly lead to additional business opportunities, and opportunities for profit.

If a transaction is not opting in to RBF, I would argue that a zero confirmation transaction has modest amounts of security. Obviously a single confirmation has much more security than zero confirmations. Once a transaction has a single confirmation (with a 10 minute block time), the chance of loss goes down to close to zero, and will incrementally decline until 6 confirmations, when the risk is still something very close to zero, but not zero, and will not decline further as the transaction receives additional confirmations.

Someone accepting (and exchanging value for) an unlimited amount of bitcoin will want to wait for 6 confirmations, especially if they receive large amounts of bitcoin. However this is not true for retail establishments, as they are limited by their available inventory, are further limited by bottlenecks at the checkout process, and are further limited by the fact that many retail establishments will require some kind of a delay when selling very large amount of inventory to a single customer.

While it is not especially uncommon to see an orphan bitcoin block (d500 cites data suggesting about 0.5% of blocks are orphaned, which works out to about 2 every 3 days), it is uncommon for a transaction confirmed in an orphaned block to not get confirmed shortly thereafter. This implies the risk of accepting a 1 confirmation transaction is very low. Double spending a transaction that received one confirmation generally requires both mining hardware and multiple tries at double spending (or without mining hardware, MANY tries, even with RBF enabled).

I speculate at least part of the reason for the above is that most miners (the entities that actually propagate found blocks -- eg pools and solo miners) are well connected to the network, and follow similar rules to maximize tx fee revenue. Having a 1 minute average block time would obviously allow for more entitles to enter the mining world, and the rate at which a particular mining entity has not yet received a particular transaction as of when a block is found would probably increase.

I am curious if anyone has run any simulations on the effect shortening the average block time has on the percentage of transactions getting double spent that were included in an orphaned block. It shouldn't be especially difficult to figure out a way to compensate miners for orphaned blocks (such as eth's 'uncle' system). The more important issue is the risk of loss in accepting n confirmations when the average block time is changed.

A business receiving cash cannot effectively spend it instantly because most of their bills are those that require payments being sent to locations far away. Also, payment due dates are not immediate, so this is generally an issue. Most businesses will have some kind of armored car service pick up cash deposits, which often will not happen daily and takes time for the bank to process.

The underlying issue is not when a business actually receives a payment, the issue is when a business knows with x amount of certainty that they will receive a payment. With bitcoin, this can be as quickly as a few seconds, even with a 10 minute block time, as long as certain criteria is met with the transaction (RBF being set to False, no unconfirmed inputs, sufficiently high tx fee, etc). It is difficult for a business to ensue a transaction has a high probability of quick confirmation because the sender has so much control over the transaction.

The above would again make me want to circle back (please don’t discredit me for using this term), to L2 solutions. LN will ensure that a business will receive a payment nearly immediately, and if the transaction fails, both the buyer and seller will know immediately. 

When Theymos solicited factoids in 2018, I made some suggestions, and two of the factoids now resemble what I suggested. I am not sure if Theymos edited my suggestions before implementing them, if he got the ideas from someone else, or if they were already implemented (I think probably not).

I assume the factoids are part of the ad serving system. I don’t think it would be difficult to maintain as long as the ad system is being maintained. A factoid was supposed to be a benefit of donating to the forum, so I understand why it would remain up after a donator account is banned.

I think Theymos is giving up a lot of revenue with the current ad system. I think he could probably make much more overall if he were to implement an additional system that allows people to bid by section. For example, it currently makes no sense to advertise if your target market is the Spanish section because the overwhelming majority of page views are of people who don’t speak Spanish. There may be advertisers who currently advertise in English that would like to advertise in Spanish if said ads would only reach the Spanish section, or if the ads would only reach people who have posted in the Spanish section within the last n time.

The solution might be to offer ads by section, by setting some criteria for what happens when not all ads in a section sells, and the ability to serve ads in other sections than the one being paid for. Ads could be pre-approved, so there wouldn’t be the issue of serving an ad that is clearly something Theymos won’t approve.  

IIRC, those who donated 10 BTC were able to get one factoid spot. Over time, some of the links people posted in their factoids became 'dead' as projects failed/closed/ended, and those were removed.

Theymos solicited factoids in this thread in 2014, and again in in this thread in 2018.  

The issuing bank (via the debit card network) can reverse a debit card transaction under certain circumstances. The money being immediately debited from your available balance allows the bank to know the transaction will not be declined due to insufficient funds.

The biggest difference between using a credit (or debit) card and accepting a zero confirmation bitcoin transaction is that the merchant will largely know the identity of the person using a credit card (unless the physical card is stolen), while a bitcoin transaction is, for all intents and purposes anonymous in many cases.

Most merchants do not need the money in their bank account immidiately, they only need a commitment from someone that is reliable (such as a card network) that payment will be received in due time.

I think the most likely long term solution to in-person payments being completed quickly on any kind of scale will be Lightning, or some other similar L2 protocol.   

haveibeenpwned gets their information from various leaks of data. When haveibeenpwned says that a password was leaked, it means they were able to find a leak that contains a password. If haveibeenpwned is able to locate a list of stolen information, it means that someone else can also locate the same information if they know where to look. Someone hacking the haveibeenpwned database would largely be pointless because the information is already public.

CMC's obligations regarding their customers' data can be found in their privacy policy. If someone does not like the terms of their privacy policy, they can ask CMC to change the term they do not like, however until and unless CMC changes the policy, the policy as currently as written lays out their obligations.

I am also not sure there is sufficient evidence to suggest that the leaked images came from Binance or any of their vendors. Binance says that it adds a digital watermark to images it receives for KYC purposes, and the leaked images do not contain that watermark. Binance also said at the time that many of the images in question do not match the images they received from any customer.

I would also note that the alleged hacker was asking for over a million dollars from binance before releasing the images, and would not tell binance how they were able to allegedly steal the images from their systems.

The above fact pattern does not say with certainty that the images came from binance/one of their vendors. It also opens the possibility the "hacker" obtained the images via means unrelated to binance.

I don’t think it is an issue with the transaction logs, the issue is with having to actually access the private key. This is not trivial. Precautions need to be taken when accessing the private key, and this is probably not as simple as an engineer accessing the key and manually creating a transaction. Most likely, this will involve someone creating a script that gets the private key, calculates the address, checks the relevant blockchain, and creates a transaction, all without a human having access to the private key. This script, or scripts if multiple systems are involved, will need to go through testing to ensure that it is safe and does not leak any sensitive information.