deso-protocol / core Goto Github PK

Not sure where else to report this.

All third party nodes are down, and transaction-info on the main node is throwing 502s.

I am bitclout.com/u/smartalec

After logging out seed phrases stay in cookies.
They should be removed.
Also check my mail I sent u guys about me getting hacked.
I have lost money, at least protect others!
bitclout lover

If you use Link To Post on one node the full URL of that node is used. When the post appears on another node the original node URL is shown. This is highly confusing for Users, forcing them to log in to a further node to see the post.

The Link To Post feature needs to be node agnostic so that regardless of where it's originally posted it can be accessed on the same node.

Here is an example of one post with three different URLs

https://nachoaverage.com/posts/8822f3ce68544d58cae46becea81028dec88cc02cc859ab0f79318eb04e629d4?feedTab=Following&tab=posts

https://tijn.club/posts/8822f3ce68544d58cae46becea81028dec88cc02cc859ab0f79318eb04e629d4?feedTab=Following&tab=posts

https://members.giftclout.com/posts/8822f3ce68544d58cae46becea81028dec88cc02cc859ab0f79318eb04e629d4?feedTab=Following&tab=posts

running with the following params:

./backend run \
  --glog-v=2 \
  --glog-vmodule="*bitcoin_manager*=2,*balance*=2,*view*=2,*frontend*=2,*peer*=0,*addr*=0,*network*=0,*utils*=0,*connection*=0,*main*=0,*server*=2,*mempool*=2,*miner*=2,*blockchain*=2" \
  --num-mining-threads=0  \
  --max-block-templates-cache=0 \
  --txindex=true \
  --miner-public-keys=BC1YLg4sz2dEa81Zhw3ktsrEMKRz5J9ucxAczoZrM3zZRPgMoCGJM7r \
  --starter-bitclout-seed='REDACTED' \
  --data-dir=/mnt/d/data_dirs/n0_1  \
  --block-cypher-api-key=REDACTED \
  --min-satoshis-for-profile=0 \
  --postgres-uri="postgres://REDACTED@REDACTED/postgres" \
  --connect-ips="35.232.92.5:17000" \

E0823 10:49:25.105978 1883 blockchain.go:1218] MarkBlockInvalid: Block height: 46923, Block hash: 0000000000005c3002b1182c37678c887f08cfb6017eb45fae09d83ffcf7e608, Error: ConnectBlock: : ConnectTransaction: : RuleErrorInsufficientFundsForNFTBid
E0823 10:49:25.106013 1883 blockchain.go:1219] MarkBlockInvalid: Printing stack trace so error is easy to find:
E0823 10:49:25.106056 1883 blockchain.go:1220] goroutine 40 [running]:
runtime/debug.Stack(0x0, 0x0, 0x0)
/usr/local/go/src/runtime/debug/stack.go:24 +0xa5
github.com/bitclout/core/lib.(*Blockchain).MarkBlockInvalid(0xc0586b4000, 0xc06a04b400, 0xc18a60f900, 0x49)
/home/alecg/src/discoverclout/core/lib/blockchain.go:1220 +0x205
github.com/bitclout/core/lib.(*Blockchain).ProcessBlock(0xc0586b4000, 0xc187678e10, 0xc1ec663d00, 0x0, 0x0, 0x0)
/home/alecg/src/discoverclout/core/lib/blockchain.go:1935 +0x270b
github.com/bitclout/core/lib.(*Server)._handleBlock(0xc0586a8000, 0xc0d5598900, 0xc187678e10)
/home/alecg/src/discoverclout/core/lib/server.go:1178 +0x6a5
github.com/bitclout/core/lib.(*Server)._handlePeerMessages(0xc0586a8000, 0xc1882821c0)
/home/alecg/src/discoverclout/core/lib/server.go:1481 +0x291
github.com/bitclout/core/lib.(*Server).messageHandler(0xc0586a8000)
/home/alecg/src/discoverclout/core/lib/server.go:1521 +0x2d4
created by github.com/bitclout/core/lib.(*Server).Start
/home/alecg/src/discoverclout/core/lib/server.go:1697 +0xcf
E0823 10:49:25.106131 1883 blockchain.go:1227] MarkBlockInvalid: Not marking blocks invalid for now because it makes debugging easier
E0823 10:49:25.106166 1883 server.go:1126] Server._handleBlock: Encountered an error processing block <Header: < 46923, 0000000000005c3002b1182c37678c887f08cfb6017eb45fae09d83ffcf7e608, 1 >, Signer Key: BC1YLh768bVj2R3QpSiduxcvn7ipxF3L3XHsabZYtCGtsinUnNrZvNN>. Disconnecting from peer [ Remote Address: 35.232.92.5:17000 PeerID=20 ]: Error while processing block: : ConnectBlock: : ConnectTransaction: : RuleErrorInsufficientFundsForNFTBid

Currently, Bitclout has very few users. But after the marketing efforts, millions of users will join us in a short time. And that will bring some problems. One of them is the possibility of hacking accounts. In this case, users should be able to protect their own account. my suggestions;

• Account migration feature just like reserve accounts
• change seed words
• one more layer of security can be added

Hi,

My old twitter handle @paddypisa has been added to Bitclout's website without my consent:
https://bitclout.com/u/paddypisa

I would like it to be removed please.

I know this is possible as another account was removed via:
https://www.coindesk.com/bitclouts-alleged-leader-hit-with-cease-and-desist-by-prominent-crypto-law-firm

Gradually, corporate companies started to open Bitclout accounts. In these companies, the personnel responsible for social media manage the account. This situation creates a problem. If the employee is malicious, it can damage the account. It can steal all the funds in the account. I think there should be a multi-user feature. And the authority of these accounts should be restricted. (authority to manage the fund, send diamonds, send messages, edit bio)

Currently, the vast majority of users who use Bitclout.com speak English. But in the coming months, millions of people who don't speak English will start hearing about Bitclout. But most people will stop using the site because of the Language barrier. I have suggestions for this problem.

• Bitclout Node setup should be very simple. (Youtube support videos should increase: how do I set up a bitclout node? How do I change the node language?)
• Must be a local stream (country and local language)-The simplest solution for this local stream is:

---Users should be able to choose the country they live in and the language they speak when becoming a member. In this way, the posts of these users can be sent to the local stream very easily.

@maebeam @lazynina @diamondhands0

As BitClout development becomes increasingly community-driven, I believe it is time for the creation of a repository to draft and track BitClout Improvement Proposals (abbreviated BCIPs).

Overall, the BitClout community is understanding of the need, early on, for the core development team to have very flexible control over the protocol. However, more and more of us in the development community are building real-world businesses on top of the BitClout protocol, and I believe it would be a benefit to everyone if such a BCIP system existed.

This proposal calls for the creation of a repo at github.com/bitclout/bcips, similar to the equivalent repo within Bitcoin, github.com/bitcoin/bips.

Individuals drafting proposals would simply fork the bitclout/bcips repo, create a folder and README for their proposal (bcip-001, bcip-002, etc), and submit a pull request back to the bitclout/bcips repo. It would be up to the core development team to edit and merge these proposals as they see fit.

These proposals should be limited in scope to the core BitClout protocol, not the backend, frontend, or any other project.

Thank you for your consideration.

Currently only the holders of 5 keys may create new blocks on the BitClout chain, as listed in the "trusted-block-producer-public-keys" config value.

It is not clear how well distributed these keys are. At best, only 5 entities need to be compromised to have full veto power over what transactions are included in the chain. At worst, the five keys are under a central entity's control, and only one entity needs to compromised. This severely undermines BitClout's claim to be a decentralized platform. With permission based block acceptance, BitClout is more akin to a publisher than a decentralized platform.

Recommendation: Trusted Block Producer setup should be replaced as soon as possible.

Currently, there is no way to find historical BitClout prices, especially pre-exchange listing.

This is important information for several basic metrics (e.g., calculating USD ROI).

