Bitcoin Forum
August 23, 2017, 02:44:19 AM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: 1 2 3 [All]
  Print  
Author Topic: Auxiliary block: Increasing max block size with softfork  (Read 12343 times)
jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
August 29, 2013, 04:10:56 PM
 #1

I just realize that the 1MB block size limit could be increased with a softfork. I call it auxiliary block:

1. An auxiliary block is created for each main block. Auxiliary block looks like a traditional block without the header.

2. OP_NOP1 is redefined as OP_AUX

3. Initially, auxiliary blocks are empty, until someone sends X bitcoin to a scriptPubKey of this format: <serialized script x> OP_AUX. This will create a coinbase-like transaction in the auxiliary block, with X bitcoin sending to <deserialized script x>. The Merkle Root of the auxiliary block will be included in the coinbase of the main block. All upgraded nodes will check whether the bitcoins are correctly transferred from the main chain to the aux chain

4. People can transfer aux chain bitcoins like in the main chain. Miners can also collect fee in the aux chain using the same mechanism as the main chain. The only difference is there is no generation bonus in aux chain. New aux coins are generated if and only if someone send bitcoins to <serialized script> OP_AUX in the main chain

5. When someone want to transfer Y aux coins back to the main chain, he will send Y aux coins to a scriptPubKey of this format: <serialized script y> OP_AUX OP_RETURN. Seeing this, the miner will randomly choose some OP_AUX UTXO in the main chain, with value exactly equals to Y bitcoins, and pass them to <deserialized script y> in the main chain.

Backward compatibility:

1. Since old nodes will not see the aux block, the aux block could be indefinitely big

2. The OP_AUX outputs look like anyone-can-redeem so old nodes won't complaint.

3. If some try to steal these OP_AUX outputs without following the new rules, however, they will be rejected by the majority of miners.

4. Old nodes can still mine. As long as they are not trying to include or redeem OP_AUX transactions, their blocks are still valid.

