Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks]

2014-04-23 Thread Sergio Lerner
(this e-mail is cc to the bitcoin-research list) Hi everyone from the bitcoin-development mailing list! I decided to join this legendary list because it seems that all the research fun is taking place in here, and I don't want to miss the research party. Regarding the discussion about BitUndo, a

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

2014-04-24 Thread Sergio Lerner
On 23/04/2014 05:51 p.m., Mike Hearn wrote: On Wed, Apr 23, 2014 at 10:44 PM, Adam Ritter arit...@gmail.com mailto:arit...@gmail.com wrote: Isn't a faster blockchain for transactions (maybe as a sidechain) solving the problem? If there would be a safe way for 0-confirmation

[Bitcoin-development] About Compact SPV proofs via block header commitments

2014-04-26 Thread Sergio Lerner
I read the post in this threads about Compact SPV proofs via block header commitments (archived e-mail in https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04318.html). I was working on the same problem almost at the same time, which is something that's becoming very common

Re: [Bitcoin-development] About Compact SPV proofs via block header commitments

2014-04-26 Thread Sergio Lerner
El 26/04/2014 10:43 p.m., Mark Friedenbach escribió: Sergio, First of all, let's define what an SPV proof is: it is a succinct sequence of bits which can be transmitted as part of a non-interactive protocol that convincingly establishes for a client without access to the block chain that for

Re: [Bitcoin-development] About Compact SPV proofs via block header commitments

2014-04-27 Thread Sergio Lerner
El 27/04/2014 03:43 a.m., Mark Friedenbach escribió: I don't think there's an official definition of SPV proof. I wasn't trying to make a argument from definition (that would be fallacious!). Rather I suspected that we had different concepts in mind and wanted to check. So to disambiguate I

Re: [Bitcoin-development] About Compact SPV proofs via block header commitments

2014-04-28 Thread Sergio Lerner
On 27/04/2014 02:05 p.m., Mark Friedenbach wrote: On 04/27/2014 05:36 AM, Sergio Lerner wrote: Without invoking moon math or assumptions of honest peers and jamming-free networks, the only way to know a chain is valid is to witness the each and every block. SPV nodes on the other hand

Re: [Bitcoin-development] Block collision resolution using the DECOR protocol and Bonneau's Kickbacks problem

