Paul Pham 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:

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

	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.

	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.

	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
	```

	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

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

	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 ]

	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,

	import "./SafeMath.sol";

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

	contract BuyContract is Constants {

	uint256 public lastAmount;