Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Luke Dashjr
On Saturday, June 20, 2015 1:23:03 AM Aaron Voisine wrote:
 They don't need to be made cryptographically safe, they just have to be
 safer than, for instance, credit card payments that can be charged back. As
 long as it's reasonably good in practice, that's fine.

They never will be. You can get a decent rate of success merely by making one 
transaction propagate fast (eg, 1 input, 1 output) and the other slow (eg, 
1000 inputs, 1000 outputs) and choosing your peers carefully. The only reason 
unconfirmed transactions aren't double spent today is because nobody is 
seriously *trying*.

Luke

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] The Bitcoin Node Market

2015-06-15 Thread Luke Dashjr
On Tuesday, June 16, 2015 3:30:44 AM Kevin Greene wrote:
 Would SPV wallets have to pay to connect to the network too? From the
 user's perspective, it would be somewhat upsetting (and confusing) to see
 your balance slowly draining every time you open your wallet app. It would
 also tie up outputs every time you open up your wallet. You may go to pay
 for something in a coffee shop, only to find that you can't spend your
 bitcoin because the wallet had to create a transaction to pay to sync with
 the network.
 
 Also, users of centralized wallet services like Coinbase would not have to
 pay that fee; but users of native wallets like breadwallet would have no
 such option. This incentivizes users to use centralized wallets.
 
 So this is kind of imposing a worse user experience on users who want to
 use bitcoin the right way. That doesn't seem like a good thing to me :/

SPV isn't the right way either ;)

If you're running a full node (the real right way), you should be able to 
earn more bitcoins than you pay out.

Luke

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP for Proof of Payment

2015-06-06 Thread Luke Dashjr
On Saturday, June 06, 2015 2:35:17 PM Kalle Rosenbaum wrote:
 Current methods of proving a payment:
 
 * Signing messages, chosen by the server, with the private keys used to
 sign the transaction. This could meet 1 and 2 but probably not 3. This is
 not standardized either. 4 Could be met if designed so.

It's also not secure, since the signed messages only prove ownership of the 
address associated with the private key, and does not prove ownership of 
UTXOs currently redeemable with the private key, nor prove past UTXOs spent 
were approved by the owner of the address.

 A proof of payment for a transaction T, here called PoP(T), is used to
 prove that one has ownership of the credentials needed to unlock all the
 inputs of T.

This appears to be incompatible with CoinJoin at least. Maybe there's some 
clean way to avoid that by using 
https://github.com/Blockstream/contracthashtool ?

 It has the exact same structure as a bitcoin transaction with
 the same inputs and outputs as T and in the same order as in T. There is
 also one OP_RETURN output inserted at index 0, here called the pop output.

I also agree with Pieter, that this should *not* be so cleanly compatible 
with Bitcoin transactions. If you wish to share code, perhaps using an 
invalid opcode rather than OP_RETURN would be appropriate.

Luke

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP for Proof of Payment

2015-06-06 Thread Luke Dashjr
On Saturday, June 06, 2015 9:25:02 PM Kalle Rosenbaum wrote:
 * The pop output will have value 0.

Why not have it be -1 to make it completely invalid as a transaction?

Luke

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Version bits proposal

2015-05-26 Thread Luke Dashjr
On Wednesday, May 27, 2015 1:48:05 AM Pieter Wuille wrote:
 Feel free to comment. As the gist does not support notifying participants
 of new comments, I would suggest using the mailing list instead.

I suggest adding a section describing how this interacts with and changes GBT.

Currently, the client tells the server what the highest block version it 
supports is, and the server indicates a block version to use in its template, 
as well as optional instructions for the client to forcefully use this version 
despite its own maximum version number. Making the version a bitfield 
contradicts the increment-only assumption of this design, and since GBT 
clients are not aware of overall network consensus state, reused bits can 
easily become confused. I suggest, therefore, that GBT clients should indicate 
(instead of a maximum supported version number) a list of softforks by 
identifier keyword, and the GBT server respond with a template indicating:
- An object of softfork keywords to bit values, that the server will accept.
- The version number, as presently conveyed, indicating the preferred softfork 
flags.

Does this sound reasonable, and/or am I missing anything else?

Luke

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Zero-Conf for Full Node Discovery

2015-05-25 Thread Luke Dashjr
On Tuesday, May 26, 2015 4:46:22 AM Kevin Greene wrote:
 This is something you actually don't want. In order to make it as difficult
 as possible for an attacker to perform a sybil attack, you want to choose a
 set of peers that is as diverse, and unpredictable as possible.

It doesn't hurt to have a local node or two, though. Might as well to improve 
propagation, while maintaining the other peers to avoid sybil attacks.

Luke

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

2015-05-15 Thread Luke Dashjr
On Friday, May 15, 2015 9:54:55 AM s7r wrote:
 If you strip both the scriptSig of the parent and the txid, nothing can
 any longer be mutated but this is not safe against replays. This could
 work if we were using only one scriptPubKey per tx. But this is not
 enforced, ...

