DeSo is a blockchain built from the ground up to support a fully-featured social network

Related tags

Network deso
Overview

DeSo Logo

About DeSo

DeSo is a blockchain built from the ground up to support a fully-featured social network. Its architecture is similar to Bitcoin, only it supports complex social network data like profiles, posts, follows, creator coin transactions, and more.

Read about the vision

About this Repo

This repo contains all of the consensus code for the DeSo protocol. While it can technically be built and run as a stand-alone binary, it is mainly intended to be "composed" into other projects that want to build on top of DeSo. We provide multiple examples of how to do this in this README.

Building on DeSo Core

Below we provide a few real-world examples of how to compose DeSo core into your project.

Example 1: A Standard DeSo App (e.g. bitclout.com or flickapp.com)

The code that powers DeSo apps like bitclout.com is fully open-source such that anyone in the world can run it, and it consists of three repositories:

The repo that is most interesting for understanding the role of DeSo core is backend because it effectively includes core as a library to run a node. Then, it builds on core's basic functionality to expose a rich API of its own that can be used to construct transactions, submit transactions to the network, manage user data, and much more.

The backend repo's API is then utilized by frontend and identity, which are Angular apps that are served as the frontend to apps like bitclout.com.

Example 2: A Rosetta API for Exchange Listing

Rosetta is an API developed by Coinbase and used by exchanges all over the world to list coins. For most modern exchanges, implementing a Rosetta API makes it a breeze to integrate a coin because all of their infrastructure can plug into a standardized interface.

Because exchanges have a different set of needs than what's required to run a DeSo web app, composing core allowed us to build a fully Dockerized Rosetta API that conforms perfectly to spec as its own self-contained service. This allows exchanges to integrate DeSo without having to run the unnecessary services associated with serving bitclout.com.

For more information on the DeSo Rosetta API, see our rosetta-deso repo here:

Example 3: A MongoDB Data Dumper

Another example of composing the core repo is the DeSo MongoDB Dumper.

This tool does the following:

  • It includes core as a library
  • It uses its embedded core code to download all of the blockchain data
  • It takes all of the blockchain data and indexes it into MongoDB

This gives users the ability to query all of the chain data using the MongoDB commandline tool, or to layer a product like Retool on top of it.

Running DeSo Core

Because core is intended to be composed into other projects, we suggest that users who want to run it start by reading the README in the backend repo mentioned previously. This repo provides instructions on how set up a dev environment for a full frontend and backend stack that can serve a full clone of apps like bitclout.com with one's own custom feed.

We also provide a run repo that shows how to run this full stack in a fully Dockerized production environment.

Acknowledgements

The architecture for DeSo was heavily-inspired by Bitcoin. We also owe a debt of gratitude to the developers of btcd for producing a truly amazing Go Bitcoin client that served as a reference when building DeSo.