(More extremely, we may disallow people transferring aux coin back to the main chain by requesting them to send bitcoin to <serialized script x> OP_AUX OP_RETURN on the main chain. This will provide better backward compatibility since such outputs are not redeemable in both new and old nodes, and old miners would see these as non-standard and won't mine them)

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1503456259
Hero Member
*
Offline Offline

Posts: 1503456259

View Profile Personal Message (Offline)

Ignore
1503456259
Reply with quote  #2

1503456259
Report to moderator
1503456259
Hero Member
*
Offline Offline

Posts: 1503456259

View Profile Personal Message (Offline)

Ignore
1503456259
Reply with quote  #2

1503456259
Report to moderator
1503456259
Hero Member
*
Offline Offline

Posts: 1503456259

View Profile Personal Message (Offline)

Ignore
1503456259
Reply with quote  #2

1503456259
Report to moderator
TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
August 29, 2013, 04:23:37 PM
 #2

This means that there is always a one to one mapping of aux-block to main block?

What happens if there is a block with no aux-block (say mined by an old miner)?  I assume it is just like a main chain block, but with no transactions?

Miners would refuse to build on new blocks if there is no aux-block?  Would you foresee a new message type? 

In fact, what happens if you send extra data in a "block" message?  I assume it is basically ignored?

The extended block, could be of the form


...
...
varInt: n = number of transactions in main block
tx[n]: transactions
varInt: m = number of extra transactions
aux-tx[m]

I think the current client basically ignores extra fields.

This would allow blocks of 32MB.  You need a way to split blocks over multiple messages to go above that,

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106


View Profile
August 29, 2013, 04:38:41 PM
 #3

What's really interesting about this approach is how users and miners are both required to buy into a larger blocksize, which means that adopting a larger blocksize requires the economic majority to convincingly show that they do in fact wish it to happen. Note how SPV users are required to accept the change as well if they want to accept aux-block coins as payment.

jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
August 29, 2013, 04:40:23 PM
 #4

If there is no aux transaction, there will be no aux-block, even from a upgraded miner. So basically aux-blocks do not form a chain. They are the extension of the main blocks, indicated by the Aux-Merkle-Root in the main-coinbase.

For backward compatibility, aux-block will not be sent to old nodes. A new command like getauxblock will be used among new nodes.


This means that there is always a one to one mapping of aux-block to main block?

What happens if there is a block with no aux-block (say mined by an old miner)?  I assume it is just like a main chain block, but with no transactions?

Miners would refuse to build on new blocks if there is no aux-block?  Would you foresee a new message type? 

In fact, what happens if you send extra data in a "block" message?  I assume it is basically ignored?

The extended block, could be of the form


...
...
varInt: n = number of transactions in main block
tx[n]: transactions
varInt: m = number of extra transactions
aux-tx[m]

I think the current client basically ignores extra fields.

This would allow blocks of 32MB.  You need a way to split blocks over multiple messages to go above that,

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
August 29, 2013, 04:54:47 PM
 #5

What's really interesting about this approach is how users and miners are both required to buy into a larger blocksize, which means that adopting a larger blocksize requires the economic majority to convincingly show that they do in fact wish it to happen. Note how SPV users are required to accept the change as well if they want to accept aux-block coins as payment.

And since this is a soft-fork, it avoids a lot of political considerations. Anyone with 51% hashing power could implement this (if they can code)

Just a minor note: just like v2 block, the aux-coinbase must include the height of the corresponding main block to avoid crash of tx hash.

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
August 29, 2013, 05:08:33 PM
 #6

With aux-block, some other hardforks could also become softforks. For example, the calculation of tx hash in aux-block may exclude scriptSig, so transactions are identified purely by their inputs and outputs.

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
d'aniel
Sr. Member
****
Offline Offline

Activity: 461


View Profile
August 29, 2013, 06:30:21 PM
 #7

3. If some try to steal these OP_AUX outputs without following the new rules, however, they will be rejected by the majority of miners.
Get majority hash power, steal all the coins?  (Or at least a very large amount, potentially.)  This creates a huge incentive to commit a "51% attack", does it not?
TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
August 29, 2013, 06:39:19 PM
 #8

Get majority hash power, steal all the coins?  (Or at least a very large amount, potentially.)  This creates a huge incentive to commit a "51% attack", does it not?

You can only steal coins from people who don't upgrade.  A soft fork is a fork that the obsoleted clients will still accept (if it has enough POW).

And since this is a soft-fork, it avoids a lot of political considerations. Anyone with 51% hashing power could implement this (if they can code)

I would strongly recommend that it also includes an alt-header.  That way new fields can be more easily added.  It is not possible to indefinitely use 32 bytes of coinbase space for everything.

If the alt-block had a variable length header field (old clients ignore new fields), then you can use the same 32 coinbase bytes for all extensions.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
nomailing
Full Member
***
Offline Offline

Activity: 126


View Profile
August 29, 2013, 07:17:49 PM
 #9

Get majority hash power, steal all the coins?  (Or at least a very large amount, potentially.)  This creates a huge incentive to commit a "51% attack", does it not?
You can only steal coins from people who don't upgrade.  A soft fork is a fork that the obsoleted clients will still accept (if it has enough POW).

I thought just the contrary: With more than 50% you could steal all coins in the aux-blocks of upgraded users, because
2. The OP_AUX outputs look like anyone-can-redeem so old nodes won't complaint.

So old nodes wouldn't complain if a miner would transfer all coins from the aux-blocks to his own address.
The only incentive for miners to not do this, is that they know that these blocks would be considered invalid by more than 50% of hashing power if most miners have upgraded.

BM-2D9KqQQ9Fg864YKia8Yz2VTtcUPYFnHVBR
nomailing
Full Member
***
Offline Offline

Activity: 126


View Profile
August 29, 2013, 07:22:00 PM
 #10

But, wouldn't the system be incompatible for miners with old software (without the upgrade).
Some attacker (does not need to be a miner, just a regular client) might create transactions to redeem the coins in the aux-block. These transactions would seem valid for old miners. These miners with old versions would accept these transactions and therefore their blocks would be invalid for upgraded miners.

Or maybe I didn't understand something of the idea?

BM-2D9KqQQ9Fg864YKia8Yz2VTtcUPYFnHVBR
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2268



View Profile
August 29, 2013, 07:39:04 PM
 #11

Once a transaction is in the aux block all of its children must forevermore be in the aux block.

This was also how I thought we could implement a new transaction syntax (one that makes the scriptsigs prunable) and switch to using hash-sum trees to make the coinbase value provable: move all txn into a separate tree eventually, and eventually require that the only txn in a block be the coinbase.

The downside is that until the transition is complete you have degraded fungibility with two kinds of Bitcoins.

Bitcoin will not be compromised
TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
August 29, 2013, 08:03:28 PM
 #12

So old nodes wouldn't complain if a miner would transfer all coins from the aux-blocks to his own address.

If an attacker did that, then he would fork the chain.  "Soft-fork" is actually relative.  It means that there are 2 sets of rules, but the majority of the hashing power supports the more restrictive rules.

This means that blocks that are banned by the restrictive rules are orphaned by a majority of the hashing power.

A soft fork switches to an actual fork (2 incompatible chains), if the majority of the hashing power deserts it.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
August 30, 2013, 01:15:57 AM
 #13

Once a transaction is in the aux block all of its children must forevermore be in the aux block.

This was also how I thought we could implement a new transaction syntax (one that makes the scriptsigs prunable) and switch to using hash-sum trees to make the coinbase value provable: move all txn into a separate tree eventually, and eventually require that the only txn in a block be the coinbase.

The downside is that until the transition is complete you have degraded fungibility with two kinds of Bitcoins.

With this approach, we could change pretty much everything in the protocol with soft-fork. Just some examples:

  • The way to calculate tx hash
  • Coin divisibility
  • New fields in block header and transaction
  • Native color coin support
  • Shorten block time interval
  • Ultimately, we could trim the original Satoshi protocol to absolutely minimal (probably except the few involving block headers like double SHA256 PoW and Merkle Tree), and implement a completely new set of rules

For the fungibility problem, a very aggressive solution is to create a genesis-aux-block with all UTXO in the main chain. New miners will collect their reward in the aux-chain only, and they will reject any main chain tx except the dummy coinbase tx with zero value. So all old nodes are broken immediately, but it's still a softfork because the PoW is still valid for them. I call this the ultimate-51%-attack.


Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
August 30, 2013, 01:56:35 AM
 #14

Unfortunately, this also means that 51% miners could violate the Satoshi philosophy. They could print as many  aux coins as they want, steal ancient aux UTXO,  etc. Minority users need to hardfork if they don't like these rules.

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
August 30, 2013, 07:04:22 AM
 #15

So old nodes wouldn't complain if a miner would transfer all coins from the aux-blocks to his own address.

If an attacker did that, then he would fork the chain.  "Soft-fork" is actually relative.  It means that there are 2 sets of rules, but the majority of the hashing power supports the more restrictive rules.

This means that blocks that are banned by the restrictive rules are orphaned by a majority of the hashing power.

A soft fork switches to an actual fork (2 incompatible chains), if the majority of the hashing power deserts it.

If a soft fork is implemented correctly, there will be no fork at all. (see the v1 to v2 block transition)

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2268



View Profile
August 30, 2013, 07:07:15 AM
 #16

Unfortunately, this also means that 51% miners could violate the Satoshi philosophy. They could print as many  aux coins as they want, steal ancient aux UTXO,  etc. Minority users need to hardfork if they don't like these rules.
You can see someone attempting this right now with "mastercoin" which is apparently supposed to be an alt-coin which forces Bitcoin nodes to store its data by stuffing them in perpetually non-redeemable utxo... so it even goes a step beyond undermining the rules with an alternative system, it moots pruning in Bitcoin and would eventually— if successful— make it much harder to run a validating node.

Bitcoin will not be compromised
TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
August 30, 2013, 08:16:43 AM
 #17

If a soft fork is implemented correctly, there will be no fork at all. (see the v1 to v2 block transition)

Right, the question was what happens if 51% violate the rules of the soft fork, after it has been accepted.

The miners of 750 of the last 1000 blocks add "/AUXBL/" to their coinbase

This proves that miners support the (soft) fork

Once that happens, the change is "locked-in".  New blocks that violate the new rules are simply rejected and new clients have the rule built in.

New clients and old client all track the same main chain.  Miners still using the old rules are orphaned almost immediately.

An attacker arrives (with 51%) and violates the new rules.  This converts a (correctly implemented) soft fork into an actual fork.  All old clients follow the attacker and all new clients follow the updated rules.

The attack has split the network.

If the soft fork rule allowed reversion, then after 1000 blocks, even the new clients will follow his chain, since less than 750 of the last 1000 blocks will have the coinbase message.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
johnyj
Legendary
*
Offline Offline

Activity: 1820


Beyond Imagination


View Profile
August 30, 2013, 11:05:36 AM
 #18

I still think it is mush safter to phase-in an agreed change instead of a fork. A fork is very likely to create some confusion and unpredictable behavior for miners/nodes/merchants

MatthewLM
Legendary
*
Offline Offline

Activity: 1092



View Profile WWW
August 30, 2013, 11:12:47 AM
 #19

The thing I don't like is that all of the workarounds to create soft-forks make bitcoin unnecessarily more complicated. A hard fork set for some date in the future allowing people time to upgrade would be much more simple.

Bitcoin Extra Wallet | Peercoin Android Wallet
BTC: 1D5A1q5d192j5gYuWiP3CSE5fcaaZxe6E9  PPC: PH7fVn1Xs7nkUFmdwCX2ZRYfLPCSwGxAq9
jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
August 30, 2013, 04:49:07 PM
 #20

The thing I don't like is that all of the workarounds to create soft-forks make bitcoin unnecessarily more complicated. A hard fork set for some date in the future allowing people time to upgrade would be much more simple.

The complicated part should be transparent to users. Eventually, all tx will happen in the aux block, leaving only a dummy coinbase tx in the main block (which works as extended block header). The risk of hardfork is too high and I believe it should be used only in absolutely necessary cases like:

  • Bug fix like BIP50
  • Timestamp overflow in year 2106
  • SHA256 is completely compromised

I believe these are the ONLY scenarios that a hardfork is unavoidable. Please point out other scenario if anyone finds one.

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
September 10, 2013, 03:40:51 AM
 #21

The thing I don't like is that all of the workarounds to create soft-forks make bitcoin unnecessarily more complicated. A hard fork set for some date in the future allowing people time to upgrade would be much more simple.
Yeah, that's one thing that really worries me. This works, but it's a complete hackjob. That is one of many reasons why I decided against releasing this idea earlier this year, but it looks like someone else independently thought of it. Oh well.

Anyway, let me add my thoughts to this. First off, in the main-chain to aux-chain transaction, you could use that script with P2SH to make these transactions fully transparent, backward compatible, and standard all the way back to 0.6.0. The script for these transactions would only need to be revealed once the transaction is spent in the aux-chain. An interesting benefit of doing it this way is that it allows transactions to be sent to aux-addresses even in blocks that contain no aux-block. These transactions also don't need to be recorded in the aux-coinbase, since each client can independently convert the transaction to an aux-transaction once they have the script.

Secondly, on the return trip from the aux-chain to the main-chain, the transactions being sent should be sent to fees and picked up in the coinbase and sent to the designated scripts, that way they get locked for 100 blocks for all clients. This is important because a reorg would otherwise result in a different transaction hash for the aux-to-main transaction on the main chain side, breaking any transaction that may have depended on that transaction, even if that wasn't intended.

And yes, pretty much any hardfork short of changing the monetary supply can be done with a softfork using this technique. And even that can be done if auxcoins aren't redeemable 1:1 with mainchain bitcoins. That is why I opted not to release this idea. This is extremely powerful and must be handled with care.

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2268



View Profile
September 10, 2013, 04:02:12 AM
 #22

That is why I opted not to release this idea. This is extremely powerful and must be handled with care.
I guess it was kinda pointless to not bother talking about it, a lot of people realized the same thing and amusingly also decided to not brag about it.

Llike the stuff I was proposing in the covenants thread: it feels like it has a lot of danger to be used in powerfully stupid ways that hurt fungibility.

That said...  Say there was change to core blockchain functionality that  51% of the bitcoin owners (however you want to measure it) really wanted... and 49% thoroughly opposed.  I think it would be immoral for the majority to force that onto the minority (if you make the minority small enough, I think this argument fails at some point— but for 49% it holds fine).   And yet, I think it's also wrong (if not immoral— after all, they adopted foo by their own free choice as it was—, just unoptimal and probably not stable) to not give the _majority_ what they want.

I think I've thought situations would be resolved through things like altcoins and gradual market forces. ... if you have foo and you want bar.. you don't _force_ with your majority-clique-power all the foo users to become bar users, you sell your foo and buy bar.  And if both foo and bar are good local design-space minima which are distinct from each other (e.g. I don't think ~any of the altcoins existing have this property) perhaps they'll both happily coexist without one forcing the other out of the market through network effect.

The point being, that it may be ultimately better for foo users if bar exists as part of foo but in a way which minimally disrupts foo, instead of as something wholly distinct. Degrading fungibility is sad, but I don't think its more sad than coercive action by the majority through protocol changes, or more sad than an even greater fungibilty loss switching to an entirely separate system.

So while I certainly wouldn't rush out to create such a thing, I think there is room for us to entertain ideas in this space without feeling that it is abhorrent to the idea of Bitcoin.

Bitcoin will not be compromised
jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
September 10, 2013, 04:19:29 AM
 #23

Quote
And yes, pretty much any hardfork short of changing the monetary supply can be done with a softfork using this technique. And even that can be done if auxcoins aren't redeemable 1:1 with mainchain bitcoins. That is why I opted not to release this idea. This is extremely powerful and must be handled with care.

I didn't realize it is so powerful when I first proposed it. Now I believe everything can be done with a softfork, except changing the format of block header and coinbase tx. I wonder if Satoshi was aware of this when he designed the protocol.

Anyway, I have (unintentionally) opened the Pandora's box. This reminds us that a 51% attacker could do a lot more than we usually think.

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
September 10, 2013, 04:24:41 AM
 #24

With the aux-block technique, we could release CoinCovenants from limbo  Roll Eyes


Llike the stuff I was proposing in the covenants thread: it feels like it has a lot of danger to be used in powerfully stupid ways that hurt fungibility.


Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2268



View Profile
September 10, 2013, 04:28:59 AM
 #25

This reminds us that a 51% attacker could do a lot more than we usually think.
Dunno there: someone with a bunch of hashpower can't make anyone actually use whatever crap they add to their blocks.

Bitcoin will not be compromised
jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
September 10, 2013, 04:36:10 AM
 #26

This reminds us that a 51% attacker could do a lot more than we usually think.
Dunno there: someone with a bunch of hashpower can't make anyone actually use whatever crap they add to their blocks.

Attackers can reject any tx that is not following their rules. Other people could either follow, or hardfork

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2268



View Profile
September 10, 2013, 04:42:36 AM
 #27

Fortunately since it would take a conspiracy or compromise of at least _three_ people to have control over 50% of Bitcoin's mining hashpower today, so we can be quite confident that such an outcome is completely infeasible.

Bitcoin will not be compromised
Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
September 10, 2013, 05:32:12 AM
 #28

This reminds us that a 51% attacker could do a lot more than we usually think.
With this, it's not attackers we should be worried about. Think about it: changing the max block size just became as painless to the community as changing the protocol to prevent duplicate transaction ids was. Take that as you will, for better or for worse.

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2268



View Profile
September 10, 2013, 05:52:24 AM
 #29

With this, it's not attackers we should be worried about. Think about it: changing the max block size just became as painless to the community as changing the protocol to prevent duplicate transaction ids was. Take that as you will, for better or for worse.
Woah woah, you've taken a reasonable point and exaggerated it here. A softforking rule that just denies some kinds of transactions is not the same as having clients that have to accept whole different kinds of invisible bitcoins. You still have to change the client software to be able to see or spend your bloatcoins.

(But then again with 200k users or whatever being on BC.i we can probably just dispense with the blockchain in any case…)

Bitcoin will not be compromised
Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
September 10, 2013, 06:43:47 AM
 #30

With this, it's not attackers we should be worried about. Think about it: changing the max block size just became as painless to the community as changing the protocol to prevent duplicate transaction ids was. Take that as you will, for better or for worse.
Woah woah, you've taken a reasonable point and exaggerated it here. A softforking rule that just denies some kinds of transactions is not the same as having clients that have to accept whole different kinds of invisible bitcoins. You still have to change the client software to be able to see or spend your bloatcoins.
Technically, that's correct. Practically, my statement is dead on. Usurping Bitcoin is as easy as getting 51% of the hashing power and some number of users (doesn't need to be a majority, just a few percent) on your side. We need to think long and hard about the implications this will have in the future.

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2268



View Profile
September 10, 2013, 07:02:50 AM
 #31

Technically, that's correct. Practically, my statement is dead on. Usurping Bitcoin is as easy as getting 51% of the hashing power and some number of users (doesn't need to be a majority, just a few percent) on your side. We need to think long and hard about the implications this will have in the future.
I think you need to think through your attack a bit more.