Assuming you mean one output per scriptPubKey (and not limiting tx to one 
output), the alternative is essentially undefined, and creates real problems 
for Bitcoin today. It's not something we should go out of the way to support 
or encourage. Therefore, regardless of whatever other options are available, I 
would like to see a scriptPubKey-only sighash type for strong safety within 
all malleability situations (including CoinJoin and other sender-respends) 
that more advanced wallet software could take advantage of in the future 
(while strictly enforcing no-reuse on its own wallet to avoid known replays).

Luke

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

2015-05-13 Thread Luke Dashjr
I think this hardfork is dead-on-arrival given the ideas for OP_CHECKSIG 
softforking. Instead of referring to previous transactions by a normalised 
hash, it makes better sense to simply change the outpoints in the signed data 
and allow nodes to hotfix dependent transactions when/if they are malleated. 
Furthermore, the approach of using a hash of scriptPubKey in the input rather 
than an outpoint also solves dependencies in the face of intentional 
malleability (respending with a higher fee, or CoinJoin, for a few examples).

These aren't barriers to making the proposal or being assigned a BIP number if 
you want to go forward with that, but you may wish to reconsider spending time 
on it.

Luke


On Wednesday, May 13, 2015 12:48:04 PM Christian Decker wrote:
 Hi All,
 
 I'd like to propose a BIP to normalize transaction IDs in order to address
 transaction malleability and facilitate higher level protocols.
 
 The normalized transaction ID is an alias used in parallel to the current
 (legacy) transaction IDs to address outputs in transactions. It is
 calculated by removing (zeroing) the scriptSig before computing the hash,
 which ensures that only data whose integrity is also guaranteed by the
 signatures influences the hash. Thus if anything causes the normalized ID
 to change it automatically invalidates the signature. When validating a
 client supporting this BIP would use both the normalized tx ID as well as
 the legacy tx ID when validating transactions.
 
 The detailed writeup can be found here:
 https://github.com/cdecker/bips/blob/normalized-txid/bip-00nn.mediawiki.
 
 @gmaxwell: I'd like to request a BIP number, unless there is something
 really wrong with the proposal.
 
 In addition to being a simple alternative that solves transaction
 malleability it also hugely simplifies higher level protocols. We can now
 use template transactions upon which sequences of transactions can be built
 before signing them.
 
 I hesitated quite a while to propose it since it does require a hardfork
 (old clients would not find the prevTx identified by the normalized
 transaction ID and deem the spending transaction invalid), but it seems
 that hardforks are no longer the dreaded boogeyman nobody talks about.
 I left out the details of how the hardfork is to be done, as it does not
 really matter and we may have a good mechanism to apply a bunch of
 hardforks concurrently in the future.
 
 I'm sure it'll take time to implement and upgrade, but I think it would be
 a nice addition to the functionality and would solve a long standing
 problem :-)
 
 Please let me know what you think, the proposal is definitely not set in
 stone at this point and I'm sure we can improve it further.
 
 Regards,
 Christian

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] CLTV opcode allocation; long-term plans?

2015-05-12 Thread Luke Dashjr
It should actually be straightforward to softfork RCLTV in as a negative CLTV.
All nLockTime are = any negative number, so a negative number makes CLTV a 
no-op always. Therefore, it is clean to define negative numbers as relative 
later. It's also somewhat obvious to developers, since negative numbers often 
imply an offset (eg, negative list indices in Python).

Luke

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-05-11 Thread Luke Dashjr
On Monday, May 11, 2015 7:03:29 AM Sergio Lerner wrote:
 1. It will encourage centralization, because participants of mining
 pools will loose more money because of excessive initial block template
 latency, which leads to higher stale shares
 
 When a new block is solved, that information needs to propagate
 throughout the Bitcoin network up to the mining pool operator nodes,
 then a new block header candidate is created, and this header must be
 propagated to all the mining pool users, ether by a push or a pull
 model. Generally the mining server pushes new work units to the
 individual miners. If done other way around, the server would need to
 handle a high load of continuous work requests that would be difficult
 to distinguish from a DDoS attack. So if the server pushes new block
 header candidates to clients, then the problem boils down to increasing
 bandwidth of the servers to achieve a tenfold increase in work
 distribution. Or distributing the servers geographically to achieve a
 lower latency. Propagating blocks does not require additional CPU
 resources, so mining pools administrators would need to increase
 moderately their investment in the server infrastructure to achieve
 lower latency and higher bandwidth, but I guess the investment would be
 low.