Can you please share the function (and BitCoin peg) that can help the dev community identify historical BitClout prices?

I do realize this might not be an "issue" in the strictest sense. However, received guidance to create an issue here for more information on this.

Thank you so much.

Hi,
I've tried to update our node to start supporting NFTs, using the "stable" docker images for backend and frontend (see the docker-compose attached), it's still now showing in the menu.

From the discussion on the discord, recommendation is to wipe out database and resync again. That seems to be odd considering it should be new feature not related to previous Transactions / Blokcs, plus loosing our global feed is not optimal either.

Any suggesting how to progress and get the NFTs available on our node without wiping database?

Thanks.

I've noticed the following crash when shutting down:

github.com/dgraph-io/badger/v3.(*memTable).IncrRef(0x0)
        /home/gfodor/go/pkg/mod/github.com/dgraph-io/badger/[email protected]/memtable.go:231 +0x19
github.com/dgraph-io/badger/v3.(*DB).getMemTables(0xc0a189a480)
        /home/gfodor/go/pkg/mod/github.com/dgraph-io/badger/[email protected]/db.go:696 +0x1cc
github.com/dgraph-io/badger/v3.(*DB).get(0xc0a189a480, {0xc2bcc40120, 0x2d, 0x2d})
        /home/gfodor/go/pkg/mod/github.com/dgraph-io/badger/[email protected]/db.go:730 +0x165
github.com/dgraph-io/badger/v3.(*Txn).Get(0xc2bcc4e000, {0xc2bcc400f0, 0x25, 0x30})
        /home/gfodor/go/pkg/mod/github.com/dgraph-io/badger/[email protected]/txn.go:478 +0x4da
github.com/bitclout/core/lib.DbGetUtxoEntryForUtxoKeyWithTxn(0xc2bcc4e000, 0xc2bcc400c0)
        /home/gfodor/1729/bitclout/core/lib/db_utils.go:1991 +0xda
github.com/bitclout/core/lib.DbGetUtxoEntryForUtxoKey.func1(0xc2bcc4e000)
        /home/gfodor/1729/bitclout/core/lib/db_utils.go:2016 +0x45
github.com/dgraph-io/badger/v3.(*DB).View(0xc0a189a480, 0xc00b8b0b00)
        /home/gfodor/go/pkg/mod/github.com/dgraph-io/badger/[email protected]/txn.go:806 +0x162
github.com/bitclout/core/lib.DbGetUtxoEntryForUtxoKey(0xc0a189a480, 0xc2bcc400c0)
        /home/gfodor/1729/bitclout/core/lib/db_utils.go:2015 +0x7d
github.com/bitclout/core/lib.(*UtxoView).GetUtxoEntryForUtxoKey(0xc00fa40340, 0xc2bcc400c0)
        /home/gfodor/1729/bitclout/core/lib/block_view.go:1270 +0xd0
github.com/bitclout/core/lib.(*BitCloutMempool).tryAcceptTransaction(0xc00d8acf20, 0xc1f5a4e5b0, 0x0, 0x1, 0x1)
        /home/gfodor/1729/bitclout/core/lib/mempool.go:1229 +0x628
github.com/bitclout/core/lib.(*BitCloutMempool).processTransaction(0xc00d8acf20, 0xc1f5a4e5b0, 0x1, 0x0, 0x1, 0x1)
        /home/gfodor/1729/bitclout/core/lib/mempool.go:1942 +0x165
github.com/bitclout/core/lib.(*BitCloutMempool).ProcessTransaction(0xc00d8acf20, 0xc1f5a4e5b0, 0x1, 0x0, 0x1, 0x1)
        /home/gfodor/1729/bitclout/core/lib/mempool.go:1992 +0x156
github.com/bitclout/core/lib.(*Server).ProcessSingleTxnWithChainLock(0xc0023fd140, 0xc00adc4000, 0xc1f5a4e5b0)
        /home/gfodor/1729/bitclout/core/lib/server.go:1338 +0x150
github.com/bitclout/core/lib.(*Server)._processTransactions(0xc0023fd140, 0xc00adc4000, 0xc0c7c0cd98)
        /home/gfodor/1729/bitclout/core/lib/server.go:1358 +0x1e6
github.com/bitclout/core/lib.(*Peer).HandleTransactionBundleMessage(0xc00adc4000, 0xc0c7c0cd98)
        /home/gfodor/1729/bitclout/core/lib/peer.go:343 +0x4f2
github.com/bitclout/core/lib.(*Peer).StartBitCloutMessageProcessor(0xc00adc4000)
        /home/gfodor/1729/bitclout/core/lib/peer.go:556 +0x57a
created by github.com/bitclout/core/lib.(*Peer).Start
        /home/gfodor/1729/bitclout/core/lib/peer.go:1141 +0x213

I believe this is happening because the peer message processor is not being shut down, and if a transaction comes in during the end of shutdown after the database is closed this crash occurs. However after a brief investigation I'm not sure if/where this message processor is supposed to be gracefully terminated - the Stop() function in the connection manager just closes the listeners.

After full sync of blocks, postgresql node starts reporting this error:

E0824 21:14:44.360203       1 txindex.go:170] tryUpdateTxindex: Problem running update: Update: Problem fetching attach block with hash 00000016c72096930787c7e7de4ad069198c2137feddeecbe6a9ec4d61cb6870: Key not found
I0824 21:14:45.380051       1 txindex.go:270] Update: Updating txindex tip (height: 0, hash: 5567c45b7b83b604f9ff5cb5e88dfc9ad7d5a1dd5818dd19e6d02466f47cbd62) to block tip (height: 54444, hash: 00000000000040ad0b7a1c87854db70e970c06475be2be504879a5fc631f04ed)

After a few minutes of this (about 250 errors) - panic occurred. Not sure if related.

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xb416a7]

goroutine 50 [running]:
github.com/bitclout/core/lib.(*UtxoView).CopyUtxoView(0xc148fa1a40, 0xc00010b140, 0xc14b537eb0, 0x414fc5)
        /bitclout/src/core/lib/block_view.go:1013 +0xd07
github.com/bitclout/core/lib.(*BitCloutMempool).regenerateReadOnlyView(0xc000524000, 0x127cd00, 0xc000524020)
        /bitclout/src/core/lib/mempool.go:1926 +0x47
github.com/bitclout/core/lib.(*BitCloutMempool).RegenerateReadOnlyView(0xc000524000, 0x0, 0x0)
        /bitclout/src/core/lib/mempool.go:1953 +0xa8
github.com/bitclout/core/lib.(*BitCloutMempool).StartReadOnlyUtxoViewRegenerator.func1(0xc000524000)
        /bitclout/src/core/lib/mempool.go:1909 +0x148
created by github.com/bitclout/core/lib.(*BitCloutMempool).StartReadOnlyUtxoViewRegenerator
        /bitclout/src/core/lib/mempool.go:1894 +0xa5

Update to latest backend from 7 hours ago (58caa9a) does not resolve the issue.

Source of issue:
https://github.com/bitclout/core/blob/c2e844140e5b9c1ad67a4a863a17bc1acf622ac0/lib/txindex.go#L370

Hash 00000016c72096930787c7e7de4ad069198c2137feddeecbe6a9ec4d61cb6870 is in the database

Not sure when this started but seeing a lot of errors Diamond level 0 does not exist in map from the line below on multiple nodes

https://github.com/bitclout/core/blob/51c2ab3548fe005188f2e8b3747e2d73e3e99dff/lib/blockchain.go#L3103

845147 errors

first few:

E0817 14:42:06.271718       1 blockchain.go:3103] GetBitCloutNanosForDiamondLevelAtBlockHeight: Diamond level 0 does not exist in map map[1:50000 2:500000 3:5000000 4:50000000 5:500000000 6:5000000000 7:50000000000 8:500000000000]; this should never happen
E0817 14:42:06.272369       1 blockchain.go:3103] GetBitCloutNanosForDiamondLevelAtBlockHeight: Diamond level 0 does not exist in map map[1:50000 2:500000 3:5000000 4:50000000 5:500000000 6:5000000000 7:50000000000 8:500000000000]; this should never happen

