You're right. I had not considered that.

Although you are still limited as to how many potential signers there are in a script (this is my understanding), and there is still the issue of having to change keys whenever an employee leaves, and changing keys with multi-sig means that a transaction is required, including the cost of said transaction.

Also, the employees need to be in a location specified by the employer in order to sign a transaction when using SSS with my setup. If a group of employees are fired for misconduct, as long as you can keep them outside of the room containing the computer used to sign transactions (and otherwise limit their access to said computer), your private keys are safe.

If you are using multi-sig without sharing keys, the company could just look at the blockchain, specifically the signature of the transaction to see who signed the transaction.

This thread is an example of certain people believing they are above the rules, can do whatever they want, and see above the rest of the community.

The thread in question hasn’t been updated in months (except for an attempt to exploit what certain people believed was a loophole). The purpose of the thread in question is not to protect forum members. The purpose is to upset forum members (aka troll).

If you do that, you must have a single manager and cannot have one of multiple managers sign off on a transaction.

You are also limited to one mandatory person and a second group of people. With SSS, you can have an arbitrary number of groups of people required to access the ultimate secret.

In my scenario, a company computer most be used to access the secret. Using a computer that is not the specific computer designed by the computer to calculate the secret will result in useless information. This allows the company to log any transactions that are signed, including which employees are approving the transaction.

This is not cryptographically provable, however the same can be said about other business records generated by companies. 

When your channel becomes unbalanced, you can reduce the fees on the unbalanced side so that you will receive transactions on the side that has a low balance.

You can also use dynamic pricing so that as one side gets low, the fee rate will change to encourage transactions to be routed to that side of the channel.

The OP appears to be interested in licensing his software. As such, it would not really be possible to have a publicly facing GitHub repo. If he had one, anyone could clone his project and use his software for free.

If I am not mistaken, to calculate the chances of x or more events over an interval when y events are expected, you can do one of two things:
If x is sufficiently small, you can plug (x - 1) and y into the Poisson formula, note the resulting probability, repeat with x being decreased by an additional 1, noting the result, and repeating until you note the result after x = 0. The sum of the probabilities subtracted from one is the resulting probability.

For larger x values, you can plug x and y into the Poisson formula, note the resulting probability, repeat with x being increased until x is 4 standard deviations away from y (for Poisson distributions, one standard deviation is the square root of the expected value, or y in my example), and the sum will be within 0.1% of the actual probability, or you can continue until 5 standard deviations from y, and the sum of the resulting probabilities will be within 0.00006% of the actual probability.

Multi-sig treats all signing keys equally. So the only way to implement forcing two different groups of people needing to sign is via a 2-of-2 multi-sig with all members of each group sharing the same key.

Most of the above can be automated, including the replacing of the secrets. It also allows for logging of who is signing off on transactions, which is not possible using a 2-of-2 multisig when keys are shared.

A college fund is for well, college. As such, the child should not have access to his or her college fund until he or she is old enough to attend college. At that point, he or she will hopefully learned how to sufficiently protect his or her money.

At a bank, in order to access cash, you must have one person from one set of employees, and another from another set of employees to open a vault/safe (some employees are assigned a small amount of cash they are personally responsible for so they can handle smaller transactions).

With SSS the setup could be as follows:
A 3-of-24 SSS unlocks 1 of a 2-of-2 SSS secret[1]
The 2-of-2 SSS secret named "[1]" above is used to unlock a second 2-of-2 SSS secret[2] that is the private key(or xprvkey).
The second secret needed to unlock [1] is stored on the computer kept in a secure location in which it is difficult for employees to access.
The second secret needed to unlock [2] can be derived from a 2-of-3 SSS used by a different group of people (such as the managers)
In the event an employee leaves the company, a new 2-of-3 SSS[3] is created with one being the output of a new 3-of-24 SSS, one being stored on the above described computer, and one being destroyed.
After [3] is created, the secret for [1] is destroyed on the above described computer.
Alternatively, [3] could be a 3-of-3 SSS in which two of the 3 secrets are stored on the above described computer, and one is derived from the new 3-of-24 SSS for the employees.

As long as the old secrets stored on the above described computer are destroyed, it would be impossible for former employees to use their secrets to get any meaningful information.

LN is far superior to a hypothetical coin with a one-minute block time that has the security of bitcoin. Provided there is an available route, a transaction will be completed nearly instantly. Further, a transaction completed on LN will have the security of 6+ confirmations as of the second it is completed.

If there is some reason why using LN is not feasible, there are ways for a business to make waiting potentially 3-5 minutes not a negative customer experience, while not giving up security. A business can do this by engineering their process such that the customer will send a payment with sufficient time before the business would be able to provide the product to the customer.

I ran some tests, and you're right. I stand corrected.

If you break any rule enough times, you will eventually get banned. I am not calling for a ban, I am just laying out the facts about what will happen next if current trends continue.

Suchmoon apparently doesn't like me warning nutildah to stop breaking the rules. I don't particularly like nutildah, but I am not trying to get him banned. So she accuses QS and PN7 of sockpuppeting for saying two very different things.

---

O/T:
You are not going to find any.

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.