大额转账（砸盘）CEX数据统计

[binggo]

| Order type   | Date                      | Tx ID                                    | Description                          | Asset value |
|--------------|---------------------------|------------------------------------------|--------------------------------------|-------------|
| Transfer     | 02:44:09 UTC 2019\-12\-19 | b7978c1070adfecfc2ce4771eecfccadecec70b9 |  blocktrades sent to binance\-bts\-1 | 920000      |
| Transfer     | 15:23:30 UTC 2019\-12\-19 | 4fc9e2f99011c0f805697167f1c77d8d75b1bb35 |  blocktrades sent to binance\-bts\-1 | 825000      |
| Transfer     | 18:36:57 UTC 2019\-12\-19 | 11d85ce5fbf6a7ccfd6791cb9e3ae83cfb7ee13c |  blocktrades sent to binance\-bts\-1 | 750000      |
| Transfer     | 00:50:42 UTC 2019\-12\-20 | 8d8892d6bc8b9bc70287dd8bdfc0f01cc6612438 |  blocktrades sent to binance\-bts\-1 | 400000      |
| Transfer     | 16:06:30 UTC 2019\-12\-24 | c858078ea9e90154d55b15efc04d5845e7840f09 |  blocktrades sent to binance\-bts\-1 | 2560\.84652 |
| Transfer     | 16:43:30 UTC 2019\-12\-27 | fafabf926a03fc275509eb0159733aa288a07fa9 |  blocktrades sent to binance\-bts\-1 | 500000      |
| Transfer     | 19:23:48 UTC 2019\-12\-27 | 131af1dc08d907a9019e9b61333e940c3b8c1878 |  blocktrades sent to binance\-bts\-1 | 750000      |
| Transfer     | 21:32:48 UTC 2019\-12\-27 | cb59deed646f3af1c3420cb2a52305a50b5a8934 |  blocktrades sent to binance\-bts\-1 | 600000      |
| Transfer     | 05:13:15 UTC 2019\-12\-29 | 91f13e822dcc6d6b07ee651c1bbc89213806d97c |  blocktrades sent to binance\-bts\-1 | 900000      |
| Transfer     | 10:21:33 UTC 2019\-12\-29 | dc02f2b4b77433d16da876ef64855808971f0e8f |  blocktrades sent to binance\-bts\-1 | 800000      |
| Transfer     | 19:07:45 UTC 2019\-12\-29 | 5f74457cd1fbe05a5fc8bfd3c3d512ce7d99e82a |  blocktrades sent to binance\-bts\-1 | 975000      |
| Transfer     | 01:18:27 UTC 2019\-12\-30 | 17e0dff79f3b203d9f33abe04e888d0e468ec606 |  blocktrades sent to binance\-bts\-1 | 950000      |
| Transfer     | 17:56:45 UTC 2019\-12\-30 | 4b37bd6914cce4b0af3ba4d629a250b0bc4888db |  blocktrades sent to binance\-bts\-1 | 900000      |
| Transfer     | 00:35:09 UTC 2019\-12\-31 | e0c2eecb9a47cf0b1aba79701d131f7025480c2c |  blocktrades sent to binance\-bts\-1 | 850000      |
| Transfer     | 08:12:09 UTC 2019\-12\-31 | 655091e03724df06b3866e1a61ac53c019be85f5 |  blocktrades sent to binance\-bts\-1 | 900000      |
| Transfer     | 22:55:00 UTC 2019\-12\-31 | 1aa34ac8e8fc79d6bb2094dc46b597227bee7b42 |  blocktrades sent to binance\-bts\-1 | 850000      |
| Transfer     | 02:59:15 UTC 2020\-01\-02 | 854f2288106eb7b043e11e2ee50a85c1b65b6ff5 |  blocktrades sent to binance\-bts\-1 | 925000      |
| Transfer     | 14:05:03 UTC 2020\-01\-02 | a6d75d30858fb5b5a41e7ee91bc5e0083b39f829 |  blocktrades sent to binance\-bts\-1 | 875000      |
| Transfer     | 17:48:09 UTC 2020\-01\-02 | b1cc2c8721c55c4fb5c39ba976f289adfc614d47 |  blocktrades sent to binance\-bts\-1 | 900000      |
| Transfer     | 17:54:21 UTC 2020\-01\-06 | 72c4b6b07fa286a2999b2d2981293dd08ba33cae |  blocktrades sent to binance\-bts\-1 | 500000      |
| Transfer     | 21:34:42 UTC 2020\-01\-06 | 93329b6b3e163a4221a53dd0db975344e872f0ca |  blocktrades sent to binance\-bts\-1 | 600000      |
| Transfer     | 23:34:39 UTC 2020\-01\-06 | 7b0aa8b7c5dc07bf53afba315f42f8b809c5f7b7 |  blocktrades sent to binance\-bts\-1 | 400000      |
| 16072560\.85 |

[binggo]

remember

这个账号没有交易记录。

额，这个是留记……

[binggo]

jabberw0cky


fericia-brick

[abit]

remember

这个账号没有交易记录。

[binggo]

ccedkbts
ccedk.marketing
abinia-rivard
tqsplit
wesley-waugaman

remember

[dannotestein]

Its like you're just ignoring the reason why I made this proposal to begin with. At the time, the core team had left the project, and there was doubt about what would happen in an emergency situation with no core team available to fix the problem. It was also intended to fix smaller bugs as well, but this was my chief concern. In the case of such an emergency, there could easily be no way for stakeholders to vote funds to fix the problem (e.g. the chain could be down). This proposal provided an insurance against such problems.

But, realistically speaking, if the current voters really don't want such insurance any more, I'm ok to return the funds. If you feel strongly on this issue, create an "opinion proposal" on whether the funds should be returned to the reserve pool. If it gets funded, I'm fine to return the funds and end this insurance policy.

You should return the funds instead of keeping it for yourself

I'm just going to assume you're not a native English speaker, and therefore not able to understand the phrases you're quoting from me, since your response makes no sense to me otherwise. I've already expressed clearly that I am not "keeping it for myself". If I was, I would have sold it off long ago when I sold off my own holdings after I decided BTS price was likely to drop due to current scheme to freeze the pricefeed to protect those shorting bitusd/bitcny into existance from taking their normal losses.

[ljk424]

Its like you're just ignoring the reason why I made this proposal to begin with. At the time, the core team had left the project, and there was doubt about what would happen in an emergency situation with no core team available to fix the problem. It was also intended to fix smaller bugs as well, but this was my chief concern. In the case of such an emergency, there could easily be no way for stakeholders to vote funds to fix the problem (e.g. the chain could be down). This proposal provided an insurance against such problems.

But, realistically speaking, if the current voters really don't want such insurance any more, I'm ok to return the funds. If you feel strongly on this issue, create an "opinion proposal" on whether the funds should be returned to the reserve pool. If it gets funded, I'm fine to return the funds and end this insurance policy.

You should return the funds instead of keeping it for yourself

[binggo]

ok...snowflake

[Thul3]

Its like you're just ignoring the reason why I made this proposal to begin with. At the time, the core team had left the project, and there was doubt about what would happen in an emergency situation with no core team available to fix the problem. It was also intended to fix smaller bugs as well, but this was my chief concern. In the case of such an emergency, there could easily be no way for stakeholders to vote funds to fix the problem (e.g. the chain could be down). This proposal provided an insurance against such problems.

But, realistically speaking, if the current voters really don't want such insurance any more, I'm ok to return the funds. If you feel strongly on this issue, create an "opinion proposal" on whether the funds should be returned to the reserve pool. If it gets funded, I'm fine to return the funds and end this insurance policy.

fair deal

[dannotestein]

Its like you're just ignoring the reason why I made this proposal to begin with. At the time, the core team had left the project, and there was doubt about what would happen in an emergency situation with no core team available to fix the problem. It was also intended to fix smaller bugs as well, but this was my chief concern. In the case of such an emergency, there could easily be no way for stakeholders to vote funds to fix the problem (e.g. the chain could be down). This proposal provided an insurance against such problems.

But, realistically speaking, if the current voters really don't want such insurance any more, I'm ok to return the funds. If you feel strongly on this issue, create an "opinion proposal" on whether the funds should be returned to the reserve pool. If it gets funded, I'm fine to return the funds and end this insurance policy.

[Thul3]

Ah, you edited your reply, so now your point is clearer to me.

If the proposal for the work had been for some specific task, I would agree with you that the funds should be returned. The point is, the proposal was a simple catch-all insurance policy against blockchain failure, not a specific task.

You clearly posted all unused funds will be refunded.

I think it can't be more clear.

You are playing a dishonest game and it should not surprise you it upsets some people like bingo.

By law you have no right to keep the funds and dictate your point of view.

Once again your own written condition for that contract

It was always my plan to refund unused pay from the worker

Changing it after receiving funds without consent is nothing which has any kind of legality

[dannotestein]

Ah, you edited your reply, so now your point is clearer to me.

If the proposal for the work had been for some specific task, I would agree with you that the funds should be returned. The point is, the proposal was a simple catch-all insurance policy against blockchain failure, not a specific task.

[Thul3]

But please point us at your worker which says you are allowed to hold unused funds for unlimited time for possible future maintenance should ever some be needed.

I think bitshares philosophy is very clear which was always that unused funds go back to reserve funds or are being pushed to another worker which community decides

[dannotestein]

Well, I hadn't interpreted his words this way, but you could be correct.

But if so, releasing funds only for "done work" is somewhat problematic, IMO. It will certainly be difficult to find workers who can afford to wait till after a job is done before they receive payment. In fact, I think that you won't find any such workers, unless they do it only for their own satisfaction, and only consider any reward for the work as an afterthought. In other words, I think you will get only "free" work contributions with such a payment model (with the possible exception for some, quick easy tasks).

Paying in parts for done work is no issue.

I'm not completely sure what you meant by the above statement. But my general impression is that you're brushing off as easy something that is actually very difficult: contracting with a software developer, getting good results for both parties, and not having payment problems. And the damages can result on both sides too, not just the contractee side: I've had cases where we didn't receive payment for work done, because the contractee could no longer afford to pay for the work. Costs build up quickly on both sides of such arrangements.

In traditional hiring for software work, conflicts often arise between the developers and the contractee because of misunderstandings and incorrect expectations on both sides and external forces such as economic problems for either  party. Blockchain-based payment is going to be no different and is going to suffer the same kinds of problems.

[Thul3]

Well, I hadn't interpreted his words this way, but you could be correct.

But if so, releasing funds only for "done work" is somewhat problematic, IMO. It will certainly be difficult to find workers who can afford to wait till after a job is done before they receive payment. In fact, I think that you won't find any such workers, unless they do it only for their own satisfaction, and only consider any reward for the work as an afterthought. In other words, I think you will get only "free" work contributions with such a payment model (with the possible exception for some, quick easy tasks).

Paying in parts for done work is no issue.

But please point us at your worker which says you are allowed to hold unused funds for unlimited time for possible future maintenance should ever some be needed.

I think bitshares philosophy is very clear which was always that unused funds go back to reserve funds or are being pushed to another worker which community decides