Last few

E0818 13:18:30.950004       1 blockchain.go:3103] GetBitCloutNanosForDiamondLevelAtBlockHeight: Diamond level 0 does not exist in map map[1:50000 2:500000 3:5000000 4:50000000 5:500000000 6:5000000000 7:50000000000 8:500000000000]; this should never happen
E0818 13:18:30.950590       1 blockchain.go:3103] GetBitCloutNanosForDiamondLevelAtBlockHeight: Diamond level 0 does not exist in map map[1:50000 2:500000 3:5000000 4:50000000 5:500000000 6:5000000000 7:50000000000 8:500000000000]; this should never happen

Hello,

Do remove profile and photo shown at https://bitclout.com/u/ecwiti

Kind regards,
James

It seems that latest updates for the new transaction types:

NFT_TRANSFER
ACCEPT_NFT_TRANSFER
BURN_NFT

Did not include the tables for Postgres in the migrations This seems to cause syncing to fail from block 61015 no transactions added and duplication transaction errors occur. Might have a relation with issue 115

This issue is for the SUBMIT_POST transaction type.

If a username has an underscore in it (e.g., Clout_Cast) the mentioned public key under the Affected Public Key object inaccurately puts the Public Key of Clout account.

Potentially the first part of the username (before the underscore) is being taken to look up the Public Key to put it under the affected public key.

Please see the examples below:

Tx id 3JuEU8PsztU6naxDWoYCkD2mmkKBV6SNrtHqfSLHyFSeNkYz1nGgBM

raw

6bf53c5c4ad2400371550e205096f57fb4ac7335f0928380003be419eca2d7a4e901eb9c1fded3ba9ff15c3308d3b464c3ddd160ae9b93879aeb2670306a93e459d50098621ac3197c67433d0e15386dbec056ec96ad15d0115b31dcc63e12e9860b7a00b47bf4cb20b2b0a27af44b15887bbf4ba91b49e1c4b317a9052c010866215c95001185ae0dd31eb85b608487b5e272e118b6d7e40c6c0db08b7510326a37abbcd6000aa14bc3713819a6bad64026dc3885a09884816227761f8fa27cf579e2e604050044be58138b884f6570150a6b1f9cde52353c01a844de1058d220251e3c11491b01e7e6c232fde304fd2c9c692df4fe961e5d2c294757122b2f7598ac1814fed75f00481dd19c26f4088c41e30104d5636e075e4d8148b9db3d895c582b274035f9830007055fe960f2847d3ce9d853ed9bea0dbbcbc7f3ef91751f400202aeabd99f2600421cb05f194c912dc07c30038bbb7c3439234f96c89c6a9357255e1e223779f600c625bbe60903eb850de1e466de922a11bc360d1ae3ad5fd685a8b5b7460a27b0001a2e89ea1da24c8183666fadd3b2c0500507ba4a3f3ce5ae7a6b20dd1d1312a00067d8681623212902c7513a681e6d5d31736a79ff5b0d283fa978ef9e21726f5c01a14b90092f241678cb5e5b567b101492e1ac5784171be84efcb7a43f7255876f008993182bff331e71750599cba8638f7352c2e73a69de5d45f93a5d35e02d785100bfe83189836430196faf00f90426d7238db5dd2f091c03488814dd8ee4b5391c01eb8a10b8ef60eb3c8cdb63807a6323b8d85036e923deae04b0aac5245c5e16d900ca21a36f052e83ec3a9a77c1c95f001dde0b31f34a3652dfd151c0547aa47f8b01521b74db33f83e44ab74f2442a1da16a3bb6caca7d7eacdc4b1ce0280e1e1788018ed4c3cf09d7a3f7eae3a8c56e229c8d9fee29e74a537027eba1ea27b183082600224a350a66503efec0011ece4ff65c68e4491a4a3664bddd7d7b8082b43a2b7801d5615df6bcc9b390a85aaab68853a9e6292382f01bd8b7c1c29542fa79a2ec1a0066bbdbde19dd53989786b9fcdd21c54a48a607aab601e4513441d99a480f2f5d0054a26f32c2e01e51463aa773c2e53107d859827be596ae747217a9fcac95956200b98bc0065323165c4490f6341671026d33f31ff77c373730ab18c17716af96c90044be58138b884f6570150a6b1f9cde52353c01a844de1058d220251e3c11491b00a5f69470098301eaaee82a9d203466a87b9a29f7d5b75a7d91acb5e513de100800e3030be731e606a7646ef0bb4896332008cd144c56d2eed832afd79bf7ecbd5c01e15c5a07a28673ea95eae135527ce30f38b2afad85dcc00a6e46c6123e75eb3f00146b689ace72b7886554835d0b1e4e7f6d95f30b11e4c25fca339b24497be25e001b69cae32f84c748ab48e5455caf0e6497c61136f0a95a2623d322d98cfc60af00fdd753e104c3cc38892b40dd049e2d19d546ff9a3692a44072e97359be43cab200f1f6f96032058f77e750c2c06987e4862f21c2207997276d2342605bf3382302002aa02aeb5fefe26e888e43da8e78f3d8135a5ec0f2e73b65f54d338f2d92d96300529db4c1f2d491da12b477944ee2d80be6133a35b251668e48653194938f874201eceb970d86bc7fdf1047461ad43d811de99b34ccfe93aa6e1f70c49d6309d3f401a2c95287e576d447a179b8e6aa946574b4327d6e1f420116ffcb96124c715643016ace583165be27e0e37306c24598ee276db4a8e47c649400adcf3692d51c4cd901695e848f5ac366cd2975d653238d9fd21f6e7b4e164df629723f554919666c7c012aa02aeb5fefe26e888e43da8e78f3d8135a5ec0f2e73b65f54d338f2d92d96301eb9c1fded3ba9ff15c3308d3b464c3ddd160ae9b93879aeb2670306a93e459d5017ae94c880d581a3765dc6442419b62533214c35782631314748c49f2f9232af901c92c4bfa76f4daae8f2fd0e0413d3354d62994b241e660b810c5be21ade26fc4011b69cae32f84c748ab48e5455caf0e6497c61136f0a95a2623d322d98cfc60af0188603c989864eb10fd1e73df58adfc28af15736ca9dad3c5658b0cf31b540412012791c941bfeed98b24c13711b3c08d9abc9125ef91bd051716789dda5296d1be00a2c95287e576d447a179b8e6aa946574b4327d6e1f420116ffcb96124c715643004cde6f436c7c697f93d6637fa9b4748eb6a36dff3ca6f21a6928c02502dc3f6401421cb05f194c912dc07c30038bbb7c3439234f96c89c6a9357255e1e223779f601ce5e0a97319d2bf310830058b67a85654bc173971b01224dd7751d68c0f4bbb801695e848f5ac366cd2975d653238d9fd21f6e7b4e164df629723f554919666c7c00892fcac995d1ae2146662b9390bbee7d8cfa2c555cf580ecc82b44caeaa858fd001a2e89ea1da24c8183666fadd3b2c0500507ba4a3f3ce5ae7a6b20dd1d1312a00166df4c2d1642dadddea01b23b45186a87b0548174091991111e6fd20d8a24dcf019445497659c4aba0126651aa5af775e79efa97630695769534d5e85bc7a4fd5000ab747581774c2c8988ad8e470905c29755fef3b30a7667741c1368c669fd8aa30085d5bdf3eea14110f2fc6dc3a2aeb826d47881e09d82d1ab30947d99b6bfc19e007ae94c880d581a3765dc6442419b62533214c35782631314748c49f2f9232af900c33c7354badc9409f2bfe0635067a3107978a6105e978f8ccec0a1b32ceed72b00521b74db33f83e44ab74f2442a1da16a3bb6caca7d7eacdc4b1ce0280e1e178800ecc1ad5bfdb62ee74c9c654975aecce3484bb3d12900c14738f63d41710868f9007935fdba811e25b87128d709321e40fb5682b53d0df41724dc6d2e8cb2e6311e01aac8de062f7dba7e3abbd24c6f4bec09b93031bdbc51c820899e7cb72e3e1db501d5615df6bcc9b390a85aaab68853a9e6292382f01bd8b7c1c29542fa79a2ec1a01e8c74dafbf208ab02eacca508479c9a6867403face57fd2dbfacf0016dd6f4ef018a28a6b4ff93170699a15880674c45b2a3ada0da4d4d5c5b5bab941620c292de01fb894c27e4cf8734bf5a813ecf801c0ac85a542153f02a32ab31da4f5805a5d101ab747581774c2c8988ad8e470905c29755fef3b30a7667741c1368c669fd8aa301ecc1ad5bfdb62ee74c9c654975aecce3484bb3d12900c14738f63d41710868f9010c264b89fb1a439d6dbdae475d85eb9cf536fb0e0faefdd9c7b376049f4b0c9301146b689ace72b7886554835d0b1e4e7f6d95f30b11e4c25fca339b24497be25e01eb8a10b8ef60eb3c8cdb63807a6323b8d85036e923deae04b0aac5245c5e16d901f1f6f96032058f77e750c2c06987e4862f21c2207997276d2342605bf3382302015b8984796c0b47a9d69b6f7a5567d6d5db7b528129ce9c606a72c17c81fe214b00299dd50435ed4fd65fa60add37014b66f4fdbb857678cbd53de3e40ebb1bdbe80118120a1bf9f15fef32aff9076164ae89af3d8fec6bd9b77bfb4fe24e0b0a070501b98bc0065323165c4490f6341671026d33f31ff77c373730ab18c17716af96c9012791c941bfeed98b24c13711b3c08d9abc9125ef91bd051716789dda5296d1be015b8984796c0b47a9d69b6f7a5567d6d5db7b528129ce9c606a72c17c81fe214b01c92c4bfa76f4daae8f2fd0e0413d3354d62994b241e660b810c5be21ade26fc400224a350a66503efec0011ece4ff65c68e4491a4a3664bddd7d7b8082b43a2b780085d5bdf3eea14110f2fc6dc3a2aeb826d47881e09d82d1ab30947d99b6bfc19e01e4e94519483dc2242f9e35c785fd3f7d7dadcc714318893aa8eef1a268b40848017fd39b04b40a080787766e16fa00ed796bca6aea16b226c9ef00cd65ccdfb18601ce5e0a97319d2bf310830058b67a85654bc173971b01224dd7751d68c0f4bbb80066df4c2d1642dadddea01b23b45186a87b0548174091991111e6fd20d8a24dcf00bfe83189836430196faf00f90426d7238db5dd2f091c03488814dd8ee4b5391c0005b0db45fd244996aea2d05e039b2b1891307ecd3f71da03f0d38f850d970eab01e7e6c232fde304fd2c9c692df4fe961e5d2c294757122b2f7598ac1814fed75f01ac2b77d6308717c416a73904cf74e9c9f1a6f7095b8afcbdc2ac5e7a91c0091400529db4c1f2d491da12b477944ee2d80be6133a35b251668e48653194938f874200c33c7354badc9409f2bfe0635067a3107978a6105e978f8ccec0a1b32ceed72b01eceb970d86bc7fdf1047461ad43d811de99b34ccfe93aa6e1f70c49d6309d3f4000b0867d4a197ce7f14a3e819ae976e43da4130472c62b55638524dd85be3c95f017935fdba811e25b87128d709321e40fb5682b53d0df41724dc6d2e8cb2e6311e00f53c5c4ad2400371550e205096f57fb4ac7335f0928380003be419eca2d7a4e900cd81472d9fbee7b93d5f6797eebb7621aaefa2447529fc5b388759916a79c9ab00ca21a36f052e83ec3a9a77c1c95f001dde0b31f34a3652dfd151c0547aa47f8b00e8c74dafbf208ab02eacca508479c9a6867403face57fd2dbfacf0016dd6f4ef0098621ac3197c67433d0e15386dbec056ec96ad15d0115b31dcc63e12e9860b7a01e4e6bff25a40cb10f028c62b0062ab5eba998761d950e1b7bb04090e31a8382d00e38a7300a723ac71154cfb1c77785d1c4f17e5dc5ff4ba592822af442b1f2b0401e3030be731e606a7646ef0bb4896332008cd144c56d2eed832afd79bf7ecbd5c0040ea254e14f124ddce482f5eb9fb11b1e467b344943880b829c5731fd61c6f97003512c5abd5826a8924f12b754e0cf23f1794b14fb6327856dcb40b7d393d108900acf8a9441ef466823e39de130a8ba8f0930acdc2ebdec5fc0f06e1f66974a8980002020e8fe7a8b27cd5eaf90727fbc283ef5f149d134b11348b3696d483e7c59eba3980ffcff60c036d724caf194e80ac30d5beb48c749400e890d9b1a97b41f9d20656f51a3eff8c87a08844020021036d724caf194e80ac30d5beb48c749400e890d9b1a97b41f9d20656f51a3eff8c00473045022100c967a8fbf760d3e3afb7d764b81e6afedfdfd7d37c17b87844c2a69ad51e5ab602202e70751c82ba2eb778d3d7f4e1420c2cab220a225fcda422cf16cc3405e6f011

