Bitcoin Forum
May 11, 2024, 03:10:45 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 [18] 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 »
341  Bitcoin / Development & Technical Discussion / Re: ANN: Announcing code availability of the bitsofproof supernode on: December 08, 2013, 09:43:28 PM
Added BIP39 support,  that passes Trezor's test vectors.
https://github.com/bitsofproof/supernode/blob/master/api/src/main/java/com/bitsofproof/supernode/wallet/BIP39.java

Added Shamir's secret shares algorithm
https://github.com/bitsofproof/supernode/blob/master/api/src/main/java/com/bitsofproof/supernode/wallet/ShamirsSecretSharing.java

You can create a random word list e.g.:
Code:
		SecureRandom random = new SecureRandom ();
byte[] seed = new byte[16];
random.nextBytes (seed);
System.out.println (BIP39.encode (seed, ""));
// assume it prints:
// mind evil language crouch legal brave insane bid speed notice material scheme

You may now create a BIP32 master out of a word list as e.g.
Code:
		String mnemonic = "mind evil language crouch legal brave insane bid speed notice material scheme";
ExtendedKey key = ExtendedKey.create (BIP39.decode (mnemonic, ""));
System.out.println (key.serialize (true));
// prints: xprv9s21ZrQH143K2uwgrphL7P5ePDPBp8ukjVT3CspHyvdHigHY9DAYQX6D6dkBThQCgmJskkzTbHFy6ZGvz3Vm8GzkGuDAWmvqsKrityeTW5W

Instead of storing the secret word list you could create 3 backups of which 2 is needed to recreate the list (and one is useless alone).

Code:
		List<String> backups = ShamirsSecretSharing.issueMnemonicShares (BIP39.decode (mnemonic, ""), 3, 2, "");
for ( String b : backups )
{
System.out.println (b);
}
// prints:
// find worry owner drill category cancel error stock inspire place bullet blind wood course spend gather response fat
// huge bulk human envelope theory van cricket cattle reopen divorce alley upper pig afford spy mass design reduce
// noodle predict ancient tuition still result garbage melt wise angle island peace rate cereal outside actual more lock

Now take any two of the three to reconstruct the key:

Code:
		List<String> pick = new ArrayList<> ();
pick.add (backups.get (0));
pick.add (backups.get (2));
ExtendedKey recreated = ExtendedKey.create (ShamirsSecretSharing.reconstructFromMnemonicShares (pick, ""));
System.out.println (recreated.serialize (true));
// prints again:
// prints: xprv9s21ZrQH143K2uwgrphL7P5ePDPBp8ukjVT3CspHyvdHigHY9DAYQX6D6dkBThQCgmJskkzTbHFy6ZGvz3Vm8GzkGuDAWmvqsKrityeTW5W

Use the passphrase option (the "" in parameters) to get plausible deniability of the wallet, since you may fund more than one passphrase.
342  Bitcoin / Meetups / Re: announcement: the international "when-bitcoin-reaches 1000,- $ party" on: December 02, 2013, 06:44:15 PM
As you may heard that Bits of Proof will provide the ticket technology for this event.

The reason is that BOP can create a solution that is worthy for this watershed event, demonstrating the world that Bitcoin's ledger is
capable of much more than a payment solution. Here are the unique features of the ticket sale:

1. Payment requests for 1 Bitcoin is generated via bopshop.
    bopshop is unique if compared to other similar services as it generates addresses using the BIP32 master public key of the
    merchant, therefore the payment flows from customer to merchant without BOP taking the funds in possession, not even
    temporarily. BOP can facilitate processing without being a payment processor in any legal sense, since it has no
    access to the funds transferred. See http://bopshop.bitsofproof.com for details and API.

2. The 1 Bitcoin received by the organizer will be immediately split into two parts 999 mB goes to the Vault, see point 3
    and 1 mB goes to the address of a paper wallet you generate, that will act as an entry ticket.

