Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Wed, Dec 9, 2015 at 7:54 AM, Jorge Timón wrote: > From this question one could think that when you said "we can do the > cleanup hardfork later" earlier you didn't really meant it. And that > you will oppose to that hardfork later just like you are opposing to > it now. > As

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

My apologies for the apparent miscommunication earlier. It is of interest to me that the soft-fork be done which is necessary to put a commitment in the most efficient spot possible, in part because that commitment could be used for other data such as the merged mining auxiliary blocks, which are

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

Fair enough. On Dec 9, 2015 4:03 PM, "Gregory Maxwell" wrote: > On Wed, Dec 9, 2015 at 7:54 AM, Jorge Timón wrote: > > From this question one could think that when you said "we can do the > > cleanup hardfork later" earlier you didn't really meant it. And that >

[bitcoin-dev] Impacts of Segregated Witness softfork

Although the plan is to implement SW with softfork, I think many important (but non-consensus critical) components of the network would be broken and many things have to be redefined. 1. Definition of "Transaction ID". Currently, "Transaction ID" is simply a hash of a tx. With SW, we may need

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Wed, Dec 9, 2015 at 3:03 AM, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I think it would be logical to do as part of a hardfork that moved > commitments generally; e.g. a better position for merged mining (such > a hardfork was suggested in 2010 as

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On 12/08/2015 10:12 AM, Gavin Andresen via bitcoin-dev wrote: > Why segwitness as a soft fork? Stuffing the segwitness merkle tree in > the coinbase is messy and will just complicate consensus-critical code > (as opposed to making the right side of the merkle tree in > block.version=5 blocks the

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

If SegWit were implemented as a hardfork, could the entire blockchain be reorganized starting from the Genesis block to free up historical space? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org

Re: [bitcoin-dev] Scaling by Partitioning

Thanks for giving serious consideration to my post. With regard to your question "if a transaction spends a "coin" that ends in "1" and creates a new coin that ends in "1", which partition should process the transaction?", I would answer that only one partition is involved. In other words, there

Re: [bitcoin-dev] "Subsidy fraud" ?

I meant a miner claiming more in the coinbase's output than subsidy + fees allow. On Dec 10, 2015 5:26 AM, "xor" wrote: > Pieter Wuille mentions "subsidy fraud" in his recent talk: > https://youtu.be/fst1IK_mrng?t=57m2s > > I was unable to google what this is, and the

Re: [bitcoin-dev] Scaling by Partitioning

I guess the most basic question is how do you define a coin here? Thanks, Loi Luu On 10 Dec 2015 2:26 a.m., "Akiva Lichtner" wrote: > Thanks for giving serious consideration to my post. > > With regard to your question "if a transaction spends a "coin" that > ends in

[bitcoin-dev] "Subsidy fraud" ?

Pieter Wuille mentions "subsidy fraud" in his recent talk: https://youtu.be/fst1IK_mrng?t=57m2s I was unable to google what this is, and the Bitcoin Wiki also does not seem to explain it. If this is a well-known problem, perhaps it would be a good idea to explain it somewhere? signature.asc

[bitcoin-dev] Standard BIP Draft: Turing Pseudo-Completeness

Hello Bitcoin-Dev, I hope this isn't out of line, but I joined the mailing list to try to start a discussion on adding opcodes to make Script Turing Pseudo-Complete as Wright suggested is possible. --- In line with Wright's suggestion, I propose adding a return stack alongside the, already

Re: [bitcoin-dev] Scaling by Partitioning

Hi Akiva I sketched out a similar proposal here: https://bitcointalk.org/index.php?topic=1083345.0 It's good to see people talking about this :). I'm not quite convinced with segregated witness, as it might mess up some things, but will take a closer look. On Dec 9, 2015 7:32 AM, "Loi Luu via

Re: [bitcoin-dev] Scaling by Partitioning

It's an interval (a,b) where a, b are between 0 and 21*10^6*10^8 . Somebody pointed out that this is not easily accomplished using the current code because there are no coin ids. On Wed, Dec 9, 2015 at 4:16 PM, Loi Luu wrote: > I guess the most basic question is how do

[bitcoin-dev] Segregated Witness features wish list

It seems the current consensus is to implement Segregated Witness. SW opens many new possibilities but we need a balance between new features and deployment time frame. I'm listing by my priority: 1-2 are about scalability and have highest priority 1. Witness size limit: with SW we should

[bitcoin-dev] Not this again.

I am not Craig Wright. We are all Satoshi. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Scaling by Partitioning

Hi Andrew, What you suggested is much more sophisticated than what I suggested. I am strictly talking about independent chains - that's all. I am struck by the fact that the topic of "scaling bitcoin" seems to be a mix of different problems, and when people are really trying to solve different

Re: [bitcoin-dev] Standard BIP Draft: Turing Pseudo-Completeness

There is no need for a BIP draft. "Turing complete" is just a fancy, executive-impressing term for "it can run any computer program", or put even more simply, "it can loop" Furthermore, the specification of such a language is trivial. It is the economics of validation that is the complex piece.

Re: [bitcoin-dev] Standard BIP Draft: Turing Pseudo-Completeness

On Dec 10, 2015 10:10 AM, "Luke Durback via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > This, combined with the ability to make new transactions arbitrarily would allow a function to pay its creator. I don't understand what you mean by "a function" in this context, I assume you

Re: [bitcoin-dev] Scaling by Partitioning

Edit: "... as well as those blocks with hashes for which the last B bits match any of the next N bit patterns where *N is largest* integer for which the claimed output is not *greater* than (subsidy+fees)*(N/(2^B)). On Wed, Dec 9, 2015 at 8:08 PM, Dave Scotese wrote: >

Re: [bitcoin-dev] Scaling by Partitioning

If we partition the work using bits from the TxID (once it is no longer malleable) or even bits from whatever definition we use for "coin," then every transaction may have to use all the other partitions to verify that the incoming coin is good. If all partitions are involved in validating and

Re: [bitcoin-dev] Standard BIP Draft: Turing Pseudo-Completeness

Tomorrow, I'll work on writing a way to do voting on proposals with BTC used as voting shares (This will be difficult as I do not know FORTH). That seems like a fairly simple, useful example that will require loops and reused functions. I'll add a fee that goes to the creator. IMO, if you write