The tx persists in mempool on ALL nodes, excluding core nodes.

I want to know the reason for it? Due to this issue, UTXOs on noncore team nodes are different from core team nodes. The TX looks legit, and I wonder why the primary core nodes did not accept it.

Any clarification for this issue? Thx. P.S. Met this issue 2nd time already.

Hey there, we have setup our node, setup GCP_BUCKET_NAME and GCP_CREDENTIALS_PATH, we're able to upload images to the GCP_BUCKET without issue,

So far so good, buut
I had to update the Caddy file to be able to display images from our bucket to mitigate CSP blocking on our node (adding our bucket address to the img-src - see the Caddyfile attached) . After that, we can display images on our own node, but other nodes (starting with bitclout.com) are not loading images with error "(blocked:csp)". Is there a way how to enable images from our gcp bucket or what is general approach to this when you host your own node and bucket storage?

Post example:
Our, working, node:
https://node.flickapp.com/posts/8b2877038285a0e2ed59caa3228305f9e91ae0aee68a34ca2d2ac6a82a3530b3

Bitclout node, same post is not displaying image with - (blocked:csp)
https://bitclout.com/posts/8b2877038285a0e2ed59caa3228305f9e91ae0aee68a34ca2d2ac6a82a3530b3

Any advice what we can setup to avoid image breakdown on other nodes?

Caddyfile.dev.txt

Thanks for any advice.

Images load at 1000px wide however the css for .modal-dialog is set to a max-width of 500px at the min-width:576px. Updating this to 50% would make the images ideal for non-mobile devices.

TransactionIDBase58Check: 3JuETNfkcDLas17M1ujVB21bFNhtCeSC9TZSQNDiAYHdHXyNKdi9d9
returns BlockHashHex: 53c7878afa8e50a667934eeb0f5c289c675d409ef0d2dc6e1235af3032a36bb3

This block hash hex doesn't exist when queried via block api. Tried on multiple nodes, including bitclout.com. Submitting as I'm not able to trace myself if this is normal, or it's a sign of some hidden problem?

