Bitcoin Forum
May 01, 2024, 12:45:22 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »
1  Bitcoin / Development & Technical Discussion / Re: Forking vs. Knifing on: August 28, 2015, 09:17:53 AM
There would probably be an alert sent out by the developers and then they would decide whether to roll back the blockchain back to the fork point, or choose one chain and set checkpoints into the software to make sure that is the one used.

In this situation it would be hard to avoid using the longest chain, especially if it was a significant difference. Including a checkpoint in the software would be like declaring war on the majority hashrate, and they may well respond by locking out the minority until they'd got the money they thought they were owed...

This isn't entirely academic, because the majority hashrate is in an authoritarian regime that's long been propped up by a good economy, and that economy isn't looking good. If they felt at serious risk of a revolution it's not hard to imagine them turning off access to the outside world.

I think the upshot would be that you couldn't safely use bitcoin until the situation sorted itself out.
2  Bitcoin / Development & Technical Discussion / Re: Idea/Proposal: Dramatically increase the bitcoin block propagation speed on: August 06, 2015, 12:40:18 AM
When was the last time an invalid block was created on purpose?

Presumably in the BIP 66 fork the miners would have put up, and ultimately lost, their guarantee, because they were oblivious to the fact that the network had upgraded on them.
3  Bitcoin / Development & Technical Discussion / Re: Blockchain joke on: August 05, 2015, 03:02:02 AM
I keep clicking on this thread and expecting to see something starting "I'd tell you a blockchain joke but..."

Can someone help out with the punchline?
4  Bitcoin / Development & Technical Discussion / Re: Random block size and the fee market on: July 28, 2015, 03:59:44 AM
Another interesting thought in this area is Greg Maxwell's suggestion that you could make the block difficulty depend on the block size. A transaction with high fees could not only ensure you get into the next block, it also could increase the probability that the next block will be found quickly, because miners are incentivised to drop their block size and reduce the difficulty to increase their chances of collecting the fee. This also scales up in the opposite direction where needed to handle a capacity crunch, because if you've got a long tail of transactions waiting with a reasonable cumulative fee, you're incentivized to stretch out the block size to accomodate them.
5  Bitcoin / Development & Technical Discussion / Re: Using Pycoin to spend non-standard scripts on: July 20, 2015, 12:41:57 PM
I don't know if this is related but something seems to have changed in the way pybitcointool serializes scripts since I was working with this around:
https://github.com/vbuterin/pybitcointools/commit/87aaf6dc3f38d853dd8cb324a4eaf72ae309d322
...which I think is still the version you get if you do
pip install pybitcointool
(This is before the name changed to "bitcoin".)

I haven't had a chance to get to the bottom of this and it may be that the old version is broken and the new one is right, but you might like to try comparing what you get with the old version.
6  Bitcoin / Development & Technical Discussion / Re: BIP0074 draft proposal (dynamic rate lookup) on: July 17, 2015, 04:19:56 AM
This is cool. I'm not normally a big fan of bitcoin for point-of-sale but where I think it's really nice is for trust-but-audit-or-shame scenarios. The classic one would be a bitcoin parking meter, consisting of... a QR code in front of the space.

That said, I wonder whether people would rather use this than just use the QR code to send the customer to a web page.
7  Bitcoin / Development & Technical Discussion / Re: Bitcoin XT code enabling bigger blocks on: July 05, 2015, 12:44:26 PM
A soft fork adds limitations that make previously-valid blocks invalid, so miners who aren't enforcing _any_ limitations are effectively on the "didn't upgrade" side. But a hard fork makes blocks that were previously invalid valid, so if 75% are advertising big-block support but some miners who haven't advertised that aren't validating at all, you'll actually have more than 75% mining the big-block main chain.

PS. In reality you'll have much more than 75% advertising big-block support once the switch-over comes (if it ever does) because most miners will upgrade during the 2-week grace period rather than be left mining dead coins.

PPS. After losing money this way I doubt many miners will continue running with verification completely switched off; They have much better alternatives either by getting blocks propagated faster and mining normally or by at least verifying in parallel and giving up trying to mine on top of blocks once they've found that they're invalid.

Fair enough, but don't forget MPEX, etc. plan to sabotage any attempt to raise max_blocksize.  IE, they will falsely advertise >1MB compliance in order to (prematurely) bait the hard fork into a prearranged GavinCoin Short kill box.

