looking to hire shills for reddit and 4chan.

Pls post your rates and proof you are legit.

I can build an android wallet from scratch for your coin.
PM me for details (along with github link to coins code, site etc.) and I'll give you a price.

[simple_unlock]

So current tx. is (basically) like this right;

Code:

inputs;
<unlock script>(n times)

outputs;
OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG (n times)

but this is really boilerplate. And probably like 90% of tx. are like this^. so why not have an inbuilt method to process these tx. much easier and more scalable?

so like this;

Code:

type: simple_tx,
inputs: {
  tx_id: <id> (n times)
  aggregated signature: <signature> (1 time)
}

outputs: {
  type: simple_unlock
  new_owner: <pub key>
}

so here we get rid of a lot a lot of data by making tx much more simple. Node processes inputs by searching all tx_id's and makes sure they are all of the type simple_unlock. Then it adds all the pub keys for those tx up and makes sure that the input signature matches*. Then if its valid the node adds the new outputs to the db.
if simple_unlock is used with traditional scripting unlocks outputs then it just defaults to  OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG and the spender has to provide a valid unlock script.

Using this method means that you can get size of input signatures down from O(n) to O(1). There is also space saving on the outputs because you only need to use a pub key and not other scripting stuff.

*i am not sure if ecdsa has signature aggregation? But I know schnorr does.

Is it possible that at least one of them had an exploit in them?
Making all of the transactions/addresses sent during that period vulnerable to attack?

I already know about nicehash, are there any other places?

so say there is one block 1500. the next block published is 1501_a. but at the same time another block is published 1501_b.
a node recieves 1501_a first and stores it as the main chain. but the next block is actually mined on top of 1502_b.

so now the node has to revert any changes made with block 1501_a. and change it so that it never happened but was instead 1501_b and then 1502_b.

how does the node revert the changes exactly?

the only thing i can think that has to be changed are, the utxo set would need to be edited to go back to 1500. and then 1501_b, 1502_b.
and the last block hash has to be changed to 1502_b as well as deleting 1501_b.

but how is the utxo set reverted? it means that utxos that were spent and deleted from the db after block 1502_a was processed, will have to some how be recovered again. how is this done?

IS the utxo set stored independently from the block set?

so for each block that comes in you store;
block (Key: BlockHash)
then extract each tx and store;
tx (Key: TxHash)

or is it all stored inside blocks? how does bitcoin search the db for a given utxo to verify a transaction is legitimate if it just stores the blocks?