{
"TransactionIDBase58Check": "3JuETNfkcDLas17M1ujVB21bFNhtCeSC9TZSQNDiAYHdHXyNKdi9d9",
"PublicKeyBase58Check":"",
"IDsOnly":false
}
{
"Error": "",
"Transactions": [ {
"TransactionIDBase58Check": "3JuETNfkcDLas17M1ujVB21bFNhtCeSC9TZSQNDiAYHdHXyNKdi9d9",
"RawTransactionHex": "1ebe8180bfa2f49b591c145e14baa85cb3d8107247dfd9d093c7f154694c9b22590097d2d38fdf19396fb1a876bcdba1a6fe6f8a47a4a5875b6a85321f29934a5ec40057dae3d3f06f84d2774471f1f25f881e4e8970259e53d117d95fa60902682c8800472ee469ccee6c866c002c67e638e13ed56e9af121483b84cc6ff1bea128af7800ee3aca0fd9f9890b09d28983936bfe6f62341b0ffe860a9e5f46cd5b29a9267a0092fbbba5632c6d0f9a074a6f897b0e74376643c89773b855fb5062227089c7a7006209fd528ca250df4105f39204233361f7dde54466f2889e775e9bc24c884f8300c0b8a9eaba75ad326c817fef7b75b40ec305421cf971a556b98d185abd6c751b00fdd7c226530ce29057bd46430e52caff855bd315f617b5d288779475aa53882000c0a7e8add6b90046ac2d5f0840acde7e4aa9d44fe419bb755c89ad087f3edf280003c62da553cde4610dbefd5326590404fb8ec74e8bb80b122ee3b03acc27ef94015d34f94d235b2f74d11ba020502592c66f33206e307366f475c2af660ed4322f009a56d113846e9c57470352019711bb1aab505c7bafaf623ab01642adc99af49300ccd5c02208c5e49cbe9b061bf69401d4729510b4311ce5de3e5763bcf335b5cd006b61c11d034156ce91d65fc89e68d9e4d06631ff25626125a41061549d4ed10500c800cec11a0e362fa5f48e7f1a33341e6209309ba0ac87ccdb71ade1b5b73c85006937de8ea9954641a42b4294a452fbf8b8ef316831216e808d6ec58f2c2ecbb30018feb978c636c1745370dd03134cc64c31fe96d3a8edc310e4423d02eccc31990026dbdf1dccb2f8d6cf1ddd3580ed5bded43868711fb4c709a400042e574d4796001428a3c0b2e6cd034b701429868e5369d01ec762bfe4b7b22453e55bc56e38c000c3f83ae3a3f605bafd5365dc0561d906d5d1164a7c02ad679c30fe20e3e6f397001f0fa4e81649c152c0f4816fccff6d1b031381abb5cc4d2a8b368760bb7d66db00a376c401f1d9ce4034660029471e58de19c81abde88825cc24aa385175e382b400848d50a2603638a8fcecf20127668c55119f15324e2fd86a6f5170779f4fd058006c2506fbfe78a4b194e6994e80e2d7597e317f9ca31e498246e68515cff468af0023d9070a0fbae99879970681ae99702b2c5a68d5015dec3f57d85a1d90156a49002547a295f9a22cd76429f4b18f4d02d0f08bfbe4fb5d7a57563d21dc793a40ec00b5e22d960f8db881003d36c1b739a0a7a9fae8ada960f3e37ece88e09804e24b006a3af6d13843af263187e227464cb271c62d0ae88c6f3114d0e4087e12bd43e70038dabc5855eca3c56e16e4ac140051daebdbc9b0376a2dd70f4b6bc804c77d460002030633bc2abd496dea2eb42d1076a190df2e524b5dadbaa438679ae9b6254af7aa90b5dad2f601032db0d6fe16086d8650faa600d3dc82b5ec284bdcfcd54a23361596fe3f663be9bfd9859a0b020021032db0d6fe16086d8650faa600d3dc82b5ec284bdcfcd54a23361596fe3f663be900473045022100ca8c0252964d81b89167a633d9c2852034107d7fa2f5e6f81c97b8a3055f542f0220182408d2c43e29264dcb994661a6927106ae010677b3017ae0f35b2c3ea49544",
"Inputs": [
{
"TransactionIDBase58Check": "3JuEUBfwHgxQAhjMd4szXYHN8fnPuvsnbNCBeeLhic1CnwRpdxoJxW",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuETtdrAxyEuAfA9DBVQmpuMD1sGr3TfbsSM1u7mpguFGKajpXU9v",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuETQTrnD1vwGGoycr5wRTmUPqSiKNDGPQWKuYsM9TEujkeMbHXsc",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuETH7zsgKj1eoobcELK7YQhxjgtEXMJDtUiPckXxkrTjHoFEQGDx",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuEUYgybWBd835cWQtQSVfnmYwGVr8RLTp2VwrcFXWawa7LNmtvyc",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuETrWDFKx6G5Zh8TbiQU5BJfDLu5bU4vuJHyKixQ6w3pQ8bpe6es",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuETUwzgHhCCaxjwzESD6WPsSaRggjLWTWEqPiaNLHtJbEFuarBHn",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuEUCeXagHEysLS9Dxg4aYT9aLgEzFzZ3qe2Y1oVeTiiiMLZU17BD",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuEUfZnzfe1A6PHmLapPaeipoQyC8oRcqrbUs7jXQyCMT41KDD5wu",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuEUCcrckpF5qMBBuPeWZjvHPPnskoJbPbtxitSo6YgdLVPwEPBub",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuESmS8DUqXoRGGvBgs2DGGcCtrDPPngUrTn5LrvWHnrsmbhtDcG1",
"Index": 1
},
{
"TransactionIDBase58Check": "3JuETSpZn49dZmExKcrqiaPbEoxSHyjeZaFjcn3QmD29VQRGr2zKYY",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuETuk76WQ2DWayxnyGp2PHPdoVefDhaUAwMeVz3mvGL5Qdqbi46a",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuEUHyxJKKiwd6REWgRe9gtYMVvaMsrGp1CXoorMHH6pCtT1xazYd",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuETZ4ePBDECtrDdFBbx3giKLHsqXVcgJyBeww6GJPvdfB6SDYLKP",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuEUFrXpXW4C3AWeQ2diMj4iwgr4GNEz4fmrDCp7xbpBTqkbbdK5F",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuETY7NvMAHkrourFz2VozDgYxVU8BoV9suEgDAGy8RsCcKjHwa59",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuESvnBdvPn1HpibAp8nK8xTFPqvoCV1wLiwH1eRsMpjWKr2j6vMS",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuET2tKPJYoFCpymb2qDsvVCxqFt4mkXGKHpSwa5rReirSyVt5P8J",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuESteeYphhH1fWAUcjZ8tgHFGgPmnZvqQk27kA1MD7JFfbZnjvD1",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuEUE5W3uvG57n3gtye5JWcdNuj587VqZ5y7UZezMDbXnhnwztQX5",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuESyT8kMt3pVf8UQrPWuvgWMPj4HjvQWAPiXWm7PyfsZywzPSrqg",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuETymBnGNgLTe5L8qSiHc9Z5LedtqGMaACfWyCsXtwesywAh6FWX",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuETk9anM6Egrd58L7MYRYPphvendsrKS6dKDKRXGtmH8V8Hf1beB",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuETZQ8URACYnnwrkfFiewAVcixmVoC4oUAHpm3PNB6xTAmQhmc6L",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuET1ZQL5JuVVva47kN8RK52NaozYVS56sAHsbLXnE2oxutxAY1t9",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuET2ByySu9naU84obTmKhLSkc4u9osWmjEv57BogNa5YxjQHm6i2",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuEU7sgyr9zrgukcN3sjVjYFsSXGxq5bMF1MJK84sUidZ3gZywrCW",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuETYZEN12et1yLNzqX7yZKL7n2gHQssfyy2KM5WqefZXaB6toAiH",
"Index": 0
},
{
"TransactionIDBase58Check": "3JuETAozPd6ijBVWdsMv6P1vATpaHbRCjnhoNsyLjRzbTM4pGGnAKo",
"Index": 0
}
],
"Outputs": [
{
"PublicKeyBase58Check": "BC1YLhfM59gdrgzwwvAw3UgqsGLr442BBwDn2dSBrBR4gJheFWVWrw8",
"AmountNanos": 66208570000
},
{
"PublicKeyBase58Check": "BC1YLhxjkv3gZVcrTEdiX7t1ewi56yfJ4LwdSK1QtuiQe8XUeJRj6Vt",
"AmountNanos": 3007409343
}
],
"SignatureHex": "3045022100ca8c0252964d81b89167a633d9c2852034107d7fa2f5e6f81c97b8a3055f542f0220182408d2c43e29264dcb994661a6927106ae010677b3017ae0f35b2c3ea49544",
"TransactionType": "BASIC_TRANSFER",
"BlockHashHex": "53c7878afa8e50a667934eeb0f5c289c675d409ef0d2dc6e1235af3032a36bb3",
"TransactionMetadata": {
"BlockHashHex": "53c7878afa8e50a667934eeb0f5c289c675d409ef0d2dc6e1235af3032a36bb3",
"TxnIndexInBlock": 0,
"TxnType": "BASIC_TRANSFER",
"TransactorPublicKeyBase58Check": "BC1YLhxjkv3gZVcrTEdiX7t1ewi56yfJ4LwdSK1QtuiQe8XUeJRj6Vt",
"AffectedPublicKeys": [
{
"PublicKeyBase58Check": "BC1YLhfM59gdrgzwwvAw3UgqsGLr442BBwDn2dSBrBR4gJheFWVWrw8",
"Metadata": "BasicTransferOutput"
},
{
"PublicKeyBase58Check": "BC1YLhxjkv3gZVcrTEdiX7t1ewi56yfJ4LwdSK1QtuiQe8XUeJRj6Vt",
"Metadata": "BasicTransferOutput"
}
],
"TxnOutputs": [
{
"PublicKey": "AwYzvCq9SW3qLrQtEHahkN8uUktdrbqkOGea6bYlSveq",
"AmountNanos": 66208570000
},
{
"PublicKey": "Ay2w1v4WCG2GUPqmANPcgrXsKEvc/NVKIzYVlv4/Zjvp",
"AmountNanos": 3007409343
}
],
"BasicTransferTxindexMetadata": {
"TotalInputNanos": 69215980527,
"TotalOutputNanos": 69215979343,
"FeeNanos": 1184,
"UtxoOpsDump": "",
"UtxoOps": null,
"DiamondLevel": 0,
"PostHashHex": ""
}
}
}],
"LastTransactionIDBase58Check": "",
"LastPublicKeyTransactionIndex": 0,
"BalanceNanos": 0
}