Issues
  • SOFT FORK: Today, BitClout joins the environmental movement.

    SOFT FORK: Today, BitClout joins the environmental movement.

    I am proud to announce that the dev community has committed to moving to a zero-waste consensus mechanism, and that it is taking a major step in that direction with a new update.

    Cryptocurrencies have gotten a lot of heat recently for being harmful to the environment.

    This is due in large part to "proof of work," a consensus mechanism that burns CPU power to secure the network.

    BitClout has relied on proof of work to get off the ground, but since launching the dev community has already invested in consensus mechanisms that allow BitClout to operate on orders of magnitude less power than most existing proof of work cryptocurrencies.

    Now, in a show of solidarity with the environmental movement, and to take the first big step toward a zero-waste consensus mechanism, BitClout is deploying a new update that reduces its power consumption by a full order of magnitude.

    BitClout is reducing the block reward, and thus the amount of environmental waste its consensus mechanism incurs, by a factor of ten.

    This was a difficult change to make, and it took the input of several major node operators to deploy it safely.

    We understand that miners in particular may not like this change; however, there is now consensus around the decision to push the limits of the BitClout chain toward conservation rather than allowing the depletion of what are ultimately finite environmental resources.

    There is still more work to do to move to a zero-waste consensus mechanism without compromising on decentralization (e.g. full proof of stake).

    But the dev community is committed to getting there sooner rather than later, and we hope this change shows just how committed we are.

    opened by diamondhands0 47
  • BitClout Improvement Proposals

    BitClout Improvement Proposals

    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.

    opened by connerdouglass 17
  • SEV1 -- All 3rd Party Nodes are Down, main node transaction-info unresponsive

    SEV1 -- All 3rd Party Nodes are Down, main node transaction-info unresponsive

    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

    opened by Zyther 15
  • Issue rendering images on nodes when hosting own node with GCP_BUCKET

    Issue rendering images on nodes when hosting own node with GCP_BUCKET

    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.

    opened by MirekR 12
  • Pn/derived keys

    Pn/derived keys

    Core idea is we accept txns signed by non-owner (derived) keys in _verifySignatureDerived() which is called in _connectBasicTransfer() on signature verification. Client looks for all derived keys associated with the txn public key and checks if any of them matches the signature. With this approach, I'm not making any changes to how txns are sent. A derived key must first be authorized by sending a new TxnTypeAuthorizeDerivedKey transaction constructed in CreateAuthorizeDerivedKeyTxn(). When clients receive the Authorize txn, they connect it and modify the new PKIDToDerivedKeyEntry map in UtxoView. I also added a new prefix in the DB for Authorize entries. When we flush to the DB, we call _flushDerivedKeyEntryToDbWithTxn. Let me know if this makes sense!

    Note: I haven't written tests yet, and last time I checked, there was no YT tutorial on how to add a new txn to BitClout. So this is probably buggy :)

    opened by AeonSw4n 12
  • postgres exception RuleErrorInsufficientFundsForNFTBid on block 46923

    postgres exception RuleErrorInsufficientFundsForNFTBid on block 46923

    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://[email protected]/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

    opened by Zyther 9
  • Postgres DB missing tables

    Postgres DB missing tables

    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

    opened by mvanhalen 7
  • Add optional

    Add optional "Sources" field to `SUBMIT_POST` txs

    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.

    opened by HPaulson 5
  • plan to filter content by movie type PG, PG13, R, X, etc. rating system

    plan to filter content by movie type PG, PG13, R, X, etc. rating system

    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.

    opened by andrewarrow 5
  • Only main.go, no remote_miner_main.go or miner_main files

    Only main.go, no remote_miner_main.go or miner_main files

    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.

    opened by Mentors4EDU 4
  • Added additional nodes

    Added additional nodes

    Added Nodes 13 - 18 to the registry list.

    Each of these machines is owned and operated by SeismicCore, LLC on behalf of our clients listed in the "Owner" field therein. Each node meets all necessary listing criteria, and has been operating for at least 30 days.

    opened by HPaulson 1
  • MySQL

    MySQL

    null

    opened by maebeam 0
  • Buy Now NFTs (FORKING CHANGE)

    Buy Now NFTs (FORKING CHANGE)

    Add support for selling an NFT at a fixed price instead of an auction style.

    What's been done:

    1. Move the logic of connecting/disconnecting NFT sales out of _connectAcceptNFTBid and _disconnectAcceptNFTBid in block_view.go into a helper function that can be used by _connectNFTBid and _disconnectNFTBid when an NFT is a buy now NFT.
    2. Update _connectNFTBid and _disconnectNFTBid to automatically sell an NFT when a bid is submitted on an NFT that is a Buy Now NFT.
    3. Prevent making an NFT a Buy Now NFT if the NFT has unlockable content.
    4. Prevent putting an NFT on sale as a Buy Now NFT with a Purchase price of 0.
    5. Add rosetta fields to UtxoOperation struct to support the Output to the coin that is generated by this transaction.
    6. Create a utility function that gathers enough inputs to cover a certain amount of spend. This helps gather enough inputs for an NFT bid on a Buy Now NFT - similar to how we gather additional inputs for Creator Coin purchases.
    7. Add some new Errors
    8. Add test for Buy Now functionality.
    opened by lazynina 0
  • Allow pending NFT sales (FORKING CHANGE)

    Allow pending NFT sales (FORKING CHANGE)

    As it stands, users that want to put transferred NFTs up for sale must first "accept" the NFT transfer. This is cumbersome and does not add any obvious utility. This PR removes that restriction, automatically accepting an NFT transfer when it is put up for sale.

    In drafting this change, I took inventory of all NFT transactions and noted those that are affected by the "IsPending" status of an NFT. This is the current state of NFT consensus:

    Unaffected NFT Transaction:

    • CreateNFT
    • BurnNFT
    • NFTTransfer (one can already transfer a pending NFT)

    Affected NFT Transactions:

    • NFTBid -> Can't bid on a pending NFT.
    • AcceptNFTBid -> Can't accept a bid on a pending NFT.
    • UpdateNFT -> You can't update an NFT that is a pending transfer.
    • AcceptNFTTransfer -> Sanity check's that an NFT is not for sale before accepting a transfer. Therefore, if an NFT was for sale and pending, one could not accept it. Since it is unreasonable to create a state where the user cannot accept a transfer, this must be avoided.

    Given the current state of consensus, the best solution is to force a user to accept a transfer if they update an NFT. This prevents us from being in a situation where an NFT is for sale and pending while keeping all other logic working as expected.

    opened by redpartyhat 0
  • restricted post feature

    restricted post feature

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

    opened by mikestaub 3
  • [wip] Trends

    [wip] Trends

    null

    opened by maebeam 0
  • Node agnostic Link To Post URL

    Node agnostic Link To Post URL

    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

    opened by GJARTmusic 0
  • Peer accessing db during shutdown causes crash

    Peer accessing db during shutdown causes crash

    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.

    opened by gfodor 1
  • Postgresql backend panic on GetPublicKeyForPKID

    Postgresql backend panic on GetPublicKeyForPKID

    @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)

    opened by tijno 4
  • Z/testnet blockheight params

    Z/testnet blockheight params

    Create params for global blockheights for use in testnet.

    opened by superzordon 1