This is not a serious suggestion. You'd need 25% of mining power to pull it off even if zero miners switched in the grace period, but since most of the remaining miners will switch during the grace period you need more like [conservatively] 45%. MPEX control approximately 0% of mining power, and if they were able to acquire more than 25% they could block bigger blocks the normal way by refusing to upgrade.
8  Bitcoin / Development & Technical Discussion / Re: Bitcoin XT code enabling bigger blocks on: July 05, 2015, 05:07:55 AM
BIP66 thought it had "95%" support, which in reality turned out to be 64%.

Can you elaborate? Isn't it pretty easy to ascertain if the 95% of the previous 1000 blocks version 3, or is there any confusion here?

If you think this is bad:

https://www.reddit.com/r/Bitcoin/comments/3c2cfd/psa_f2pool_is_mining_invalid_blocks/csrumgv?context=3

wait until the Gavinistas attempt their contentious fork with an ostensible (and much lower) "75%" of the network...   Cheesy

Actually it works the other way around. A soft fork adds limitations that make previously-valid blocks invalid, so miners who aren't enforcing _any_ limitations are effectively on the "didn't upgrade" side. But a hard fork makes blocks that were previously invalid valid, so if 75% are advertising big-block support but some miners who haven't advertised that aren't validating at all, you'll actually have more than 75% mining the big-block main chain.

PS. In reality you'll have much more than 75% advertising big-block support once the switch-over comes (if it ever does) because most miners will upgrade during the 2-week grace period rather than be left mining dead coins.

PPS. After losing money this way I doubt many miners will continue running with verification completely switched off; They have much better alternatives either by getting blocks propagated faster and mining normally or by at least verifying in parallel and giving up trying to mine on top of blocks once they've found that they're invalid.
9  Bitcoin / Development & Technical Discussion / Re: Elastic block cap with rollover penalties on: June 03, 2015, 06:56:07 AM
If we're making drastic changes it may be worthwhile to target balance of unspent outputs instead of / as well as block size, since UTXO size seems to be a more likely bottleneck than the network, unfortunate American core devs still connected to the internet using 1870s-style copper wires notwithstanding.
10  Bitcoin / Development & Technical Discussion / Re: Could a Bitcoin wallet replace online passwords? on: May 17, 2015, 10:23:27 PM
The real-world implementation of the keypairs-instead-of-passwords idea is client-side SSL certificates. The ability to do this has been in servers and browsers since forever.

Unfortunately the user experience has generally been a massive PITA, with the result that they're mostly confined to corporate or government systems where the security-conscious IT Department can mandate their use and the users have to suck it up. A lot of these problems are probably fixable, but as with bitcoin, the UX issues involved in generating keys and storing them securely without bollocksing it up aren't trivial.

There's a good summary here - the comments are worth a read, too.
http://pilif.github.io/2008/05/why-is-nobody-using-ssl-client-certificates/

Thanks, I'll have to dig into this. I figured I wasn't treading new ground, just can't figure out why it should be so difficult.

The depressing thing about this is that the <keygen> tag (for creating keypairs on the browser and sending the public key to the server) has been around since 1996, but here we are in 2015 and we're still waiting for something without horribly broken usability.

If some smart marketer can turn the whole bitcoin-technology-but-not-bitcoin hype into a way to get this old technology actually usefully adopted that would be a huge win... We should tell people Satoshi invented a basic authentication logout button while we're at it...
11  Bitcoin / Development & Technical Discussion / Re: Could a Bitcoin wallet replace online passwords? on: May 17, 2015, 09:26:58 AM
The real-world implementation of the keypairs-instead-of-passwords idea is client-side SSL certificates. The ability to do this has been in servers and browsers since forever.

Unfortunately the user experience has generally been a massive PITA, with the result that they're mostly confined to corporate or government systems where the security-conscious IT Department can mandate their use and the users have to suck it up. A lot of these problems are probably fixable, but as with bitcoin, the UX issues involved in generating keys and storing them securely without bollocksing it up aren't trivial.

There's a good summary here - the comments are worth a read, too.
http://pilif.github.io/2008/05/why-is-nobody-using-ssl-client-certificates/
12  Bitcoin / Development & Technical Discussion / Re: Practical ways to store a redeem script for a P2SH address on: February 03, 2015, 10:53:29 PM
If all parties use HD wallets, you can use HDM. Then you don't have to remember the public keys that were used because you can regenerate them.


In theory yes, but when multiple parties are involved you're at least going to need to store _something_ related to the other party, even if you've removed the need to store many things.

