learner-long-life

public void updateJarFile(File srcJarFile, String targetPackage, File ...filesToAdd) throws IOException {
    File tmpJarFile = File.createTempFile("tempJar", ".tmp");
    JarFile jarFile = new JarFile(srcJarFile);
    boolean jarUpdated = false;
 
    try {
        JarOutputStream tempJarOutputStream = new JarOutputStream(new FileOutputStream(tmpJarFile));
 
        try {
            //Added the new files to the jar.

learner-long-life

In response to https://moxie.org/2022/01/07/web3-first-impressions.html

A well-stated critique is worth its weight in gold. I'm a fan of the work on encrypted text messenging by
anyone named Moxie Marlinspike, and acknowledge that it reflects a particular ethos, exhibited by Signal,
a project that Moxie co-founded with Brian Acton. This ethos is strongly opinionated on behalf of users,
makes the best choice for most people in a large variety of cryptographic
protocols and their parameters, and offers it in a tightly integrated desktop/mobile app and centralized
server infrastructure.

Marlinspike raises a valid gap between the decentralized ethos of web3, and a few centralized providers of its data.

learner-long-life

Let's say you have a serverless cloud function system which reproducible, stateless, only operates on its immutable inputs and produces immutable output all the functional things.
```
F(x) = y
```

You also have an on-chain verifier function (I know, unrealistic, but we'll try and fix this later) that you can run, much faster than `F`, that you publish on a ledger tied to
```
G(x,y) = true for all x, y=F(x)
false otherwise with overwhelming probability
```

learner-long-life

Keybase proof

I hereby claim:

• I am cryptogoth on github.
• I am cryptogoth (https://keybase.io/cryptogoth) on keybase.
• I have a public key ASAiMoYKJFX-jltr1H6tAB8YheZ3MGxHjZJpjnTc8GeUAAo

To claim this, I am signing this object:

learner-long-life

for atomic swaps, as you stated in your proposal, the basic primitive is a hash time-lock contract (or those four words in a similar order :)
I don't know the exact details, but if I were to make it up from scratch, it would go something like this (a double-escrow)
most blockchains support a multisig address, one where two or more signatures are needed to spend funds, or some other secret / hash is needed which is not known beforehand but can be verified
party A and party B both have keypairs for blockchain A and blockchain B (there are 4 keypairs involved)
furthermore, most of those blockchains also support a "limited time only" feature where a temporary multisig can only be spent before a certain block number
party A on blockchain A locks up some funds in a temporary multisig, valid for time_A blocks, where the other authorization to spend is something like party B's blockchain A signature of a multisig tx on blockchain B
likewise party B on blockchain B locks up some funds in a temporary multisig, valid fo

learner-long-life

The Peculiar Balance is a device which contains a weight, of value n units, and gives you an infinite set of fixed weights
with values 1, 3, 9, 27, ... and so forth, all powers of three.

The known weight n is on the left side of the balance, and there is a right side (initially empty).

Your goal is to balance the Peculiar Balance, with a weight that you know (n), using only the fixed weights,
placed either on the right or the left side.

As a first step, given n, come up with a formula for M, the smallest fixed weight which, when placed on the
right-hand side, would tip the balance to the right (i.e. the smallest fixed weight that is still greater than n).

learner-long-life

       const validatedResult = await cxResult.minedTx(
          cxResult.ace.validateProof,
          [ JOIN_SPLIT_PROOF, cxResult.unlabeled.transfererAddress, cxResult.unlabeled.jsProofData ]
        )
        await( validatedResult['0'], 'ace.validateProof succeeds for second time with sender address' )

        expect (
          cxResult.minedTx(
            cxResult.ace.validateProof,
            [ JOIN_SPLIT_PROOF, cxResult.unlabeled.senderAddress, cxResult.unlabeled.jsProofData ]

learner-long-life

As for running your own Ethereum node, that's what you might want to do if you are going to be
making many smart contract calls for your users. Most people use Infura's free public nodes for
casual calls or development, but when they have a production system, they have to pay per 1000
smart contract calls or they can run their own dedicated Ethereum nodes. This involves maintaining
a Linux system and syncing the blockchain, and people who do this often use Amazon's hosted service, AWS.
I suspect Infura also uses AWS.

So for the same AWS credits, you could run a subgraph / GraphQL server to index the Ethereum events,
and have your front-end query it much more efficiently each time a user refreshes your website, instead
of calling the Ethereum mapping getter method repeatedly. You'll probably want to run your own subgraph server,

learner-long-life

Run Your Own Status Whisper Node

Rather than start geth with all the necessary flags and have blockchain syncing going on, you may wish to just run whisper functionality for private messaging in a lightweight way. You should always run your own node using current Whisper v6 or below, as the node administrator is able to sniff your keypairs as they are requested.

To do that, you can use Status's excellent docker image, which sadly has had its documentation taken down from here: https://status.im/docs/run_status_node.html

learner-long-life

import "./SafeMath.sol";

contract Constants {
    uint8 public constant BUY_ID = 1;
    uint8 public constant SUBSCRIBE_ID = 2;
}

contract BuyContract is Constants {
    
    uint256 public lastAmount;