I see in the bitcoin wiki there is something called "script" which compiles down to some bytecode to be run by a very very basic virtual machine.
Does this mean that each block is actually just a string/array of bytes when it comes in and is processed by a node?
so a block in its "true" format would look something like [0x01, 0x04, 0x0f, 0xa1.... etc. ?

and then the node that recieves the block just puts the bytes into the interpreter to be run by the bitcoin VM?
or is there some plaintext involved in the block as well? so it looks something like JSON;
{
   blockhash: 12983092....,
   transactions: [ {8123098...}, {12381923...}],
   timestamp: "08:00:23 12/09/2017"
}

which is correct? a block is pure bytecode or JSON? what would a bitcoincore node understand when receiving a new block?

from wikipedia

G is a basepoint on a curve.
Alice picks a key; d_{A} and a corresponding pub key; Q_{A} = d_{A} * G

Calculate e = HASH(m), where HASH is a cryptographic hash function, such as SHA-2.
Let z be the L_{n} leftmost bits of e, where L_{n} is the bit length of the group order n.
Select a cryptographically secure random integer k from [1,n-1].
Calculate the curve point (x_1, y_1) = k * G.
Calculate r = x_1 mod n. If r = 0, go back to step 3.
Calculate  s=k^-1(z+rd_{A}) mod n. If s=0, go back to step 3.
The signature is the pair (r,s).

But how can s be an integer since k^-1 will yield a decimal amount (e.g. 123.12347)?

What are the exact technical steps to serialize a transactions so that it is ready to be signed and the resulting signature is valid?

As I understand it a pub key is calculated by;

u = random number (private key)
(x, y) = G = Base point

uG = P = public key

my question is, if its possible to calculate the pub key with uG then since you are doing u computations already, can't you just calculate the private key from P?
Just brute force G as many times as needed until you arrive at P.

Obviously I am misunderstanding something. Is P calculated in a more efficient way than just u*G?

Is there a javascript library that lets you sign and verify a message offline with a bitcoin private key?

e.g.

Code:

import ecc from "ecc-library";

const privateKey = "5K9Rx5LtXrTCo7Rb1ZsE3rKYxinzE5Ge8Rm3xeuyXm8LyjApqyH";
const address = "1EheWoBDtpU46ioGrycKnxAkJZR7xRQ6Bt";
const message = "My message";
const signature = ecc.sign(message, privateKey); //Signs the message
ecc.isValidSignature(signature, message, address); //Checks if signature is valide

A fully decentralised (or rather, distributed) consensus algorithm in a perfect world would be where, every participant in the network has an equal voting weight on what the correct history of transactions is.

Currently no crypto has this feature... with PoW based systems anyone can effectively *buy* the chain with their hashpower. With PoS the same can be said with buying actual stake within the network in terms of coins - the same applies to DPoS, and pretty much every other consensus mechanism I have come accross... WITH the exception of IOTA - despite the fact that IOTA doesn't work yet, I think the core game theory behind it, is probably the most innovative in the entire crypto space.

Instead of incentivising transaction verification through a monetary reward within the network (i.e. a coinbase reward), transaction verification is incentivised by the user's willingness to MAKE a transaction*.

The problem with this method and the reason it doesn't work properly is that it is quite easy for an attacker to game.

In what other ways can you shift around the game theoretic model of incentivising transaction verification and honesty on the network? I think this is the key to a fully distributed network where 1 person = 1 vote.


*If you don't know how IOTA works, user's basically have to perform a PoW on two previous tx. confirming them within a DAG like structure in order to broadcast their own tx.

What is the best way to go about this?

Should i just run a full node server side and then make rpc requests to localhost to get info?
Or do i need to design a whole database and write the blocks to a specialised file somewhere?

What is the most secure way to generate a private key for a user?

Is this secure?

Hashing a password that the user inputs (longer than 10 characters with numbers, capital letters), then hashing with the current date and time, then hashing with random number generated between 1-100,000?

Does anyone know how is private key generation handled in other clients?

Edit: This is for a wallet service, so all code should be run within the browser side.

[bower install bitcore-lib]

I am asking here as a last resort...
No one has responded to the issue I opened on the github or on their forum xD

When I run: bower install bitcore-lib
I get this error: bower invalid-meta  The "main" field cannot contain minified files

I need to create bitcore-lib.min.js file so I can use in a browser.
Has anyone had this issue? How to solve it?

Thanks )

Is this a secure way to sign and publish a transaction or can the node intercept the private key?

Code:

var bitcore = require('bitcore');

let privateKey = "11111111111111111111111111";
let address = "1aaaaaaaaaaaaaaaaaaaa";
let amount = 100;

//creates transaction
var transaction = new bitcore.Transaction();
var transaction.from(<insert UTXO>).to(address, amount);
transaction.sign(privateKey);
transaction.serialize();

//Bitpay's tools
var Insight = require('bitcore-explorers').Insight;
var insight = new Insight('testnet');

//broadcasts transaction using bitpay's server
insight.broadcast(transaction, function (err, id) {
    if (err) {
      console.log(err);
    } else {
      console.log("Transaction Id: " + id);
    }
};

I am a solidity (ethereum) dev looking for a project to work on.
Does anyone know where I can go?

I heard that it's on sourceforge but would be nice if someone has any earlier links

[Join telegram group for Airdrop https://t.me/NightshadeOfficial]

Join telegram group for Airdrop https://t.me/NightshadeOfficial