Deterministic wallets are actually making this problem more pressing, because if you already have to store and back up a bunch of random private keys then you presumably already have a process for storing and backing up new data, but nowadays people reasonably expect not to lose funds unless they lose their seed.
13  Bitcoin / Development & Technical Discussion / Practical ways to store a redeem script for a P2SH address on: February 03, 2015, 01:36:12 AM
A lot of people out there are starting to do more interesting stuff with multi-sig, often involving multiple parties combining their keys in transactions to create a P2SH address.

When one of the parties comes to actually spend whatever's been sent to that P2SH address, they're going to need the original public keys to recreate the P2SH address, even if they don't actually need the corresponding private keys that would allow them to sign. So this information needs to be stored somewhere. We want this to be around even if whatever site may have helped set up the transaction has gone away, and it probably doesn't need to be secret, since it's ultimately going to show up on the blockchain anyway. I guess that implies we want it to be mirrored in several or more places, ideally run by a mix of different people in a mix of jurisdictions.

I know there are a bunch of clever data alt-coins and things in development, but has anyone got any suggestions for something practical we can use for a web app right now? We all love P2P but if there isn't a good fully P2P solution I think the "reasonably trustworthy vendor" model is OK here, as long as you have the data synced to reasonably diverse reasonably trustworthy vendors.

Basically I guess we're looking at an append-only public data storage for shortish bits of data. (I guess the fiddly bit is how you do anti-spam, since it's hard to squeeze "pay the data storage guy" in some of these workflows until you actually do the redeem.)

I know I'm not the first person to be feeling pain here - any suggestions for something that would be good to use, or if not any thoughts about what would be a useful thing to build?
14  Bitcoin / Development & Technical Discussion / Re: Is it time to reevaluate OP_EVAL ? on: January 29, 2015, 12:32:19 PM
Now that redeem scripts can be arbitrary, I think OP_EVAL might find a new usage.

Imagine you create a redeem that can be proven by anybody knowing some secret OR owning a specific bitcoin address.

Quote
Script redeemScript = new Script(
    "OP_IF "
        + "OP_HASH256 " + Op.GetPushOp(secretHash) + " OP_EQUAL " +
    "OP_ELSE "
        + address.ScriptPubKey + " " +
    "OP_ENDIF");

Such script works fine if address is a P2PKH, however if address is a P2SH then the only condition to satisfy the ELSE branch is to know the redeem script of address.
This could be fixed with OP_EVAL by the following way. (assuming address is P2SH)

Quote
Script redeemScript = new Script(
    "OP_IF "
        + "OP_HASH256 " + Op.GetPushOp(secretHash) + " OP_EQUAL " +
    "OP_ELSE "
        "OP_DUP " + address.ScriptPubKey + " OP_EVAL" +
    "OP_ENDIF");

Sure, we could also use multi sig or public key ScriptPubKey directly in the ELSE branch, but they might not necessarily be known by the builder of the redeem script.

You could of course put the content that would have been hashed directly into one of the branches of the OP_IF, rather than trying to do these recursive script hashes. Presumably one of the parties to the transaction knows what needs to go in there, because otherwise they won't be able to spend it.

That's what I do here for Reality Keys transactions (output spendable by Alice+Yes or Bob+No or Alice+Bob):
https://github.com/edmundedgar/bitcoin-branching-transaction-builder/
15  Bitcoin / Development & Technical Discussion / Re: MultiSig BUT with Bitcoin Addresses NOT Public Keys on: January 10, 2015, 08:34:10 AM
Sweet. We should probably:
1) Write a test for the other branch as well
2) Try sending the tx to a 0.10 node before using blochain.info/pushtx on it to prove that the network will really take these things when it starts to upgrade.

1) Ok. I have to learn how to do a push request (I suck at GIT) and I'll make a suggestion to  your test.
2)  the blockchain.info method is a kind of a cheat ;-) But if it works ;-) but I'd LOVE to test that. I'm just happy it's working (and it worked. I got my 2 cents ;-) Who tests on the testnet any more ;-)


P.S. Your library will be talked about at tomorrow's Miami Bitcoin hackathon cause it's amazing. Thank you so much for helping me with this.

OK, I just went ahead and added those tests myself.

The redeem transaction went fine through a stock bitcoin 0.10, and enough of the network seems to have relayed it for it to show up on blockchain.info.
https://blockchain.info/tx/c6b283ed4f2742b3c5aca31380daa423e89620e95a53cddf3d81338dcca95b8c
Edit to add: And mined, also by Eligius. Discus Fish doesn't seem to be a thing any more...
16  Bitcoin / Development & Technical Discussion / Re: MultiSig BUT with Bitcoin Addresses NOT Public Keys on: January 09, 2015, 11:03:50 PM
Who tests on the testnet any more ;-)

