I've always assumed honeypots were meant to look like regular, yet
poorly-secured, assets. If the intruder could identify this as a honeypot
by the strange setup (presigned, non-standard transactions lying around)
and was aware that the creator intended to doublespend as soon as the
transaction was
Adding witness data to a non-segwit script is invalid by consensus:
https://github.com/bitcoin/bitcoin/blob/d612837814020ae832499d18e6ee5eb919a87907/src/script/interpreter.cpp#L1467
This PR will detect such violation early and ban the peer:
https://github.com/bitcoin/bitcoin/pull/8499
Another
On Wed, Aug 24, 2016 at 11:03 PM, Chris Priest via bitcoin-dev
wrote:
> How does your system prevent against insider attacks? How do you know
> the money is stolen by someone who compromised server #4, and not
> stolen by the person who set up server #4? It is my understanding
> these days most at
How does your system prevent against insider attacks? How do you know
the money is stolen by someone who compromised server #4, and not
stolen by the person who set up server #4? It is my understanding
these days most attacks are inside jobs.
On 8/24/16, Peter Todd via bitcoin-dev
wrote:
> On Thu
In a previous thread ("New BIP: Dealing with OP_IF and OP_NOTIF
malleability in P2WSH") it was briefly discussed what happens if someone
modifies segwit data during transmission. I think the discussion should
continue.
What worries me is what happens with non-segwit transactions after segwit
is ac
On Thu, Aug 25, 2016 at 01:37:34AM +1000, Matthew Roberts wrote:
> Really nice idea. So its like a smart contract that incentivizes
> publication that a server has been hacked? I also really like how the
> funding has been handled -- with all the coins stored in the same address
> and then each ser
On Wed, Aug 24, 2016 at 04:29:19PM +, Jimmy wrote:
> Is this unrelated to Bitcoin Vigil idea published in 2014?
>
> http://www.coindesk.com/bitcoin-vigil-program-guards-against-intrusion-coin-theft/
I think it's very related; to be absolutely clear the idea of a Bitcoin
honeypot is 100% not m
On Wednesday, August 24, 2016 1:47:08 PM Andreas Schildbach via bitcoin-dev
wrote:
> FWIW, BIP44 also doesn't encode a seed birthday. This needed so that SPV
> wallets do not need to scan from the beginning of the blockchain.
>
> That doesn't mean BIP44 could not be final. There are some wallets
Is this unrelated to Bitcoin Vigil idea published in 2014?
http://www.coindesk.com/bitcoin-vigil-program-guards-against-intrusion-coin-theft/
On Wed, Aug 24, 2016 at 8:42 AM Matthew Roberts via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Really nice idea. So its like a smar
Really nice idea. So its like a smart contract that incentivizes
publication that a server has been hacked? I also really like how the
funding has been handled -- with all the coins stored in the same address
and then each server associated with a unique signature. That way, you
don't have to split
I want to pitch a use-case that might have been ignored in this discussion:
I don't think this protocol is only useful for hardware wallets.
Technically any website that wants to request public keys/signatures and
offload the responsibility for managing keys and signing to the user
would also find
On 24.08.2016 16:18, Jonas Schnelli via bitcoin-dev wrote:
>
> Another thing that I think could be a BIP misdesign:
>
> BIP44 Gap Limits
> From the BIP:
>
> --
> "Address gap limit is currently set to 20. If the software hits 20
> unused addresses in a row, it expects there are no used
Hi
> 6 - Finally, and most importantly, BIP39 seed phrases do not have a
> version number. Without a version number, how are you going to derive
> addresses from a BIP39 seed phrase, when wallets start to use to new
> derivation methods (such as SegWit, or Schnorr signatures)? Does it mean
> that
FWIW, BIP44 also doesn't encode a seed birthday. This needed so that SPV
wallets do not need to scan from the beginning of the blockchain.
That doesn't mean BIP44 could not be final. There are some wallets that
interoperate on that standard and that's fine. The whole reason I
insisted on separatin
Le 23/08/2016 à 22:12, Luke Dashjr via bitcoin-dev a écrit :
> BIP 39: Mnemonic code for generating deterministic keys
> - Used by many wallets and hundreds of thousands of users.
>
> BIP 44: Multi-Account Hierarchy for Deterministic Wallets
> - Appears to be implemented by multiple wallets.
>
I
On Tue, Aug 23, 2016 at 8:54 PM, Kenneth Heutmaker via bitcoin-dev
wrote:
> SPV is kinda broken if the wallet doesn’t do this detection. If your wallet
> connects only to nodes that don’t support bloom filtering, the wallet never
> gets updates. We have had a spike in users reporting that their
>> Additionally, BIP 111 (NODE_BLOOM service bit) has been implemented in
>> Bitcoin
>> Core and derivatives; it is unclear if used by clients yet. Can developers of
>> such clients please comment and let me know: 1) if their software supports
>> this BIP already; 2) if not, do they intend to supp
17 matches
Mail list logo