3. The Vault is a P2SH address (see https://en.bitcoin.it/wiki/BIP_0016) for a 2 out of 3 multi signature script. The three organizer
    generated their own key and sent the public part to BOP, so it could compute the P2SH address and automate the
    transfer of the 999 mB to it. This Vault address will be public, so you may use any block explorer to audit the holding and spend
    of the funds by the organizer.

4. At entry to the event you will be required to show your paper wallet's private key as a QR code, so it can be swept by a BOP
   mobile program that the same time spends and validates that the mB you presented is in fact a mB that was the part of a
   payment to the Vault. Since the mB will be taken no copies of the same paper wallet will be admitted at the second attempt.
   Note that the organizer might stop ticket sale if the event is sold out. Direct payments to the Vault
   bypassing Step 1 can be identified and will be considered as donations, not as entry fees. The process is a simplified
   demonstration of colored coins.

5. The organizer will be supplied with a special purpose Wallet by BOP, so they can spend the Vault to any address they need to
   fund the event, provided 2 out of them signs the same transaction. Note that, BOP will be at no point in possession of the
   funds, nor any of the organizer individually.

6. All tools involved and specific to the process, such as the coin splitter, event entry validation mobile application and the special
   purpose wallet will be open sourced to demonstrate Bitcoins' and BOP capabilities to go far beyond simple payments without
   requiring trust into the technology provider.

All above was agreed by BOP and the event organizer as Bitcoin was far away from its current value. As you know Bitcoin rose
much faster than most of us imagined, and this project became much more urgent than anticipated by any of us.

I hope you agree that above technology demonstration adds to the anticipated positive media effect of the party, and therefore
forgive us for being not able to match the stunning speed of Bitcoin's appreciation with development and testing.

Our current plan is to start ticket sales on 9. December.



343  Bitcoin / Bitcoin Discussion / Re: $10,000 Bet that Bitcoins will outperform Gold, Silver by 100X !!! on: November 30, 2013, 08:59:39 PM
You are great Roger. Did everything right, again. Thank you.
344  Bitcoin / Project Development / Re: Game Idea - Basically a Cryptocoin filled version of Ingress on: November 27, 2013, 09:56:47 PM
I'd be surprised if Bitcoin would not soon become the medium of transport for in-game perks and currency from one game to the other.
345  Bitcoin / Development & Technical Discussion / Re: BIP38 code in Java available on: November 27, 2013, 11:57:52 AM
Thanks for updating the link, yes it moved.
346  Bitcoin / Development & Technical Discussion / Re: SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data on: November 22, 2013, 12:31:59 PM
The script subsystem only requires the tx you are signing.

Not really. To create a valid signature you have to hash in the output script of the transaction outputs you are spending. Assuming you sign with the right key, you could even imply those output scripts without retrieving them. You can't responsibly do that know since you would not know the amount spent consequently the fee you spend.

Having the source transaction on hand helps and you can easily verify if it is the right source transaction by rehasing it and comparing the hash to the source in the transaction you sign. The source transaction can however be arbitrary large with outputs you do not care this is a problem for memory constrained hardware devices. In addition it means you need source transaction for offline (cold-wallet) signing.

The burden of retrieving the source transaction could be eliminated if the to be signed hash would contain the assumption on the output value you spend. Is the assumption correct, then you can create a valid transaction without seeing the input, no harm done if not, the signed transaction is just invalid.
347  Bitcoin / Development & Technical Discussion / Re: SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data on: November 22, 2013, 12:08:50 PM
The problem is not that it might sign an invalid transaction but that it signs a *valid* one which outputs say 1 BTC but includes a 99 BTC fee (assuming the UTXO was 100 BTC).

The offline device can show you that 1 BTC is going to be output but it cannot tell you anything about the change if it doesn't have the relevant information (which I believe that the Trezor doesn't have).

Or have I missed something obvious here?

You missed that the transaction hash contains the output value therefore Trezor can rehash the input transaction presented to check that its hash that is in the input.

So the approach is secure but expensive since you need the entire source transaction for the re-hash instead of just the value the output(s) the transaction spends. The source transaction might be arbitrarily large having lots of outputs that do not play any role in the to be signed transaction.