I'm liking this system where an address I control is hard-coded in the test code, and people test their code by sending real money to it...
17  Bitcoin / Development & Technical Discussion / Re: MultiSig BUT with Bitcoin Addresses NOT Public Keys on: January 09, 2015, 09:36:10 PM
Just updating the group.

We have created successfully a MultiSig Signature from JUST the Bitcoin Addresses (I think we're the first to do that, can't find anyone else online doing this.)
NO PUBKEY WAS USED (well the PubKey HASH was using, but not the original uncompressed full PubKey)

See transactions IN (the first from edmundedgar with the public Keys and the second from ME using the code below)

https://blockchain.info/address/3PcxJeW5f6Tp4mVAXe4ggGRvDREAPCMF4o


Thanks of course to everyone. And especially to edmundedgar for his amazing code examples INCLUDING his private keys (which makes live easier)

You need to do a:
1) download edmundedgar's Bitcoin Branching Transaction builder: https://github.com/edmundedgar/bitcoin-branching-transaction-builder
2) run "npm install bitcoinjs-lib" on that root directory
3) Make an app.js in the root of that project with the following code below (of course you have to have NODEjs installed)

Code:
var bitcoin = require('bitcoinjs-lib');
var BranchingTransactionBuilder = require('./src/branching_transaction_builder');
var ECKey = bitcoin.ECKey;
var Address = bitcoin.Address;
var scripts = bitcoin.scripts;

var BitcoinAddress1 = "1Fratqwo3Bu2FwMBzAex8WgDbmmGgJYLGH";
var BitcoinAddress2 = "112jFbM3Lp3qRSjezGFCv2rejT3UQ6rH5Z";

var addr1 =  Address.fromBase58Check(BitcoinAddress1);
var addr2 =  Address.fromBase58Check(BitcoinAddress2);

var branch1 = scripts.pubKeyHashOutput(addr1.hash);
var branch2 = scripts.pubKeyHashOutput(addr2.hash);


var branch_builder = new BranchingTransactionBuilder();
branch_builder.addSubScript(branch1);
branch_builder.addSubScript(branch2);
var branch_redeem_script = branch_builder.script();

var scriptPubKey = bitcoin.scripts.scriptHashOutput(branch_redeem_script.getHash())
var multisigAddress = bitcoin.Address.fromOutputScript(scriptPubKey).toString()
console.log("MultiSig Address: " + multisigAddress);
console.log("Redeem script: " + branch_redeem_script.buffer.toString('hex'));            


console.log("");
console.log("Ok. Now you FUND the account with something of MORE than 0.0001 bitcoins (that's the minimum)");
console.log("");

// Make Transaction
var Transaction = bitcoin.Transaction;
var TransactionBuilder = bitcoin.TransactionBuilder;

var BitcoinToSendTo = "1GzUEmh472VwWydkhY4vDQMqY3xFpZRcKs";
var addrToSendTo = Address.fromBase58Check(BitcoinToSendTo);
var branchToSendTo = scripts.pubKeyHashOutput(addrToSendTo.hash);

// Just repeating what's above to reiterate and segregate the code
BitcoinAddress2 = "112jFbM3Lp3qRSjezGFCv2rejT3UQ6rH5Z";
addr2 =  Address.fromBase58Check(BitcoinAddress2);
branch2 = scripts.pubKeyHashOutput(addr2.hash);

// Unspent amount: from https://blockchain.info/unspent?active=3PcxJeW5f6Tp4mVAXe4ggGRvDREAPCMF4o
            var test_output = {"unspent_outputs":[
                    {
                        "tx_hash":"3be8387e161bfc927cd4d06e4f1a800806ba509f74185709ee460967fe1d57c5",
                        "tx_hash_big_endian":"c5571dfe670946ee095718749f50ba0608801a4f6ed0d47c92fc1b167e38e83b",
                        "tx_index":74160687,
                        "tx_output_n": 0,
                        "script":"a914f08e151def9e83a2d96b44b5d87c719dcd374d8a87",
                        "value": 200000,
                        "value_hex": "030d40",
                        "confirmations":0
                    }
            ]};


var branch_redeem_script2 = branch_builder.script(branch_redeem_script.buffer.toString('hex'));
var spend_builder = new TransactionBuilder();
spend_builder.addInput(test_output['unspent_outputs'][0]['tx_hash_big_endian'], 0);
spend_builder.addOutput("1Dc8JwPsxxwHJ9zX1ERYo9q7NQA9SRLqbC", test_output['unspent_outputs'][0]['value'] - 10000);