If you are imagining something as simple as "deny all new transactions, mine just blocks committing to MegaBitcoin auxblocks with 21 trillion coins instead" then it would be simple enough for the honest Bitcoin users to ignore blocks with the MegaBitcoin Commitments in them.

So instead I think your attack is a weaker versions of an attack where you merge mine Bitcoin with an altcoin and DOS bitcoin and do all your stuff in your altcoin. At least then it's harder for Bitcoin users to fork off your blocks by their shape.

Of course, if you're using a majority of hashpower to DOS bitcoin you've disprove one of the fundamental security assumptions (arguably the current hashpower distribution is already disproving them, but its not clear how fast that would change if there was an attack) and so what would be the point of your MegaBitcoin?  If you want to trust a cooperating conspiracy, there are far more efficient ways to interact with them for finical purposes.

So really this just sounds like "if you can get a conspiracy of a majority of hashpower you can kill bitcoin" but we've always known that— thats what it said on the tin.

... When I stop having problems with people paying to me on a P2SH address, adopted at the beginning of 2012— you can't send to them in half the clients apps, including ones promoted on Bitcoin.org, or via many popular webwallets or commercial services, even though the change is a couple lines of code and is economically neutral... I might start worrying more about "in practice" more. Experience shows that having some network rules does far less than you might guess.

