Re: [bitcoin-dev] BIP Proposal: Rate Limiting with server specified Proof of Work challenges

2017-05-08 Thread Karl Johan Alm via bitcoin-dev
Erik, On Tue, May 9, 2017 at 3:58 AM, Erik Aronesty wrote: > - It would be cool if any rate-limiting POW was specified as bytecode ... so > nodes can plug in as many "machine-captcha" things as they please, and > solvers can choose to solve... or just say "nope too hard". I'm not entirely sure w

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

2017-05-08 Thread Alphonse Pace via bitcoin-dev
Sergio, I'm not sure what the data you present has to do with the discount. A 75% discount prevents witness spam precisely because it is 75%, nothing more. The current usage simply gives a guideline on how much capacity is gained through a particular discount. With the data you show, it would im

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

2017-05-08 Thread Christopher Jeffrey via bitcoin-dev
Johnson, Yeah, I do still see the issue. I think there are still some reasonable ways to mitigate it. I've started revising the extension block specification/code to coexist with mainchain segwit. I think the benefit of this is that we can require exiting outputs to only be witness programs. Pres

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

2017-05-08 Thread Gregory Maxwell via bitcoin-dev
On Mon, May 8, 2017 at 10:42 PM, Sergio Demian Lerner via bitcoin-dev wrote: > The non-witness data weight factor should not be 4 but 2.35. The closest > integer value is 2, which leads to a 50% witness discount. Sergio, You've provided absolutely no information to qualify your "should be". It s

[bitcoin-dev] Some real-world results about the current Segwit Discount

2017-05-08 Thread Sergio Demian Lerner via bitcoin-dev
I have processed 1000 blocks starting from Block #461653. I computed several metrics, including the supposed size of witness data and non-witness data (onchain), assuming all P2SH inputs/outputs are converted to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH. This takes into account

Re: [bitcoin-dev] Full node "tip" function

2017-05-08 Thread Sergio Demian Lerner via bitcoin-dev
Yes you practically can. No proxy can defeat the protocol investing less money than buying storage space to store the blockchain. Even with challenge-response delays of minutes. That's why it will be fully controlled by a RSK smart-contract, with no user intervention. I'm will post about this soo

Re: [bitcoin-dev] Full node "tip" function

2017-05-08 Thread Natanael via bitcoin-dev
Den 8 maj 2017 23:01 skrev "Sergio Demian Lerner via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: I'll soon present a solution to encourage full nodes to store the blockchain based on Proof-of-Unique-Blockchain-Storage (PoUBS) Proving that you're holding your own copy of the blockchain

Re: [bitcoin-dev] Full node "tip" function

2017-05-08 Thread Sergio Demian Lerner via bitcoin-dev
A full node provides several services to the network: 1•Broadcasts blocks (public service) 2•Broadcasts transactions (public/private service) 3•Increases privacy by hiding other node’s IPs 4•Increases network security by protecting it from global DoS. 5•Provides information filtering services to S

Re: [bitcoin-dev] BIP Proposal: Rate Limiting with server specified Proof of Work challenges

2017-05-08 Thread Erik Aronesty via bitcoin-dev
- It would be cool if any rate-limiting POW was specified as bytecode ... so nodes can plug in as many "machine-captcha" things as they please, and solvers can choose to solve... or just say "nope too hard". - Alternately, it would be a lot nicer if you just required people to pay a nanobit t

Re: [bitcoin-dev] TXMempool and dirty entries

2017-05-08 Thread Suhas Daftuar via bitcoin-dev
Hi, I've moved the bitcoin-dev list to bcc:, as this question is better suited to forums dedicated to Bitcoin Core implementation specifics, rather than the general bitcoin development list. Please feel free in the future to ask questions like this on the bitcoin-core-dev mailing list (https://li

[bitcoin-dev] TXMempool and dirty entries

2017-05-08 Thread DJ Bitcoin via bitcoin-dev
Hi Guys,   I have a question about the use of txmempool. find attached the code in txmempool.h     == /* Adding transactions from a disconnected block can be very time consuming,  * because we don't have a way to limit the number of in-me