var priv2 = ECKey.fromWIF('L3MRgBTuEtfvEpwb4CcGtDm4s79fDR8UK1AhVYcDdRL4pRpsy686');
var gp_builder = new BranchingTransactionBuilder(spend_builder);

// input 0 of the tx, second branch of 2 (index 1)
gp_builder.selectInputBranch(0, 1, 2);
gp_builder.signBranch(0, priv2, branch_redeem_script2, null, branchToSendTo);
var tx = gp_builder.build();

console.log(tx.toHex());


Sweet. We should probably:
1) Write a test for the other branch as well
2) Try sending the tx to a 0.10 node before using blochain.info/pushtx on it to prove that the network will really take these things when it starts to upgrade.
18  Bitcoin / Development & Technical Discussion / Re: MultiSig BUT with Bitcoin Addresses NOT Public Keys on: January 09, 2015, 01:05:07 PM

@edmundedgar; using your code and  your "bitcoin-branching-transaction-builder" project (and Peter Todd's public Bitcoin Address so he could sign a TRANSACTION)

Code:
var bitcoin = require('bitcoinjs-lib');
var BranchingTransactionBuilder = require('./src/branching_transaction_builder');
var Script = bitcoin.Script;

var BitcoinAddress1 = "1KYestTGTEJzM5pR7AAQ7ckBE55ytLRaDk";
var BitcoinAddress2 = "1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv";
var rules = "OP_IF OP_DUP OP_HASH160 "+ BitcoinAddress1 + " OP_EQUALVERIFY OP_CHECKSIG. OP_ELSE OP_DUP OP_HASH160 " + BitcoinAddress2 + "  OP_EQUALVERIFY OP_CHECKSIG. OP_ENDIF";
var NewP2SHAddress = Script.fromASM(rules);

console.log(NewP2SHAddress.buffer.toString('hex'));


 I get a bitcoin address of: 6376a90088006776a900880068

Is this right? Where is the redeemScript


I just added a quick test for branching versions of pay-to-public-key-hash - hopefully this will make it clearer how it's supposed to work. Basically bitcoinlib-js takes care of making the bits inside the OP_IF branching, and my thing takes care of putting them together in a branching script, so you don't need to put in your own scripting from the ASM code or anything.
https://github.com/edmundedgar/bitcoin-branching-transaction-builder/blob/master/test/branching_transaction_builder.js#L81

Blockchain.info took my redeeming TX (the non-standard one) - let's see if it'll confirm in a reasonable time (or at all...)
https://blockchain.info/tx/7d8cf0dac56e90bfff76cee1a13464cc07f0ac36241b6703a894d28987630218
Edit to add: Yup, Eligius took it.

Some of the other suggestions people have made here will be variously more flexible (for more combinations of conditions) and more economical (in saving a few bytes) than mine, but you'll have to work out how to sign them since my code won't help you. YMMV, let us know how you get on...
19  Bitcoin / Development & Technical Discussion / Re: MultiSig BUT with Bitcoin Addresses NOT Public Keys on: January 08, 2015, 10:39:26 PM
Technically an address can be created from the hash of a custom script (P2SH) but I am unsure if there are the necessary op_codes in the scripting language to allow you to validate against signature of one of many pubkeyhashes.

You can do "or" cases like this with branching OP_IFs (inside P2SH). Simplest case 1/2:

Code:
OP_IF
OP_DUP OP_HASH160 <address1> OP_EQUALVERIFY OP_CHECKSIG.
OP_ELSE
OP_DUP OP_HASH160 <address2> OP_EQUALVERIFY OP_CHECKSIG.
OP_ENDIF

...then sign with an OP_1 or OP_0 flag on the end to say which branch should be used.

For JavaScript this may help:
https://github.com/edmundedgar/bitcoin-branching-transaction-builder
I haven't tried it for this specific case, but I think it would be OK.

This is currently non-standard, but it should become standard as people start running bitcoin 0.10. In the meantime you should be able to broadcast it with blockchain.info, and it should get mined by Discus Fish or Eligius, which will generally get it mined in an hour or two.
20  Bitcoin / Development & Technical Discussion / Re: MultiSig BUT with Bitcoin Addresses NOT Public Keys on: January 08, 2015, 10:29:25 PM
Thank you DeathAndTaxes;

How can I make a multiSig address with just regular Bitcoin Addresses?

I'm trying to create a bitcoin address where any ONE of TWO (or THREE) bitcoin private addresses can SIGN a transaction.

You could make a special script to do this, but you'd probably need some special software to sign it. Is that an acceptable requirement? If so we can talk about the best way to script it.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!