Bitcoin will not be compromised
jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
September 10, 2013, 03:57:38 PM
 #32


Anyway, let me add my thoughts to this. First off, in the main-chain to aux-chain transaction, you could use that script with P2SH to make these transactions fully transparent, backward compatible, and standard all the way back to 0.6.0. The script for these transactions would only need to be revealed once the transaction is spent in the aux-chain. An interesting benefit of doing it this way is that it allows transactions to be sent to aux-addresses even in blocks that contain no aux-block. These transactions also don't need to be recorded in the aux-coinbase, since each client can independently convert the transaction to an aux-transaction once they have the script.

Secondly, on the return trip from the aux-chain to the main-chain, the transactions being sent should be sent to fees and picked up in the coinbase and sent to the designated scripts, that way they get locked for 100 blocks for all clients. This is important because a reorg would otherwise result in a different transaction hash for the aux-to-main transaction on the main chain side, breaking any transaction that may have depended on that transaction, even if that wasn't intended.


Interesting idea. So an aux-coinbase is needed only for collecting aux-fee and it's more block space efficient. A drawback is the need to store all genesis aux-transactions as they are required to redeem the locked fund in the main chain (though the people who want to redeem may supply such info to miners)

There are different approaches to push the new protocol.

1. The one in OP is (I believe) the gentlest way. It allows people move between old and new protocol, and guarantee full fungibility of old and new coins. If there is any value difference between old and new coins, arbitrageurs will close the gap. The problem is that would make the protocol more complicated. After the majority of people have moved to aux block, we may stop processing any traditional transaction in the main chain*, and stop allowing people to redeem main-coin with aux-coin. All these could be done with further soft-forks. However, we can never completely obsolete the main block because some main-UTXO (e.g. lost coins) will always exist. (* with the P2SH suggested above, one needs to spend the coin at the aux-block immediately to show that's not a traditional P2SH transaction.)

2. The other solution is to create a no-return system from the beginning, as gmaxwell suggested at https://bitcointalk.org/index.php?topic=283746.msg3037821#msg3037821 . Actually I think this is not a good idea because no one would want to be the guinea pig to send bitcoins to the aux block, with the risk of being locked in limbo. As a result, the value of aux-coin will be lower than main-coin, and further reinforce the reluctance to the transition. Even if the aux system is superior than the old one, it still won't be adopted. Therefore, any no-return system must be accompanied by banning any traditional transaction, as suggested above.

3. A very rude way is to move all UTXO to the aux chain at a pre-defined block height, and prohibit any main-transaction forever. This is also the cleanest way as it will leave nothing but a dummy coinbase tx in the main block. However, its impact is same as a hardfork since all old nodes will be broken immediately, so it may be easier to implement a hardfork directly.

4. We can combine approaches 1 and 3. Approach 1 is implement at first. The code, however, further indicates that the approach 3 will be adopted if >95% miners agree and >70% of UTXO are in the aux-chain.


Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
September 10, 2013, 04:09:08 PM
 #33

3. A very rude way is to move all UTXO to the aux chain at a pre-defined block height, and prohibit any main-transaction forever. This is also the cleanest way as it will leave nothing but a dummy coinbase tx in the main block. However, its impact is same as a hardfork since all old nodes will be broken immediately, so it may be easier to implement a hardfork directly.

It is similar to a scheduled hard-fork.  Old clients will just stop working.  

It wouldn't be possible to send an old client fake transactions, since they will still track the block chain.  All blocks will just be empty.  

When someone tries to send a transaction, they will wonder why it never confirms (and find out that they need to download a new client).

This is pretty much equivalent to destroying Bitcoin v1 and salting the earth, so it can't be revived in its original form, while simultaneously creating a new coin on the ashes.

Having said that, if people wanted to continue, they could just blacklist the now empty blocks.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
September 10, 2013, 04:58:02 PM
 #34

It wouldn't be possible to send an old client fake transactions, since they will still track the block chain.  All blocks will just be empty.  

This is probably the strongest argument for doing a softfork instead of hardfork.

Having said that, if people wanted to continue, they could just blacklist the now empty blocks.

Yes. In any fork, soft or hard, people always have the option to follow the original one.

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
September 10, 2013, 06:52:50 PM
 #35

Technically, that's correct. Practically, my statement is dead on. Usurping Bitcoin is as easy as getting 51% of the hashing power and some number of users (doesn't need to be a majority, just a few percent) on your side. We need to think long and hard about the implications this will have in the future.
I think you need to think through your attack a bit more.
The problem is that I'm not referring to what is generally accepted to be considered an "attack". If that were the case, I would have contacted Gavin about this issue long ago. The problem with this, which is far more subtle than an "attack", is that now the Bitcoin "contract" can be violated with a mere simple-majority support. That's why I didn't tell any developers about this method (although I would have if the block size became a major issue and no hardfork was in sight).