{
"Height": 0,
"HashHex": "53c7878afa8e50a667934eeb0f5c289c675d409ef0d2dc6e1235af3032a36bb3",
"FullBlock": false
}

{"Error": "APIBlockRequest: Problem fetching block: Key not found"}

Introduced here:
a4bbfa5#diff-a5a5f778c343d89a36db05b482345198caeb9d6aa30bd34685c76e73e934f22e

Tx data:
{
"TransactionIDBase58Check": "3JuESvYxAcPXMoCRN3StmLPHKp2hkdSwnDQHgkK1CdKhdsq8LNYfFy",
"RawTransactionHex": "01af7e5c2406ac513fbda473e5c03eb995ca8d4178db22ba0c03b190a855f7ff720001021134b0ccce10a8316ffb868fa86418fdd52c051dbf73bd722a8fb9a375cfebb58da0d8050c442103576d48b30347170e00b784aa1bf1c0312405c0fc0b0280549ff365a41c73145421035808ea17bddcad4915e2b6ad021bb07a22fa08247a433e0ce311ca6931baf64421021134b0ccce10a8316ffb868fa86418fdd52c051dbf73bd722a8fb9a375cfebb5004630440220776baef173baaca82a8b04bfef6f93ef84ddfed8c02ce9322ae5ba6e6a335e52022021ccf380fbdf1fd31e6248ec6032a00f9b1c02f611d9163b74e767d0186b8917",
"Inputs": [ {
"TransactionIDBase58Check": "3JuEU54U7jehFcQp5UDvuYcARbUKHwjKNUR4yU7pKdLLfLw7dSu7sB",
"Index": 0
}],
"Outputs": [ {
"PublicKeyBase58Check": "BC1YLfoSyJWKjHGnj5ZqbSokC3LPDNBMDwHX3ehZDCA3HVkFNiPY5cQ",
"AmountNanos": 11931661
}],
"SignatureHex": "30440220776baef173baaca82a8b04bfef6f93ef84ddfed8c02ce9322ae5ba6e6a335e52022021ccf380fbdf1fd31e6248ec6032a00f9b1c02f611d9163b74e767d0186b8917",
"TransactionType": "SWAP_IDENTIY",
"BlockHashHex": "0000000000006be449a09dbc93675c597934c4be3bf0e762185e4a11183dd738",
"TransactionMetadata": {
"BlockHashHex": "0000000000006be449a09dbc93675c597934c4be3bf0e762185e4a11183dd738",
"TxnIndexInBlock": 729,
"TxnType": "SWAP_IDENTIY",
"TransactorPublicKeyBase58Check": "BC1YLfoSyJWKjHGnj5ZqbSokC3LPDNBMDwHX3ehZDCA3HVkFNiPY5cQ",
"AffectedPublicKeys": [
{
"PublicKeyBase58Check": "BC1YLfoSyJWKjHGnj5ZqbSokC3LPDNBMDwHX3ehZDCA3HVkFNiPY5cQ",
"Metadata": "BasicTransferOutput"
},
{
"PublicKeyBase58Check": "BC1YLiH7rJcVDoRX7hat9XHdZD4LswvEAA9mJ1hNnbuD2EjX1aJp85W",
"Metadata": "FromPublicKeyBase58Check"
},
{
"PublicKeyBase58Check": "BC1YLiHPNyUBfHs2vRKxaBYnR15CqxizFGDdQG2gogVRcnY5v6nUcX4",
"Metadata": "ToPublicKeyBase58Check"
}
],
"TxnOutputs": [ {
"PublicKey": "AhE0sMzOEKgxb/uGj6hkGP3VLAUdv3O9ciqPuaN1z+u1",
"AmountNanos": 11931661
}],
"BasicTransferTxindexMetadata": {
"TotalInputNanos": 11931917,
"TotalOutputNanos": 11931661,
"FeeNanos": 256,
"UtxoOpsDump": "",
"UtxoOps": null,
"DiamondLevel": 0,
"PostHashHex": ""
},
"SwapIdentityTxindexMetadata": {
"FromPublicKeyBase58Check": "BC1YLiH7rJcVDoRX7hat9XHdZD4LswvEAA9mJ1hNnbuD2EjX1aJp85W",
"ToPublicKeyBase58Check": "BC1YLiHPNyUBfHs2vRKxaBYnR15CqxizFGDdQG2gogVRcnY5v6nUcX4",
"FromDeSoLockedNanos": 0,
"ToDeSoLockedNanos": 80538952585
}
}
},

How can a user submit a post that only a select group of users can view? ( not a group DM )

Been digging more into the chain and seem to be running into an issue where 147 transactions use 3JuESjmiiRsfbF4AKB6y9QUMj6iAN24abbSBBhh69JxqfwPLHqW53k as Input - but it does not exist.

Ive tried all explorers (pulse, bitclout and cloutangel).

Analysing these i think they should use Genesis as input 3JuEUEgf48j68DJPn7M4RMNpBxHZo221sYm39hatrnMyUdDVyC6w3F

There are no transactions on the chain that use 3JuEUEgf48j68DJPn7M4RMNpBxHZo221sYm39hatrnMyUdDVyC6w3F as Input.

Is this a known issue?

Hi, please use the command docker build -t ubuntu-test:latest . over the docker build Dockerfile command or update the contexts, please see here

Many people are complaining that different versions of Bitclout will not sync.

I experienced this issue using the recent releases (not run), so I deleted my data to try to resync:

If you delete your node data and try a fresh resync it will fail at block #7651 every time and not go beyond that.

E0520 14:47:50.001408 29894 blockchain.go:1073] MarkBlockInvalid: Block height: 7651, Block hash: 000000000055e730dfdd449306fd8a94aaa4d09f612d34ba288022331346c391, Error: ConnectBlock: : ConnectTransaction: : RuleErrorBitcoinExchangeBlockHashNotFoundInMainBitcoinChain

All sync errors seem to be caused by this BTC check.

I manually edited the code to ignore the BTC check (temporary) and was able to fully sync.

Hope this info helps!

So I did a test.

I sold all of my coin = 11.539803943
Then I rebought with exactly 1.85 CLOUT
Then I resold all of my coin(11.539803943)

After reselling, my wallet balance went down exactly 0.000370487 CLOUT
I did this several times to verify

( rebought to not have a rugpull)

Is this supposed to happen? I know about transaction fees,
but I don't think they are supposed to add up between a buy+sell to 0.000370487 CLOUT?

When I start a fresh sync. new Node and empty Postgres DB in the 2nd block I see this error:

ProcessBlock: Problem upserting block and transactions: ERROR #42703 column "de_so_to_sell_nanos" of relation "pg_metadata_creator_coins" does not exist

After that block status stays 26 for consequent blocks. Seems there might be a wrong table reference or instruction. Seems it should be deso_to_sell_nanos instead of de_so_to_sell_nanos.

Using latest backend build from docker. Does not seem to happen with stable backend

Will see if I can do a PR.

team,

the salomon bug has been fixed however i'm still seeing accounts that their price are not making sense.

https://github.com/bitclout/core/blob/2cbd77da61109303f3f961c227a414ab063a74d6/lib/constants.go#L78

It seems the bug is not only happening on buy option but sell too.

Please check https://bitclout.com/u/Petrh -> it seems the bug occurred in the sell option , different from salomon bug.
https://bitcloutsignal.com/history/petrh

Also please look at https://bitclout.com/u/speakinglight -> this seems to be like the salomon bug
https://bitcloutsignal.com/history/speakinglight

please look at this before we get more users onboarded, since this can be a significant challenge going forward if the creator coins are not always working correctly.

this might be a UI problem and not blockchain, if we go to signalclout we can see their real price.

petrh - should be around 555 usd
speakinglight - should be around 268 usd

thanks in advance!

When I bring down the containers (during initial sync, eg at height 13807) and restart them again - node will not store incoming blocks anymore and output errors Problem fetching block ... during attach in reorg: Key not found.

This happens at any time during the sync if backend crashes or is stopped, both with postgres running locally or on remote server.

Full error:

E0822 18:02:15.434559       1 server.go:1126] Server._handleBlock: Encountered an error processing block <Header: < 13808, 00000000006242429dc303a203bb9bc527b750ed6280db725cec0832a78d534e, 0 >, Signer Key: NONE>. Disconnecting from peer [ Remote Address: 34.123.41.111:17000, DISCONNECTED PeerID=179 ]: Error while processing block: : ProcessBlock: Problem fetching block (< TstampSecs: 1617938118, Height: 13807, Hash: 000000000053ee995f93af61bc8d7ea7c6d94578d61c811f7faabd78f5489d81, ParentHash 00000000003edd704218a7dd7ecf39bd25ca2aff076fa27ebed263cd7de5f905, Status: HEADER_VALIDATED | BLOCK_PROCESSED | BLOCK_STORED, CumWork: 16874254463500418>) during attach in reorg: Key not found

I bought my own coin for $500. My money disappeared. Also, the token price was a ridiculous number. Can you please solve my problem? @diamondhands @maebeam @craig
@lazynina

0+0+0 = 0.1119 ???

I probably don't know any nuances, but I can't just take and import your kernel into the project because of modified third-party packages. I have to clone the repository and take it to a level above the project.
In go.mod to register ...

replace github.com/deso-protocol/core => ../core/
replace github.com/golang/glog => ../core/third_party/github.com/golang/glog
replace github.com/laser/go-merkle-tree => ../core/third_party/github.com/laser/go-merkle-tree
replace github.com/sasha-s/go-deadlock => ../core/third_party/github.com/sasha-s/go-deadlock

Can you give any recommendations for development? Perhaps it is worth considering the design in the form of full-fledged modules in separate repositories and pull up as dependencies?

The Genesis Block #0 has this transaction listed:

3JuEUEgf48j68DJPn7M4RMNpBxHZo221sYm39hatrnMyUdDVyC6w3F

Running any of the transaction-info API calls on this transaction return back an error stating the Transaction could not be found.

(Error: APITransactionInfo: Could not find transaction with TransactionIDBase58Check = 3JuEUEgf48j68DJPn7M4RMNpBxHZo221sYm39hatrnMyUdDVyC6w3F)

This transaction contains most of the outputs towards the six centralized public keys from the genesis.

This leads to the missing input: 3JuESjmiiRsfbF4AKB6y9QUMj6iAN24abbSBBhh69JxqfwPLHqW53k

Referring to @tijno issue #21

As the BitClout ecosystem expands, and many new applications are built on top of the protocol, having a standard for node-specific content will become vital. For example, if an engineer wanted to create an app built on top of the protocol which only displayed posts meant for that app (For example, if you wanted to make a Reddit-like app, it wouldn't make sense to display all posts from all subreddits on one twitter-like feed), the app could formulate a field like such in the request: Sources: ["myApp.com"]. BitClout.com, and any other nodes looking to display all content, could use the "Default" source to signify it displays regular content not specific to an application type. Those nodes could filter by this source. This could allow engineers to display posts only allowed for their source, without doing anything too hacky.

While methods for doing this already exist, for example hiding a post by default and making use of PostExtraData to identify the source application & if the post is actually hidden or not, however, I think having a standard method of doing such would be a much better, and long-lasting, solution.

I think for the long-term success of BitClout we need many types of applications built on top of the protocol, and additions like this would be very very helpful in accomplishing such.

I've gotten this crash twice now. I restart and everything is fine. Anyone else seen this?

I0722 13:29:42.472383   23223 base.go:182] Final exchange rate: 10001
POTENTIAL DEADLOCK:
Previous place where the lock was grabbed
goroutine 84448 lock 0xc00052aeb0
I0722 13:29:52.825029   23223 base.go:116] Refreshing exchange rate...
~/core/lib/blockchain.go:1495 lib.(*Blockchain).ProcessBlock { bc.ChainLock.Lock() } <<<<<
~/core/lib/server.go:1235 lib.(*Server)._handleBlock { _, isOrphan, err = srv.blockchain.ProcessBlock(blk, true) }
~/core/lib/server.go:1529 lib.(*Server)._handlePeerMessages { srv._handleBlock(serverMessage.Peer, msg) }
~/core/lib/server.go:1577 lib.(*Server).messageHandler { srv._handlePeerMessages(serverMessage) }

Have been trying to lock it again for more than 10m0s
goroutine 3172891 lock 0xc00052aeb0  

Here is what goroutine 84448 doing now
goroutine 84448 [runnable]:
github.com/bitclout/core/lib.DBGetProfileEntryForPKIDWithTxn.func1(0xc133d99500, 0x13e8, 0x13e8, 0x13e8, 0x0)
        /home/ec2-user/core/lib/db_utils.go:3867 +0xda
github.com/dgraph-io/badger/v3.(*Item).Value(0xc002306e10, 0xc06e4a51f8, 0x0, 0x0)
        /home/ec2-user/go/pkg/mod/github.com/dgraph-io/badger/[email protected]/iterator.go:112 +0x138
github.com/bitclout/core/lib.DBGetProfileEntryForPKIDWithTxn(0xc0e8450000, 0xc0f2818ea0, 0xb)
        /home/ec2-user/core/lib/db_utils.go:3867 +0x16c