With this proposal the signing device would only need to know the value of the previous output, since even the output script could be implied by the key the device uses to sign. The signature and therefore the transaction would then be either valid with correct fee or invalid entirely.
348  Bitcoin / Development & Technical Discussion / Re: SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data on: November 21, 2013, 04:12:49 PM
Sorry but I don't think this is worth hard forking Bitcoin over. For validating a signature we currently need only the input (if it's signed). This change increases the number of dependencies for signature checking code. Namely Bitcoin validation nodes now need to fetch the previous output. This could seriously complicate the design and functionality of Bitcoin nodes if widely used. It is a good idea, but there are many ways to improve Bitcoin. I'm not sure Bitcoin is made for these things and should stay more simple and focused (like UNIX vs the other operating systems).

http://www.gwern.net/Bitcoin%20is%20Worse%20is%20Better?2

Bitcoin works because it doesn't try to do much. If we want to maintain a decentralised and open Bitcoin, I think it's a bit of a slippery slope to throw every feature we get excited about into Bitcoin.
In contrary, the current situation forces the wallet to know the previous input, especially its value.

The proposal does not require to fetch previous input for signature but to have an opinion on the value of the previous input. If that opinion is wrong the transaction will be rejected and therefore avoided that a value incorrectly assumed goes to the miner.
349  Bitcoin / Development & Technical Discussion / Re: SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data on: November 21, 2013, 03:25:40 PM
For reference, I specifically recall retep talking to Gavin about it on IRC shortly after his last post, and Gavin agreed that modifying the SIGHASH system was a bad idea.  I didn't feel like pressing it, at the time, though.

That's not to say that this can't be done or that Gavin and the other devs aren't persuadable.  But it would mean mobilizing support for it and presenting a strong case to those that are against it.  If the system was built with feature from the start, we'd all be happy and no one would have an issue with it.  It's more about convincing folks that the benefit is worth the trouble of making the change.  As you said... the people who most strongly support this are the ones actually developing software that has to deal with the megabytes of supporting transactions just to verify a few bytes.

You'll have more luck pushing for this by developing a multisig wallet implementation and getting people to actually use it first - P2SH required a painful soft-fork yet years later it's still hardly ever used, making people question the value of new features. P2SH was something that everyone was supposed to be using by now because of the "obvious" security need; you're proposed reason for a soft-fork and associated system-wide risk is significantly more niche.


Bits of Proof is launching a JV product that uses P2SH before end of this year. Can't tell more yet.

In addition it also facilitates ticket sales for the btc1k party in Frankfurt am Main for which the vault will also use P2SH.
350  Bitcoin / Development & Technical Discussion / Re: SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data on: November 20, 2013, 07:15:26 AM
The consensus seems to be that no one thinks it's worth doing this.  I still think it makes sense to do as one of those latent upgrades that goes in now but isn't active until 12 months from now.   But as you can see from the discussion some people are very focused on overhauling the SIGHASH system entirely, and don't think it's worth the effort to do this small change.  I disagree, but what can I do?
The consensus unlikely includes those developing wallets. It is the single most dangerous "feature" I came across while implementing Bitcoin that one is not able to validate the fee of a transaction on its own but need to retrieve its referenced predecessors. We should do this.
351  Bitcoin / Development & Technical Discussion / Identity assertions with Bitcoin instead of CA in Payment Protocol? on: November 04, 2013, 07:58:45 AM
https://eprint.iacr.org/2013/622.pdf

The authors of the paper claim in the abstract:

Quote
In this work we propose a novel anonymous credential scheme that eliminates the need for a trusted
credential issuer. Our approach builds on recent results in the area of electronic cash and uses techniques |
such as the calculation of a distributed transaction ledger | that are currently in widespread deployment
in the Bitcoin payment system. Using this decentralized ledger and standard cryptographic primitives,
we propose and provide a proof of security for a basic anonymous credential system that allows users to
make exible identity assertions with strong privacy guarantees. Finally, we discuss a number of practical
applications for our techniques, including resource management in ad hoc networks and prevention of
Sybil attacks. We implement our scheme and measure its eciency.