Interesting idea. So an aux-coinbase is needed only for collecting aux-fee and it's more block space efficient. A drawback is the need to store all genesis aux-transactions as they are required to redeem the locked fund in the main chain (though the people who want to redeem may supply such info to miners)
We get that for free. When the main-to-aux txout gets spent on the aux chain, the script needed to redeem the transaction on the main chain is revealed and is stored in the aux chain as part of that transaction's txin. The txout that is left behind on the main chain would remain in the main chain's UTXO tree, since you have to keep that separate tree for compatibility, anyway. All of the information needed to redeem those transactions later on the main chain can therefore be gathered from the raw, unpruned blocks, just like how our UTXO tree is today. Miners could safely drop the information linking the UTXOs to their redemption script, true, but I'd question how much memory that would really save, especially because miners could safely defrag the main-to-aux UTXOs by adding more inputs than needed for the aux-to-main transaction and creating a single change anyone-can-redeem output.

There are different approaches to push the new protocol.

1. The one in OP is (I believe) the gentlest way. It allows people move between old and new protocol, and guarantee full fungibility of old and new coins. If there is any value difference between old and new coins, arbitrageurs will close the gap. The problem is that would make the protocol more complicated. After the majority of people have moved to aux block, we may stop processing any traditional transaction in the main chain*, and stop allowing people to redeem main-coin with aux-coin. All these could be done with further soft-forks. However, we can never completely obsolete the main block because some main-UTXO (e.g. lost coins) will always exist. (* with the P2SH suggested above, one needs to spend the coin at the aux-block immediately to show that's not a traditional P2SH transaction.)

3. A very rude way is to move all UTXO to the aux chain at a pre-defined block height, and prohibit any main-transaction forever. This is also the cleanest way as it will leave nothing but a dummy coinbase tx in the main block. However, its impact is same as a hardfork since all old nodes will be broken immediately, so it may be easier to implement a hardfork directly.

4. We can combine approaches 1 and 3. Approach 1 is implement at first. The code, however, further indicates that the approach 3 will be adopted if >95% miners agree and >70% of UTXO are in the aux-chain.

And if we want, after we've DoSed Bitcoin v1 for some time, we could drop support for the Bitcoin v1 chain altogether, allowing us to create a new blockheader for the aux-chain, therefore making it completely independent of Bitcoin v1. This should be safe, because the difficulty would be absurdly high and there would be no fees that could be collected by main-chain-only miners, so almost every miner would switch. It would take years for someone to generate a single block on that chain after the drop-dead date, so old clients couldn't be abused. If needed, we could even drop the v1 UTXO tree at that time, but that shouldn't be necessary unless we fundamentally change the way transactions work (like if we don't allow ECDSA for signatures in aux-transactions) and we want to drop the legacy transaction code.

