Maciej Trebacz [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-08-22 to 2014-04-06
💬 Posted a total of 3 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:17:25

- reply

📅 Original date posted:2014-04-06
📝 Original message:So, OP_RETURN is here and there is no coming back. So if we have it, it
would be nice to actually make use of it in a good way. I would like to
write a process BIP with a proposal for standardizing OP_RETURN
transactions for better interoperability between services. Right now there
are no guidelines for crafting these transactions, so everyone just does
what he believes is good for him.
What I would propose is a common, extensible protocol that can be used by
anyone. The generic format would be like this:
OP_RETURN OP_PUSHDATA[length] {2-byte message type} {data}
So basically, we would have a list of message types, that can be then
parsed by everyone because the format is open. It could go like this:
MSG Type | Parameters | Description
00 00 | unknown | Unused type, use it if you don't want to share your
message format with others
00 01 | none | Proof of burn transaction. Use it if you want to effectively
destroy coins (by sending it all as fees to miners)
...
And so on. I have few more ideas for these kind of messages, but it will
only work if we try to make it an open standard, hence the BIP idea. Can I
expect that it will be included with other BIPs if I write it?
--
Best regards,
Maciej Trębacz - Bitalo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140406/ea43f13d/attachment.html>

2023-06-07 15:06:29

- reply

📅 Original date posted:2013-08-23
📝 Original message:As far as I know current Bitcoin protocol doesn't let you to include any
arbitrary data with the transactions (as it would become non-standard and
clients would not relay it). So if you have multiple addresses you can't
sign them with a single private key and include that signature in the
transaction so other party can verify it against your public key. This
could become very handy though - a reputable wallet service could issue
transactions that require zero confirmations from the other party,
because with the added signature they know that the transaction is from
this reputable service and they trust that this service won't try to double
spend. I'm thinking of something like Mt.Gox's "green address", but baked
into protocol (Mt.Gox does this by sending your funds to some known by the
others Bitcoin address and then relaying them to the final destination).
Do you think it's possible/feasible to add a feature like this to the
current protocol without forking the chain? This could be as simple as
adding support for following scripts:
<data block> OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECK
<data block> OP_DROP OP_HASH160 <pubKeyHash> OP_EQUAL
The <data block> should not be longer than 34 bytes (or more, depending if
we want to have some room for future use cases). This is all that needs to
be changed in the Bitcoin client. Now for actually using the feature a
further definition of <data block> is required:
22 AC 20 <32 byte signature>
22 is data block length and "AC 20" is just a sub-opcode that can be either
defined by the protocol (in this case I'm reusing OP_CHECKSIG's opcode but
that's not required since this is all part of data block) or just agreed
upon between people that want to use this feature.
It's possible that the above could be achieved in some simpler way using
other opcodes or mechanisms present in Bitcoin protocol that I'm not aware
of. Either way, I'd like to hear your opinions whether a feature like this
should be considered and added.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130823/28949a48/attachment.html>

2023-06-07 15:06:25

- reply

📅 Original date posted:2013-08-22
📝 Original message:Will removing "getwork" from the client impact the "setgenerate" RPC call?
I.e. would you still be able to generate coins on testnet-in-a-box this
way, or would you need a dedicated miner for that? testnet-in-a-box is very
useful for testing and easy to setup, it would be great if it stays that
way :).
On Wed, Aug 21, 2013 at 11:39 PM, <rob.golding at astutium.com> wrote:
> > It appears that we will soon be at a hashrate where all the desktop
> > CPUs in the world couldn't really make a dent in it... certainly not
> > desktop cpus using the slow integrated cpu miner,
>
> I thought the integrated miner was retired a version or so ago - I
> dontrecall seeing it for some time in bitcoin-qt
>
> Now you can buy a USB stick for $20 which can be pushed to around
> 500MH/s, and there's no reason the manufacturers couldn't ship those
> with a miner-program onboard !
>
> Rob
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130822/988a3ab0/attachment.html>