2014-05-05 Thread Sergio Lerner
On 02/05/2014 10:56 a.m., Joseph Bonneau wrote: This is an interesting idea Sergio. I have two concerns: You mention 50% of the block reward going to the uncle block. Does this mean the parent gets 1, and the uncle 0.5, or both get 0.5? In the first interpretation (which I assumed was the

[Bitcoin-development] DECOR+ Better block selection rule

2014-05-06 Thread Sergio Lerner
This e-mail is an extract of my post: http://bitslog.wordpress.com/2014/05/07/decor-2/ Some posts ago I presented the DECOR protocol. One of the assumptions I did was that the amount of coins each miner earned in competing blocks was approximately the same. This could be true for cryptocurrencies

Re: [Bitcoin-development] Paper Currency

2014-05-19 Thread Sergio Lerner
Alex, I think that what you are talking about more or less something like the Firmcoin Check: http://firmcoin.com/?p=92 On 18/05/2014 08:47 a.m., Alex Kotenko wrote: One problem we couldn't figure out here though - how to protect the notes from unauthorized redeem. Like if someone

[Bitcoin-development] BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance:

2014-06-19 Thread Sergio Lerner
I propose a setting that prevent mining pools AND reduce payoff variance which requires two changes: increasing the block-rate and changing the Bitcoin PoW (but still allowing current Bitcoin ASICs to work (as far as I know)). The block rate must be increased at least 20 times and block must still

[Bitcoin-development] Question on creating test cases for block.CheckBlock()

2014-07-21 Thread Sergio Lerner
I'm working on a BIP which needs to modify the block acceptance rules. I have two ways of testing: - Mining blocks on the testnet - Creating test cases for Bitcoin Core. I want to create those test cases for block.CheckBlock(), which involves verifying 100 dynamically generated blocks. What is

Re: [Bitcoin-development] Miners MiTM

2014-08-09 Thread Sergio Lerner
Since the information exchanged between the pool and the miner is public, all that's needed is a mutual private MAC key that authenticates messages. This requires a registration step, that can be done only once using a simple web interface over https to the miner website. But the miner website is

Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin without trusted third parties

2014-08-09 Thread Sergio Lerner
Hi Tim, It's clear from the paper that the second party in the protocol can de-anonymize the first party. So it's seems that dishonest shufflers would prefer to be in that position in the queue. There are two possible solutions to this: 1. Derive the first order of parties in the shuffle from

[Bitcoin-development] Improvement to the Test Framework in the processing of test blocks

2014-08-12 Thread Sergio Lerner
We've coded and tested changes to the Bitcoin testing framework to allow the creation and processing of blocks in unit test cases in order to test ProcessBlock(), CheckBlock(), ActivateBestChain(), ActivateBestChainStep() and ConnectTip(), including block-chain reorganizations, majority rules,

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-01 Thread Sergio Lerner
I like the proposal. I suggest that applications and nodes should only broadcast transactions having OP_CHECKLOCKTIMEVERIFY a few blocks after the timeout value. If a node broadcasts a TX having OP_CHECKLOCKTIMEVERIFY and nLockTime is equal to the current height and equal to the timeout value,

[Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-05 Thread Sergio Lerner
I would like to share with you a vulnerability in the Bitcoin protocol I've been thinking of which might have impact on the future of Bitcoin. Please criticize it! *The Freeze on Transaction Problem * The freeze problem occurs if someone publishes a transaction with fees much higher than the

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-06 Thread Sergio Lerner
Comments between lines... On 06/10/2014 03:42 a.m., Alex Mizrahi wrote: . This doesn't require protocol changes(*) and can be simply incorporated into a piece of code which decides what to do when a transaction with unusually large fee appears. (I.e. it will automatically share the fee,

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-07 Thread Sergio Lerner
On 06/10/2014 08:43 p.m., Tom Harding wrote: On 10/5/2014 4:00 PM, Sergio Lerner wrote: If everyone acts rationally in his own interest, then the best choice for the remaining miners is to try to mine a competing block at the same height n including the high-fee transaction, to collect

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-07 Thread Sergio Lerner
On 07/10/2014 04:16 p.m., Gregory Maxwell wrote: Then I spend the output of the fraudulent spend nlocked one block higher, and spend the output of that one again, nlocked one block higher, and so on... each step paying fees. Yes, you're right. I didn't consider that case. But the problem is

[Bitcoin-development] Death by halving (pro-active proposals)

2014-10-29 Thread Sergio Lerner
Instead of discussing what will happen when the subsidy is halved (which nobody really knows) maybe we can think about of what we can do to mitigate any damage in case something unwanted happens. Let's be proactive. For instance, any form of merged-mining (like higher frequency side-chains) will

[Bitcoin-development] ACK NACK utACK Concept ACK

2014-12-09 Thread Sergio Lerner
Is that the full terminology or are there more acronyms? Is this documented somewhere? Best regards, Sergio. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge

[Bitcoin-development] BIP: Voluntary deposit bonds

2014-12-29 Thread Sergio Lerner
I propose to allow miners to voluntarily lock funds by letting miners add additional inputs to the coinbase transaction. Currently the coinbase transaction does not allow any real input to be added (only a pseudo-input). This is a hard-fork, and we could include it the next time a hardfork is

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

2014-12-30 Thread Sergio Lerner
On 30/12/2014 01:51 a.m., Gregory Maxwell wrote: On Mon, Dec 29, 2014 at 7:21 PM, Sergio Lerner sergioler...@certimix.com wrote: I propose to allow miners to voluntarily lock funds by letting miners add additional inputs to the coinbase transaction. Currently the coinbase transaction does

[Bitcoin-development] network disruption as a service and proof of local storage

2015-03-16 Thread Sergio Lerner
The problem of pseudo-nodes will come over and over. The cat and mouse chase is just beginning. It has been discussed some times that the easiest solution world be to request some kind of resource consumption on each peer to be allowed to connect to other peers. Gmaxwell proposed Proof of Storage

Re: [Bitcoin-development] network disruption as a service and proof of local storage

2015-03-31 Thread Sergio Lerner
Matt is right: the goal is to prove digital copies of a public file. Nothing more, nothing less. Regarding the IP, I don't claim that every machine should provide the protocol. Mobiles phones shouldn't. But machines that what to be prioritized in some way or that want to be rewarded for hosting

Re: [Bitcoin-development] network disruption as a service and proof of local storage

2015-03-26 Thread Sergio Lerner
If I understand correctly, transforming raw blocks to keyed blocks takes 512x longer than transforming keyed blocks back to raw. The key is public, like the IP, or some other value which perhaps changes less frequently. Yes. I was thinking that the IP could be part of a first layer of

Re: [Bitcoin-development] A way to create a fee market even without a block size limit (2013)

2015-05-11 Thread Sergio Lerner
El 10/05/2015 06:07 p.m., Gregory Maxwell escribió: On Sun, May 10, 2015 at 8:45 PM, Sergio Lerner sergioler...@certimix.com wrote: Can the system by gamed? Users can pay fees or a portion of fees out of band to miner(s); this is undetectable to the network. Then this is exactly what

[Bitcoin-development] Reducing the block rate instead of increasing the maximum block size

2015-05-11 Thread Sergio Lerner
In this e-mail I'll do my best to argue than if you accept that increasing the transactions/second is a good direction to go, then increasing the maximum block size is not the best way to do it. I argue that the right direction to go is to decrease the block rate to 1 minute, while keeping the

[Bitcoin-development] A way to create a fee market even without a block size limit (2013)

2015-05-10 Thread Sergio Lerner
Two years ago I presented a new way to create a fee market that does not depend on the block chain limit. This proposal has not been formally analyzed in any paper since then, but I think it holds a good promise to untangle the current problem regarding increasing the tps and creating the fee

Re: [Bitcoin-development] Reducing the block rate instead of increasing the maximum block size

2015-05-12 Thread Sergio Lerner
On 11/05/2015 04:25 p.m., Leo Wandersleb wrote: I assume that 1 minute block target will not get any substantial support but just in case only few people speaking up might be taken as careful support of the idea, here's my two cents: In mining, stale shares depend on delay between

Re: [Bitcoin-development] Version bits proposal

2015-05-27 Thread Sergio Lerner
I like the idea but I think we should leave at least 16 bits of the version fixed as an extra-nonce. If we don't then miners may use them as a nonce anyway, and mess with the soft-fork voting system. My original proposal was this: https://github.com/bitcoin/bitcoin/pull/5102 Best regards