God, now I feel like we're engineering the IPv4 to IPv6 transition...

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2268



View Profile
September 10, 2013, 07:04:39 PM
 #36

Technically, that's correct. Practically, my statement is dead on. Usurping Bitcoin is as easy as getting 51% of the hashing power and some number of users (doesn't need to be a majority, just a few percent) on your side. We need to think long and hard about the implications this will have in the future.
I think you need to think through your attack a bit more.
The problem is that I'm not referring to what is generally accepted to be considered an "attack". If that were the case, I would have contacted Gavin about this issue long ago. The problem with this, which is far more subtle than an "attack", is that now the Bitcoin "contract" can be violated with a mere simple-majority support. That's why I didn't tell any developers about this method (although I would have if the block size became a major issue and no hardfork was in sight).
This wouldn't have news to us, go look at bitcoin-dev logs around june-july 2011.  I wish you wouldn't have ignored the rest of my message.

It's isomorphic to a majority hashpower DOS attack and an altcoin.  The challenge in saying that its different is that if a majority of hashpower violates the contract then the security assumptions underlying Bitcoin (and any similarly constructed altcoin) are invalid.

Bitcoin is secure if:

(0) Various cryptographic constructs do what they're supposed to.
(1) A majority of the involved computing power behaves honestly (correctly imposed the rules of the contract)
(2) If information is easy/cheap to spread and hard to stifle so that its participants cannot be isolated (including excessive delays) from the honest majority.

And we argue that (1) is probable because faithful behavior is what makes performing computing valuable.

Bitcoin will not be compromised
jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
September 11, 2013, 02:34:42 AM
 #37

The problem is that I'm not referring to what is generally accepted to be considered an "attack". If that were the case, I would have contacted Gavin about this issue long ago. The problem with this, which is far more subtle than an "attack", is that now the Bitcoin "contract" can be violated with a mere simple-majority support. That's why I didn't tell any developers about this method (although I would have if the block size became a major issue and no hardfork was in sight).

There are many easier ways for a 51% attacker to violate the contract without major coding effort:
  • 1. collect fee according to bitcoin-days-destroyed, effectively turning Bitcoin to Friecoin.
  • 2. request AML registration for every addresses, so bitcoin becomes the most traceable currency on the planet
  • 3. turn it to SolidCoin by rejecting all blocks that are not signed by a central server
  • 4. blacklist tainted addresses and transactions
  • 5. collect miner tax: the 49% miners have to pay part of the reward to the attacker
1, 3, 5 are already happening in some altcoins.

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
September 16, 2013, 06:15:04 PM
 #38

I think the confusion here is that I'm not arguing any technical points, but rather political points. Does this fundamentally change security properties that we thought to be true? Of course not. An attacker can do much worse with much less effort than implementing this. What this does fundamentally change is that the "good guys" now have a method to modify the Bitcoin contract that doesn't require absolute consensus and incentives them to do it in a way that forces people to make a choice about what chain to follow (because the default choice is a non-functional client).