Releases(v1.2.7)
  • v1.2.7(Nov 8, 2021)

  • v1.2.6(Nov 7, 2021)

    What's Changed

    • Headers sync is 100x faster
    • Rosetta indexes are now built during core consensus, and don't need to rely on txindex anymore
    • Added support for historical balance lookups for Rosetta
    Source code(tar.gz)
    Source code(zip)
  • v1.2.5(Nov 5, 2021)

    What's Changed

    • Add fix for update profile transactions that clobber deso locked nanos by @maebeam in https://github.com/deso-protocol/core/pull/139
    • [Postgres] Added String Trimmer & Terminators for mention notifications by @HPaulson in https://github.com/deso-protocol/core/pull/129
    • Fix swap identity txn string. by @redpartyhat in https://github.com/deso-protocol/core/pull/138
    • NFTTranser -> NFTTransfer in mispelled rule errors by @lazynina in https://github.com/deso-protocol/core/pull/130

    New Contributors

    • @HPaulson made their first contribution in https://github.com/deso-protocol/core/pull/129

    Full Changelog: https://github.com/deso-protocol/core/compare/v1.2.3...v1.2.5

    Source code(tar.gz)
    Source code(zip)
  • v1.2.3(Oct 29, 2021)

    What's Changed

    • Fix readme by @AeonSw4n in https://github.com/deso-protocol/core/pull/124
    • add additionalOutputs to transaction construction for node fees by @lazynina in https://github.com/deso-protocol/core/pull/125
    • Fix a minor bug by @diamondhands0 in https://github.com/deso-protocol/core/pull/126
    • Fix fee validation for create profile transactions by @lazynina in https://github.com/deso-protocol/core/pull/127
    • Fix postgres sync issue by @maebeam in https://github.com/deso-protocol/core/pull/128
    • add constants for NotGraylisted and NotBlacklisted by @lazynina in https://github.com/deso-protocol/core/pull/132
    • Fix bug and add check for mempool in test. by @redpartyhat in https://github.com/deso-protocol/core/pull/134
    • Keep track of changes to DESO locked in creator coins by @maebeam in https://github.com/deso-protocol/core/pull/135

    Full Changelog: https://github.com/deso-protocol/core/compare/v1.2.1...v1.2.3

    Source code(tar.gz)
    Source code(zip)
  • v1.2.1(Sep 28, 2021)

  • v1.2.0(Sep 28, 2021)

  • v1.1.6(Sep 13, 2021)

  • v1.1.5(Sep 10, 2021)

    Changes:

    • Add NFT transfers and burns
    • Fix CLOUT diamond notifications
    • Fix a bug when closing the txindex DB
    • Add Postgres as a backing store
    • Remove Bitcoin syncing code (woohoo!)
    Source code(tar.gz)
    Source code(zip)
  • v1.1.4(Aug 18, 2021)

    Changes:

    • Diamonds are now paid in CLOUT (#91)
    • Properly shutdown block producer (#86) (@gfodor)
    • Fix bug in get DB high and low bid entries for NFT (#85)
    Source code(tar.gz)
    Source code(zip)
  • v1.1.3(Jul 29, 2021)

  • v1.1.2(Jul 28, 2021)

  • v1.1.0(Jul 27, 2021)

  • v1.0.7(Jul 20, 2021)

    Changes:

    • Add shared secret encryption/decryption
    • Fix mentions with underscores
    • Launched dorsey testnet
    • Added --regtest flag which is now recommended when developing locally
    Source code(tar.gz)
    Source code(zip)
  • v1.0.6(Jun 28, 2021)

    Fixes a bug when users purchase creator coins on a deleted BalanceEntry Fixes a bug when a ParamUpdater creates a profile for a public key

    Source code(tar.gz)
    Source code(zip)
  • 1.0.5(Jun 26, 2021)

  • v1.0.4(Jun 24, 2021)

    Changes:

    • Add block and header heights to statsd
    • Fix a concurrent map read/write
    • Fix @mention notifications
    • Replace trusted block producer key
    Source code(tar.gz)
    Source code(zip)
  • v1.0.3(Jun 16, 2021)

  • v1.0.2(Jun 16, 2021)

    Changes:

    • Decrease block reward maturity in testnet
    • Move txindex from backend to core
    • Set deflation bomb block height
    • Adjust mining supply schedule
    Source code(tar.gz)
    Source code(zip)
  • v1.0.1(May 21, 2021)

    Changes

    • Fix an issue with lru.Cache that caused mempools to diverse
    • Fix an issue with old, mined bitcoin exchange transactions stalling initial sync
    • Add ENTRYPOINT to Dockerfile
    Source code(tar.gz)
    Source code(zip)
  • v1.0.0(May 18, 2021)

Plants social network

Plantbook, plants social network. For generate plantbook-server nedd to be installed go-swagger#install # after change spec run command below... swagg

Michael Gunkoff 0 Jun 20, 2021
gqlgenc is a fully featured go gql client, powered by codegen

gqlgenc Note: ⚠️ This is a WIP, backward-compatibility cannot be guaranteed yet, use at your own risk gqlgenc is a fully featured go gql client, power

Infiot Inc 20 Nov 21, 2021
Package socket provides a low-level network connection type which integrates with Go's runtime network poller to provide asynchronous I/O and deadline support. MIT Licensed.

socket Package socket provides a low-level network connection type which integrates with Go's runtime network poller to provide asynchronous I/O and d

Matt Layher 24 Nov 2, 2021
GraphQL API server for galaxy powered blockchain network

ICICB GraphQL API Server GraphQL API server for galaxy powered blockchain network. Releases Please check the release tags to get more details and to d

Galaxy developer Team 4 Nov 4, 2021
Xray, Penetrates Everything. Also the best v2ray-core, with XTLS support. Fully compatible configuration.

Project X Project X originates from XTLS protocol, provides a set of network tools such as Xray-core and Xray-flutter. License Mozilla Public License

Project X Community 6.7k Dec 1, 2021
SwipeChain is a decentralised liquidity network built with CosmosSDK.

SwipeChain is a CosmosSDK-powered replicated state machine to coordinate asset movement for ASGARDEX, including processing swaps, stakes and more. SwipeChain does not peg assets, it simply determines how to move them.

Swipe 13 Sep 13, 2021
🌐 (Web 3.0) Pastebin built on IPFS, securely served by Distributed Web and Edge Network.

pastebin-ipfs 简体中文 (IPFS Archivists) Still in development, Pull Requests are welcomed. Pastebin built on IPFS, securely served by Distributed Web and

Mayo/IO 149 Dec 5, 2021
LNC is a lightning network capital management tool built for routing nodes.

LNC is a lightning network capital management tool built for routing nodes.

LN.capital 5 Oct 27, 2021
[deprecated] A full-featured SPDY library for the Go language.

Deprecated With the release of Go1.6 and the addition of http2 to the standard library, this package is no longer under active development. It is high

Jamie Hall 120 Aug 4, 2021
Full-featured BitTorrent client package and utilities

torrent This repository implements BitTorrent-related packages and command-line utilities in Go. The emphasis is on use as a library from other projec

Matt Joiner 4.1k Nov 29, 2021
Magma is an open-source software platform that gives network operators an open, flexible and extendable mobile core network solution.

Connecting the Next Billion People Magma is an open-source software platform that gives network operators an open, flexible and extendable mobile core

Magma 1.1k Dec 7, 2021
Optimize Windows's network/NIC driver settings for NewTek's NDI(Network-Device-Interface).

windows-ndi-optimizer[WIP] Optimize Windows's network/NIC driver settings for NewTek's NDI(Network-Device-Interface). How it works This is batchfile d

Nil Hiiragi 2 Sep 23, 2021
A simple network analyzer that capture http network traffic

httpcap A simple network analyzer that captures http network traffic. support Windows/MacOS/Linux/OpenWrt(x64) https only capture clienthello colorful

null 1 Nov 24, 2021
🚀Gev is a lightweight, fast non-blocking TCP network library based on Reactor mode. Support custom protocols to quickly and easily build high-performance servers.

gev 中文 | English gev is a lightweight, fast non-blocking TCP network library based on Reactor mode. Support custom protocols to quickly and easily bui

徐旭 1.3k Nov 30, 2021
Designed to support DNS brute-forcing with a minimal number of network connections

Fast Use of DNS Resolvers Designed to support DNS brute-forcing with a minimal number of network connections. Installation go get -v -u github.com/caf

Jeff Foley 16 Nov 3, 2021
A major platform Remote Access Terminal Tool based by Blockchain/P2P.

NGLite A major platform Remote Access Terminal Tool based by Blockchain/P2P. No public IP address required.More anonymity Example Detection Warning!!!

null 183 Nov 27, 2021
The official repository of the Gravity Bridge Blockchain

Gravity bridge is Cosmos <-> Ethereum bridge designed to run on the Cosmos SDK blockchains like the Cosmos Hub focused on maximum design simplicity an

Gravity Bridge Foundation 2 Dec 4, 2021
Gmqtt is a flexible, high-performance MQTT broker library that fully implements the MQTT protocol V3.1.1 and V5 in golang

中文文档 Gmqtt News: MQTT V5 is now supported. But due to those new features in v5, there area lots of breaking changes. If you have any migration problem

null 519 Dec 4, 2021
Automatically spawn a reverse shell fully interactive for Linux or Windows victim

Girsh (Golang Interactive Reverse SHell) Who didn't get bored of manually typing the few lines to upgrade a reverse shell to a full interactive revers

null 200 Nov 30, 2021