1. Latency is what matters here, not bandwidth so much. And latency reduction 
is either expensive or impossible.
2. Mining pools are mostly run at a loss (with exception to only the most 
centralised pools), and have nothing to invest in increasing infrastructure.

 3, It will reduce the security of the network
 
 The security of the network is based on two facts:
 A- The miners are incentivized to extend the best chain
 B- The probability of a reversal based on a long block competition
 decreases as more confirmation blocks are appended.
 C- Renting or buying hardware to perform a 51% attack is costly.
 
 A still holds. B holds for the same amount of confirmation blocks, so 6
 confirmation blocks in a 10-minute block-chain is approximately
 equivalent to 6 confirmation blocks in a 1-minute block-chain.
 Only C changes, as renting the hashing power for 6 minutes is ten times
 less expensive as renting it for 1 hour. However, there is no shop where
 one can find 51% of the hashing power to rent right now, nor probably
 will ever be if Bitcoin succeeds. Last, you can still have a 1 hour
 confirmation (60 1-minute blocks) if you wish for high-valued payments,
 so the security decreases only if participant wish to decrease it.

You're overlooking at least:
1. The real network has to suffer wasted work as a result of the stale blocks, 
while an attacker does not. If 20% of blocks are stale, the attacker only 
needs 40% of the legitimate hashrate to achieve 50%-in-practice.
2. Since blocks are individually weaker, it becomes cheaper to DoS nodes with 
invalid blocks. (not sure if this is a real concern, but it ought to be 
considered and addressed)

 4. Reducing the block propagation time on the average case is good, but
 what happen in the worse case?
 
 Most methods proposed to reduce the block propagation delay do it only
 on the average case. Any kind of block compression relies on both
 parties sharing some previous information. In the worse case it's true
 that a miner can create and try to broadcast a block that takes too much
 time to verify or bandwidth to transmit. This is currently true on the
 Bitcoin network. Nevertheless there is no such incentive for miners,
 since they will be shooting on their own foots. Peter Todd has argued
 that the best strategy for miners is actually to reach 51% of the
 network, but not more. In other words, to exclude the slowest 49%
 percent. But this strategy of creating bloated blocks is too risky in
 practice, and surely doomed to fail, as network conditions dynamically
 change. Also it would be perceived as an attack to the network, and the
 miner (if it is a public mining pool) would be probably blacklisted.

One can probably overcome changing network conditions merely by trying to 
reach 75% and exclude the slowest 25%. Also, there is no way to identify or 
blacklist miners.

 5. Thousands of SPV wallets running in mobile devices would need to be
 upgraded (thanks Mike).
 
 That depends on the current upgrade rate for SPV wallets like Bitcoin
 Wallet  and BreadWallet. Suppose that the upgrade rate is 80%/year: we
 develop the source code for the change now and apply the change in Q2
 2016, then  most of the nodes will already be upgraded by when the
 hardfork takes place. Also a public notice telling people to upgrade in
 web pages, bitcointalk, SPV wallets warnings, coindesk, one year in
 advance will give plenty of time to SPV wallet users to upgrade.

I agree this shouldn't be a real concern. SPV wallets are also more likely and 
less risky (globally) to be auto-updated.

 6. If there are 10x more blocks, then there are 10x more block headers,
 and that increases the amount of bandwidth SPV wallets 

Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

2015-02-14 Thread Luke Dashjr
On Saturday, February 14, 2015 2:23:47 PM Tamas Blummer wrote:
 We have seen that the consensus critical code practically extends to
 Berkley DB limits or OpenSSL laxness, therefore it is inconceivable that a
 consensus library is not the same as Bitcoin Core, less its P2P service
 rules, wallet and RPC server.

You can describe 'A' from a group of A, B, C, D, E as the group minus B, C, 
D, E, sure - but I don't see how this is relevant?

UTXO storage is indeed consensus critical, as you say, but it is a lot simpler 
to get right than the rest combined. Thus, the end goal is to have a 
libbitcoinconsensus with the rest, and a (as of yet named) 
libbitcoincompleteconsensus that ties in the canonical UTXO storage. Ideally, 
software should use the latter when it is available, but if there is a strong 
reason to change UTXO storage, one can remain mostly-safe with just the 
former. I'm not sure why this topic is of relevance, though...

Luke

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP for deterministic pay-to-script-hash multi-signature addresses

2015-02-12 Thread Luke Dashjr
Where is the Specification section?? Does this support arbitrary scripts, or 
only the simplest CHECKMULTISIG case?