Is this a good thing? I say yes. We just need to be very cautious about how we use this. I'm just worried that now that things that used to require a hard-fork no longer require a huge event where everything changes at once that we will slowly, over time, make enough compromises in the design of Bitcoin that were the changes made all at once today, they would have been rejected.


This wouldn't have news to us, go look at bitcoin-dev logs around june-july 2011.
Interesting. What keywords/topics should I be looking for?

I wish you wouldn't have ignored the rest of my message.
I figured that my comments on the rest of your post would be very uninteresting, since it seemed to me that you were misinterpreting what I was trying to say. However, if you insist...

If you are imagining something as simple as "deny all new transactions, mine just blocks committing to MegaBitcoin auxblocks with 21 trillion coins instead" then it would be simple enough for the honest Bitcoin users to ignore blocks with the MegaBitcoin Commitments in them.
Indeed it would. However, it would require downloading a special client to do this. A conscious decision about which chain to follow would have to be made. I would argue that this is a good thing, but many people who want to see 1 MB blocks forever would disagree.

So instead I think your attack is a weaker versions of an attack where you merge mine Bitcoin with an altcoin and DOS bitcoin and do all your stuff in your altcoin. At least then it's harder for Bitcoin users to fork off your blocks by their shape.
Pretty much, except no effort would be made to actively make it hard to fork from the DoSed chain. So yes, it is a weaker version of that.

Of course, if you're using a majority of hashpower to DOS bitcoin you've disprove one of the fundamental security assumptions (arguably the current hashpower distribution is already disproving them, but its not clear how fast that would change if there was an attack) and so what would be the point of your MegaBitcoin?
To solve real problems with Bitcoin's current design without a hard fork. Whether those changes are good or not would be debatable, but a large amount of people would at least see the changes as a good thing.

If you want to trust a cooperating conspiracy, there are far more efficient ways to interact with them for finical purposes.
Agreed.

So really this just sounds like "if you can get a conspiracy of a majority of hashpower you can kill bitcoin" but we've always known that— thats what it said on the tin.
Agreed.

... When I stop having problems with people paying to me on a P2SH address, adopted at the beginning of 2012— you can't send to them in half the clients apps, including ones promoted on Bitcoin.org, or via many popular webwallets or commercial services, even though the change is a couple lines of code and is economically neutral... I might start worrying more about "in practice" more. Experience shows that having some network rules does far less than you might guess.
That's disappointing, but the point is that backwards-compatibility would already exist in some form, so we wouldn't have to seed it for a few years before we started using it. Using this method, we could get around the 1 MB block limit in as little as one month after this is deployed, because a large chuck of the userbase would already be compatible.

It's isomorphic to a majority hashpower DOS attack and an altcoin.  The challenge in saying that its different is that if a majority of hashpower violates the contract then the security assumptions underlying Bitcoin (and any similarly constructed altcoin) are invalid.

Bitcoin is secure if:

(0) Various cryptographic constructs do what they're supposed to.
(1) A majority of the involved computing power behaves honestly (correctly imposed the rules of the contract)
(2) If information is easy/cheap to spread and hard to stifle so that its participants cannot be isolated (including excessive delays) from the honest majority.

And we argue that (1) is probable because faithful behavior is what makes performing computing valuable.
But what does it mean to behave honestly? Is a node that cashes in all the outstanding P2SH transactions that they have the original script for (but not the keys to redeem) behaving honestly? After all, the original protocol says that you only need the data that hashes into the script hash to redeem these transactions.

jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
September 17, 2013, 05:09:18 AM
 #39

By definition, soft-fork means making currently valid block invalid, hard-fork means making currently invalid block valid. However, I think soft-forks could be further divided into 4 levels.

"Level I soft-fork" will only affect miner. An example of level I soft-fork is the recent upgrade to v2 block. Upgrade is optional for non-miner. If they don't upgrade, their effective security will decrease to SPV level. However, they can still enjoy the full functionality of bitcoin. Developers of alternative SPV clients do not need to take any action.

