On Sun, Jun 21, 2015 at 11:31 AM, Jorge Timón wrote:
> You mean the timewarp fix can be coded as a softfork instead of a
> hardfork? How so?
>
The easiest would be a rule requiring that all blocks are within 1 day of
the median of the previous 11 blocks. At the moment, you need to be
greater th
The off by 1 bug could be fixed by a soft fork. Since the point is to show
how a non-controversial hard fork works, it doesn't matter much.
--
___
Bitcoin-development mailing lis
I agree giving notice that the change is going to happen is critical for a
hard fork. If miners vote in favor, they need to give people time to
upgrade (or to decide to reject the fork).
The BIP 100 proposal is that no change will happen until a timestamp is
reached. It isn't clear exactly how i
On Fri, Jun 19, 2015 at 5:42 PM, Eric Lombrozo wrote:
> If we want a non-repudiation mechanism in the protocol, we should
> explicitly define one rather than relying on “prima facie” assumptions.
> Otherwise, I would recommend not relying on the existence of a signed
> transaction as proof of int
On Tue, Jun 16, 2015 at 6:18 AM, Venzen wrote:
> Mike Hearn, you should cease your activity of a unilateral hard-fork
> immediately. You are doing untold damage by breaking FOSS governance
> protocol requiring methodical collaborative work and due process of
> change implementation by consensus.
Once the 75% threshold is reached, miners who haven't updated are at risk
of mining on invalid blocks.
If someone produces a version 3 block that violates the new rules, then
miners who haven't upgraded will end up wasting mining power building on
that block.
This could be used as an expensive wa
On Tue, Jun 9, 2015 at 2:36 PM, Gavin Andresen
wrote:
> How about this for mitigating this potential attack:
>
> 1. Limit the memory pool to some reasonable number of blocks-worth of
> transactions (e.g. 11)
> 2. If evicting transactions from the memory pool, prefer to evict
> transactions that a
I am glad to see the transaction version number increase. The commit
doesn't update the default transaction version though. The node would
still produce version 1 transactions.
Does the reference client already produce transactions with final sequence
numbers? If so, then they will be valid ver
On Fri, May 29, 2015 at 5:39 PM, Raystonn . wrote:
> Regarding Tier’s proposal: The lower security you mention for extended
> blocks would delay, possibly forever, the larger blocks maximum block size
> that we want for the entire network. That doesn’t sound like an optimal
> solution.
>
I do
On Fri, May 29, 2015 at 3:09 PM, Tier Nolan wrote:
>
>
> On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen
> wrote:
>
>> But if there is still no consensus among developers but the "bigger
>> blocks now" movement is successful, I'll ask for help getting
On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen
wrote:
> But if there is still no consensus among developers but the "bigger blocks
> now" movement is successful, I'll ask for help getting big miners to do the
> same, and use the soft-fork block version voting mechanism to (hopefully)
> get a maj
On Fri, May 29, 2015 at 12:26 PM, Mike Hearn wrote:
> IMO it's not even clear there needs to be a size limit at all. Currently
> the 32mb message cap imposes one anyway
>
If the plan is a fix once and for all, then that should be changed too. It
could be set so that it is at least some multiple
On Thu, May 28, 2015 at 5:22 PM, s7r wrote:
> In this scenario, if channel is closed, Alice is the only one who can
> take the coins back after a relative locktime of 150 blocks. Bob is not
> able to do this.
>
Yes, Alice is assumed to be the one who funded the channel. It is a single
direction
e purpose of explaining. It
> doesn't actually change the code.
>
> Regarding saving more bits, there really isn't much room if you consider
> time-based relative locktimes and long-lived channels on the order of a
> year or more.
>
> On Thu, May 28, 2015 at 8:18 AM, T
On Thu, May 28, 2015 at 3:59 PM, Mark Friedenbach
wrote:
> Why 3? Do we have a version 2?
>
I meant whatever the next version is, so you are right, it's version 2.
> As for doing it in serialization, that would alter the txid making it a
> hard fork change.
>
The change is backwards compatible (
On Thu, May 28, 2015 at 1:04 PM, Peter Todd wrote:
> For that matter, we probably don't want to treat this as a *version*
> change, but rather a *feature* flag.
I think it is still a version change. At the moment, the 4 bytes refer to
the sequence number and afterwards they mean something else
Can you update it so that it only applies to transactions with version
number 3 and higher. Changing the meaning of a field is exactly what the
version numbers are for.
You could even decode version 3 transactions like that.
Version 3 transactions have a sequence number of 0x and the
seq
ith the warning system. For each block height, there is a
set of known BIP bits that are allowed. Once the final deadline is passed,
the expected mask is zeros.
On Wed, May 27, 2015 at 11:15 AM, Jorge Timón wrote:
> On May 27, 2015 11:35 AM, "Tier Nolan" wrote:
>
> > Was
This could cause legacy transactions to become unspendable.
A new transaction version number should be used to indicate the change of
the field from sequence number to relative lock time.
Legacy transactions should not have the rule applied to them.
On Wed, May 27, 2015 at 9:18 AM, Gregory Maxw
I think it would be better to have the deadlines set as block counts. That
eliminates the need to use the median time mechanism.
The deadline could be matched to a "start-line". The definition would then
be something like
BIP 105
Start block: 325000
End block: 35
Activation: 750 of 1000
Imp
On Tue, May 19, 2015 at 9:28 AM, Christian Decker <
decker.christ...@gmail.com> wrote:
> Thanks Stephen, I hadn't thought about BIP 34 and we need to address this
> in both proposals. If we can avoid it I'd like not to have one
> transaction hashed one way and other transactions in another way.
>
On Mon, May 18, 2015 at 2:42 AM, Rusty Russell
wrote:
> OK. Be nice if these were cleaned up, but I guess it's a sunk cost.
>
Yeah.
On the plus side, as people spend their money, old UTXOs would be used up
and then they would be included in the cost function. It is only people
who are storing
On Sat, May 16, 2015 at 5:39 AM, Stephen
wrote:
> I think this could be mitigated by counting confirmations differently. We
> should think of confirmations as only coming from blocks following the
> miners' more strict rule set. So if a merchant were to see payment for the
> first time in a block
On Sat, May 9, 2015 at 4:08 AM, Peter Todd wrote:
> > I wonder if having a "miner" flag would be good for the network.
>
> Makes it trivial to find miners and DoS attack them - a huge risk to the
> network as a whole, as well as the miners.
>
To mitigate against this, two chaintips could be trac
On Sat, May 16, 2015 at 1:22 AM, Rusty Russell
wrote:
> Some tweaks:
>
> 1) Nomenclature: call tx_size "tx_cost" and real_size "tx_bytes"?
>
Fair enough.
>
> 2) If we have a reasonable hard *byte* limit, I don't think that we need
>the MAX(). In fact, it's probably OK to go negative.
>
I
On Sat, May 16, 2015 at 4:58 AM, Stephen
wrote:
> We should make sure to consider how BIP34 affects normalized transaction
> ids, since the height of the block is included in the scriptSig ensuring
> that the txid will be different. We wouldn't want to enable replay attacks
> in the form of spend
On Fri, May 15, 2015 at 10:54 AM, s7r wrote:
> Hello,
>
> How will this exactly be safe against:
> a) the malleability of the parent tx (2nd level malleability)
>
The signature signs everything except the signature itself. The normalized
txid doesn't include that signature, so mutations of the
On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille
wrote:
>
> This was what I was suggesting all along, sorry if I wasn't clear.
>
>
That's great. So, basically the multi-level refund problem is solved by
this?
--
One dashbo
After more thought, I think I came up with a clearer description of the
recursive version.
The simple definition is that the hash for the new signature opcode should
simply assume that the normalized txid system was used since the
beginning. All txids in the entire blockchain should be replaced w
On Wed, May 13, 2015 at 6:14 PM, Pieter Wuille
wrote:
> Normalized transaction ids are only effectively non-malleable when all
> inputs they refer to are also non-malleable (or you can have malleability
> in 2nd level dependencies), so I do not believe it makes sense to allow
> mixed usage of the
On Wed, May 13, 2015 at 4:24 PM, Christian Decker <
decker.christ...@gmail.com> wrote
> It does and I should have mentioned it in the draft, according to my
> calculations a mapping legacy ID -> normalized ID is about 256 MB in size,
> or at least it was at height 330'000, things might have change
On Wed, May 13, 2015 at 1:26 PM, Alex Mizrahi
wrote:
> He tries to investigate, and after some time discovers that his router (or
> his ISP's router) was hijacked. His Bitcoin node couldn't connect to any of
> the legitimate nodes, and thus got a complete fake chain from the attacker.
> Bitcoins
I think this is a good way to handle things, but as you say, it is a hard
fork.
CHECKLOCKTIMEVERIFY covers many of the use cases, but it would be nice to
fix malleability once and for all.
This has the effect of doubling the size of the UTXO database. At minimum,
there needs to be a legacy txid
On Wed, May 13, 2015 at 11:31 AM, Alex Mizrahi
wrote:
>
> But this matters if a new node has access to the globally strongest chain.
>
A node only needs a path of honest nodes to the network.
If a node is connected to 99 dishonest nodes and 1 honest node, it can
still sync with the main network
On Sat, May 9, 2015 at 4:36 AM, Gregory Maxwell wrote:
> An example would
> be tx_size = MAX( real_size >> 1, real_size + 4*utxo_created_size -
> 3*utxo_consumed_size).
This could be implemented as a soft fork too.
* 1MB hard size limit
* 900kB soft limit
S = block size
U = UTXO_adjusted_siz
On Wed, May 13, 2015 at 10:49 AM, Thomas Voegtlin
wrote:
>
> The reason I am asking that is, there seems to be no consensus among
> core developers on how Bitcoin can work without miner subsidy. How it
> *will* work is another question.
>
The position seems to be that it will continue to work fo
On Wed, May 13, 2015 at 6:19 AM, Daniel Kraft wrote:
> 2) Divide the range of all blocks into intervals with exponentially
> growing size. I. e., something like this:
>
> 1, 1, 2, 2, 4, 4, 8, 8, 16, 16, ...
>
Interesting. This can be combined with the system I suggested.
A node broadcasts 3 p
(5) The communication about what blocks a node has should be compact.
>
> (6) The coverage created by the network should be uniform, and should
> remain uniform as the blockchain grows; ideally it you shouldn't need
> to update your state to know what blocks a peer will store in the
On Tue, May 12, 2015 at 6:16 PM, Peter Todd wrote:
>
> Lots of people are tossing around ideas for partial archival nodes that
> would store a subset of blocks, such that collectively the whole
> blockchain would be available even if no one node had the entire chain.
>
A compact way to describe
On Sat, May 9, 2015 at 12:58 PM, Gavin Andresen
wrote:
> RE: fixing sigop counting, and building in UTXO cost: great idea! One of
> the problems with this debate is it is easy for great ideas get lost in all
> the noise.
>
If the UTXO set cost is built in, UTXO database entries suddenly are wort
On Fri, May 8, 2015 at 5:37 PM, Peter Todd wrote:
> The soft-limit is there miners themselves produce smaller blocks; the
> soft-limit does not prevent other miners from producing larger blocks.
>
I wonder if having a "miner" flag would be good for the network.
Clients for general users and mer
Sorry for the spam of the last mail. I hit send by accident.
Assurance contracts are better than simple donations.
Donating to a project means that you always end up losing the money but the
project might still not get funded.
An assurance contract is like Kickstarter, you only get your CC char
gt; instead of debating low level encodings all the time.
>
> On Fri, May 8, 2015 at 4:15 PM, Tier Nolan wrote:
> > Just to clarify the process.
> >
> > Pledgers create transactions using the following template and broadcast
> > them. The p2p protocol could be mod
Just to clarify the process.
Pledgers create transactions using the following template and broadcast
them. The p2p protocol could be modified to allow this, or it could be a
separate system.
*Input: 0.01 BTC*
*Signed with SIGHASH_ANYONE_CAN_PAY*
*Output 50BTC*
*Paid to: <1 million> OP_CHECK
One of the suggestions to avoid the problem of fees going to zero is
assurance contracts. This lets users (perhaps large merchants or
exchanges) pay to support the network. If insufficient people pay for the
contract, then it fails.
Mike Hearn suggests one way of achieving it, but it doesn't act
In terms of miners, a strong supermajority is arguably sufficient, even 75%
would be enough.
The near total consensus required is merchants and users. If (almost) all
merchants and users updated and only 75% of the miners updated, then that
would give a successful hard-fork.
On the other hand, i
On Thu, May 7, 2015 at 12:12 AM, Matt Corallo
wrote:
> The point of the hard block size limit is exactly because giving miners
> free rule to do anything they like with their blocks would allow them to
> do any number of crazy attacks. The incentives for miners to pick block
> sizes are no where
On Wed, May 6, 2015 at 11:12 PM, Matt Corallo
wrote:
> Personally, I'm rather strongly against any commitment to a block size
> increase in the near future.
Miners can already soft-fork to reduce the maximum block size. If 51% of
miners agree to a 250kB block size, then that is the maximum blo
On Wed, May 6, 2015 at 8:37 AM, Jorge Timón wrote:
>
> This gives you less flexibility and I don't think it's necessary.
> Please let's try to avoid this if it's possible.
It is just a switch that turns on and off the new mode.
In retrospect, it would be better to just up the transaction versi
I think that should be greater than in the comparison? You want it to fail
if the the height of the UTXO plus the sequence number is greater than the
spending block's height.
There should be an exception for final inputs. Otherwise, they will count
as relative locktime of 0x. Is this ch
rs to mine version 3 blocks. I could
add a new field to the getblocktemplate that has the 2 transactions ready
to go.
What do pools actually use for generating blocks. I assume it's custom
code but that they use (near) standard software for the memory pool?
On Mon, Nov 10, 2014 at 11:39 PM,
-header.mediawiki
On Mon, Nov 10, 2014 at 9:21 PM, Tier Nolan wrote:
> I updated the BIP to cover only the specification of the transactions that
> need to be added. I will create a network BIP tomorrow.
>
> On Mon, Nov 10, 2014 at 11:42 AM, Tier Nolan wrote:
>
>> The aheaders m
I updated the BIP to cover only the specification of the transactions that
need to be added. I will create a network BIP tomorrow.
On Mon, Nov 10, 2014 at 11:42 AM, Tier Nolan wrote:
> The aheaders message is required to make use of the data by SPV clients.
> This could be in a separa
> > that pay to a particular address but the transaction would be timelocked.
> > The private key for the output would be known. However, miners who mine
> > version 2 blocks wouldn't be able to spend them early.
> >
> >
> > On Sat, Nov 8, 2014 at 11:45 PM, Tie
timelocked.
The private key for the output would be known. However, miners who mine
version 2 blocks wouldn't be able to spend them early.
On Sat, Nov 8, 2014 at 11:45 PM, Tier Nolan wrote:
> I created a draft BIP detailing a way to add auxiliary headers to Bitcoin
> in a bandwidt
I created a draft BIP detailing a way to add auxiliary headers to Bitcoin
in a bandwidth efficient way. The overhead per auxiliary header is only
around 104 bytes per header. This is much smaller than would be required
by embedding the hash of the header in the coinbase of the block.
It is a sof
On Fri, Apr 11, 2014 at 5:54 PM, Gregory Maxwell wrote:
> For the non-error-coded case I believe nodes
> with random spans of blocks works out asymptotically to the same
> failure rates as random.
>
If each "block" is really 512 blocks in sequence, then each "slot" is more
likely to be hit. It
at 9:48 PM, Tier Nolan wrote:
> On Wed, Apr 30, 2014 at 7:59 PM, Luke Dashjr wrote:
>
>> Instead of TX0, TX1, etc, can you put some kind of meaningful identifier
>> for
>> these transactions?
>>
>
> Sorry, that is the names come from the original thread,
On Wed, Apr 30, 2014 at 7:59 PM, Luke Dashjr wrote:
> Instead of TX0, TX1, etc, can you put some kind of meaningful identifier
> for
> these transactions?
>
Sorry, that is the names come from the original thread, where I was
outlining the idea. I updated the names.
> TX1 and TX2 *cannot* be s
Due to "popular" demand, I have created a BIP for cross chain atomic
transfers.
Unlike the previous version, this version only requires hash locking. The
previous version required a "selector" transaction based on if statements.
OP_HASH160 OP_EQUAL_VERIFY [public key] OP_CHECKSIG
OP_HA
On Sat, Apr 26, 2014 at 12:11 PM, Jorge Timón wrote:
> script IsStandard
> main IsStandardTx
> main AcceptToMemoryPool
>
Accept to memory pool could probably be replaced with an
IsStandard(scriptPubKey, scriptSig) method. The only "isStandard" part of
the process is the check inputs method (and
Maybe the solution is to have a defined way to import an unknown wallet?
This means that the gap space and a search ordering needs to be defined.
Given a blockchain and a root seed, it should be possible to find all the
addresses for that root seed.
The hierarchy that the wallet actually uses co
On Fri, Apr 25, 2014 at 10:14 PM, Peter Todd wrote:
> Along those lines, rather than doing up yet another format specific type
> as Tier Nolan is doing with his BIP, why not write a BIP looking at how
> the IsStandard() rules could be removed?
Removal of isStandard() would be even be
On Fri, Apr 25, 2014 at 9:26 PM, Luke-Jr wrote:
> They define standard for interoperability between
> software. So, if you want nodes to relay these transactions, you need to
> convince them, not merely write a BIP for the transaction format.
I agree with you in theory, each miner could decide
On Fri, Apr 25, 2014 at 8:58 PM, Peter Todd wrote:
> Keep in mind that P2SH redeemScripts are limited to just 520 bytes;
> there's going to be many cases where more complex transactions just
> can't be encoded in P2SH at all.
>
True. Having said that, this is just a change to isStandard(), rath
distributed verification of the block chain easier.
Everything needed to verify a script is present in the transaction (except
that the output actually exists).
A soft fork that expands P2SH functionality would be even better, but I
would rather not let the best be the enemy of the good.
>
>
&g
On Fri, Apr 25, 2014 at 8:18 PM, Luke-Jr wrote:
> This one looks entirely useless (it cannot be made secure)
The hash locking isn't to prevent someone else stealing your coin. Once a
user broadcasts a transaction with x in it, then everyone has access to x.
It is to release the coin on the ot
This is a BIP to allow the spender to choose one of multiple standard
scripts to use for spending the output.
https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki
This is required as part of the atomic cross chain transfer protocol. It
is required so that outputs can be retrieved, if
As part of the atomic cross chain system, outputs need to be hash locked.
https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki
https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949
A user needs to provide x corresponding to hash(x) in order to spend an
output.
Under th
On Wed, Apr 23, 2014 at 10:39 PM, Gregory Maxwell wrote:
> You can see me proposing this kind of thing in a number of places (e.g.
> http://download.wpsoftware.net/bitcoin/wizards/2014-04-15.txt "p2pool
> only forces the subsidy today, but the same mechnism could instead
> force transactions..
I
An interesting experiment would be a transaction "proof of publication"
chain.
Each transaction would be added to that chain when it is received. It
could be merge mined with the main chain.
If the size was limited, then it doesn't even require spam protection.
Blocks could be "discouraged" if
On Wed, Apr 23, 2014 at 7:46 PM, Pavol Rusnak wrote:
>
> > Setting the gap limit to high is just a small extra cost in that case.
>
> Not if you have 100 accounts on 10 different devices.
>
I meant for a merchant with a server that is handing out hundreds of
addresses.
The point is to have a si
Bitcoin has various checks and balances that help keep everything honest.
Even if a pool had 60% of the hashing power, they couldn't reverse 6 blocks
without anyone noticing that it had happened.
There are sites which monitor the blocks and estimate the percentage of the
blocks found by each pool
Different users could have different gap limit requirements. 20 seems very
low as the default.
A merchant could easily send 20 addresses in a row to customers and none of
them bother to actually buy anything.
Setting the gap limit to high is just a small extra cost in that case.
Bip-32 serializ
On Mon, Apr 21, 2014 at 5:06 AM, Peter Todd wrote:
> Of course, in reality smaller miners can just mine on top of block headers
> and include no transactions and do no validation, but that is extremely
> harmful to the security of Bitcoin.
>
I don't think it reduces security much. It is extreme
How does this system handle problems with the lower chains after they have
been "locked-in"?
The rule is that if a block in the child chain is pointed to by its parent,
then it effectively has infinite POW?
The point of the system is that a node monitoring the parent chain only has
to watch the h
On Thu, Apr 10, 2014 at 7:32 PM, Pieter Wuille wrote:
> If you trust hashrate for determining which UTXO set is valid, a 51%
> attack becomes worse in that you can be made to believe a version of
> history which is in fact invalid.
>
If there are invalidation proofs, then this isn't strictly true
Error correction is an interesting suggestion.
If there was 1 nodes and each stored 0.1% of the blocks, at random,
then the odds of a block not being stored is 45 in a million.
Blocks are stored on average 10 times, so there is already reasonable
redundancy.
With 1 million blocks, 45 would b
used with the getheaders message and if the new peer is on a
different chain, then it will just send you the headers starting at the
genesis block.
If that happens, you need to download the entire chain from that peer and
see if it is better than your current best.
*From:* Tier Nolan
*Sent:* Mo
On Mon, Apr 7, 2014 at 8:50 PM, Tamas Blummer wrote:
> You have to load headers sequantially to be able to connect them and
> determine the longest chain.
>
The isn't strictly true. If you are connected to a some honest nodes, then
you could download portions of the chain and then connect the v
On Mon, Apr 7, 2014 at 8:03 PM, Gregory Maxwell wrote:
> A bitmap also means high overhead and-- if it's used to advertise
> non-contiguous blocks-- poor locality, since blocks are fetched
> sequentially.
>
A range seems like a great compromise. Putting it in the address is also a
pretty cool.
On Mon, Feb 10, 2014 at 7:47 PM, Oliver Egginger wrote:
> As I understand this attack someone renames the transaction ID before
> being confirmed in the blockchain. Not easy but if he is fast enough it
> should be possible. With a bit of luck for the attacker the new
> transaction is added to the
The random number that the buyer uses could be generated from a root key
too.
This would allow them to regenerate all random numbers that they used and
recreate their receipts. The master root would have to be stored on your
computer though.
The payment protocol is supposed to do something like
On Fri, Jan 3, 2014 at 9:59 AM, Drak wrote:
> Which is why, as pointed out several times at 30c3 by several renowned
> figures, why cryptography has remained squarely outside of mainstream use.
> It needs to just work and until you can trust the connection and what the
> end point sends you, auto
On Tue, Dec 24, 2013 at 8:52 AM, Jeremy Spilman wrote:
> Are there any past instances of applications hijacking or interfacing with
> the exiting p2p messages, or abusing 'getaddr' functionality? Are there
> any guidelines on this, or should there be?
>
>
There was a BIP by Stefan Thomas for addi
On Wed, Nov 6, 2013 at 5:50 AM, Matt Corallo wrote:
> Relay node details:
> * The relay nodes do some data verification to prevent DoS, but in
> order to keep relay fast, they do not fully verify the data they are
> relaying, thus YOU SHOULD NEVER mine a block building on top of a
> relayed block
On Sun, Jul 28, 2013 at 7:42 PM, John Dillon
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Wed, Jul 24, 2013 at 11:55 AM, Tier Nolan wrote:
> > Distributing headers with 1/64 of the standard POW means that a header
> would
> > be broadcast approxi
On Wed, Jul 24, 2013 at 10:42 AM, Peter Todd wrote:
> Please provide equations and data justifying the 'magic constants' in
> this proposal.
>
The are a range of workable values. Ideally, there would first need to be
agreement on the general principle.
Distributing headers with 1/64 of the sta
I was thinking about a change to the rules for distinguishing between forks
and maybe a BIP..
*Summary*
- Low POW headers should be broadcast by the network
If a header has more than 1/64 of the POW of a block, it should be
broadcast. This provides information on which fork is getting most of t
89 matches
Mail list logo