On Thursday, February 12, 2015 9:42:23 PM Thomas Kerin wrote:
 Hi all,
 
 I have drafted a BIP with Jean Pierre and Ruben after the last
 discussion, related to a standard for deriving a canonical
 pay-to-script-hash address given a set of public keys and the number of
 signatures required. There have been two or three discussions about it
 on the mailing list to date, and various services already carry out this
 process. I hope a BIP to describe this process will allow services to
 declare themselves as BIPXX compliant, working towards interoperability
 of services and simplifying the derivation of scripts and their
 addresses by all parties.
 
 
   BIP: XX
   Title: Deterministic Pay-to-script-hash multi-signature addresses
 through public key sorting
   Author: Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries
   Status: Draft
   Type: Standards Track
   Created: 8 February 2015
 
 ==Abstract==
 
 This BIP describes a method to deterministically generate
 multi-signature transaction scripts.  It focuses on defining how the
 public keys must be encoded and sorted so that the redeem script and
 corresponding P2SH address are always the same for a given set of keys
 and number of required signatures.
 
 ==Motivation==
 
 Most multi-signature transactions are addressed to P2SH
 (pay-to-script-hash) addresses, as defined in BIP-0016.
 
 Multi-signature redeem scripts do not require a particular ordering or
 encoding for public keys.  This means that for a given set of keys and
 number of required signatures, there are as many as 2(n!) possible
 standard redeem scripts, each with its separate P2SH address.  Adhering
 to a an ordering scheme and key encoding would ensure that a
 multi-signature “account” (set of public keys and required signature
 count) has a canonical P2SH address.
 
 By adopting a sorting and encoding standard, compliant wallets will
 always produce the same P2SH address for the same given set of keys and
 required signature count, making it easier to recognize transactions
 involving that multi-signature account.  This is particularly attractive
 for multisignature hierarchical-deterministic wallets, as less state is
 required to setup multi-signature accounts:  only the number of required
 signatures and master public keys of participants need to be shared, and
 all wallets will generate the same addresses.
 
 While most web wallets do not presently facilitate the setup of
 multisignature accounts with users of a different service, conventions
 which ensure cross-compatibility should make it easier to achieve this.
 
 Many wallet as a service providers use a 2of3 multi-signature schema
 where the user stores 1 of the keys (offline) as backup while using the
 other key for daily use and letting the service cosign his transactions.
 This standard will help in enabling a party other than the service
 provider to recover the wallet without any help from the service provider.
 
 ==Implementation==
 
 For a set of public keys, ensure that they have been received in
 compressed form, sort them lexicographically according to their binary
 representation before using the resulting list of keys in a standard
 multisig redeem script.  Hash the redeem script according to BIP-0016 to
 get the P2SH address.
 
 ==Compatibility==
 
 * Uncompressed keys are incompatible with this specificiation. A
 compatible implementation should not automatically compress keys.
 Receiving an uncompressed key from a multisig participant should be
 interpreted as a sign that the user has an incompatible implementation.
 * P2SH addressses do not reveal information about the script that is
 receiving the funds. For this reason it is not technically possible to
 enforce this BIP as a rule on the network.  Also, it would cause a hard
 fork.
 * Implementations that do not conform with this BIP will have
 compatibility issues with strictly-compliant wallets.
 * Implementations which do adopt this standard will be cross-compatible
 when choosing multisig addressses.
 * If a group of users were not entirely compliant, there is the
 possibility that a participant will derive an address that the others
 will not recognize as part of the common multisig account.
 
 ==Test vectors==
 The required number of signatures in each case is 2.
 
 Vector 1
 * List
 ** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8
 ** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f
 * Sorted
 ** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f
 ** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8
 * Script
 **
 522102fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f2102f
 f12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f852ae *
 Address
 ** 39bgKC7RFbpoCRbtD5KEdkYKtNyhpsNa3Z
 
 Vector 2 (Already sorted, no action required)
 * List:
 ** 

[Bitcoin-development] [SPAM] Re: determining change addresses using the least significant digits

2015-02-05 Thread Luke Dashjr
On Friday, February 06, 2015 3:16:13 AM Justus Ranvier wrote:
 On 02/04/2015 02:23 PM, Isidor Zeuner wrote:
  Hi there,
  
  traditionally, the Bitcoin client strives to hide which output
  addresses are change addresses going back to the payer. However,
  especially with today's dynamically calculated miner fees, this may
  often be ineffective:
  
  A user sending a payment using the Bitcoin client will usually
  enter the payment amount only up to the number of digits which are
  considered to be significant enough. So, the least significant
  digits will often be zero for the payment. With dynamically
  calculated miner fees, this will often not be the case for the
  change amount, making it easy for an observer to classify the
  output addresses.
  
  A possible approach to handle this issue would be to add a
  randomized offset amount to the payment amount. This offset amount
  can be small in comparison to the payment amount.
 
 Another possible approach is to randomize the number of change outputs
 from transaction to transaction.
 
 Doing this, it would be possible to make change outputs that mimic
 real spends (low number of s.d.)

This uses more data.

Why not just round change down (effectively rounding fee up)?

Luke

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-12-29 Thread Luke Dashjr
On Monday, December 29, 2014 7:21:02 PM Sergio Lerner 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 not allow any real input  to be added (only a
 pseudo-input).

This is something I've wanted since 2011, but hasn't been a priority.

 Because sometime in the future (maybe 5-10 years) we may have to deal
 with problems of securing the blockchain, as the subsidy is lowered. We
 don't want the number of confirmation blocks to be increased in
 compensation because Bitcoin won't be able to compete with other payment
 networks.
 Then by having this hardfork now, we will be able to soft-fork later to
 any rule we may came come up with involving deposit bonds,
 proof-of-stake, and the penalization of double-mining (mining two blocks
 at the same height) to prevent short-range attacks.

I'm not sure this increases the priority of it.

If someone feels it's worth the time, I'd suggest coding up a branch that 
hardforks it in at some far-off block height. Even if it doesn't get merged 
right away, at least the code will be available for testing and ready to go 
when/if that time comes.

Luke

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-12-29 Thread Luke Dashjr
On Monday, December 29, 2014 9:10:20 PM Mike Hearn wrote:
 How does adding inputs to a coinbase differ from just having pay-to-fee
 transactions in the block?

Pay-to-fee transactions can be stolen by another block at the same or 
greater height. Additional inputs to the generation transaction are tied to 
that block alone.

Luke

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Serialised P2SH HD chains

2014-12-04 Thread Luke Dashjr
Is anyone working on a serialisation format to convey P2SH HD chains? For 
example, to give someone who wants to make recurring payments a single token 
that can be used to generate many P2SH addresses paying to a multisig script.

I'm thinking of something along the lines of a simple series of tokens, each 
indicating either a HD chain or literal script content. For all HD chains in 
the data, a child key would be generated based on the payment number, and all 
tokens concatenated to form the P2SH serialised script. Eg, for a simple 2-
of-2, you would do something like this:
literal(OP_2) HDChain HDChain literal(OP_2 OP_CHECKMULTISIG)
Does this sufficiently cover all reasonable use cases?

Luke

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Serialised P2SH HD chains

2014-12-04 Thread Luke Dashjr
On Thursday, December 04, 2014 8:02:17 PM Jeffrey Paul wrote:
 What is the use case for something like this?  It’s my impression that a
 single token that can be used to obtain many P2SH addresses paying to a
 multisig script looks something like
 
bitcoin:?r=https://payee.com/customer12345/recurring/paymentrequest/new

This requires the payee operate a server. My use case is for payment to 
individuals, who may or may not have a computer powered at the time of the 
transactions being sent. Furthermore, the users I am targeting (miners, to be 
specific), wish to remain entirely anonymous, and not hold accounts of any 
sort.

 The model that you describe where a payer can, without communication with
 the payee, generate additional multisig p2sh addresses based on a set of
 xpubs presumes that the payee would never want to e.g. cycle their own
 keys or change their cooperating multisig participants’ keys.  Is this
 wise?

This depends on the framework. As of present day, miners are limited to only 
use a single address ever, and cannot change it even to avoid address reuse. 
One goal is to solve that, without breaking multisig.

Luke

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-16 Thread Luke Dashjr
On Sunday, November 16, 2014 4:21:27 PM Flavien Charlon wrote:
 The data that can be embedded as part of an OP_RETURN output is currently
 limited to 40 bytes. It was initially supposed to be 80 bytes, but got
 reduced to 40 before the 0.9 release to err on the side of caution.
 
 After 9 months, it seems OP_RETURN did not lead to a blockchain
 catastrophe, so I think it might be time to discuss increasing the limit.

Mining policies such as this is always up to miners.
It's not a development topic.

 There are a number of proposals:
 
1. Allow two OP_RETURN outputs per transaction (PR
https://github.com/bitcoin/bitcoin/pull/5075)

This one seems uselessly inefficient. Protocols needing OP_RETURN could just 
as easily look for an independent push opcode in a single OP_RETURN output.

2. Increase the default maximum payload size from 40 bytes to 80 bytes (
PR https://github.com/bitcoin/bitcoin/pull/5286)
Note that the maximum can be configured already through the
'datacarriersize' option - this is just changing the default.

I don't care strongly, but IMO this kind of focus on defaults is part of the 
problem. I'd prefer to have the default be randomised to incentivise miners to 
make the decision they're supposed to be making, rather than pushing the 
responsibility onto developers to set defaults.

3. Make the maximum OP_RETURN payload size proportional to the number of
outputs of the transaction

Right now, this policy requires code hacks. Of the three ideas, this one looks 
the most ripe for code changes (particularly one that makes it possible to 
configure this policy, not hardcoding it).

Luke

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposed BIP status changes

2014-10-16 Thread Luke Dashjr
On Thursday, October 16, 2014 6:22:04 AM Wladimir wrote:
  Shouldn't we be doing this in a GitHub PR rather than spamming up the ML?
 
 Not really. BIP changes should be discussed on the mailing list,
 that's the way to get community consensus (as specified in BIP1).
 
 Wladimir

Discussion vs simple ACKing.

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposed BIP status changes

2014-10-15 Thread Luke Dashjr
On Wednesday, October 15, 2014 8:47:18 AM Wladimir wrote:
 These BIPs should go to Final state - they are implemented all over
 the place, and are thus entirely fixed in place now. Any changes would
 require a new BIP as amandment:
 
 - BIP 14 (BIP Protocol Version and User Agent)

ACK

 - BIP 21 (URI Scheme)

ACK

 - BIP 22 (getblocktemplate - Fundamentals)

ACK

 - BIP 31 (Pong Message)

ACK

 - BIP 34 (Block v2, Height in coinbase)

ACK

 - BIP 35 (mempool message)

ACK

 - BIP 37 (Bloom filtering)
 
 Let me know if you (don't) agree.

Shouldn't we be doing this in a GitHub PR rather than spamming up the ML?

Luke

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP process

2014-10-15 Thread Luke Dashjr
On Wednesday, October 15, 2014 7:40:04 PM Peter Todd wrote:
 On Wed, Oct 15, 2014 at 08:00:10PM +0100, Btc Drak wrote:
   * Google lists are somehow a little proprietary or gmail lockin
   focused eg it makes things extra hard to subscribe with a non-google
   address if google has any hint that your address is associated with a
   gmail account.  Quite frustrating.
  
  Mailman is good enough...
 
 I used these guys for awhile to host a small mailman list with
 absolutely no issues. Just $5/month for 1000 subscribers.
 
 https://www.mailmanlist.net/

I've been using http://lists.nongnu.org/ for BFGMiner announce/dev mailing 
lists for a while. I don't know what software it runs, but it works.

Catch is that we'd need to go through Savannah's free software auditing.
That might be a good idea anyway?

Luke

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Request for review/testing: headers-first synchronization in Bitcoin Core

2014-10-12 Thread Luke Dashjr
On Sunday, October 12, 2014 8:41:29 AM Geir Harald Hansen wrote:
 On 12.10.2014 01:34, Pieter Wuille wrote:
  * No orphan blocks stored in memory anymore (reducing memory usage during
  sync).
 
 Will this slow down reorgs after a fork, compared to today?

It shouldn't... he's talking about actual orphan blocks (ones without a known 
previous/parent block), not stale blocks.

Luke

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-10-03 Thread Luke Dashjr
On Friday, October 03, 2014 2:28:17 PM Matt Whitlock wrote:
 Is there a reason why we can't have the new opcode simply replace the top
 stack item with the block height of the txout being redeemed? Then
 arbitrary logic could be implemented, including output cannot be spent
 until a certain time and also output can ONLY be spent until a certain
 time, as well as complex logic with alternative key groups with differing
 time constraints.

This cannot be done in a softfork.

Furthermore, output can ONLY be spent until a certain time contradict's 
Bitcoin's present security assumptions: that assuming a honest sender, the 
transaction will remain valid and simply re-confirm if a reorg kicks it out.

Luke

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-10-01 Thread Luke Dashjr
On Wednesday, October 01, 2014 1:08:26 PM Peter Todd wrote:
 I've written a reference implementation and BIP draft for a new opcode,
 CHECKLOCKTIMEVERIFY.

Thoughts on some way to have the stack item be incremented by the height at 
which the scriptPubKey was in a block? A limitation of encoding the target 
height/time directly, is that miners may choose not to mine the first 
transaction until they can also take the burn to fee. So, one may prefer to 
say cannot be spent until 100 blocks after the first transaction is mined, 
in effect reproducing the generation maturity rule.

I propose any stack item under 0x4 be incremented by the height at which 
the scriptPubKey was mined for comparison. Maybe there is a use case for doing 
something similar for time too?

Luke

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-10-01 Thread Luke Dashjr
On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote:
 On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr l...@dashjr.org wrote:
 Thoughts on some way to have the stack item be incremented by the
 height at
 which the scriptPubKey was in a block?
 
 Better to create a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator.
 scriptPubKey would be:
 GET-TXIN-BLOCKHEIGHT-EQUALVERIFY
 (fails unless top stack item is equal to the txin block height)
 delta height ADD
 (top stack item is now txin height + delta height)
 CHECKLOCKTIMEVERIFY

This sounds do-able, although it doesn't address using timestamps.

  A limitation of encoding the target
 height/time directly, is that miners may choose not to mine the first
 transaction until they can also take the burn to fee. So, one may
 prefer to
 say cannot be spent until 100 blocks after the first transaction is
 mined,
 in effect reproducing the generation maturity rule.
 
 You'd want these sacrifices to unlock years into the future to thoroughly
 exceed any reasonable business cycle; that's so far into the future that
 miners are almost certain to just mine them and collect the fees.

For many use cases, short maturity periods are just as appropriate IMO.

Luke

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] replace-by-fee v0.9.3 release

2014-09-28 Thread Luke Dashjr
On Sunday, September 28, 2014 5:15:53 AM Peter Todd wrote:
 On Sat, Sep 27, 2014 at 07:55:44PM -0700, Tom Harding wrote:
  On 9/25/2014 7:37 PM, Aaron Voisine wrote:
   Of course you wouldn't want nodes to propagate alerts without
   independently verifying them
  
  How would a node independently verify a double-spend alert, other than
  by having access to an actual signed double-spend?
  
  #4570 relays the first double-spend AS an alert.  Running this branch on
  mainnet, I have been keeping a live list of relayed double-spend
  transactions at http://respends.thinlink.com
 
 Speaking of, I ported my replace-by-fee branch the recent v0.9.3
 release: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.3
 
 I actually ported it a few days ago; that release has been running on a
 half-dozen or so nodes right now for a few days with no issues.
 
 The v0.9.3 release's scriptSig size limit increase adds a new category
 of double-spending exploit. I'm not going to get time to add that
 exploit to my replace-by-fee toolkit(1) for at least another week or so
 though - pull-reqs accepted.
 
 1) https://github.com/petertodd/replace-by-fee-tools

Do you have or can you provide a version compatible with CPFP, such that a 
child paying a higher fee trumps the parent's replacement?

Preferably something that will merge cleanly into 0.9.x-ljr :)

Luke

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

2014-08-23 Thread Luke Dashjr
On Saturday, August 23, 2014 6:44:15 PM Mike Hearn wrote:
  Not to mention encrypting basically non-sensitive inter-node traffic is
  almost completely worthless in providing anonymity anyway...
 
 Recall that P2P connections carry Bloom filters too, which are not public
 information.

As soon as you tell it to an unknown/public peer, it is public information.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Miners MiTM

2014-08-08 Thread Luke Dashjr
On Friday, August 08, 2014 6:21:18 PM Jeff Garzik wrote:
 gmaxwell noted on IRC that enabling TLS could be functionally, if not
 literally, a DoS on the pool servers.  Hence the thought towards a
 more lightweight method that simply prevents client payout redirection
 + server impersonation.

My thought for GBT2 a while ago was to use simple ECDSA signatures for 
messages. It'd be nice to use the same as Bitcoin, but then we'd hit problems 
with RedHat/Fedora legal being stupid. :(

Luke

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Miners MiTM

2014-08-07 Thread Luke Dashjr
On Thursday, August 07, 2014 11:02:21 PM Pedro Worcel wrote:
 Hi there,
 
 I was wondering if you guys have come across this article:
 
 http://www.wired.com/2014/08/isp-bitcoin-theft/
 
 The TL;DR is that somebody is abusing the BGP protocol to be in a position
 where they can intercept the miner traffic. The concerning point is that
 they seem to be having some degree of success in their endeavour and
 earning profits from it.
 
 I do not understand the impact of this (I don't know much about BGP, the
 mining protocol nor anything else, really), but I thought it might be worth
 putting it up here.

This is old news; both BFGMiner and Eloipool were hardened against it a long 
time ago (although no Bitcoin pools have deployed it so far). I'm not aware of 
any actual case of it being used against Bitcoin, though - the target has 
always been scamcoins.

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Miners MiTM

2014-08-07 Thread Luke Dashjr
On Friday, August 08, 2014 12:29:31 AM slush wrote:
 AFAIK the only protection is SSL + certificate validation on client side.
 However certificate revocation and updates in miners are pain in the ass,
 that's why majority of pools (mine including) don't want to play with
 that...

Certificate validation isn't needed unless the attacker can do a direct MITM 
at connection time, which is a lot harder to maintain than injecting a 
client.reconnect. This, combined with your concern about up to date 
certs/revokes/etc, is why BFGMiner defaults to TLS without cert checking for 
stratum.

Luke

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin address TTL key expiration?

2014-07-15 Thread Luke Dashjr
On Tuesday, July 15, 2014 8:00:41 AM Jeff Garzik wrote:
 Proxying another's idea, from CoinSummit.
 
 The request:   It would be useful to limit the lifetime of a bitcoin
 address.  Intentionally prevent (somehow) bitcoins being sent to a
 pubkey/pkh after the key expires.
 
 You could append don't [permit|confirm] after X [time|block]  to
 the address I suppose.  The metadata would not be digitally signed,
 but it would be hash-sealed.  As address is a client-side notion,
 wallet clients would be the ones enforcing such a rule.

I agree this would be useful for the permit case, but not the confirm case 
- it's important that transactions valid in block X also be equally valid in 
block X+1 to avoid reorg issues.

 Bitcoin protocol of course knows about keys, and key expiration is a
 well known and useful concept in public key cryptography.  The best
 insertion point in the protocol for key expiration is an open
 question, if it's even a good idea at that level at all.  Some flag
 no more TxOuts exactly like this [after X block?]?

This would force every wallet to keep an index of all TXOs ever.

 I readily admit I don't have good answers, but it does seem valuable IMO to
 * Prevent users from accidentally sending to an expired TxOut/pkh.
 This happens in the field.
 * Discourage address reuse

Actually, I think this may make address reuse easier, as with base58 adding 
data will make it impossible to tell at a glance when someone is reusing a key 
with just a different expiration... I suppose something other than base58 
*could* be used to resolve this, however.

 * Enable sites that generate lots of keys to rotate ancient keys off
 their core systems.  (HD wallets mitigate this)

They can already do this. It's perfectly valid for wallets/services to ignore 
(and not consider as payment) transactions using an address more than once. 
There might be race attacks if this is implemented in an immediate fashon 
(attacker transaction gets mined first to kill a payment), but should be 
pretty safe after a few blocks.

Luke

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin address TTL key expiration?

2014-07-15 Thread Luke Dashjr
On Tuesday, July 15, 2014 3:11:25 PM Jeff Garzik wrote:
 On Tue, Jul 15, 2014 at 10:48 AM, Luke Dashjr l...@dashjr.org wrote:
  They can already do this. It's perfectly valid for wallets/services to
  ignore (and not consider as payment) transactions using an address more
  than once. There might be race attacks if this is implemented in an
  immediate fashon (attacker transaction gets mined first to kill a
  payment), but should be pretty safe after a few blocks.
 
 Sure it's valid.  However, few users will appreciate you ignored my
 deposit as a feature.
 
 Payment protocol just doesn't well the use cases of,
 * an on-going payment stream from, e.g. Eligius to coinbase

https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Serialization_format

 * deposit addresses and deposit situations

There's no reason deposits cannot use a unique payment request or address 
every time...

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Lets discuss what to do if SHA256d is actually broken

2014-06-02 Thread Luke Dashjr
On Tuesday, June 03, 2014 4:29:55 AM xor wrote:
 Hi,
 
 I thought a lot about the worst case scenario of SHA256d being broken in a
 way which could be abused to
 A) reduce the work of mining a block by some significant amount
 B) reduce the work of mining a block to zero, i.e. allow instant mining.