If that holds shouldn't Payment Protocol's use of CA be revisited?
352  Bitcoin / Development & Technical Discussion / Re: Incremental chain download using SPV proofs? on: November 02, 2013, 05:32:47 PM
It would be useful for applications that care of the origin e.g. colored coins.
353  Bitcoin / Development & Technical Discussion / Incremental chain download using SPV proofs? on: November 02, 2013, 05:21:48 PM
What do you think of a protocol extension for SPV style chain download of the subset relevant for one's wallet?

A node would query SPV style proofs for transaction inputs relevant to it until proofs reach coin bases or verified by previous proofs.
354  Bitcoin / Development & Technical Discussion / Re: O(2^80) theoretical attack on P2SH on: November 02, 2013, 04:44:45 PM
I see, I missed that this works if the attacker can choose the original script.
355  Bitcoin / Development & Technical Discussion / Re: O(2^80) theoretical attack on P2SH on: November 02, 2013, 04:02:56 PM
 That can be done in work O(2^80) (and massive storage), or various time memory tradeoffs with lower storage and more work.

While work might become feasible, a successful attack on P2SH needs more than a collision: an alternate script valid and redeemable by the attacker.


The attacker uses a 1-of-N multisig redeemScript where the first public key is legitimately his and the other keys (up to 130 bytes) are what he keeps twiddling until he finds a collision.
How is this easier than mining private keys that lead to public key hash (aka. an address) of pay to address transaction?
356  Bitcoin / Development & Technical Discussion / Re: Transactions with only one possible next address? on: November 02, 2013, 03:10:30 PM
nlocktime is usable and could be utilized to create an offsetting transaction in advance.
It would be a similar scheme thane implemented in bitcoinj micropayment channel:

https://bitcointalk.org/index.php?topic=244656.msg2593783#msg2593783
357  Bitcoin / Development & Technical Discussion / Re: O(2^80) theoretical attack on P2SH on: November 02, 2013, 03:04:17 PM
  That can be done in work O(2^80) (and massive storage), or various time memory tradeoffs with lower storage and more work.

While work might become feasible, a successful attack on P2SH needs more than a collision: an alternate script valid and redeemable by the attacker.
358  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 25, 2013, 12:09:47 PM
If you've gone all the way to implement a bitcoin client, which is an impressive feat, adding the payment protocol functionality is easy and relatively well documented and easily testable.

I did not re-implement a "bitcoin client" but a protocol server facing P2P and other modules that connect to the protocol server using its message bus.

Those modules implement wallets, exchanges, a payment processor and more to come. The payment protocol is a puzzle that will fit into some modules or be implemented as part of specific business processes.

I would eventually replace my protocol server with the reference client if it was moving into a direction of being extensible instead of embedding yet an other proof of a concept. I agree with the concept but not the implementation and the priority it enjoys.
359  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 25, 2013, 07:43:00 AM
It makes sense to roll this into the Bitcoin-QT client (in fact, it would be totally awesome if all bitcoin clients were to support it).

Would it not be easier to achieve wide support by implementing the payment protocol self contained, so it can be connected to other wallet implementations?

I know, bitcoin-qt does not currently have interfaces to allow such loose coupling, but should that be the excuse to embed yet an other complex protocol instead of implementing a better interface?

We do suffer under a monolithic reference implementation and this extension, if added as usual, compounds the problem.
360  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 25, 2013, 07:23:56 AM
I wish for a proof of concept implementation of the payment protocol that is a separate build artifact from the protocol server and ask if this was considered and if why rejected?

https://github.com/gavinandresen/paymentrequest


Should give you everything you need to get up and running. I recall that Gavin also had a test page up and running somewhere, but I can't seem to find it right now.


This is great, but why is it planned to be closely coupled and embedded with the code base of bitcoin-qt in 0.9 ?
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 [18] 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!