github.com/bitclout/core/lib.DBGetProfileEntryForPKID.func1(0xc0e8450000, 0x1a588dc10eab0000, 0xc0e8450000)
        /home/ec2-user/core/lib/db_utils.go:3881 +0x3d
github.com/dgraph-io/badger/v3.(*DB).View(0xc000164900, 0xc06e4a52b0, 0x0, 0x0)
        /home/ec2-user/go/pkg/mod/github.com/dgraph-io/badger/[email protected]/txn.go:808 +0x95
github.com/bitclout/core/lib.DBGetProfileEntryForPKID(0xc000164900, 0xc0f2818ea0, 0xc0f2818ea0)
        /home/ec2-user/core/lib/db_utils.go:3880 +0x6f
        /home/ec2-user/core/lib/db_utils.go:3880 +0x6f
github.com/bitclout/core/lib.(*UtxoView).GetProfileEntryForPKID(0xc0efa92370, 0xc0f2818ea0, 0x21)
        /home/ec2-user/core/lib/block_view.go:3277 +0x79
github.com/bitclout/core/lib.(*UtxoView).GetProfileEntryForPublicKey(0xc0efa92370, 0xc057fa9410, 0x21, 0x21, 0xc068dd4e00)
        /home/ec2-user/core/lib/block_view.go:3264 +0x86
github.com/bitclout/core/lib.(*UtxoView)._connectFollow(0xc0efa92370, 0xc06ebaa230, 0xc0331d3ca0, 0x10000af23, 0x180, 0x0, 0x0, 0x3, 0x4, 0x0, ...)
        /home/ec2-user/core/lib/block_view.go:4098 +0x1e8
github.com/bitclout/core/lib.(*UtxoView)._connectTransaction(0xc0efa92370, 0xc06ebaa230, 0xc0331d3ca0, 0x0, 0x1010000af23, 0x1, 0xc00, 0xc068dd4de0, 0x3, 0x4, ...)
        /home/ec2-user/core/lib/block_view.go:6219 +0x885
github.com/bitclout/core/lib.(*UtxoView).ConnectTransaction(0xc0efa92370, 0xc06ebaa230, 0xc0331d3ca0, 0x0, 0x10000af23, 0xc068dd4de0, 0x3, 0x4, 0x2d445, 0x2d368, ...)
        /home/ec2-user/core/lib/block_view.go:6147 +0x94
github.com/bitclout/core/lib.(*UtxoView).ConnectBlock(0xc0efa92370, 0xc0ebf91710, 0xc0eee5e000, 0xb4d, 0xc00, 0x1, 0xc00, 0x0, 0x0, 0x100000000000000, ...)
        /home/ec2-user/core/lib/block_view.go:6309 +0x213
github.com/bitclout/core/lib.(*Blockchain).ProcessBlock(0xc00052ae70, 0xc0ebf91710, 0xc0020c5e01, 0x0, 0x0, 0x0)
        /home/ec2-user/core/lib/blockchain.go:1765 +0xd1a
github.com/bitclout/core/lib.(*Server)._handleBlock(0xc00087fc80, 0xc000358480, 0xc0ebf91710)
        /home/ec2-user/core/lib/server.go:1235 +0x965
github.com/bitclout/core/lib.(*Server)._handlePeerMessages(0xc00087fc80, 0xc0ed066680)
        /home/ec2-user/core/lib/server.go:1529 +0x137
github.com/bitclout/core/lib.(*Server).messageHandler(0xc00087fc80)
        /home/ec2-user/core/lib/server.go:1577 +0x215
created by github.com/bitclout/core/lib.(*Server).Start
        /home/ec2-user/core/lib/server.go:1764 +0xbd
Other goroutines holding locks:
goroutine 131434 lock 0xc05353c4c0
~/core/third_party/github.com/sasha-s/go-deadlock/deadlock.go:119 go-deadlock.(*RWMutex).Lock { lock(m.mu.Lock, m) } <<<<<
~/core/lib/txindex.go:156 lib.(*TXIndex).Start.func1 { err := txi.Update() }

goroutine 84444 lock 0xc05eb6a180
~/core/lib/mempool.go:2203 lib.(*BitCloutMempool).RegenerateReadOnlyView { mp.mtx.RLock() } <<<<<
~/core/lib/mempool.go:2162 lib.(*BitCloutMempool).StartReadOnlyUtxoViewRegenerator.func1 { mp.RegenerateReadOnlyView() }

There exist 7 superuser accounts defined in 'ParamUpdaterPublicKeys'.

These accounts can be used to create 'SWAP_IDENTITY' actions that can re-assign any account's username (and coin balances?) to another account. This allows any account on the platform to be cancellable by any of the superuser accounts. Having such a powerful action available undermines BitClout's claim to be a decentralized platform with self-sovereign identity.

Recommendation: Remove swap_identity and superuser accounts as soon as possible.

@maebeam as per discord:

Syncing clean node via postgres, results in panic, after a certain height (15-20k ~ will try and identify specific point today).

Initially its fine in earlier blocks, but then it Panics.

Eg request:

POST /api/v0/get-users-stateless HTTP/2

{"PublicKeysBase58Check":["BC1YLgxLrxvq5mgZUUhJc1gkG6pwrRCTbdT6snwcrsEampjqnSD1vck"],"SkipForLeaderboard":false}

Results in this panic in logs: (updated log in next reply)

Hi, running the .sh file creates an error, given that their is no remote_miner_main.go or miner_main files in the core directory.

There are the go commands it should be running:

go build remote_miner_main.go && ./remote_miner_main
  --remote_block_producer=https://f07d2458adad0581e6e09ab745c2a258.bitclout.com
  --miner_public_key=BC1YLjJ3FNgo1Q8NU9sEzK3B2obeuq9GvzYr1GnAJgpsVnYCuczcYBe
  --alsologtostderr 
  --v=0

However, the files still need to be there for it to build properly.

Congrats on the success of this project! I'm still going through all the code but thought I'd submit this... perhaps the start of this already exists?

As a node runner maybe I'd like to only process messages that are NOT R or X rated. A way to vote with my resources, i.e. I'm willing to run a node and help this network but I have my lines of what content I'll process.

And this goes further than just Movie Style ratings, but also politics. As a node runner I might also want to ban certain usernames. Or at least the first step in all this is a way to classify, in great detail, the type of content you are asking the network to process; so the network can give you a bid on that.

For example, I have a pallet of clouts with:

178) just normal left leaning user posts
 17) high profile left politic figures
  1) very high profile political figure

or:

210) normal right leaning user posts
 47) normal left leaning user posts
 15) R or X in nature

As a node runner I would want to broker exchanges of pallets with prices for all the various options out there. This is free speech in a decentralized world? There's a market for which node runners will cross what lines. And some of the lines to one group will seem silly and not even a big deal. But just wanted to get thoughts from Clout team on how they are thinking about this...

Another way to say this: Trump could never be banned from the entire clout network, but the % of node owners willing to process him might fluctuate.

If the DB gets into a corrupted state I'm forced to reset and repull the data.

It would be great if there was a utility for rolling back to a certain block to resync corrupted DB states.

@redpartyhat @AeonSw4n @diamondhands0

Was just doing some work to prepare my BQ db schema for the new transactions:

• NFTTransfer
• AcceptNFTTransfer
• BurnNFT
• AuthorizeDerivedKey

But none of these seem to be included yet in TransactionMetadata type:

https://github.com/bitclout/core/blob/6fc331f7afa954432d849fb030e6321e28083fa9/lib/db_utils.go#L3253

Also they are not listed in ComputeTransactionMetadata func in mempool.

https://github.com/bitclout/core/blob/49d692be508150b9eb681bebdba313f6e8edc222/lib/mempool.go#L1108

Is this intentional and will the associate tx metadata not be returned in the json block output?

hello, might you remove this issue as well as #8 (comment)

or redact the name James, the name Ecwiti and the related github username/account

Kind regards,