"Level II soft-fork" will introduce new functions to bitcoin. Examples of level II soft-fork are P2SH and my proposal for native colored coin support (https://bitcointalk.org/index.php?topic=253385.0) Upgrade is still optional for non-miner. If they don't upgrade, they won't be able use the new function. However, they can still use Bitcoin the currency as usual. Developers of alternative SPV clients do not need to take any action if they don't want to support the new functions. Actually, most SPV clients are still not supporting P2SH.

"Level III soft-fork" will introduce currency changes to bitcoin. Examples of level III soft-fork is the OP proposal and my proposal for further currency divisibility (https://bitcointalk.org/index.php?topic=256516) Upgrade is still optional for non-miner. If they don't upgrade, they will have some troubles in transacting with new nodes. However, they can still spend and receive "old bitcoin" as usual. If SPV clients do not upgrade, the users will have the said trouble.

"Level IV soft-fork" will denial some or all existing services. Non-miner could only either follow the new rules or follow a hard-fork. Although by definition this is a soft-fork, politically and practically it is very similar to a hard-fork.

Any aux-block softfork would be at least Level III because it will introduce aux coins that are invisible to existing clients. That might not be as easy as we think.

EDIT:

I find an interesting point. When there is a hardfork, the original fork will become a de facto Level IV softfork, because the original fork 1. has stricter rules, and 2. denials to serve any transactions related to the hardfork. So we shouldn't exaggerate the power of a high level soft-fork.

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106


View Profile
September 17, 2013, 07:28:45 AM
 #40

jl2012: What's interesting about SPV nodes is that because they don't really verify anything, there are cases where a hard-fork for a full node is a soft-fork for a SPV node. One such example is the merkle tree itself - and SPV node wouldn't know the difference if we, say, moved the coinbase transaction to the top of the tree.

jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
September 17, 2013, 07:58:32 AM
 #41

jl2012: What's interesting about SPV nodes is that because they don't really verify anything, there are cases where a hard-fork for a full node is a soft-fork for a SPV node. One such example is the merkle tree itself - and SPV node wouldn't know the difference if we, say, moved the coinbase transaction to the top of the tree.

Many "simple" hard-forks are transparent to SPV, such as the BIP50 bug fix and increasing MAX_BLOCK_SIZE.

For your example of moving the coinbase transaction to the top of the tree, new full nodes need to somehow cheat the old SPV nodes to make it works. 

More complicated changes, e.g. merkle sum tree, will break SPV nodes

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
September 17, 2013, 01:23:53 PM
 #42

IMO, even a soft fork is unneeded.

Just make BTC2, which transits upon, and wholly depends upon, BTC.  Have the BTC2 proof-of-work depend on information in the BTC chain, and timestamp BTC2 blocks inside the BTC chain.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106


View Profile
September 17, 2013, 04:13:25 PM
 #43

jl2012: What's interesting about SPV nodes is that because they don't really verify anything, there are cases where a hard-fork for a full node is a soft-fork for a SPV node. One such example is the merkle tree itself - and SPV node wouldn't know the difference if we, say, moved the coinbase transaction to the top of the tree.

Many "simple" hard-forks are transparent to SPV, such as the BIP50 bug fix and increasing MAX_BLOCK_SIZE.

For your example of moving the coinbase transaction to the top of the tree, new full nodes need to somehow cheat the old SPV nodes to make it works.  

More complicated changes, e.g. merkle sum tree, will break SPV nodes

You're not thinking deviously enough.

Lets suppose I define a new merkle-sum-product-christmas-tree which sums all the transaction values up and even distributes presents to the homeless; we'll call the top level digest of that tree D2, and the top level digest of the old merkle tree D1.

Now ask yourself, can a SPV node know if rather than setting hashMerkleRoot to D1 as before, we've set it to Hash(D1 | D2)? A full node certainly can - they have a full list of transactions and will immediately see that something isn't adding up - but what about a SPV node?

Also, it'd be interesting to know if any SPV clients out there would even notice if they were given two transactions, ostensibly from the same block, whose merkle paths back to the block header were of different lengths.

Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
September 17, 2013, 06:19:45 PM
 #44

IMO, even a soft fork is unneeded.

Just make BTC2, which transits upon, and wholly depends upon, BTC.  Have the BTC2 proof-of-work depend on information in the BTC chain, and timestamp BTC2 blocks inside the BTC chain.
That's essentially what this is. The main (only?) reason that this would require a softfork is that it allows someone to send a transaction from BTC2 back to BTC1. Other than that, it's basically a merged-mined chain.

jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
September 18, 2013, 04:28:13 AM
 #45

jl2012: What's interesting about SPV nodes is that because they don't really verify anything, there are cases where a hard-fork for a full node is a soft-fork for a SPV node. One such example is the merkle tree itself - and SPV node wouldn't know the difference if we, say, moved the coinbase transaction to the top of the tree.

Many "simple" hard-forks are transparent to SPV, such as the BIP50 bug fix and increasing MAX_BLOCK_SIZE.

For your example of moving the coinbase transaction to the top of the tree, new full nodes need to somehow cheat the old SPV nodes to make it works.  

More complicated changes, e.g. merkle sum tree, will break SPV nodes

You're not thinking deviously enough.

Lets suppose I define a new merkle-sum-product-christmas-tree which sums all the transaction values up and even distributes presents to the homeless; we'll call the top level digest of that tree D2, and the top level digest of the old merkle tree D1.

Now ask yourself, can a SPV node know if rather than setting hashMerkleRoot to D1 as before, we've set it to Hash(D1 | D2)? A full node certainly can - they have a full list of transactions and will immediately see that something isn't adding up - but what about a SPV node?

Also, it'd be interesting to know if any SPV clients out there would even notice if they were given two transactions, ostensibly from the same block, whose merkle paths back to the block header were of different lengths.

So we have at least 4 levels of hardforks:

Level I hardfork: a hardfork that is completely transparent to SPV nodes, such as the BIP50 bug fix, increasing MAX_BLOCK_SIZE, increasing block reward (too bad!!!)

Level II hardfork: a hardfork that adds new functions while all existing functions are still supported, such as SIGHASH_WITHINPUTVALUE (https://bitcointalk.org/index.php?topic=181734.0) . Old SPV nodes can still function as usual, just not supporting the new function.

Level III hardfork: a hardfork that will partially break SPV nodes, such as fixing the OP_CHECKMULTISIG bug. SPV nodes can still receive bitcoin from bug-fixed OP_CHECKMULTISIG but cannot send with it properly

Level IV hardfork: a hardfork that will completely break SPV nodes, usually something fundamentally change block or transaction format, such as increasing coin divisibility, 64bit block timestamp.

However, this pretty depends on how an SPV node exactly works. With the examples here I assume that SPV will only 1) make sure blocks have adequate PoW; 2) find the chain with highest PoW; 3) look for related transaction outputs in the chain. It would not check the validity of the signature (otherwise SIGHASH_WITHINPUTVALUE signatures of bug-fixed OP_CHECKMULTISIG would look invalid).

Please feel free to add more levels to the list (both softfork and hardfork).

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Pages: 1 2 3 [All]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!