C) fabricate past blocks entirely.

If SHA256d is broken, Bitcoin as it is fails entirely.

Luke

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] DNS seeds unstable

2014-05-16 Thread Luke Dashjr
On Friday, May 16, 2014 5:17:17 PM Rob Golding wrote:
   dnsseed.bitcoin.dashjr.orgSERVFAIL, tried multiple ISPs
 
 dnsseed.bitcoin.dashjr.org. 60  IN  NS  jun.dashjr.org.
 but jun.dashjr.org isn't responding to dns queries (as at 18.10 GMT
 2014-05-16)
 
 that would be a fundamental problem with the dns infrastructure for that
 domain (and the sub-hosts/records) , with the authoritive server not
 replying to the dns query

jun.dashjr.org has resolved 130 requests in the past ~12 hours, and I can see 
it resolving more in tcpdump. I do observe two potential problems, however:

- For the past 24-48 hours, there seem to be some significant routing problems 
on the IPv4 internet, resulting in people using various diverse ISPs 
(including myself at home) being unable to route to any of my servers. This 
issue doesn't affect IPv6, however.

- The DNS seeder seems to only be responding to requests received over IPv4. 
This means IPv6 DNS servers get no response. :(

Luke

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] DNS seeds unstable

2014-05-15 Thread Luke Dashjr
On Thursday, May 15, 2014 11:50:29 AM Andreas Schildbach wrote:
 dnsseed.bitcoin.dashjr.orgSERVFAIL, tried multiple ISPs

FWIW, this may be a routing issue: I notice various ISPs have been unable to 
route to my server over IPv4 today. IPv6 seems to be fine.

Not sure how important DNS seed reliability is anyway; it's just 
bootstrapping, and there are multiple servers listed.

Luke

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] moving the default display to mbtc

2014-05-02 Thread Luke Dashjr
On Saturday, May 03, 2014 12:54:37 AM Ben Davenport wrote:
 My only addition is that I think we should all stop trying to attach SI
 prefixes to the currency unit. Name me another world currency that uses SI
 prefixes. No one quotes amounts as 63 k$ or 3 M$. The accepted standard at
 least in the US is currency-symbolamountmodifier, i.e. $63k or $3M.
 That may not be accepted form everywhere, but in any case it's an informal
 format, not a formal one. The important point is there should be one base
 unit that is not modified with SI prefixes. And I think the arguments are
 strong for that unit being = 100 satoshi.

Huh? Your examples demonstrate the *opposite* of your point. 'k' and 'M' *are* 
the SI prefixes. People *do* use 63k USD, $63k, and $3M. I'll be the first one 
to admit SI is terrible, but I don't understand your argument here.

Luke

P.S. Note that SI units haven't actually ever been adopted, except by force of 
law. Name me ... that uses SI is a silly thing to say, since virtually all 
naturally-or-freely-adopted units of any measure have been based on a number 
that factor to twos and threes (not fives, like decimal).

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP Draft: Atomic Cross Chain Transfer Protocol

2014-04-30 Thread Luke Dashjr
On Wednesday, April 30, 2014 6:03:59 PM Tier Nolan wrote:
 Due to popular demand, I have created a BIP for cross chain atomic
 transfers.
 
 https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki

Instead of TX0, TX1, etc, can you put some kind of meaningful identifier for 
these transactions?

TX1 and TX2 *cannot* be signed until after TX0 is completely signed by both 
parties. After TX0 is signed, but before TX2 is signed, either party could 
walk away or otherwise hold the funds hostage. The sequence of signing 
proposed in this BIP is *not possible to perform*. How did you implement and 
test this? :/

What is the purpose of the OP_EQUAL_VERIFY in TX4? I don't see a use...

IMO, there should be separate BIPs for the exchange itself, and the protocol 
to negotiate the exchange. I would recommend changing the latter from JSON-RPC 
to some extension of the Payment Protocol, if possible.

Perhaps it would be good to only support compressed keys, to discourage use of 
uncompressed ones..

Luke

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development