Note: Throughout this paper all references to covenants should be interpreted to refer to generalized covenants, in opposition to the heavily restricted covenants such as the one proposed in OP_SECURETHEBAG & Co.
Drivechains would be easily implementable if covenants are possible, as they would enable the creation of a 2-way peg that would be enforced at the transaction level through scripts that would force the funds being withdrawn from the sidechain to be sent through a chain of N transactions, each one of these being in a different block. More specifically, this would be implemented by creating N scripts that would contain an integer constant and would only be spendable to another copy of the same script with the constant increased or decreased by one, with the exception of the script where the constant reaches the value N, in which case the UTXO would be spendable only to a specific address provided in the beginning of the process. Furthremore, these scripts would prevent the possibil
We built a publish-subscribe service for NEO that allows anyone to listen for events happening on the blockchain and act on them. The service is based in websockets and can be used by just connecting to the following endpoints:
wss://pubsub.main.neologin.io?channel=events # Events triggered in smart contract executions (final)
wss://pubsub.main.neologin.io?channel=tx # A transaction has entered in the mempool (but may not be inside a block yet)
wss://pubsub.main.neologin.io?channel=block # A block is propagated (not finalized tho)
wss://pubsub.main.neologin.io?channel=consensus # Consensus messagesNote: If you wish to get events from testnet instead of mainnet just replace the main prefix with test, eg: pubsub.test.neologin.io.
| filename=$(date) | |
| ssh-keygen -t rsa -b 4096 -C "$(git config user.email)" -f "$filename" -N "" | |
| cat "$filename.pub" | |
| echo | |
| cat "$filename" | |
| # See https://github.com/marketplace/actions/github-pages-action#%EF%B8%8F-create-ssh-deploy-key |
| <!DOCTYPE HTML> | |
| <html> | |
| <head> | |
| <title>Page</title> | |
| <meta charset="utf-8" /> | |
| <link rel="shortcut icon" href="favicon.ico"> | |
| <meta name="viewport" content="width=device-width, initial-scale=1" /> | |
| </head> | |
| <body> | |
I’ve simulated packet loss by commenting out the code responsible of sending packets on the server and the results obtained are pretty much what anyone might expect, the removal of replies leads to clients requests being repeated and, when the server is using at least once invocation semantics,
Note from the author:
In Onramper, the company I am currently working in, we are trying to minimize the amount of personal data that is stored on our systems, and, as part of that effort, I am currently building a system that will allow us to avoid storing any directly identifiable data while also allowing us to track repeated customers.
A simple way of achieving that would be to hash some unique per-customer data points such as email and call it a day, but the problem with that approach is the lack of a unique salt, which would make the creation of site-wide rainbow tables possible thus severely diminishing security.
Now you might think that adding salt on that hash would be simple, but consider that here we are generating the customer identifier, so storing per-customer salt on the database becomes infeasible because you have no way to index it (you need the salt to generate the identifier but you need the identifier to retrieve the salt). It should also be possible to take an approach where salt can be retrieved
I hereby claim:
To claim this, I am signing this object:
Let's start by describing it's main building block: the ability to make a reedem script (scriptPubKey in BTC terms) have access to the transaction that is attempting to spend it. This is achievable through several ways: